Created attachment 82443 [details]
Text correctly seen with Adobe Reader

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

(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!

Created attachment 82450 [details]
Magnified - with Adobe Reader and Lucida Console

Created attachment 82451 [details]
Magnified - with Adobe Reader but without Lucida Console

> 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.

(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!

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.

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.

(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!

I know I'm saying something obvious, but Patches welcome as always :-)

-- 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.