Re: [ft-devel] Unable to load OpenType font (test case + font attached)

[suzuki toshiya]

BTW, in my understanding, the font embedded by sfnt-container with
"OTTO" tag is introduced to use its cmap table, so, when
CFF is included and cmap is not, it should be taken as invalid font
(if we focus about PDF). If the PDF generator do not want to use
"cmap" in embedded CFF/OpenType, it should use conventional CID-keyed
font embedding with raw CFF format (without sfnt container).
If anybody knows a sample PDF that embeddes CFF/OpenType but its
cmap should not be used, please let me know.

Regards,
mpsuzuki

suzuki toshiya wrote:
> Here is a preliminary patch to permit a font WITHOUT essential tables,
> if its header declares CFF/OpenType (by OTTO tag) and CFF table is
> included.
> 
> This patch does not use cmap table, it uses the character-glyph mapping
> info (Encoding dict) in CFF table. It is NOT expected behaviour, because
> CID-keyed CFF font for CJK scripts has no Encoding dict. I have to work
> more about...
> 
> Regards,
> mpsuzuki
> 
> suzuki toshiya wrote:
>> Thank you for providing a sample.
>>
>> For first, please let me comment to your question "why". An OpenType
>> embedded in PDF should not be expected to be usable as a self standing
>> OpenType font. It is a component of PDF, and some essential information
>> are removed (because the identical or substitution information are
>> stored in the side of PDF). If you check OpenType specification,
>>      http://www.microsoft.com/typography/otspec/otff.htm#otttables
>> you will find that "head" is essential table and the font lacking it
>> is not an officially self-standing OpenType font. And, PDF has their
>> own convention how to transform/compress the OpenType font and PDF
>> spec does not request the embedded OpenType is conforming to OpenType
>> spec.
>>
>> # without "head" table, TrueType font parser cannot access the
>> # glyph program, because only the "head" table provides the info
>> # how to calculate the glyph program storage location from the
>> # glyph index. but in this case, "CFF" table is used, so it
>> # is not essential.
>>
>> Anyway, I understand FreeType is often expected to load the embedded
>> OpenType font data in PDF. And, your sample would not require complex
>> trick to load as self standing font; Your sample is a simple concatenation
>> of cmap table and CFF table. It would not be so difficult changing FreeType
>> to pass included CFF stream to CFF parser. But yet I'm not sure if
>> the cmap table content should be used (if it should be used, more work
>> is needed).
>>
>>
>>
>> Regards,
>> mpsuzuki
>>
>> Harry Roberts wrote:
>>> At sfnt/ttload.c:~280
>>>
>>> The font doesn't have the two expected tables (head, sing) - if I ignore
>>> that fact and return `SFNT_Err_Ok` from `check_table_dir` then the font
>>> loads fine and renders perfectly.
>>>
>>> Why does the FreeType TTF loader required these two headers when it works
>>> without them?
>>>
>>> ```
>>> 282:     FT_TRACE2(( "check_table_dir:" ));
>>> 283: #ifdef TT_CONFIG_OPTION_EMBEDDED_BITMAPS
>>> 284:       FT_TRACE2(( " neither `head', `bhed', nor `sing' table found\n"
>>> ));
>>> 285: #else
>>> 286:      FT_TRACE2(( " neither `head' nor `sing' table found\n" ));
>>> 287: #endif
>>> 288:      error = SFNT_Err_Table_Missing;
>>> ```
>>>
>>> On 7 November 2012 01:12, Harry Roberts <address@hidden> wrote:
>>>
>>>> Recently I have come across many fonts embedded within PDF files which
>>>> cannot be loaded by FreeType v2.4.10.
>>>>
>>>> I suspect Enfocus PitStop is mangling the fonts when the PDF file is
>>>> 'optimized'.
>>>>
>>>> Attached is the font file (extracted from a PDF) and test case.
>>>>
>>>> Adobe Acrobat and Photoshop are able to load the fonts. FontForge can also
>>>> open the font, and after 'Exporting to OpenType'  the test case is able to
>>>> load the font successfully.
>>>>
>>>> I am still trying to debug the problem, but my knowledge of FreeType and
>>>> font format internals is being stretched. Any insight would be appreciated.
>>>>
>>>> Regards,
>>>>  - Harry
>>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Freetype-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
>> _______________________________________________
>> Freetype-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel