Post #1808007

2026-03-08 11:39 UTC

@frankrolf @mathieureguer It has nothing to do with the embedding bit. It has everything to do with that text inside PDF is fundamentally a sequence of *glyphs*, not characters, and that embedding the original text (as a sequence of unicode characters) was added much later, and many PDF *producers* apparently don't even bother. So to be able to do *some* form of text copying from PDFs (that do *not* embed the original text), the glyph sequence is interpreted in an attempt to *recreate* the original text. To do this, standardized glyph names are fundamental. (John Hudson can explain better than me why this approach is absolutely hopeless for all but the most simple scripts such as Latin.) So: *all* PDF viewers (that allow people to copy text) do this.

Replies (2)

@justvanrossum@typo.social 2026-03-08 11:41

@frankrolf @mathieureguer But other than that I agree that the glyph names should not matter in final fonts. In fact, they don't have to be there at all for TTF. Using a post format 3 table in TTF is a common size optimization strategy for CJK fonts.

Open ##1808008
@TiroTypeworks@typo.social 2026-03-09 15:23

@justvanrossum @frankrolf @mathieureguer You called? Specifically for Indic scripts, the order of glyphs does not correspond to the input character order, so glyph name parsing breaks down. In some scripts, ligatures are formed of elements that are not adjacent in the character string, so there is no way to name them within the Adobe glyph naming conventions that can parsed back to the original text in the way that e.g. /f_h can be in a Latin font. I think probably it would be possible to algorithmically reorder character codes parsed from glyph names in Indic fonts, but a) that would require very clear additional rules about naming various kinds of Indic glyphs, and b) a lot more work by PDF viewers.

Open ##1808010