Using CFF (Type 1C) instead of Type 1 fonts
PDFs produced by pdftex can shrink significantly in size when processed through ghostscript's pdfwrite driver. I understand a main reason for that is that ghostscript converts any Type 1 fonts that it finds into CFF (aka Type 1C) fonts. I also understand that - Type 1 fonts are eexec-encrypted, and such ciphertext cannot benefit from PDF's (de)flate compression. - CFF fonts, on the other hand, are a compacter plain-text format and compress well. - CFF fonts are also compatible with Type1, i.e. it is possible to convert any Type 1 font into a CFF font without loss of information. Is all of this correct? If so, isn't the continued use of Type 1 fonts in the TeX ecosystem an anachronism? Shouldn't TeXLive ship instead CFF/Type 1C versions of the BlueSky Computer Modern fonts and shouldn't tools like pdftex switch to using them directly? Has someone looked into what would be involved with a Type 1 to CFF migration for pdftex? It seems at the moment, pdftex is actually replacing any Type 1C glyphs that it finds in a PDF file embedded with \pdfximage with the much less space-efficient Type 1 glyphs that it find in its font map files. Has there been any progress on this since: https://tex.stackexchange.com/questions/38145/why-does-pdflatex-produce-bigg... ? Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
On 2017-12-18 at 15:42:15 +0000, Markus Kuhn wrote:
PDFs produced by pdftex can shrink significantly in size when processed through ghostscript's pdfwrite driver.
I understand a main reason for that is that ghostscript converts any Type 1 fonts that it finds into CFF (aka Type 1C) fonts.
I also understand that
- Type 1 fonts are eexec-encrypted, and such ciphertext cannot benefit from PDF's (de)flate compression.
- CFF fonts, on the other hand, are a compacter plain-text format and compress well.
- CFF fonts are also compatible with Type1, i.e. it is possible to convert any Type 1 font into a CFF font without loss of information.
Is all of this correct?
Hi Markus, yes, but CFF doesn't compress plain-text. The keywords you see in a disassembled font are replaced by op-codes (small numbers) like 00 version 01 Notice 02 FullName 03 FamilyName 04 Weight 05 FontBBox Thus a CFF font is quite compact even before it's compressed.
If so, isn't the continued use of Type 1 fonts in the TeX ecosystem an anachronism?
Shouldn't TeXLive ship instead CFF/Type 1C versions of the BlueSky Computer Modern fonts and shouldn't tools like pdftex switch to using them directly?
TeX Live just provides what people upload to CTAN. It's not possible to modify any packages. Even if we could write a script which converts all Type 1 fonts to CFF, we still have to adapt the .map files. But this isn't enough, see below.
Has someone looked into what would be involved with a Type 1 to CFF migration for pdftex?
pdftex and dvips create subsets of fonts and thus have to understand the font format. AFAIK they only understand Type 1 and Type 3 and pdftex also understands TTF. In order to support CFF, pdftex and dvips (which fortunately share the same code for Type 1 subsetting) must be enabled to convert Type 1 to CFF on the fly. If such code already exists in dvipdfm, all we need is a volunteer who does the work.
It seems at the moment, pdftex is actually replacing any Type 1C glyphs that it finds in a PDF file embedded with \pdfximage with the much less space-efficient Type 1 glyphs that it find in its font map files.
I don't think that pdftex replaces glyphs. That would require that pdftex understands CFF. I assume that pdftex first determines whether a font with the same name exists within the TEXMF tree. If true, it drops the embedded font and creates a common subset of the glyphs used in the embedded file and the main document. But the actual glyphs come from the font found in the TEXMF tree. Markus, I'm glad that you asked. I'm convinced that Type 1 fonts can be converted to CFF on the fly reliably and that many people enjoy the smaller PDF files. I don't see any technical restrictions. We just need volunteers. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------
I don't think that pdftex replaces glyphs. That would require that pdftex understands CFF. I assume that pdftex first determines whether a font with the same name exists within the TEXMF tree. If true, it drops the embedded font and creates a common subset of the glyphs used in the embedded file and the main document. But the actual glyphs come from the font found in the TEXMF tree. replacing/merging glyphs is tricky ... i remember seeing bugged
On 12/19/2017 12:56 AM, Reinhard Kotucha wrote: presentations due to this fact (irr very old pdftex was able to do such things) for instance because lucida fonts were merged where the names were the same but the glyphs actually not (it all depends on where the embedded files come from) .. so, a merge would also involve checkign if the font programs (subrs for glyphs etc) are the same Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 12/19/2017 12:56 AM, Reinhard Kotucha wrote:
Markus, I'm glad that you asked. I'm convinced that Type 1 fonts can be converted to CFF on the fly reliably and that many people enjoy the smaller PDF files. I don't see any technical restrictions. We just need volunteers. Honestly, I don't care about an already large pdf being a few hundred k larger ... not in these days of 100 MB flac and 2 GB mp4 files, not to speak of crappy pictures being megapixels. On my machine the pdf's are not the large files.
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 19/12/17 15:15, Hans Hagen wrote:> On 12/19/2017 12:56 AM, Reinhard Kotucha wrote:
Markus, I'm glad that you asked. I'm convinced that Type 1 fonts can be converted to CFF on the fly reliably and that many people enjoy the smaller PDF files. I don't see any technical restrictions. We just need volunteers.
Honestly, I don't care about an already large pdf being a few hundred k larger ... not in these days of 100 MB flac and 2 GB mp4 files, not to speak of crappy pictures being megapixels. On my machine the pdf's are not the large files.
I maintain archives of thousands of PDFs (departmental technical reports, student project dissertations, PhD theses, etc.). Many of these files contain exactly the same font information, and for many of these documents, the embedded Type 1 fonts dominate the file size. Not exactly elegant. Another point in favour of CFF is that Adobe donated in 2013 to the FreeType project their high-quality Adobe CFF Engine hinter. That only parses the CFF format, not Type 1. Therefore, you may get today on many platforms (Android phones, tables, etc. all seem to use FreeType) better hinting if the fonts are CFF encoded, rather than Type 1. https://blog.typekit.com/2013/06/19/adobe-cff-font-rasterizer-accepted-by-fr... https://opensource.googleblog.com/2013/06/youve-got-cff.html https://opensource.googleblog.com/2013/05/got-cff.html https://sourceforge.net/projects/freetype/files/freetype2/2.4.12/ I guess, the first step towards encouraging better Type 1C font support in the TeX ecosystem would be to get CFF/Type 1C versions of e.g. the BaKoMa font files onto CTAN. (I'd prefer the font files to be distributed and loaded in CFF, rather than having them converted on the fly from an anachronistic and uselessly encrypted format each time. In other words: best eradicate Type 1 at the start of the processing pipeline.) Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
FWIW, I have nothing against CFF support in pdftex, but it's not something I can take on implementing myself. As for getting official CFF versions of the CM fonts, you'd have to talk to the AMS about that. I am doubtful it is something they would want to spend company time on, but maybe they would give their blessing for some other competent person to produce a CFF version. Maybe just running the fonts through fontforge is enough; I don't know. Although of course anyone can make CFF versions without anyone else's permission, I would be loath to change the CM fonts (in TeX Live) used in most TeX-produced documents without agreement by the AMS. --best, karl.
participants (4)
-
Hans Hagen -
Karl Berry -
Markus Kuhn -
Reinhard Kotucha