| Summary: | pdftoppm's raster of one shows up incorrectly (and oddly narrow) | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Micah Chambers <micah> |
| Component: | cairo backend | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | dlaxalde, nicola |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Check if PDF knows the witdh of 'm' in case of substituted font
cairo patch attachment-32698-0.html |
||
|
Description
Micah Chambers
2016-02-08 22:51:55 UTC
I can't really see the problem here, but at least for Arial-BoldMT on my system another font is used: name object ID substitute font substitute font file ------------------------------------ --------- ------------------------------------ ------------------------------------ Arial-BoldMT 61 0 Arial Negreta /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf ArialMT 63 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf But nevertheless; poppler doesn't ship any fonts, it always uses fontconfig to find a suitable font. It's up to the user either to install the fonts he needs or just allow PDF with all fonts embedded. I will close this bug, but I send You my created PNG. If You show me that it is rendered extremely narrowly, too, please mark what You mean, send it back to me and reopen this bug! Sorry for closing this bug too fast. After Your hints and a deeper investigation I encountered that it is a poppler bug: The chars displayed wrong were set in Arial-Bold with a size of round about 8 pt, so freetype and therefore poppler should be able to render them much better. The problem was the following: If poppler encounters that a font has to be substituted by an external font it tries to check if the font matrix has to be adjusted: if real font is substantially narrower than substituted font, reduce the font size accordingly. This is done by the comparison of the expected PDF width of the character 'm' and the width of the character 'm' in the substituted font. Unfortunately the PDF font doesn't include the width of the letter 'm' (code 106), it just includes /FirstChar 32 /LastChar 89 Therefore we need another sanitize check: if the PDF width for 'm' is not included. Created attachment 121671 [details] [review] Check if PDF knows the witdh of 'm' in case of substituted font This patch solves the issue: To check wether the PDF font declaration includes the width of the letter 'm', compare it with the width of code 0. Code 0 is the replacement glyph in a font and has the width of a blank. The width table is initialized with this value, and the blank is always smaller than a 'm'. Just an additional hint: the patch of comment 3 just solves the bug for the splash backend, cairo has the same issue, too! Commited Thomas' patch for Splash, he says Cairo needs the same fix. Created attachment 121837 [details] [review] cairo patch patch for cairo *** Bug 22523 has been marked as a duplicate of this bug. *** *** Bug 36829 has been marked as a duplicate of this bug. *** Pushed the cairo patch too. Thanks! Created attachment 122681 [details] attachment-32698-0.html Thanks! On Sat, Apr 2, 2016 at 3:12 AM, <bugzilla-daemon@freedesktop.org> wrote: > Carlos Garcia Campos <carlosgc@gnome.org> changed bug 94054 > <https://bugs.freedesktop.org/show_bug.cgi?id=94054> > What Removed Added > Status NEW RESOLVED > Resolution --- FIXED > > *Comment # 9 <https://bugs.freedesktop.org/show_bug.cgi?id=94054#c9> on > bug 94054 <https://bugs.freedesktop.org/show_bug.cgi?id=94054> from Carlos > Garcia Campos <carlosgc@gnome.org> * > > Pushed the cairo patch too. Thanks! > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > > |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.