You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since updating to prawn 2.5.0, we face issues with font embedding and incorrectly or missing glyphs.
Reproduction example:
This reproduction example assumes that the file Arial Unicode MS.TTF is present in the local working directory. While the font is shipped with Microsoft Office by default and can be licensed by Microsoft, it is also available on GitHub (for example here). With the file being available, a simple irb can be started and the following script can be executed:
The @ character included in the text is not shown in Acrobat. Instead (after a few seconds), an error is shown: Cannot extract the embedded font 'e23202+ArialUnicodeMS'. Some characters may not display or print correctly.
The documentation for font_families indicates that the default for subset is false. However, this doesn't seem to be the case and it rather appears that subset: true is the default since 528a37d. Given the above example, explicitly specifying subset: true doesn't change anything (with regard to showing the @ or the file size of the resulting PDF`)
# Bug still occurs@pdf.font_families.update("ArialUnicodeMS"=>{normal: {file: "Arial Unicode MS.TTF",subset: true}})
However, changing the option to subset: false, the full TTF file is embedded and the PDF file size dramatically increases (due to the large TTF):
# Bug doesn't occur any longer, `@` is shown correctly and the resulting PDF is huge@pdf.font_families.update("ArialUnicodeMS"=>{normal: {file: "Arial Unicode MS.TTF",subset: false}})
After reducing the issue to the above-given minimal reproduction example, we are pretty confident to face a bug in Prawn. Otherwise, we probably misunderstood the subsetting and font-embedding and would be grateful about some advice - Thank you!
Yes, we've looked at #1346. From the various comments, we also got the idea of explicitly setting subset: false (despite being advertised as the default in the docs). As mentioned, subset: false resolves the issue with the missing glyph, but at some drawbacks (including the larger file size). The previous version of Prawn didn't had the same issue, and reverting also avoids the issue mentioned here. Since #1346 is closed, and we also have found a potential issue with the documentation, I decided to open a new issue. On a technical note, prawnpdf/ttfunk#102 is probably related, too.
Since updating to prawn 2.5.0, we face issues with font embedding and incorrectly or missing glyphs.
Reproduction example:
This reproduction example assumes that the file
Arial Unicode MS.TTF
is present in the local working directory. While the font is shipped with Microsoft Office by default and can be licensed by Microsoft, it is also available on GitHub (for example here). With the file being available, a simpleirb
can be started and the following script can be executed:Issues noticed:
The
@
character included in the text is not shown in Acrobat. Instead (after a few seconds), an error is shown:Cannot extract the embedded font 'e23202+ArialUnicodeMS'. Some characters may not display or print correctly.
The documentation for
font_families
indicates that the default forsubset
isfalse
. However, this doesn't seem to be the case and it rather appears thatsubset: true
is the default since 528a37d. Given the above example, explicitly specifyingsubset: true
doesn't change anything (with regard to showing the@
or the file size of the resulting PDF`)However, changing the option to
subset: false
, the full TTF file is embedded and the PDF file size dramatically increases (due to the large TTF):After reducing the issue to the above-given minimal reproduction example, we are pretty confident to face a bug in Prawn. Otherwise, we probably misunderstood the subsetting and font-embedding and would be grateful about some advice - Thank you!
--
prawn:
2.5.0
Ruby:
3.3.5
Adobe Acrobat Pro:
2024.003.20121
The text was updated successfully, but these errors were encountered: