I just wanted to clarify that I'm not actually requesting anything. The email that started this thread was from Honnesh Ramachandra, who suggested a patch.
My use of FreeType (in Xpdf) is very specific to PDF. In particular, PDF files specify a bunch of extra encoding information outside of the embedded font, so in some cases the OpenType cmap table is not used. My point here is that I already have a lot of code that checks for various situations with the PDF encoding info, missing tables in fonts, etc., and it's PDF-specific, so not anything that I would expect FreeType to fix. I've never encountered an OpenType font with head and CFF tables, but without a cmap table. If it comes up, I don't think it would be too hard to extend my code to check for that case and extract the CFF font (since I'm already checking for a missing head table). In any case, I'll be happy to help with PDF construction/manipulation -- just let me know if you need anything. - Derek On Fri, 7 Jun 2024 11:06:58 +0900 suzuki toshiya <[email protected]> wrote: > Dear Adam, Derek, > > Adam, thank you for reminding that SFNT-wrapped PostScript fonts > on Apple platforms, it sounds reasonable attitude to handle such > incorrectly(?) embedded CFF font. > > Derek, my understanding of current situation is: > > 1) currently FreeType simply raises an error for "head + CFF" > stream without special information. Even if a FreeType client > is capable to process such stream, the client has to catch all > errors and re-investigate the content of the stream. It is > "duplicating" of the font parsing. > > 2) the option best for the PDF rendering is "dealing with > head + CFF stream as simple CFF stream, ignoring head table". > > 3) another option better than current is "raising special > error indicating 'CFF is included, but other essential > tables for CFF OpenType are missing' and let the FreeType > client decide how deal such special case. > > Is it correct? > > I would try to make an artificial example by adding "head" > table to its internal CFF streams, to investigate how existing > PDF viewers handle such. I would ask how such PDF set the > font descriptor metadata to "head + CFF" stream in later. > > I'm quite sorry for that I'm too busy to recover my PDF > playground in this month, I hope this issue is not immediate > to be resolved within a few days. > > Regards, > mpsuzuki > > On 2024/06/06 4:40, Adam Twardoch (List) wrote: > > > > > > My own focus is on PDF files. The PDF spec says that fonts declared > > as OpenType should be OpenType, and the files I'm looking at > > violate the spec. (PDF also supports standalone CFF fonts, so it's > > relatively little extra work for me to pull the CFF blob out of > > these bogus "OpenType" fonts, and handle it as a CFF font.) > > > > Oh yes, you're right there. However, this is a very general > > problem. Even though OpenType is a Microsoft trademark, Microsoft > > had done a very poor job in explaining/defining what is and what > > ISN'T an "OpenType font". > > > > Windows had been announcing OpenType fonts with a glyf table but > > without a DSIG table as "TrueType" for many years, even though > > TrueType is an Apple trademark. So many end-users for a long time > > associated CFF-based OpenType with "OpenType". > > > > And PDF has its own notion of font format "branding", and then > > there's a question of how certain apps like Acrobat present these. > > > > I lost count of the different variants of fonts that "can exist" in > > a PDF a log time ago. I guess a Type42 with a variable CFF2 table > > is also theoretically possible :) Or with just CBDT, without glyf > > and CFFx. > > > > One thing for sure: on "desktop", certain fonts work out they > > don't, but they need to be kind of "complete". But PDF has this > > flurry of "partial font resources" which makes it extra-complex. > > > > A. > > > > > > > > >
