[gs-devel] Using OpenType (CFF-flavour) fonts
graham.douglas at readytext.co.uk
Mon Dec 13 18:59:27 UTC 2010
Just got home from work and read your reply. Many, many
thanks for taking time to reply in so much detail, it is
genuinely much appreciated. I will read through to digest
Very best wishes
> Hi Graham,
> apologies if some of the following is too simplistic, I'm just trying to
> cover everything and I'm not certain where to pitch it. Please just skip
> over anything which is too simple.
> At 15:20 12/12/2010 +0000, Graham Douglas wrote:
>> I would like to use some OpenType (CFF-flavour) fonts at my disposal
>> but need to understand a little more about the process, especially
>> accessing some of the glyphs which do not have designated
>> Unicode code points --- such as small caps and oldstyle numbers, I
>> because they are just design variations as opposed to being "real
>> characters" of a language.
> Its not clear to me what you mean by 'use' the fonts. The easiest way to
> use them is to have the application embed the TrueType fonts as type 42
> fonts in the PostScript program. But then I'm not sure how you are using
> GS, possibly not by sending PostScript ?
> If you want to use them as replacements for some other font requested
> PostScript program then there is the possibility that this will not
> expected, as this is a Ghostscript extension, not present in the
> specification, so there are no rules on how it should work.
> Unicode is not really relevant to PostScript, or in many ways to
> fonts. TrueType glyphs are accessed by Glyph ID (GID), the font *may* or
> may not contain a Unicode CMAP table which maps Unicode code points to
> glyph IDs, but since PostScript doesn't use Unicode this isn't terribly
> PostScript uses a 'character code' which for simple fonts is a single
> index into an Encoding array, the array contains a glyph name for each
> entry. The glyph programs are contained in a PostScript dictionary, and
> referenced by name. So the character code is looked up in the
> get a name, then the name is looked up in the CharStrings dictionary
> a program, which is then executed.
> As you can see there is no Unicode in the PostScript at all. Note that
> Encoding arrays are 256 entries, so referenced by a single byte.
> PostScript also includes type 0 fonts (Original Composite Fonts) and
> CIDFonts, both of which are potentially referenced using multiple
> the character code. It is possible to apply a Unicode CMap (that's
> TrueType CMAP table, but a PostScript construct which is quite
> to a CIDFont which will allow you to access the glyphs using Unicode
> However, that's rather co-incidental, just as its possible to
> regular Encoding which uses ASCII values to map to the named glyphs
> represent each of the ASCII code points. The PostScript interpreter
> knows nor cares.
> In general TrueType fonts in PostScript are handled by conversion to
> 42 fonts, or CIDFonts with type 42 outlines. For OpenType fonts with CFF
> outlines its also possible to convert into CFF fonts, or CIDFonts
> outlines. This is normally done by the creating application and the font
> embedded into the PostScript stream.
> Now in addition to all that, Ghsostcript can use TrueType font
> mentioned this is a non-standard extension, PostScript does not handle
> TrueType fonts). Ths can be done in two ways, either as a regular
> as a CIDFont, depending on whether you load the font in Fontmap.GS or
> When loaded as a regular font GS will attempt to use the CMAP and POST
> subtables in the TrueType font to build a reasonable Encoding for the
> If I remember correctly we prefer the 3,1 CMAP subtable for this. I'm
> certain what happens if that subtable is not present. The Encoding is
> to map the character code to a name, then on to a GID which is used to
> access the glyph.
> When loaded as a CIDFont things are of course somewhat more complicated.
> You don't normally use a CIDFont 'as-is', the only operation which works
> with a naked CIDFont is glyphshow, in this case it takes a CID rather
> a name. Normally the CIDFont is composed with a CMap in order to
> CID-keyed instance of the font. This maps a character code to a CID and
> things proceed more or less as for a regular font. The difference is
> the character code can consist of more than one byte (indeed can be of
> variable length).
> But we can't access a TrueType font using a CID, so we need to map the
> character code to a CID, then map the CID to a GID so that we can access
> the glyphs in the font. This is complicated, and obviously somewhat
> to error, since we are trying to replace a PostScript font with a
> non-PostScript font. There's quite a bit of internal jiggery-pokery
> involved with the various TrueType tables, and CIDSystemInfo
> try and build the two step mapping we need for this.
> However, the simplest way to use it is to declare the CIDFont as
> Identity CIDSystemInfo and then compose that CIDFont with an Identity
> Then you can use the GID as the character code. This effectively
> as a one-to-one mapping so that the character code ends up as the GID
> to access the glyph from the font. Since you can get the GID, this
> the easiest way to work.
> Eg in cidfmap:
> /TimesNewRoman << /CSI [(Identity) 0] /Path (c:/windows/fonts/times.ttf)
> /SubfontID 0 /FileType /TrueType >> ;
> Note that we've used the 'Identity' Ordering in the CIDSystemInfo (CSI).
> Then to use the font :
> /TimesNewRoman-Identity-H findfont
> Note that this uses the CIDFont 'TimesnewRoman' and the CMap
> if GS can't find a named font then one of the things it will do is
> identify a CIDFont-CMap combination. If it thinks there is a possible
> combination then it will see if there are appropriately named CIDFont
> CMap available. If so, then it will automatically compose the two
> to produce the CID-keyed instance for you.
>> Where I'm kinda lost is making the "bridge" between all that
>> font info and the PostScript machinery/code I need to write in order to
>> access all the glyphs in the font, especially the small caps and
>> numbers. I know you can use glyphshow to draw any glyph in the
>> CharStrings dictionary, encoded or not, but that seems a complicated
>> way to go about things, maybe --- perhaps not?
> I'm not absolutely certain (I'd have to go and read the code), but I
> think this will work with a TrueType font loaded as a PostScript
> way that the font is loaded I'm not certain that glyphs which are not
> present in the Encoding have any way to map the name to a GID. Since you
> can't access TrueType glyphs by name, that would mean you can't use
> un-encoded glyphs.
>> So, in summary, what else do I need to read or
>> understand to fully utilise OpenType CFF-flavour
>> fonts with GS in order to access all the various
>> glyphs in the font.
> Ideally you should read the font yourself, convert into a type 42, or
> CIDFont with type 42 outlines, and embed the font in the PostScript
> This is probably the only 100% reliable method.
>> --- Is it a matter of reencoding the font?
>> --- Or, is the CIDFont machinery something that
>> I need to understand?
> It may be that loading the font with an Identity-H CMap (and
> with Identity Ordering in CIDSystemInfo in cidfmap) would be the easiest
> way for you to proceed, though this does require that you know the
> the glyphs you want to use.
>> Is CIDFont machinery relevant to this situation
>> --- I have the Adobe specs but not yet fully
>> read or absorbed them.
> I doubt that you really want to use the full power of the CIDFont and
> mechanism. That would be more appropriate if you were going to embed the
> font as a CIDFont, especially if you wanted to access more than 256
> That mechanism is really present for languages which need more than 256
> glyphs at a time (eg Chinese, Japanese, Korean, Vietnamese), though
> Adobe products make extensive use of it even for Latin fonts.
> gs-devel mailing list
> gs-devel at ghostscript.com
> End of gs-devel Digest, Vol 13, Issue 5
More information about the gs-devel