Bad rendering (hinting) in Evince and Xpdf

Created an attachment (id=5037)
Evince on SUSE 10.0

Created an attachment (id=5038)
Evince on Ubuntu 5.10

Dapper has Freetype 2.1.10 now, if you could provide us with a link to that PDF,
we could check.

Created an attachment (id=5049)
PDF file generated with PDFLatex, with Type 1 Computer Modern fonts embedded.

I have just downloaded the Dapper Drake LiveCD (Flight 2). The problem persists---no change.

maybe Suse has some patches, or maybe that's due to the fontconfig configuration
or the fonts installed beeing different

Note 1: installled fonts should not be the issue here. The documents in question only use embedded fonts (the standard LaTeX Type 1
"Computer Modern" fonts, which come with any modern LaTeX disto including TeTeX).

Note 2: Another possibility---Older versions of Kpdf allowed one to toggle font hinting on or off. I seem to remember that hinting
actuallly made things worse and actually quite similar to what I am getting with Evince now. The reason is that the CM fonts did
not have very good hints. Does this make any sense?

I AM AN IDIOT^H^H^H^H^H NEWBIE. Sorry for the caps, but I have given you BAD debugging information. Sorrysorrysorry.

OK, here's the deal. The above screenshots are taken from Evince, but I had other screenshots taken from xpdf. I originally thought (due to mislabeling of one file, perhaps) that the same issue arose with xpdf and Evince/Kpdf, but this is NOT the case.

The problem exists only with Evince and Kpdf, and NOT, repeat, NOT with xpdf. Indeed, upon further experimentation, I have found that:

1. Rendering the above file (or other PDF files generated by pdflatex) with xpdf gives THE SAME RESULTS under both Ubuntu Breezy and OpenSuse 10.0.

2. Rendering the same files with Evince or Kpdf gives inferior results on Breezy relative to OpenSuse, as documented by the above screenshots.

BOTTOM LINE: I think Poppler is to blame. xpdf uses t1lib to render Type 1 fonts, and indeed pdflatex embeds Type 1 fonts. Evince and Kpdf instead use poppler-->freetype2 to render both Type 1 and TrueType fonts. Now, it turns out that t1lib does a much better job than freetype2 with Type 1 fonts.

So, perhaps Suse has patched Evince, Kpdf & Co. to use t1lib instead of Poppler for Type 1 fonts. In any case, I cannot get the nice output I get with xpdf from kpdf or evince :-(

Hopefully this clarifies the situation. Again, sorry for the initial mistake I made.

On dapper the rendering seems to be correct, could you comment if you try with the next version?

I just tried Dapper Flight 4 (Kubuntu to be precise). I did see some
improvement over Breezy, but xpdf rendering still seems distinctly
superior to kpdf/poppler rendering. It definitely has to do with the
rendering of Type 1 fonts...

On 2/18/06, Sebastien Bacher <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/26118
>
> Comment:
> On dapper the rendering seems to be correct, could you comment if you
> try with the next version?
>

--
Marciano Siniscalchi

Could be a different fontconfig config. You can changes the options with "sudo dpkg-reconfigure fontconfig" if you want to try

I think I nailed it!

First of all, the exact same issue arises in Edgy, which is what I am using now. However, it's easy to fix.

Second, it's a poppler problem, not an Evince problem per se.

See file splash/SplashFTFont.cc in poppler-0.5.4 (the Edgy version), lines 180 and following. This is where poppler loads glyphs for the splash output device; this code comes from xpdf, btw.

Basically, there is a compile-time check to see whether freetype has the bytecode interpreter enabled; if so, IT IS USED regardless of whether anti-aliasing is on or off. Otherwise, no hinting is used if anti-aliasing is on. Again, this is a compile-time check.
The problem is that, for most fonts used with LaTeX (but I'd say for most other fonts, too) it's best to omit hinting altogether.

I fixed the problem by simply deleting the portion of the code that is triggered if TT_CONFIG_OPTION_BYTECODE is defined, and instead leaving only the section that is compiled if it is not. Rebuilding with pdebuild and installing with dpkg -i did the trick.

Ideally, this should be a gconf setting, I guess.

Hope this helps,
M

FWIW, I still see bad rendering of serif fonts in Evince on Feisty.

I've forwarded that upstream: https://bugs.freedesktop.org/show_bug.cgi?id=9862

I had some crufty config enabling the freetype autohinter. Cleaning that up fixed this bug for me.

Please specify which crufty config.

I am running on feisty, and the following:

    dpkg --force-depends --purge fontconfig-config
    rm -rf /etc/fonts
    apt-get -f install fontconfig-config
    rm -rf $HOME/.font*

did not fix the problem for me.

That's what I did, additionally running dpkg-reconfigure fontconfig-config to make sure the hinter type is "native" instead of autohinter.

I was unable to fix the rendering in evince by tweaking those fontconfig-config options. For me, so far only modifying SplashFTFont.cc and recompiling has improved the rendering.

The problem is worst at small font sizes (attachment).

Yes, I did exactly the same, and it works (except that it needs to be
redone every time poppler gets updated...)

Is there any chance of getting the fix incorporated? M

On 2/25/07, Pauli Virtanen <email address hidden> wrote:
> I was unable to fix the rendering in evince by tweaking those
> fontconfig-config options. For me, so far only modifying SplashFTFont.cc
> and recompiling has improved the rendering.
>
> The problem is worst at small font sizes (attachment).
>
> ** Attachment added: "Bad hinting at small font sizes"
> http://librarian.launchpad.net/6527474/evince-bad-hinting.png
>
> --
> Bad rendering (hinting) in Evince and Xpdf
> https://launchpad.net/bugs/26118
>

--
Marciano Siniscalchi

Sorry, my "fix" was bogus. I checked the results with a TeXmacs-produced PDF, which apparently includes different fonts than what e.g. pdfetex does. The TeXmacs fonts look fine. (I wonder why.)

For the record, the fix that works for me is to change the
#ifdef...#else...#endif block beginning at line 179 of file
SplashFTFont.cc as follows:

  // if we have the FT2 bytecode interpreter, autohinting won't be used
  // MS: actually, disregard bytecode setting, as it yields poor results anyway
// #ifdef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
// if (FT_Load_Glyph(ff->face, gid,
// aa ? FT_LOAD_NO_BITMAP : FT_LOAD_DEFAULT)) {
// return gFalse;
// }
//#else
  // FT2's autohinting doesn't always work very well (especially with
  // font subsets), so turn it off if anti-aliasing is enabled; if
  // anti-aliasing is disabled, this seems to be a tossup - some fonts
  // look better with hinting, some without, so leave hinting on
  if (FT_Load_Glyph(ff->face, gid,
      aa ? FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP
                       : FT_LOAD_DEFAULT)) {
    return gFalse;
  }
//#endif

[sorry if I don't generate a patch---I still haven't learned how to do so...]

In other words, I force autohinting off if anti-aliasing is enabled,
regardless of whether or not Freetype was compiled with the bytecode
interpreted on (which, in Ubuntu, it is).

Notice that this compile-time checking that poppler does explains why
this bug is hard to trace. Even if you recompile Freetype without the
BC on, it still won't matter, as poppler is compiled against the
"standard" Ubuntu distribution with BC enabled.

M

--
Marciano Siniscalchi

I see a lot better rendering now. I don't see any relevant entries in the poppler changelog though, so maybe it's something local.

I don't know if this is related, but I'm also seeing absolutely atrocious font rendering with some PDF files in evince.

gpdf renders the same PDFs much better, but appears to use different fonts and ignore settings such as "bold".

Please see the following two screenshot for comparison. Yes, this is the same document, in evince and in gpdf on Ubuntu 6.10.

This is the actual PDF file the above screenshots were taken with.

It's not the same bug. The document you attached uses Type 3 fonts,
which in theory are drawn using Postscript (not PDF) primitives, but
in practice are just bitmaps. Ghostview and Acrobad do a fine job with
these, but poppler-based readers don't handle them well at all.

The issue being discussed here only pertains to Type 1 fonts.

So, unfortunately, I'm afraid your best bet for non-atrocious
rendering is Acroread (yech!)

M

On 3/28/07, Jens Ropers <email address hidden> wrote:
> I don't know if this is related, but I'm also seeing absolutely
> atrocious font rendering with some PDF files in evince.
>
> gpdf renders the same PDFs much better, but appears to use different
> fonts and ignore settings such as "bold".
>
> Please see the following two screenshot for comparison. Yes, this is the
> same document, in evince and in gpdf on Ubuntu 6.10.
>
> ** Attachment added: "Evince pdf screenshot"
> http://librarian.launchpad.net/7035137/Screenshot.evince.png
>
> --
> Bad rendering (hinting) in Evince and Xpdf
> https://launchpad.net/bugs/26118
>

--
Marciano Siniscalchi

Same problem here, bad rendering for (most) PDF files on Evince which work well on acroread, kpdf, gv, etc. Btw I'm using a Feisty machine (Breezy->Dapper->Edgy->Feisty upgrade). PS, DVI files work fine.

@Marciano Siniscalchi
Thank you for your comment.
Do you/does anyone know if there is another bug filed for that Type 3 fonts rendering issue?

Bug 92296 seems to be the bug you're looking for.

Thanks Peter. I've reposted my info there.

Is this solved at all? As of today, I still see some pdf files -but not others (how to tell the difference?) rendering improperly in evince.
When the text is selected, the text is suddenly smooth and nice; when deselected, it's all sketchy and rough.

Also, many equations and punctuation chars disappear when selecting text (an entirely different bug, I assume).

None of the above exist in kpdf. Only evince.

Will we see this fixed anytime soon?

> Will we see this fixed anytime soon?

Depends if somebody work on the issue

The file in comment #25 renders well in Ubuntu 10.10 "Maverick Meerkat" alpha 2 updated to the latest Ubuntu packages.

Uname: Linux 2.6.35-6-generic i686
Packages: evince 2.30.3-1ubuntu2
                  poppler 0.14.1-0ubuntu1
                  libcairo2 1.9.14-1