From: Eric Muller (email@example.com)
Date: Mon May 02 2005 - 16:40:07 CDT
Rick Cameron wrote:
>Thanks for the explanation. As you say, it's unfortunate that the PDF
>spec uses misleading terminology for these concepts.
There is a good excuse: a fair amount of the PDF terminology comes from
the PostScript world, which originated before 1985. While work on
Unicode and the character/glyph model was certainly underway, it was
also far from being the lingua franca.
>I seem to recall that the fonts used in a PDF file are restricted in the
>number of glyphs they can have. IIRC the limit is 256. Thus, when our
>app produces PDF files it has to split a large font into several derived
>fonts, and make mappings from Unicode code points to glyph indices in
>these derived fonts.
Short answer: it is possible to have fonts with large glyph complements
Long answer: PDF provides multiple (too many?) mechanisms, known as font
encodings, to go from the "character codes" to actual glyphs in fonts.
Some of those (simple fonts, PDF spec section 5.5) are applicable only
when the possible range of character codes is limited to [0 ... 255].
Others (composite fonts, PDF spec section 5.6) are applicable to
character codes in the range [0 ... 0xffff].
>It would be far more convenient if it were possible to use Unicode code
>points as glyph indices.
>Has this situation changed?
Philippe expressed consisely what I was trying to say: "the PDF document
is a *rendered* document, so it needs to reference glyphs rather than
abstract characters." That's the nature of the beast.
If you have *character strings* in your hands and you want to generate a
PDF that renders those strings, you need a layout engine.
>If not, is it likely to change in the
Regardless of what I know or don't know about future products, I cannot
This archive was generated by hypermail 2.1.5 : Mon May 02 2005 - 17:59:53 CDT