The Return of the Embedded Font Issue about ttfunk HOT 13 OPEN

Encountered the same error recently Cannot extract the embedded font '3a9d5f+Recoleta-Bold'. Some characters may not display or print correctly.

Faced issue on the versions:

• pdf-core (0.10.0)
• prawn (2.5.0)
• ttfunk (1.8.0

Resolution:
Downgraded gems to resolve:

• pdf-core (0.9.0) (automatically downgraded with prawn and ttfunk)
• prawn (2.4.0)
• ttfunk (1.7.0)

I can confirm that downgrading to previous versions of prawn and ttfunk resolved the issue. not sure though if the issue is from ttfunk or prawn upgrade

from ttfunk.

For me this causes CUPS not being able to print my PDF's over the IPP protocol. After reverting back to 1.7 everything works correctly again.

from ttfunk.

I've ran a diff on an embedded font in a prawn pdf between ttfunk 1.7.0 and 1.8.0, and the only differences are in the maxp table.

Apparently the old version just kept the maxp values from the original font, which is a valid approach. The new version tries to recalculate them, but fails. I've added the value I'd consider correct in the rightmost column.

field                original  broken  corrected
maxPoints                 124       8         50
maxContours                 7       1          1
maxCompositePoints        150       0         50
maxCompositeContours        5       0          1
maxSizeOfInstructions    1028      61       1028
maxComponentElements        3       0          1
maxComponentDepth           1       0          1

maxSizeOfInstructions contains the length of the prep table's instruction bytecode for this font, because the prep table has the longest TrueType assembly program of all glyphs, and of the prep and fpgm tables.

There are several correct ways to calculate the value. It could also measure only the length of the longest glyph program (that's what the OpenType spec says). In that case, the result would be 133 in the subsetted font. The value 61 is wrong in any case.

fonts.zip

from ttfunk.

I am outputting PDFs using Japanese fonts, e.g. IPAFont. As reported here, I am having problems opening them in Acrobat Reader.

I am not familiar with ttfunk / maxptable / font implementations, so I may be thinking about the wrong thing, but I doubt that the code below is really correct.

The following process is described at line 110 of ttf_encoder.rb.
The argument is old_to_new_glyph.

but, the receiver process appears to expect new_to_old_glyph.

Is the argument correct?

If this is not relevant, please ignore this comment.

from ttfunk.

Same problem here with ttfunk 1.8. It is required by prawn 2.5.0.

The funny thing is when opened in the browser pdf is displayed without special UTF-8 characters. But when printed, special characters are printed ok. This is all on Windows 11 with the last version of Acrobat Reader.

The previous version of the reader or Linux pdf readers are perfectly ok.

Reverting to ttfunk 1.7 also reverted pdf-core to 0.9.0 and prawn to 2.4.0 and it works as expected.

by
TheR

from ttfunk.

@pointlessone something I forgot to mention is the PDF renders perfectly fine in Chrome and Evince, the error only appears in Adobe Reader. Which I imagine means the issue is extremely subtle and complicated 😅

from ttfunk.

Same as what @xtr3me noted: we also have issues printing over CUPS, and reverting to 1.7 works.

If it helps, printing over CUPS gives the following error (which is printed by the printer):

ERROR:
invalidfont
OFFENDING COMMAND:
awidthshow

from ttfunk.