Bug 94054

Summary: pdftoppm's raster of one shows up incorrectly (and oddly narrow)
Product: poppler Reporter: Micah Chambers <micah>
Component: cairo backendAssignee: 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
For some reason a single font on this pdf shows up incorrectly. On various web readers it shows up fine, but in evince, atril and pdftoppm it renders extremely narrowly. This is on both Ubuntu 14.04 and Archlinux, using the latest release version. It seems like it might be a missing font: these are the listed font substitutions:

name                                 object ID substitute font                      substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Arial-BoldMT                             61  0 Liberation Sans Bold                 /usr/share/fonts/TTF/LiberationSans-Bold.ttf
ArialMT                                  63  0 DejaVu Sans                          /usr/share/fonts/TTF/DejaVuSans.ttf

Unfortunately the this is clients data, so I don't want to post it publicly, but I can email you a link if you are interested. Thanks for the help. 

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Arial-BoldMT                         TrueType          WinAnsi          no  no  no      61  0
ArialMT                              TrueType          WinAnsi          no  no  no      63  0
RVRWVW+ArialNarrow-Bold              TrueType          WinAnsi          yes yes no      66  0
RVRWVW+ArialNarrow                   TrueType          WinAnsi          yes yes no      69  0
Comment 1 Thomas Freitag 2016-02-10 16:10:58 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!
Comment 2 Thomas Freitag 2016-02-11 12:28:29 UTC
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.
Comment 3 Thomas Freitag 2016-02-11 12:37:24 UTC
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'.
Comment 4 Thomas Freitag 2016-02-11 12:41:02 UTC
Just an additional hint: the patch of comment 3 just solves the bug for the splash backend, cairo has the same issue, too!
Comment 5 Albert Astals Cid 2016-02-17 22:01:03 UTC
Commited Thomas' patch for Splash, he says Cairo needs the same fix.
Comment 6 Jason Crain 2016-02-19 04:45:53 UTC
Created attachment 121837 [details] [review]
cairo patch

patch for cairo
Comment 7 Jason Crain 2016-02-19 04:49:49 UTC
*** Bug 22523 has been marked as a duplicate of this bug. ***
Comment 8 Jason Crain 2016-02-19 05:01:12 UTC
*** Bug 36829 has been marked as a duplicate of this bug. ***
Comment 9 Carlos Garcia Campos 2016-04-02 10:12:36 UTC
Pushed the cairo patch too. Thanks!
Comment 10 Micah Chambers 2016-04-02 17:24:38 UTC
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.