The Return of the Embedded Font Issue

[TastyPi]

1.8.0 has introduced issues with embedding fonts with prawn, see https://github.com/prawnpdf/prawn/issues/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 :sweat_smile:

[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.

https://github.com/prawnpdf/ttfunk/blob/885061ed7fd0d1397ff40b3c67fb9d93dc30dcd0/lib/ttfunk/ttf_encoder.rb#L110

but, the receiver process appears to expect new_to_old_glyph.

https://github.com/prawnpdf/ttfunk/blob/885061ed7fd0d1397ff40b3c67fb9d93dc30dcd0/lib/ttfunk/table/maxp.rb#L86

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ǐĩīıį
òóôöǒœøõō
àáâäǎæãåāā
ßşșśš
ďð
ğġ
ħ
ķ
łļľ
źžż
çćčċ
ñńņň

[jasonperrone]

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ǐĩīıį
òóôöǒœøõō
àáâäǎæãåāā
ßşșśš
ďð
ğġ
ħ
ķ
łļľ
źžż
çćčċ
ñńņň

Eager to try that, thank you.

[pointlessone]

@jasonperrone This is an interesting observation. Could you please attach both the old "broken" and the new versions of the font?

[tobischo]

We experienced the same issue. Attached you can find the older and newer font files we had in use here.

opensans-new.zip opensans-old.zip

With the newer version + ttfunk 1.8 Adobe Acrobat is still throwing an error, but the letters seem to be shown correctly (the missing gs for example) So for now, that still keeps us at ttfunk 1.7

[jasonperrone]

I have also downgraded to prawn 2.4.0, ttfunk 1.7.0. I think that's all I can do. I downloaded the current versions of all the OpenSans-xxx.ttf fonts I use and they are all identical to the ones I already had.

[KjellMorgenstern]

Edit: TL;TR : Nothing new, except 'g' in bold OpenSans still missing and NotoSansThaiLooped is also affected (Bhat symbol).

Long text: I also tried updating from some old OpenSans (copied from google fonts 2021) to some later Open Sans (downloaded from google fonts just today). This fixed the missing "g" in regular text. However, in bold text, the "g" is still missing. Also, the "€" sign is missing.

I tried NotoSans instead. Now, only the € sign is missing. Also, some currency symbols (Bhat) from the fallback font are missing.

I use pdf.fallback_fonts ["NotoSans", "NotoSansThaiLooped"]

In December 2023 I had added a comment to my code: # TODO We can't yet replace OpenSans with NotoSans. OpenSans has reduced line heights in the address sections. But with NotoSans, the default height seems to be used everywhere. The height problem seems to be fixed, and OpenSans can be replaced with NotoSans.

Since the € symbol is still missing, I will now try the downgrade to prawn 2.4.

Acrobat Reader version is 2024.002.21005

[jenskutilek]

It's not the fonts that are broken. The maxp table calculations in ttfunk are currently incorrect. Any given font or even different subsets of the same font may work or not work. The only way to fix it is to correct the calculations, or to go back to the previous code version, which didn't touch the values inside the maxp table when embedding a font.

[wuarmin]

Hey, I came across the same issue. How should we continue here? thanks

[flavio-b]

There's an open PR (#104 ) that attempts to fix the issue with the maxp.

[swistak]

@wuarmin In the meantime lock those versions in Gemfile:

gem 'ttfunk', '~> 1.7.0'
gem 'prawn', '~> 2.4.0'