[poppler] What about Bug +3307 now?

Albert Astals Cid aacid at kde.org
Fri Aug 14 01:50:49 PDT 2009


A Divendres, 14 d'agost de 2009, vàreu escriure:
> On Fr, 2009-08-14 at 00:22 +0200, Albert Astals Cid wrote:
> > A Dijous, 13 d'agost de 2009, Tobias Wolf va escriure:
> > > The merit can only be seen by looking at many PDFs at several zoom
> > > levels. Especially small text is much more readable.
> > >
> > > But here is one striking example from the bug report:
> > > https://bugs.freedesktop.org/attachment.cgi?id=19607
> > > (top is current state, middle is the goal)
> >
> > I see almost no difference between top and middle, i'm sorry.
>
> I find that hard to believe. 

Hope you're not calling me a lier here, otherwise we can stop the discussion.

> Let me explain what you should see. So we
> are on the same page. Also, please make sure you view the image on an
> LCD not a CRT.

BENQ FP937S+, yes it's an LCD

> - Only the black text differs, the red text is annotation

I guessed

> - The first criterion is contrast. How sharp are the edges?
>
>   * The horizontal arms and serifs are much sharper. Examples: « E,T »
>     This is due to HINT_SLIGHT (hinting only in y-axis, doesn’t affect
>     kerning)

I can barely see a difference here, i have to put my eyes VERY close to the 
monitor to do so.

>   * Diagonal strokes are less coarse. Examples: « X,N »

Not for my eyes

>   * Round bowls are sharper: Examples: « C,o,0,8 »

Very slightly

>   * These two are better thanks to LCD filtering courtesy of FreeType.
>
> - The second criterion is how well the letter shapes are preserved.
>   You cannot see that in this example. Monochrome text has 100%
>   contrast, but the shapes are poor in monochrome. It’s a trade-off
>   with a sweet spot.

Does this mean that this technique makes some other fonts render worse? If so 
why should we change from one bad to another bad? If we do, won't we get the 
other side of the fence complaining?

> > > Please give guidance how to proceed.
> >
> > If there is anything that needs to be patched in poppler, give us patches
> > that someone can understand and apply, we hardly reject patches, the
> > problem is that there's not much people "reviewing" patches because
> > there's not much people at all contributing to poppler.
>
> In many distros there is at least a community effort to keep Poppler
> patched to provide this. This is because people notice.

No, this is because distros suck, if they have patches to Poppler they should 
submit them to us for inclusion in mainline code.

> The most complete patch I found is at [1]. I don’t really understand it,
> and I don’t know who wrote it and AFAIK it wasn’t even submitted to this
> list. Also it seems to not work together with the most recent Evince.
> Although, it works via PyPoppler, according to my tests.
>
> Myself, I have been using the patches attached to the bug I’m talking
> about. But they apply in part to Poppler and in part to Evince. And in
> the last iteration of Evince they stopped working most of the time.
>
> Just google "+poppler +subpixel". There is genuine interest among users.
> Of course it is also a matter of preferences and the eyes and displays
> involved.

Let me be more clear, as stated personally i do not see a difference big 
enough to guarantee me spending time there when i have lots of other bugs i do 
see the difference, so i'm not doing any effort on fixing it. So if someone 
wants it fixed he'll have to stand up, create patches we can understand and 
submit them here for proper discussion.

Albert

>
>
> --Tobias
>
> [1]
> http://hg.core.ws/devnull/raw-file/b1bdcf09782a/dev-libs/poppler-glib/files
>/poppler-glib-0.10.7-hinting.patch



More information about the poppler mailing list