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

Dear Derek,

Thank you for reminding the origin of the discussion.

Regards,
mpsuzuki

On 2024/06/08 5:27, Derek B. Noonburg wrote:
> 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.
>>>
>>>
>>>
>>>    
>>
> 
>