The Return of the Embedded Font Issue

[TastyPi]

1.8.0 has introduced issues with embedding fonts with prawn, see prawnpdf/prawn#1346

Minimal reproduction:

#!/usr/bin/env ruby

require "prawn"

pdf = Prawn::Document.new
pdf.font_families.update(
  "roboto" => {
    normal: "Roboto/Roboto-Regular.ttf",
    italic: "Roboto/Roboto-Italic.ttf",
    bold: "Roboto/Roboto-Bold.ttf",
    bold_italic: "Roboto/Roboto-BoldItalic.ttf",
  }
)
pdf.font("roboto")

pdf.text_box("€")

File.open("test.pdf", "w") do |file|
  pdf.render(file)
end

system "flatpak run com.adobe.Reader test.pdf"

The Euro symbol seems to trigger the bug.

[Salman464]

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

[TastyPi]

@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 😅

[xtr3me]

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.

[lucaong]

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

[jenskutilek]

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

[nishio-dens]

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.

ttfunk/lib/ttfunk/ttf_encoder.rb

Line 110 in 885061e

@maxp_table ||= TTFunk::Table::Maxp.encode(original.maximum_profile, old_to_new_glyph)

but, the receiver process appears to expect new_to_old_glyph.

ttfunk/lib/ttfunk/table/maxp.rb

Line 86 in 885061e

def encode(maxp, new2old_glyph)

Is the argument correct?

If this is not relevant, please ignore this comment.

[drgcms]

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

[bai-yi-bai]

I would also like to report unique behavior for PDFs generated using ttfunk 1.8.
Both stduviewer and DiffPDF foss v2.1.3 (GPL 2.0) are relatively old applications and exhibit similar behavior. They open files, but have lots of characters missing in them. I've also reverted to using ttfunk 1.7.

[formigarafa]

Heads-up,
I noticed some missing lower case "g" on Open Sans after upgrading to versions mentioned above.
But instead of changing prawn or downgrade it I have downloaded a newer version of Open Sans and the 'g's are back.

Please note that I am not sure if there is any other glyph missing but in a superficial check over the list of all characters I could produce with the keyboard the all did appear in the reader. There was also a notification "cannot extract embedded font" which stop appearing.

This is the list of chars/glyphs I've used, I hope it helps anyone who may need something to start from.

ab a b
0123456789
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
`~!@#$%^&*()-_=+[]\{}|;':",./<>?
`´¨ˆ˜
¡™£¢∞§¶•ªº–≠œ∑®†¥øπ“‘«åß∂ƒ©˙∆˚¬…æΩ≈ç√∫µ≤≥÷
ŵèéêêëěẽēėę
ř
țťþ
ýŷÿ
ùúûüǔũūűů
ìíîïiǐĩīıį
òóôöǒœøõō
àáâäǎæãåāā
ßşșśš
ďð
ğġ
ħ
ķ
łļľ
źžż
çćčċ
ñńņň