I've often wondered whether the inability of earlier versions of Windows Office to produce the kind of English text that causes pdf searchability problems is a major reason that these potential problems have not attracted more attention.
Per the Apple TrueType Specification of 1990, the CMAP Character Map can as input take more than 256 character codes, but per the Adobe Type 42 Specification the CMAP tag is stripped and the GLYF tag is subset into arrays of maximum 256. Thus when multilingual characters are used non-contiguously, what was one simple font may become multiple Type 42 fonts, and if the supplements to the TrueType Specification for presentation forms are added, then the complications for inversion from imageable composition back to character information increase.
There are three ways TrueType splines may be represented in PostScript, either they may be converted to bitmaps, or they may be converted to Type 1 (which was the case in initial versions of OS X), or they may be converted to Type 42. Adobe didn't make matters much better by implementing the PSPrinter so that if the application asked for fake bold, PSPrinter multiplied the spline with small offsets to simulate bold which in turn caused problems for search support. Another set of problems arise as the character input is inferred from glyph names and glyph positioning, that is, if one implemented a format 1 state-based kerning table for TrueType 2 for proper spacing per Jan Tschichold's specifications for post-war Penguin typography, for example, then these might appear to Acrobat's algorithms as word spaces rather than as spaces within words. Shlomo Perets has discussed these algorithmic inference problems on PlanetPDF starting in 2000. With regard to problems with inversion in PDF for composition of complex scripts, these are discussed e.g. in the documentation for FontLab 5 by Adam Twardoch in 2005.
The problem is not whether the problem has been discussed, the problem is whether one reads the discussion of the problem 🙂.
/hh
