Re: [ft-devel] Unable to load OpenType font (test case + font attached)
How did you extract the font that it came out in an SFNT container? I would not expect an SFNT given those /Font and /FontDescriptor objs. Is the pdf itself available? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
Hi, The font was extracted by dumping the stream with 'peepdf'. peepdf project: https://code.google.com/p/peepdf/ dumpstream patch: https://code.google.com/p/peepdf/issues/detail?id=6 The PDF is available at: http://derp.ltd.uk/borked-font.pdf Regards, - Harry On 11 November 2012 16:33, James Cloos cl...@jhcloos.com wrote: How did you extract the font that it came out in an SFNT container? I would not expect an SFNT given those /Font and /FontDescriptor objs. Is the pdf itself available? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
HR == Harry Roberts ha...@midnight-labs.org writes: HR The font was extracted by dumping the stream with 'peepdf'. HR The PDF is available at: http://derp.ltd.uk/borked-font.pdf I was curious whether the font was embedded into the sfnt by the extractor, but it was not. It already claims to be an OTTO in the pdf. But the pdf itself was create by pdftk(1), presumably from some other pdf. So now I wonder whether the font got mutilated in translation? (As it were.) Do you have the original pdf? If so, does the original pdf work? What software generated the original? Knowing from where it came might be instructive. Or might just be a rabbit hole. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
After some digging it seems it's Acrobat X 'Optimization' stage that's causing the problems, and *not* Enfocus Pitstop (my apologies there). Attached is another weird font file (ZDIWMH+BodoniXT' that even FontForge, Acrobat Reader 9.5 and Poppler 0.20.5 refuse to open. I have a feeling that the font isn't salvageable at all and both Poppler and Freetype are correct in not loading it, but any input would be welcome. CFF and cmap tables exist, but otfinfo reports: ``` otfinfo: 74.otf: bad major version number 0 ``` And `ttx` seems to have trouble getting glyph order. All other information from the PDF about that font, which appears to match the cmap section in the font file. ``` /Font (72) = /FirstChar 32 /Widths [ 250 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 667 0 0 0 667 0 722 0 0 0 0 0 833 0 0 0 0 722 556 667 ] /Encoding /WinAnsiEncoding /Type /Font /BaseFont /ZDIWMH+BodoniXT /LastChar 84 /FontDescriptor 73 0 R /Subtype /Type1 ``` ``` /FontDescriptor (73) = /FontBBox [ -168 -251 1000 940 ] /StemV 108 /FontStretch /Normal /FontFile3 74 0 R /XHeight 524 /Flags 34 /FontFamily Bodoni Extra T /Descent -251 /FontName /ZDIWMH+BodoniXT /Ascent 940 /FontWeight 400 /ItalicAngle 0 /CharSet /space/zero/two/A/E/G/M/R/S/T /Type /FontDescriptor /CapHeight 668 ``` On 7 November 2012 11:54, Harry Roberts ha...@midnight-labs.org wrote: Hi, Just confirming that the latest version of FreeType (from GIT) has resolved this problem, as does Suzuki's patch. I greatly appreciate both of your inputs :) Thank you for the insight into the OpenType format. There is still an outstanding issue and another big handful of PDFs to do regression testing on. I am doing my best to extract it into a test case, more debugging will show if the problem lies with Poppler or Freetype. On 7 November 2012 06:43, Werner LEMBERG w...@gnu.org 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. Hmm, the demo font works without this your patch. 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... AFAIK, PDF drivers include CFFs in `pure' format if they don't need or want to use a cmap. I'm not sure it makes sense to support a CFF in SFNT format without a real `cmap' table. Werner 74.otf Description: application/vnd.oasis.opendocument.formula-template ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Unable to load OpenType font (test case + font attached)
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
IPJYIP+PFDinTextPro-Medium.otf
Description: application/vnd.oasis.opendocument.formula-template
#include ft2build.h
#include FT_FREETYPE_H
#include stdlib.h
#include stdio.h
int main( int argc, char **argv ) {
FT_Library library;
FT_Face face;
int error;
error = FT_Init_FreeType(library);
if( error ) {
fprintf(stderr, FT_Init_FreeType error\n);
exit(1);
}
error = FT_New_Face(library, IPJYIP+PFDinTextPro-Medium.otf, 0, face);
if( error == FT_Err_Unknown_File_Format ) {
fprintf(stderr, FT_New_Face = Unknown File Format!\n);
exit(2);
}
else if( error ) {
fprintf(stderr, FT_New_Face = %d\n, error);
exit(2);
}
exit(0);
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
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 ha...@midnight-labs.org 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
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 ha...@midnight-labs.org 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
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
diff --git a/src/sfnt/ttload.c b/src/sfnt/ttload.c
index 16914f2..22a545b 100644
--- a/src/sfnt/ttload.c
+++ b/src/sfnt/ttload.c
@@ -171,7 +171,7 @@
{
FT_Error error;
FT_UShort nn, valid_entries = 0;
-FT_UInthas_head = 0, has_sing = 0, has_meta = 0;
+FT_UInthas_head = 0, has_sing = 0, has_meta = 0, has_cff = 0;
FT_ULong offset = sfnt-offset + 12;
static const FT_Frame_Field table_dir_entry_fields[] =
@@ -260,6 +260,8 @@
has_sing = 1;
else if ( table.Tag == TTAG_META )
has_meta = 1;
+ else if ( table.Tag == TTAG_CFF )
+has_cff = 1;
}
sfnt-num_tables = valid_entries;
@@ -272,7 +274,7 @@
}
/* if `sing' and `meta' tables are present, there is no `head' table */
-if ( has_head || ( has_sing has_meta ) )
+if ( has_head || ( sfnt-format_tag != TTAG_OTTO has_cff ) || ( has_sing has_meta ) )
{
error = SFNT_Err_Ok;
goto Exit;
@@ -281,9 +283,9 @@
{
FT_TRACE2(( check_table_dir: ));
#ifdef TT_CONFIG_OPTION_EMBEDDED_BITMAPS
- FT_TRACE2(( neither `head', `bhed', nor `sing' table found\n ));
+ FT_TRACE2(( neither `head', `CFF ', `bhed', nor `sing' table found\n ));
#else
- FT_TRACE2(( neither `head' nor `sing' table found\n ));
+ FT_TRACE2(( neither `head', `CFF ', nor `sing'
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
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 ha...@midnight-labs.org 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Unable to load OpenType font (test case + font attached)
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. Hmm, the demo font works without this your patch. 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... AFAIK, PDF drivers include CFFs in `pure' format if they don't need or want to use a cmap. I'm not sure it makes sense to support a CFF in SFNT format without a real `cmap' table. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
