Feature Requests item #4295, was opened at 2009-10-05 14:22 Status: Open Priority: 3 Submitted By: Lars Hellström (lars_h) Assigned to: Nobody (None) Summary: CIDFonts, raw font embedding Category: Fonts Group: v1.50 Resolution: None Initial Comment: As posted to the pdftex mailing list in September 2009: A while ago, I started examining new ways of using OpenType fonts with TeX, focusing in particular on catering for fonts that have many ligatures or alternate glyphs. I expect I'll end up creating some new tool for converting fonts to TeX-usable format, but would prefer to make do with existing backends (in particular dvips and pdfTeX) as far as possible. One of my early hypotheses, which so far has held beautifly, is that OpenType fonts are best served by being treated as CIDFonts. This is particularly clear for the combination of TrueType font and PDF, since the support in PDF (the standard) for simple TrueType fonts can at best be described as a kludge, whereas the composite font (i.e., CIDFont) counterpart provides clean control of e.g. the encoding. CIDFonts don't seem to have been much used by us TeXies, though (presumably because they were introduced to deal with CJK fonts, and their documentation is geared towards suggesting such usage). Getting dvips to map a TeX font onto a (PS type 0 font mapping to) a CIDFont is merely a matter of giving it a file with "the font" in a suitable PS wrapper, and as of today I have a couple of procedures that will generate such a wrapper for an arbitrary TrueType font.[*] Unfortunately, pdfTeX doesn't seem so easily instructed. I know what data structure should appear in the finished PDF file, but there doesn't seem to be a way of making pdfTeX put it there -- at least not (a) according to the manual (though that may be incomplete; e.g. I've noticed some mechanisms for interpreting encoding vector glyph names that exist in the source but aren't mentioned in the manual) and (b) from within the map file. Using \pdffontattr I suppose it is possible to construct a pretty arbitrary font dictionary from within TeX code, but that doesn't seem to be able to get at the base fonts of a virtual font, which would really be all that the CIDFonts should be. Moreover I'd prefer it if the font set-up could be accomplished without pdfTeX-specific TeX commands, as that is hard to integrate with LaTeX's NFSS. So therefore I would like to request a new pdfTeX feature, to the end of allowing a mapfile to specify that an arbitrary PDF data structure should be used as the font dictionary corresponding to a specific TeX font. Now, the most practical way of encoding a PDF data structure for embedding is of course to provide it within another PDF file; I understand pdfTeX already has the machinery to copy a PDF object (and everything it references) from another PDF file, so this shouldn't be difficult to implement.[**] Concerning the interface, my suggestion would be the following: * If the <fontfile> in a mapline has suffix .pdf, then the wanted font dictionary can be found in its Catalog/Pages/Resources/Fonts dictionary, i.e., among the fonts in the Resources dictionary of the root node in the pages tree of that file. The <basename> of the mapline is then the key within the Resources/Fonts dictionary of the selected font. For nice appearance, one could structure such "font container" PDF files to be demonstrations of the glyphs in the font(s), maybe even with instructions for how to configure pdfTeX to use them... Lars Hellström [*] The same principles should apply for CFF fonts, but in that case one has to cut a bit deeper when performing some necessary surgery, so I'm leaving those for later. The PS wrapper is simpler in that case than for TrueType, though. [**] Not difficult, unless one insists on subsetting the fonts. For the moment I'm perfectly happy with getting the font embedded in full, since that is /way/ better than not being able to use it at all. Subsetting can always be added later, if anyone cares enough to implement it. To the above, Thanh replied by off-list email: what you suggested should be very doable and I am interested in getting it done, too. However I am overloaded at the moment; can we come back to this issue in about 2 months? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=4295&group_id=106