[Poppler-bugs] [Bug 18379] Okular's poppler-qt4 renders poorlier than Evince's Cairo

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=18379





--- Comment #5 from James Cloos <cloos at jhcloos.com>  2008-11-06 10:16:57 PST ---
It looks like the glyphs in the top window are rendered with freetype’s
autofitter (possibly the light version) and those in the lower window
are rendered by way of the byte code interpreter.  Or perhaps the
difference is due to differing (sub-)pixel alignment.

In the lower window some—but not all—of the glyphs have their vertical
and horizontal stems snapped to whole pixels; none of the glyphs in the
upper window are snapped to pixel boundries.

It is the difference between having some stems snapped—and therefore
black—and others soft grey which makes the okular rendering objectionable.

In short, the (typographic) colour of the text should be even, and that
version of okular/qt4/freetype/fontconfig/ubintu, as configured, is not
generating even colour.

I don’t know whether ubuntu ships freetype with or without the BCI.  If
not then the difference is most likely either that okular or qt4 is
aligning the glyphs on pixel boundries—which would allow the autofitter
to draw vertical and horizontal stems in black—or that ocular/qt4 is
using the default autofitter and evince/cairo the light autofitter.

If ubuntu does compile freetype’s BCI, then I’d bet okular/qt4 is using
it whereas evince/cairo is not.  The font may have some glyphs which
lack instructions or for which the instructions just aren’t as good as
for other glyphs.

And one last possibility is that they are choosing different fonts, if
the pdf does not embed.

(My first guess was embedded bitmaps, but if you look at the snapped
glyphs well magnified it is clear that they are not bitmaps.)

Nanmus:  just in case the PDF does not embed its fonts, you can see
which fonts each of evince and okular are using by examining the file
/proc/$PID/fonts (where $PID is the process id as shown in ps or top).

I’d do:

    :; egrep -i '([ot]tf|pf[ab])' /proc/$PID/maps

That will show all of the fonts the process loaded by way of fontconfig;
both for the document and for the user interface.  Compare that with the
output of pdffonts on the pdf you are using to see whether differing
font choices is relevant.  Unless, of course, if you know that the PDF
embeds all of the fonts which is uses....


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.