[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 #6 from nanmus <nanmus at gmail.com>  2008-11-08 00:00:52 PST ---
Hi, thanks for the professional reply which is very impressive.

I guess now you clearly know what the problem is and please get it fixed.

Thanks again.

ps: I use Kubuntu instead of Ubuntu.

On 11/7/08, bugzilla-daemon at freedesktop.org
<bugzilla-daemon at freedesktop.org> wrote:
> 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 QA contact for the bug.
> You reported the bug.


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