-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Return of the Embedded Font Issue #102
Comments
Encountered the same error recently Faced issue on the versions:
Resolution:
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 |
@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 😅 |
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. |
Same as what @xtr3me noted: we also have issues printing over CUPS, and reverting to If it helps, printing over CUPS gives the following error (which is printed by the printer):
|
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 Apparently the old version just kept the
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. |
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. ttfunk/lib/ttfunk/ttf_encoder.rb Line 110 in 885061e
but, the receiver process appears to expect new_to_old_glyph. ttfunk/lib/ttfunk/table/maxp.rb Line 86 in 885061e
Is the argument correct? If this is not relevant, please ignore this comment. |
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 |
I would also like to report unique behavior for PDFs generated using ttfunk 1.8. |
Heads-up, 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.
|
Eager to try that, thank you. |
@jasonperrone This is an interesting observation. Could you please attach both the old "broken" and the new versions of the font? |
We experienced the same issue. opensans-new.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 |
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. |
1.8.0
has introduced issues with embedding fonts withprawn
, see prawnpdf/prawn#1346Minimal reproduction:
The Euro symbol seems to trigger the bug.
The text was updated successfully, but these errors were encountered: