Re: Bug report: Allow CFF based OT fonts with missing map table

[Derek B. Noonburg]

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 <mpsuzuki@hiroshima-u.ac.jp> 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.
> > 
> > 
> > 
> >   
>