#1042 font subsetting issue

[arekm]

Recent google chrome 41 broke pdf viewing when "this happen when a font specified (but NOT embedded) isn't found on the host system"
https://code.google.com/p/chromium/issues/detail?id=465322

which makes me wonder if tcpdf is embedding font correctly if subsetting is enabled.

http://www.tcpdf.org/examples/example_008.pdf fails to work, so I added in _putfonts:

// rebuild a font subset
$font = TCPDF_FONTS::_getTrueTypeFontSubset($font, $subsetchars);

• $x = fopen('/tmp/subset.ttf', 'wb');
• fwrite($x, $font);
• fclose($x);
  // calculate new font length

and then view subset.tff with ftview (font viewer; from freetype package)

Unfortunately ftview shows no glyphs in subset.ttf as shown on attached screenshot.

(left side is subset.ttf; right side is full font without subsetting enabled)

[arekm]

From google chrome bug:

"The embedded font AAAAAC+FreeSerif' in the example document is buggy. It contains a nested function definition in thefpgm' table (within FDEF #18),
most probably due to a bug in the PDF creator's font subsetting engine.
Consequently, FT_Load_Glyph returns error code 0x89, `Nested_DEFS', for all
glyphs.

FreeType's behaviour is right: A font with a broken fpgm table can't be
displayed correctly. The solution is trying to re-load the affected glyph(s)
without hinting.

The attached file contains the diff between FreeSerif.ttf's `fpgm' table
(version Version 0412.2263) and the table of the embedded font."

and the example was
http://www.tcpdf.org/examples/example_008.pdf

See https://code.google.com/p/chromium/issues/detail?id=465322#c31

[Werner LEMBERG]

In ftview, you might always try to press the 'h' key to disable hinting, or pressing 'B' to switch to light auto-hinting.

[alonagar]

Voting up, having the same issue (and tons of angry clients!).
Is this TCPDF problem or Chrome?

[arekm]

Both I think. Fixing one of these will probably make issue go away (and hide the other buggy part).

ps. I see tcpdf people are doing paid support, so best to contact them & pay if fast solution is needed.

ps2. for quick (and ugly) workaround - disable font subsetting when generating pdfs with tcpdf

[alonagar]

arekam, thanks for your reponse.
I know the workaround, but this is a problematic issue for me I am creating thousands of PDF's daily and it will block my storage and network if each of them will be 8 times bigger.

Eventually TCPDF is an opensource, so I would be happy to assist finding and killing this bug, but I have not a clue in font subsetting or debugging such issue.

[Lubos Dz]

Hi,

this is very annoying bug, that made me headache because lots of clients started to call me complaining that PDF generators stopped working. 46% percent of users use Chrome, also few Firefox users complained. All cases were related ONLY to build-in PDF viewers.

Issue was not fixes with font subsettings, no effect, still empty PDF files.

Then I recompiled few windows fonts arial, verdana, tahoma, courier, times - regular, bold, italic, bolditalic/boldoblique - I created in /tools/make.bat file with following content:

rem regular, bold -f 32
php ./tcpdf_addfont.php -b -t TrueTypeUnicode -f 32 -i arial.ttf,arialbd.ttf,tahoma.ttf,tahomabd.ttf,times.ttf,timesbd.ttf

rem regular mono -f 33
php ./tcpdf_addfont.php -b -t TrueTypeUnicode -f 33 -i courier.ttf,courierbd.ttf

rem -f 96 oblique, boldoblique (italic)
php ./tcpdf_addfont.php -b -t TrueTypeUnicode -f 96 -i arialbi.ttf,ariali.ttf,timesi.ttf,timesbi.ttf

rem -f 97 mono oblique (italic)
php ./tcpdf_addfont.php -b -t TrueTypeUnicode -f 97 -i courierbi.ttf,courieri.ttf

Result was:

• all regular worked OK.
• but bold/italic (oblique) - still appeared empty. As a workaround I turned all variants off until issue is resolved.
• Files became larger overall by 20-30%.
• Interesting is, that supplied freemono regular + bold both worked OK.

Chrome 43 should have this fixed, not sure about ver. 42.

[Nicola Asuni]

Can anyone try to edit the include/tcpdf_font.php file at line 1314 and remove the 'fpgm' table from the array to see if it works?

FROM:

$table_names = array ('head', 'hhea', 'hmtx', 'maxp', 'cvt ', 'fpgm', 'prep');

TO:

$table_names = array ('head', 'hhea', 'hmtx', 'maxp', 'cvt ', 'prep');

This will disable the hinting for subsetting.

[arekm]

Dropping fpgm from this array doesn't fix anything with chrome 41 here.

[arekm]

... but for example dropping 'prep' only (leafing fpgm as is) makes text visible. Same for dropping one of 'cvt', 'head', 'hmtx' or 'hhea' (but for head/hhea/hmtx visible font is totally different). Random poking around...

[Nicola Asuni]

Can anyone else confirm that removing the prep table fix the issue?

[alonagar]

Same here, removing the 'prep' fixing this issue.

Is it safe to remove it in production?

[alonagar]

After removing the 'prep' there is still a problem in Chrome.
I am speaking Hebrew so I can check only the Hebrew example, while in FF/Adobe reader it works perfectly, in Chrome (41.0.2272) one letter is missing (marked in red arrow) and some strange char showed instead.

[Werner LEMBERG]

Folks, removing the prep table is a silly work-around IMHO that makes subsetted fonts look ugly because they no longer can be hinted correctly!

Someone should really find out why tcpdf breaks the fpgm table. All other 'fixes' are crap.

[Lubos Dz]

I understand primary responsibility for this bug have guys that developed software used for compiling original fonts.

According to google chromium/pdfium response (see link above), original fonts are actually damaged, they have missing glyphs. This happened due to bug in font creator software. It looks like chrome already merged bugfix for this into Chrome version 42 + 43. So the original fonts supplied along with TCPDF are always damaged because original TTF fonts were damaged.

This is what I understand. Correct me, if I am wrong.

But if this is true, then all supplied truetype TCPDF fonts should be recompiled with fixed source TTF fonts or replaced with another TTF free truetype fonts from the internet (there are many fonts at e.g. http://www.fontsquirrel.com/).
It also means that TCPDF addFont utility should be probably OK, even though this is to be confirmed by Nicola.

[Werner LEMBERG]

In case of the example_008.pdf document, the original font (FreeSerif) works just fine.

[alonagar]

Guys do you have any advance?
Does newly compiled font fixed this issue?
Nicola Assuni, what do you think about this solution?

[alonagar]

Does anyone managed to overcome this bug?
Did anyone managed to get new fonts to work?
If anyone have a solution please share...

[Kris Willis]

This issue also presents itself when viewing generated PDFs (with font sub-setting) using the "Reader" application that comes with Windows 8.1 (using one of the builds from modern.ie).

[Lubos Dz]

Chrome Version 42.0.2311.90 (newest version as per today) does not seems to have this bug anymore in built-in PDF viewer. I am not able to reproduce the error.

[arekm]

Try printing it in that google chrome 42. Anyway AFAIK bug is still there, just chrome has workarounds for it.

[alonagar]

The bug still exists when trying to print.
read the last comment here...
https://code.google.com/p/chromium/issues/detail?id=465322#c49

Moreover, even when Google will fix it completely TCPDF still creating bad font when subsetting. and this bug will appear in more programs (as Chris mentioned here the bug exists in windows 8.1 PDF viewer )

The problem is in the subsetting class which creates bad font for embedding and it need to be fixed.

[Mathieu Masseboeuf]

We are no more using subsetting, not because of Chrome, but because of iOS rendering those PDF oddly. I suppose the root of the problem is the same but couldn't figure out what's going on.