Bug 66922

Summary: Several texts (with monospaced fonts) are seen with spaces within
Product: poppler Reporter: kubry
Component: generalAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: cloos
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Text badly seen with (Okular 0.15.2, KDE 4.9.2) or (Okular 0.16.4; KDE 4.9.4)
Text correctly seen with Adobe Reader
Magnified - with Adobe Reader and Lucida Console
Magnified - with Adobe Reader but without Lucida Console

Description kubry 2013-07-15 13:04:37 UTC
Created attachment 82442 [details]
Text badly seen with (Okular 0.15.2, KDE 4.9.2) or (Okular 0.16.4; KDE 4.9.4)

Several texts (with monospaced fonts) are seen with spaces within. That has happened with several pdf files; one example can be seen in the text "Command prompt" that exists in the page 10 of that file:
http://www.3ds.com/fileadmin/PRODUCTS/DRAFT_SIGHT/PDF/GETTING-STARTED-GUIDE.pdf

I used one computer with
  (Okular 0.15.2, KDE 4.9.2)
and it had the same bad result as another computer with
  (Okular 0.16.4; KDE 4.9.4).
I attach a screenshot, in the file: 
  Okular 0.15.2, KDE 4.9.2; Okular 0.16.4; KDE 4.9.4.png

I used another computer with Acrobat Reader, and the text was seen correctly. I attach a screenshot, in the file: 
  Adobe Reader.png


Thanks for all the good work!
Comment 1 kubry 2013-07-15 13:06:50 UTC
Created attachment 82443 [details]
Text correctly seen with Adobe Reader
Comment 2 Albert Astals Cid 2013-07-15 13:18:46 UTC
The file is using the "Lucida Console" font but does not embed it, so we're using the best substitute for it we find in the system, Adobe is probably shipping private fonts you don't have on your system, that's why it looks fine.

There's not much we can do here
Comment 3 kubry 2013-07-15 16:17:42 UTC
(In reply to comment #2)

Thank you ("gràcies"), Albert. 

> The file is using the "Lucida Console" font but does not embed it, so we're
> using the best substitute for it we find in the system, Adobe is probably
> shipping private fonts you don't have on your system, that's why it looks
> fine.
I went again to the machine with Adobe reader, I opened the PDF, I made a screenshot [^1], I removed the "Lucida Console" font there, I restarted the machine, I opened again the PDF, and the result was very similar (the letters were not identical, of course) [^2].

[^1]: Attachment "magnified - with Adobe Reader and Lucida Console.png".
[^2]: Attachment "magnified - with Adobe Reader but without Lucida Console.png".

But what it did not happen there is what I reported in this bug, the "spaces within letters". For example, in the first attachment of this bug, we can see too much space between the "C" and the "o", between the "p" and the "t", etc., and not between "m" and "m". Adobe Reader uses a monospaced font as a substitute and this does not happen to it.

Thanks for all the good work!
Comment 4 kubry 2013-07-15 16:19:13 UTC
Created attachment 82450 [details]
Magnified - with Adobe Reader and Lucida Console
Comment 5 kubry 2013-07-15 16:20:34 UTC
Created attachment 82451 [details]
Magnified - with Adobe Reader but without Lucida Console
Comment 6 James Cloos 2013-07-16 12:43:59 UTC
> I opened again the PDF, and the result was very similar (the letters
> were not identical, of course)

Adobe includes a pair of multiple master fonts with acroread.  It uses
them to substitute for missing latin fonts.  The individual glyphs are
scaled to match the embedded metrics.

The fonts are:

    ZX______.PFB (Adobe Sans MM)
    ZY______.PFB (Adobe Serif MM)

MM fonts are *hard* to create and the MM concept was abandoned when t1
fonts were replaced with cff fonts in sfnt containers (otf fonts).

No one has released an MM font under a DFSG license, and AFAIK support
for them has not been added to any DFSG licensed pdf viewer.

For many years now even Adobe has strongly advised everyone to include
fonts in pdf documents, and not to rely on font substitution.
Comment 7 kubry 2013-07-17 06:55:23 UTC
(In reply to comment #6)
Thank you, James, for your detailed information. That text can be used as a future reference for other bugs, too.

I'll try to explain the bug from another point of view.
As we know, in a monospaced font, the "m" letter occupies the same horizontal space as a "C". Let's see the first attachment of this bug, and its problematic texts, "Command prompt" and "Specify next point":
1) In the original PDF, a monospaced font is used in those texts. But in the final view, the "m" does not occupy the same horizontal space as a "i", because a "non-monospaced" font is used. 
2) But... the "reserved" horizontal space is the same for each of those letters, as if a monospaced font was used (but it's not); that causes that huge space after the "i" letters, and the correct space (a minor one) between the "m" letters, for example.

For example, if a monospaced font was used in the final view, the problem would not exist, there would not be those huge gaps after the letters that are not an "m".

Excuse my English :-) . Thanks for all the good work!
Comment 8 James Cloos 2013-07-17 14:50:10 UTC
OK.  For the specific case of non-embedded monowidth fonts, there may be
enough info in the pdf for poppler to prefer a monowidth substitute font
over proportional ones.

In that pdf, the obj for LucidaConsole specifies /Flags 32, which means
Nonsymbolic.  It should specify /Flags 33, which adds FixedPitch.

I’ll attach a version of the pdf with that change, in case anyone would
like to test whether if makes a difference.

Otherwise, parsing the /Widths arrays, and guessing monowidth when they
are all 0 or a fixed int probably is reasonable, as you’ve suggested.
Comment 9 James Cloos 2013-07-17 15:02:15 UTC
Bz didn’t like the size of the attachment, so I put it at:

  http://people.freedesktop.org/~cloos/Poppler/GSG.pdf

The attachment comment would have read:

  This only changes the Flags for LucidaConsole from:

    32 (Nonsymbolic)

  to:

    33 (FixedPitch | Nonsymbolic)

  to test whether that is enough of a hint to prefer a monowidth substitute font.
Comment 10 kubry 2013-07-20 09:11:25 UTC
(In reply to comment #8)

> OK.  For the specific case of non-embedded monowidth fonts, there may be
> enough info in the pdf for poppler to prefer a monowidth substitute font
> over proportional ones.

> I’ll attach a version of the pdf with that change, in case anyone would
> like to test whether if makes a difference.

I tried it, although a difference wasn't seen (at least with Okular 0.16.5).
 
> Otherwise, parsing the /Widths arrays, and guessing monowidth when they
> are all 0 or a fixed int probably is reasonable, as you’ve suggested.

Thanks for all the good work!
Comment 11 Albert Astals Cid 2013-08-04 22:32:42 UTC
I know I'm saying something obvious, but Patches welcome as always :-)
Comment 12 GitLab Migration User 2018-08-21 10:49:44 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/387.

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.