No subpixel rendering

Reported by Tobias Wolf on 2007-01-22
218
This bug affects 41 people
Affects Status Importance Assigned to Milestone
Poppler
Confirmed
Wishlist
poppler (Ubuntu)
Low
Ubuntu Desktop Bugs
Nominated for Karmic by Սահակ

Bug Description

Can we enable FreeType’s subpixel rendering mode in Poppler? Just asking whether that’s possible.

this hasn't happened yet as far as I can tell

Tobias Wolf (towolf) wrote :

Can we enable FreeType’s subpixel rendering mode in Poppler? Just asking whether that’s possible.

Here is a proof-of-concept kludge. It’s a ~10 line patch that forces subpixel rendering in the cairo backend:
  <http://anders.kaseorg.com/pub/patches/poppler-subpixel.patch>

The major issue is that I disabled the clipping region. My debugging revealed that when the dimensions of the clipping rectangle translate to non-integral numbers of pixels, cairo fails to translate this rectangle into a pixman region in _cairo_traps_extract_region, and instead uses some fallback code that doesn’t support subpixel rendering. BTW, I wonder if this fallback code is also a performance problem...

I'm not familiar enough with Cairo to say what should be done about this, but maybe this will give someone else ideas.

Created an attachment (id=8715)
patched example 1

(In reply to comment #2)
> Here is a proof-of-concept kludge.

I gave it a shot and it works quite well (at least superficially).
I cannot add much for the implementation but I can try to document the change.

I’ll attach some examples with mixed copy in pairs; with (SR) and without the patch (noSR).

Switching back and forth helps seeing what differences there are.
For me small type has better contrast with subpixel rendering, but quite obvious kerning problems are apparent with SR. Those also appear elsewhere (e.g., GTK windows)
Ignore the graphics in the Nature example, they are not antilaliased because Ubuntu builds poppler with splash only.

TBH I expected a more salient effect, one that was immediately apparent patching Xft for browsing for instance. Perhaps this is due to the fact that in PDFs the point sizes vary so much.

Created an attachment (id=8716)
unpatched example 1

Created an attachment (id=8717)
patched example 2

Created an attachment (id=8718)
unpatched example 2

Created an attachment (id=8719)
patched example 3

Created an attachment (id=8720)
unpatched example 3

Created an attachment (id=8727)
acroread 7 example 3

Now comparing the rendering with Adobe’s so-called "CoolType" the similarity is striking. The letters are extremely similar. Reader has different kerning problems and worse yellow collision artifacts, while we have some redness problems in vertical stems (on my screen of course).

I surely prefer patched Poppler over Acroread.

You’re basically comparing Splash with Cairo, and so the fonts are likely to be rendered in very different ways (like different hinting methods). If you compare Cairo with subpixel Cairo, you should find that the letter spacing is identical; all that will change is that the letters will be sharper on LCD screens. (It is theoretically possible to take advantage of subpixel rendering to position letters more accurately in 1/3-pixel increments, but I don’t think current Cairo does that yet.)

Any color artifacts you see are Cairo’s fault. I recommend applying this patch, which makes Cairo use Freetype 2.3’s (much better) subpixel filtering: <http://www.freetype.org/freetype2/patches/cairo-1.2.4-lcd-filter-1.patch> Anyway, any improvements in these areas are Cairo’s job and not Poppler’s.

On the Poppler side, all we need to do is figure out the clipping problem I mentioned above, and make Poppler respect the desktop-wide font rendering settings.

(In reply to comment #10)
> You’re basically comparing Splash with Cairo, and so the fonts are likely to
> be rendered in very different ways (like different hinting methods). If you
> compare Cairo with subpixel Cairo, you should find that the letter spacing is
> identical; all that will change is that the letters will be sharper on LCD
> screens. (It is theoretically possible to take advantage of subpixel rendering
> to position letters more accurately in 1/3-pixel increments, but I don’t
> think current Cairo does that yet.)

I was aware that the comparison is flawed but I was also a bit lazy. Still the images document a quite significant improvement. And yes subpixel kerning is my next big wish. I’m afraid it will not be easy though. Conceptually the vert. stems that you can more or less still fit to the grid now will then have to be shifted, with a risk of more artifacting (e.g., consider « ill » with SR kerning).

> Any color artifacts you see are Cairo’s fault. I recommend applying this
> patch, which makes Cairo use Freetype 2.3’s (much better) subpixel filtering:
> <http://www.freetype.org/freetype2/patches/cairo-1.2.4-lcd-filter-1.patch>
> Anyway, any improvements in these areas are Cairo’s job and not Poppler’s.

The color artifacts are not that bad actually, they are worse for Adobe. I actually already have the Freetype 2.3.1 flavor and Poppler was a missing piece of the puzzle, that you thankfully created.

> On the Poppler side, all we need to do is figure out the clipping problem I
> mentioned above, and make Poppler respect the desktop-wide font rendering
> settings.

Hope you can work it out.

Hmm, somehow re-patching a new Ubuntu package (0.5.9-9ubuntu1 / gutsy) doesn’t give subpixel rendering anymore, even though the patching should’ve worked.

This patch was pretty awesome, couldn’t we get someone to review it?

From the cairo point-of-view, a patch to poppler like this should
not be needed and should not be applied. If poppler is rendering
to a cairo-xlib surface and the user has requested sub-pixel rendered
fonts, (by configuring font preferences in GNOME or KDE dialogs or
whatever), then cairo should be doing subpixel rendering.

If it's not, then masking that bug by forcing the rendering on, (and
hard-coding a particular sub-pixel order), doesn't help anything and
will hurt any users that don't want this.

Please find the real problem, and we'll definitely want to fix it,
but please don't apply this patch.

-Carl

PS. Reading back over the original description of the patch, it sounds
like Anders is describing a real problem, (a non-integer clipping
rectangle being passed to cairo). For cairo, I'm still curious as to
why that should disable sub-pixel rendering, (that sounds like a bug).
But meanwhile, the right thing to do, and likely the easiest, is to
simply fix poppler to correctly round the crop box values to integers
before passing them to cairo. And yes, this should also improve
performance.

Pedro Villavicencio (pedro) wrote :

that's an upstream request and you can ask that on the poppler mailing list not in a bug tracker, thanks.

Changed in poppler:
status: New → Invalid
Tobias Wolf (towolf) wrote :

Posted at mailing list, problem is due to bug in Cairo backend surface code.

https://bugs.freedesktop.org/show_bug.cgi?id=3307

Changed in poppler:
status: Invalid → Confirmed
Changed in poppler:
status: Unknown → Confirmed
Changed in poppler:
importance: Undecided → Low
status: Confirmed → Triaged
assignee: nobody → desktop-bugs
Tom Jaeger (thjaeger) wrote :

Could someone please explain what the deal is with evince linking against libpoppler2?

Tom Jaeger (thjaeger) wrote :

Nevermind, evince/intrepid links against libpoppler3.

Tom Jaeger (thjaeger) wrote :

quick-and-dirty workaround

Tom Jaeger (thjaeger) wrote :

This deb should enable subpixel smoothing in evince. It needs the evince package from intrepid.

Tobias Wolf (towolf) wrote :

Tom, that patch from freedesktop bugzilla is not cool. It messes with the symptoms but not with the cause of the bug. Did you read the comments in the thread?

http://lists.freedesktop.org/archives/poppler/2008-May/003814.html

Tom Jaeger (thjaeger) wrote :

The patch from bugzilla has a more obvious problem: It doesn't work. So I created this patch which will at least give people what they want even if it's not the "right" solution. That's what "quick-and-dirty workaround" means. Obviously I wouldn't even think about submitting this upstream, but does anybody really think upstream is going to fix this anytime soon? This really shouldn't be too hard to fix for someone with some knowledge of the inner workings of poppler and cairo, but apparently people don't care about subpixel smoothing.
Poppler leaves the cairo font options at their default settings, but the cairo documentation is quiet about how it is determined what the default settings are (strangly enough, if I draw into a pixbuf via a simple gtkmm/cairomm program, subpixel smoothing is enabled, but it'll use lcdfilterlegacy). So I've decided that it's not worth my time going through the cairo source trying to figure this out.

Tobias Wolf (towolf) wrote :

Right, that’s fair enough. As long as you don’t propose this as the fix.
In your patch, why do you hard code pixel order to RGB? What if someone rotates his screen?

Tom Jaeger (thjaeger) wrote :

It doesn't matter. I don't know where the font options come from, but they definitely don't come from gconf. So even if you don't explicitly set the pixel order, it'll still assume RGB.

Tobias Wolf (towolf) wrote :

Patch seems to do what what it says on the box, with nice results.

Looking at the poppler core and glib parts, it seems that the surface used is not a cairo-xlib, but a cairo-image surface. To me that sounds like a reasonable explanation for cairo not using the xlib options!

Maybe a solution would be to create temporarily a small xlib surface, copy its font options using cairo_surface_get_font_options() and apply them using cairo_set_font_options()?

Ok, I've looked at the bug a bit deeper. To me it seems there are two different problems:
* poppler_page_render()
This actually works a bit: if I pass a surface which has font options set to subpixel antialiasing, some fonts are correctly antialiased. For instance, I've modified poppler-glib-demo, and either forcing the font options of an cairo_image surface or asking to render directly on the xlib surface leads to some font being antialiased with subpixel. (I'll come back to this later on.)

* poppler_page_render_selection_to_pixbuf()
This is the place which comment #2 "fixed". A cairo image surface has default font options set to simple antialiasing. That's perfectly fine, after all no one knows what is going to be done with this pixbuf. The problem is that some applications uses this function and later display the pixbuf on the screen. So I see three possible solutions, depending on what is the purpose of the function (I don't know enough poppler to decide):
 - it's supposed to be a generic function, for rendering anywhere approximately correctly and easily used: then don't modify the function, update the API description to let know the developers that the antialiasing of the fonts is fixed to grey levels.
 - it's supposed to be a generic function, but can be complexified: add a second function which has another parameter for font_options. Therefore the developers can decide which antialiasing to use (for instance by copying the values of X).
 - it's supposed to be specific to glib on a screen: Add inside the function a read to the default values in glib and setup the font options accordingly.

Problem with some fonts:
I've noted that in the PDFs some fonts, do get correctly displayed following the subpixel antialiasing, while some don't. At first look, it seems that type1 embedded are correctly displayed, but TrueType embedded are not (always grey). This is a major problem.

Also, I've noticed that in poppler/CairoFontEngine.cc, the load of fonts is forced with FT_LOAD_NO_HINTING, I wonder if it's a good idea. There is no comment explaining why this is so...

> Also, I've noticed that in poppler/CairoFontEngine.cc, the load of fonts is
> forced with FT_LOAD_NO_HINTING, I wonder if it's a good idea. There is no
> comment explaining why this is so...

I would guess this is because it is important for a PDF viewer to give an accurate reproduction of a printed page, and the purpose of hinting is to sacrifice accurate metrics and color for increased contrast.

Since the legacy LCD filter (FC_LCD_LEGACY / FT_LCD_FILTER_LEGACY / CAIRO_LCD_FILTER_DEFAULT(!)) adds bad color fringing to unhinted text, it might be a good idea to also ensure that the LCD filter is FC_LCD_DEFAULT or FC_LCD_LIGHT.

Created an attachment (id=19607)
Comparing HINT_NONE to HINT_SLIGHT

> I would guess this is because it is important for a PDF viewer to give an
> accurate reproduction of a printed page, and the purpose of hinting is to
> sacrifice accurate metrics and color for increased contrast.
>
> Since the legacy LCD filter (FC_LCD_LEGACY / FT_LCD_FILTER_LEGACY /
> CAIRO_LCD_FILTER_DEFAULT(!)) adds bad color fringing to unhinted text, it might
> be a good idea to also ensure that the LCD filter is FC_LCD_DEFAULT or
> FC_LCD_LIGHT.
>

This is interesting. I didn’t realize that Poppler disables hinting. It’s true that full hinting would alter the positioning due to the pixel snapping, but fortunately HINT_SLIGHT does not, because it only hints in the vertical axis to reduce smear on horizontal strokes.

Combined with the so called DEFAULT LCD filter HINT_SLIGHT gives really nice results -- without affecting the positioning. See the attachment.

Ooohhh, I really wish all my PDFs could be displayed with HINT_SLIGHT & FIR5! Just out of curiosity, what did you modify to force it?

BTW, I think that for precise positioning of small glyphs, it could be possible to do sub-pixel positioning, as defined here: http://www.freetype.org/freetype2/docs/glyphs/glyphs-5.html . For the small glyphs, instead of generating one glyph per character, it would generate 4 glyphs (or whatever number) corresponding to the possible displacement compared to the base pixel. Then depending on the exact position of the character, the best fitting of the 4 glyphs would be used.

Created an attachment (id=19620)
Layered Gimp file comparing small text

(In reply to comment #18)
> Ooohhh, I really wish all my PDFs could be displayed with HINT_SLIGHT & FIR5!
> Just out of curiosity, what did you modify to force it?

Well, I simply removed lines with FT_LOAD_NO_HINTING and then changed CAIRO_HINT_STYLE_NONE to CAIRO_HINT_STYLE_SLIGHT. I realized last night that sometimes vertical hinting leads to roundish letters drooping slightly below the baseline at certain zoom levels. This is the only drawback I found.

> BTW, I think that for precise positioning of small glyphs, it could be possible
> to do sub-pixel positioning, as defined here:
> http://www.freetype.org/freetype2/docs/glyphs/glyphs-5.html . For the small
> glyphs, instead of generating one glyph per character, it would generate 4
> glyphs (or whatever number) corresponding to the possible displacement compared
> to the base pixel. Then depending on the exact position of the character, the
> best fitting of the 4 glyphs would be used.

Yes, this is one thing that should be looked at some time in the future. Actually David Turner implemented an algorithm that adjusts kerning by caching side-bearing deltas before and after hinting, .i.e., no actual subpixel positioning. But the results are already striking. The ftdiff tool is a good demo for this.
If you want to see how it looks when positioning is done well, download the attachment, open it in Gimp, and compare the layers. The top layer is so much more regular and readable than what Poppler and Cairo produce.

Tobias Wolf (towolf) wrote :

It seems that Poppler also disables hinting completely. I created test packages in a special PPA that enable both slight hinting, which really improves vertical text contrast, and the default LCD filter, which improves horizontal contrast a great deal.

I had to revert the removal of the FreeType LCD filtering API in Cairo 1.7.6 so that Tom’s patch still works as intended. The PPA sources can be found here:

https://edge.launchpad.net/~improved-lcd-filtering/+archive

The attachment shows one example of the effect of slight hinting and the subpixel LCD filter.
Please test, you will see that in most cases it improves readability, but for some (thin) fonts and zoom levels, there’s also color fringing.

mbana (m.bana) wrote :

Can someone please explain in layman terms when subpixel rendering is going to be available in evince (okular), the difference between a pdf and the fonts which evince renders is huge.

I've started a thread on the Evince mailing lists; http://news.gmane.org/gmane.comp.gnome.apps.evince.general hopefully it'll get fixed soon enough.

I'm also surprised more people aren't aware of this.

Tobias Wolf (towolf) wrote :

Mohamed, can you try my packages above and see if they are an improvement? I think they achieve what you are looking for.

mbana (m.bana) wrote :

Tobias: Thanks. Your package offers huge improvements over the standard one, but, I use hintfull as my default hinting style and I'm curious as to how your changes would look if you compiled with hintfull instead of hintslight.

Screenshot; http://img381.imageshack.us/my.php?image=popplerhintslightmk3.png

Download full text (3.7 KiB)

Presently, and as noted in comment #15, poppler-glib appears to use font options from the surface it was given by the caller. It is rather convenient, as it allows to implement management of subpixel rendering from the application with minimal effort. As an example, here's a patch for evince pdf backend that hard-codes horizontal rgb with slight hinting:

diff -pur evince-2.24.2-r1/work/evince-2.24.2/backend/pdf/ev-poppler.cc evince-2.24.2-r2/work/evince-2.24.2/backend/pdf/ev-poppler.cc
--- evince-2.24.2-r1/work/evince-2.24.2/backend/pdf/ev-poppler.cc 2008-11-24 22:09:30.000000000 +0300
+++ evince-2.24.2-r2/work/evince-2.24.2/backend/pdf/ev-poppler.cc 2009-01-19 01:15:15.048150478 +0300
@@ -451,14 +451,22 @@ pdf_page_render (PopplerPage *page,

 #ifdef HAVE_POPPLER_PAGE_RENDER
        cairo_t *cr;
+ cairo_font_options_t *options;

        surface = cairo_image_surface_create (CAIRO_FORMAT_RGB24,
                                              width, height);
        memset (cairo_image_surface_get_data (surface), 0xff,
                cairo_image_surface_get_height (surface) *
                cairo_image_surface_get_stride (surface));
+ options = cairo_font_options_create ();
+ cairo_surface_get_font_options (surface, options);
+ cairo_font_options_set_antialias (options, CAIRO_ANTIALIAS_SUBPIXEL);
+ cairo_font_options_set_subpixel_order (options, CAIRO_SUBPIXEL_ORDER_RGB);
+ cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_SLIGHT);

        cr = cairo_create (surface);
+ cairo_set_font_options (cr, options);
+ cairo_font_options_destroy (options);
        switch (rc->rotation) {
                case 90:
                        cairo_translate (cr, width, 0);

So I think poppler is already doing its job with regards to subpixel rendering.

However, I'd like to second the point from comment #17: I believe it is better to use slight hinting instead of disabling hinting altogether. What about something along these lines:

diff -pur poppler-0.10.0/poppler/CairoFontEngine.cc poppler-0.10.0-r1/poppler/CairoFontEngine.cc
--- poppler-0.10.0/poppler/CairoFontEngine.cc 2008-09-22 22:25:45.000000000 +0400
+++ poppler-0.10.0-r1/poppler/CairoFontEngine.cc 2008-10-31 14:10:27.000000000 +0300
@@ -80,7 +80,7 @@ _ft_new_face_uncached (FT_Library lib,
     return gFalse;

   font_face = cairo_ft_font_face_create_for_ft_face (face,
- FT_LOAD_NO_HINTING |
+ FT_LOAD_TARGET_LIGHT |
                                                          FT_LOAD_NO_BITMAP);
   if (cairo_font_face_set_user_data (font_face,
                                     &_ft_cairo_key,
@@ -214,7 +214,7 @@ _ft_new_face (FT_Library lib,
   _ft_open_faces = l;

   l->font_face = cairo_ft_font_face_create_for_ft_face (tmpl.face,
- FT_LOAD_NO_HINTING |
+ FT_LOAD_TARGET_LIGHT |
                                                          FT_LOAD_NO_BITMAP);
   if (cairo_font_face_set_user_data (l-...

Read more...

Created an attachment (id=22153)
comparison of Alexander’s patch vs. one that sets CAIRO_LCD_FILTER_FIR3 explicitly

Alexander, your patch is interesting. Which is the Cairo version you are using? If it’s greater than 1.7.4, then I think the Cairo surface will use the internal intra-pixel method for LCD filtering. This is clearly worse than what I have shown above because one cannot really mate the intra-pixel method with light hinting due to excessive color bleeding. See the image

> Alexander, your patch is interesting. Which is the Cairo version you are using?
> If it’s greater than 1.7.4, then I think the Cairo surface will use the
> internal intra-pixel method for LCD filtering. This is clearly worse than what
> I have shown above because one cannot really mate the intra-pixel method with
> light hinting due to excessive color bleeding. See the image
>

Right, I should have mentioned I'm assuming patched cairo. Right now I'm using 1.8.4 with, IIUC, ubuntu's lcd filtering patches. On the content I read there's no color bleeding.

I'm also seeing the problem mentioned in comment #15: some embedded truetype fonts are not subpixel-antialiased.

Alexander Blinne (sunday) wrote :

I'm still looking forward to seeing out-of-the-box subpixel-support in libpoppler. What's the news since November?

Hi,

Tobias packages makes font rendering so much better in Evince, but not in Okular :-(
I took a quick look at the Okular source code and there's no reference to Cairo.. how could I enable subpixel rendering in this case?

Rahhhh, this problem is driving me crazy !..
So Okular/Poppler-QT4 in fact doesn't use Cairo at all, but uses "Arthur" instead. Yay, back to square one!

As Tom Jaeger pointed out earlier, why nobody seem to care about subpixel smoothing in PDF readers ?!
In fact I have subpixel smoothing for about every text in KDE and Gnome but the two main PDF readers, the kind of app that displays the heaviest quantity of text on an end-user machine with web browsers.. how convenient !...

The problem with Evince is that scrolling is too fast(abrupt), there's no way to slow it down and I always need to hide the next part of the text in order to try to guess it (maths course books). That plus the lack of annotations.. So back on Okular and its eye-damaging fonts.

Flooder out, hope we'll this fixed someday (?).

Is there any chance that somebody tackles that one day? Subpixel smoothing is now used everywhere but when viewing PDF and PS files, which is when you read the most text. Thanks! ;-)

ViktigLemma (jorgsk) wrote :

I have this problem too in Okular. The results are slightly better when I don't use T1 fonts in Latex as per this bug report

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

but still the fonts in Okular from latex-generated documents are thin and weak.

mattibal (mattibal) wrote :

I tried to install the packages from the PPA above, but they didn't solved the problem.
It changed the font rendering method, but it didn't enabled subpixel rendering.
In the attachment there is a comparison between the same pdf viewed in Evince with and without PPA's packages. Sorry if they doesn't have the same level of zoom, but they look the same also with another level of zoom.
I'm using Ubuntu Karmic x86-64, in Gnome font settings I have set Slight subpixel smoothing, and it works fine in all apps.
I had also modified /etc/fonts/conf.d when I was running jaunty in order to enable subpixel rendering in jaunty's firefox-3.5, but this has never give me a problem, because I have only put system-wide the same settings that there are in gnome.

Tobias Wolf (towolf) wrote :

Mattibal can you post the output of this command please?

    dpkg -l | grep "poppler\|evince\|libevview\|libevdoc\|libcairo2"

mattibal (mattibal) wrote :

This is the output (I've removed package descriptions on the right):

ii evince 2.29.2-0ubuntu2~ppa3
ii libcairo2 1.8.8-2ubuntu3~ppa2
ii libevdocument1 2.28.1-0ubuntu3~ppa1
ii libevdocument2 2.29.2-0ubuntu2~ppa3
ii libevview1 2.28.1-0ubuntu3~ppa1
ii libevview2 2.29.2-0ubuntu2~ppa3
rc libpoppler-glib3 0.8.7-1ubuntu0.2
ii libpoppler-glib4 0.12.0-0ubuntu3~ppa1
ii libpoppler-qt4-3 0.12.0-0ubuntu3~ppa1
rc libpoppler3 0.8.7-1ubuntu0.2
rc libpoppler4 0.10.5-1ubuntu2.5
ii libpoppler5 0.12.0-0ubuntu3~ppa1
ii poppler-utils 0.12.0-0ubuntu3~ppa1
ii python-evince 2.28.0-0ubuntu1

Tobias Wolf (towolf) wrote :

I’m not sure why it doesn’t work for you. You have the full set of packages.

Unfortunately I moved my system onwards to Lucid, so I can’t reproduce your setup.
But I know that a friend added this PPA on his Karmic sytem and it worked.

Anyway, I upload another Evince to the Karmic PPA. Can you try again in a while?

Also, do you have a ,fonts.conf?

Ilja Sekler (ilja-sekler-) wrote :

The latest packages from the PPA work fine for me on Karmic, but why does the evince version

2.29.2-0ubuntu2~ppa3

as reported by dpkg and apt-cache differ from

2.29.5-0ubuntu5~ppa3

as listed at <https://edge.launchpad.net/~improved-lcd-filtering/+archive/ppa>? If I rebuild the packages from source on my system, which requires deleting any references to hardening-includes in debian/rules and debian/control, I get the correct version.

(This is totally unrelated, but evince 2.29.5, at least on Karmic, doesn't save gui configuration globally but does this on per-file base, which is utterly annoying...)

Ilja Sekler (ilja-sekler-) wrote :

Never mind, was too quick. Now apt-cache reports the correct version.

Tobias Wolf (towolf) wrote :

Ah yes. Now I can imagine what went wrong. For some files the patch does nothing. I’m not sure why, but I have a hunch that it is related to what type of fonts are embedded. So on these oddball files you always get gray antialias.

Ilja, I reported that exact bug in Gnome Bugzilla. Please go there and confirm this annoyance.
https://bugzilla.gnome.org/show_bug.cgi?id=606090

Tobias, your improved-lcd-filtering PPA contains a version of poppler labelled as “0.12.4-0ubuntu4~ppa1”. However, it is actually based on 0.12.4-0ubuntu1, and is missing the changes in Ubuntu’s 0.12.4-0ubuntu2, even though it claims to have a higher version.

Similarly for evince 2.29.92-0ubuntu4~ppa1 based on 2.29.92-0ubuntu1, and cairo 1.8.10-2ubuntu4~ppa1 based on 1.8.10-2ubuntu1 (updated Ubuntu versions haven’t been released yet for these, but when they do they will have a lower version number than your packages).

You should version packages that are based on Ubuntu’s -XubuntuY as either -XubuntuYppa1 or -Xubuntu(Y+1)~ppa1, not anything higher, because otherwise you might prevent the user from receiving important security upgrades when Ubuntu releases -Xubuntu(Y+1). (If you need to release more than one PPA version, change ppa1 to ppa2, etc.)

Hello Anders, you just caught me being sloppy. I needed a method to
override the packaged versions and by trial and error it appeared that I
have to increment ubuntuX. I had been using this method for a while when
I figured I can save work for myself if skip incremental updates during
development period if I use ubuntuX+n.

Perhaps I should use a bit more care considering that these packages are
also consumed publicly.

On another note, you posted a patch in 2007 to the upstream bug report.
Can’t we do anything to close this upstream? I know upstream wants a
patch and sees no difference between LCD filter and no filtering anyhow.
But really.

And then there’s the issue that Carl Worth removed the LCD filtering API
from Cairo because some test suite images came out differently. In PDF
rendering we cannot follow the desktop settings because only slight
hinting and the across-pixel filter work properly on PDFs. We have to
have control over the font rendering settings.

> I needed a method to override the packaged versions and by
> trial and error it appeared that I have to increment ubuntuX.

No; the correct versioning scheme for a PPA is described here:
https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning

> On another note, you posted a patch in 2007 to the upstream bug report.
> Can’t we do anything to close this upstream?

I hope so (though the particular patch I posted in 2007 isn’t useful anymore).

> I know upstream wants a patch and sees no difference between LCD
> filter and no filtering anyhow. But really.

It’s totally reasonable for them to want a patch, and there’s no reason to believe that they “see no difference”.

> And then there’s the issue that Carl Worth removed the LCD filtering API
> from Cairo because some test suite images came out differently.

That was a long time ago in the 1.7 branch. Freetype LCD filtering has never been in a stable release of Cairo; Ubuntu has been patching it in.

> In PDF rendering we cannot follow the desktop settings because
> only slight hinting and the across-pixel filter work properly on
> PDFs.

Those are the default desktop settings these days on Ubuntu, right? But anyway, why should PDFs need to be any different than the rest of the desktop?

Tobias Wolf (towolf) wrote :
Download full text (3.6 KiB)

> No; the correct versioning scheme for a PPA is described here:
> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning

Duly noted.

> > I know upstream wants a patch and sees no difference between LCD
> > filter and no filtering anyhow. But really.
>
> It’s totally reasonable for them to want a patch, and there’s no reason
> to believe that they “see no difference”.

Well, yes. And I received a stupefying reaction when I expressed
disbelief about this claim back then:
http://lists.freedesktop.org/archives/poppler/2009-August/005008.html

> > And then there’s the issue that Carl Worth removed the LCD filtering API
> > from Cairo because some test suite images came out differently.
>
> That was a long time ago in the 1.7 branch. Freetype LCD filtering has
> never been in a stable release of Cairo; Ubuntu has been patching it in.

The removal of filtering API is something in addition to that (i.e.,
just using the filters that FreeType provides) and Ubuntu doesn’t patch
that back in now. What I think is needed to set the filter method on the
canvas is cairo_font_options_set_lcd_filter() and that was removed in
this commit:

commit 5d887ad5dca5af0f8216830d1b04d08a5aba9bee
Author: Carl Worth <email address hidden>
Date: Thu Sep 25 13:31:20 2008 -0700

    Remove all lcd_filter code.

    We reverted the public API for setting lcd_filter font options
    back in 1b42bc8033bc , but we had left the implementation which
    would examine fontconfig and Xft properties for the option, and
    which would call into freetype for subpixel glyph rasterization.

    However, I recently realized, (and the test suite had been trying
    to tell me for a while), that this approach would cause a
    regression for users who were previously using sub-pixel text,
    but without sub-pixel rendering built directly into freetype.
    That's not acceptable, so all the code is coming out for now.

and:

API changes since 1.7.4
-----------------------
There have been a few changes of API that was new during the 1.7
series:

* Remove cairo_font_options_set_lcd_filter
   and cairo_font_options_get_lcd_filter

  Motivation: At the Cairo Summit, this API was determined to be too
        specific to the freetype font backend to be in the general
        API. A similar API with a cairo_ft prefix might be introduced
        in the future. Note that cairo will still respect the
        corresponding fontconfig settings for these options.

> > In PDF rendering we cannot follow the desktop settings because
> > only slight hinting and the across-pixel filter work properly on
> > PDFs.
>
> Those are the default desktop settings these days on Ubuntu, right? But
> anyway, why should PDFs need to be any different than the rest of the
> desktop?

Yes, but there are still many users who revert back to the old look and
the old filter (e.g.: http://goo.gl/tnvl )

In a PDF strong hinting and that intra-pixel filtering model don’t
really work. In PDF you have a scalable canvas and fractional advance
widths. In normal on-screen text you have integer advances, so pixel
snapping/quantization makes some sense. But there is a reason that
Poppler disables h...

Read more...

> Well, yes. And I received a stupefying reaction when I expressed
> disbelief about this claim back then:
> http://lists.freedesktop.org/archives/poppler/2009-August/005008.html

Sounds like he sees a slight difference, not enough to personally care
about it, but would accept a good patch if someone else cares enough to
write one.

> The removal of filtering API is something in addition to that (i.e.,
> just using the filters that FreeType provides) and Ubuntu doesn’t patch
> that back in now.

The filtering API was introduced in 1.7.2 and removed in 1.7.4/1.7.6; it
has never been on the stable 1.6 or 1.8 branches. Ubuntu has never had a
package with this API, except briefly during the Intrepid development
cycle.

The way forward here is to work with Cairo upstream to resolve the
problems with users whose FreeType lacks subpixel rendering, and try get
the patches reintroduced for the 1.9 branch.

> Yes, but there are still many users who revert back to the old look and
> the old filter (e.g.: http://goo.gl/tnvl )

People’s monitors, vision, and preferences differ; they always will. We
should respect that instead of forcing our preferences upon them.

> The reason is that you would get very bad kerning if you would enable
> full hinting in a PDF.

Hasn’t that been a solved problem for many years?
http://fishsoup.net/articles/grid-fitting/

(I personally prefer slight hinting, but if different settings work for
other people that’s fine with me!)

Tobias Wolf (towolf) wrote :

On Mi, 2010-03-24 at 09:12 +0000, Anders Kaseorg wrote:

> The way forward here is to work with Cairo upstream to resolve the
> problems with users whose FreeType lacks subpixel rendering, and try get
> the patches reintroduced for the 1.9 branch.

Yes, I hope they will pick this up soon.

The test suite point is something I didn’t really agree with. If a
distribution wants to avoid the risk of patent infringement and disables
LCD filtering then it doesn’t matter if the code doing the filtering is
at a lower or higher level. The FreeType solution to higher level
libraries requesting LCD filtering then was to just render R=G=B, which
I agree is a lame way to handle it.

> > Yes, but there are still many users who revert back to the old look and
> > the old filter (e.g.: http://goo.gl/tnvl )
>
> People’s monitors, vision, and preferences differ; they always will. We
> should respect that instead of forcing our preferences upon them.

Right, everything should remain configurable. But we need a method to
configure LCD filter on an app-by-app basis. Just asking FontConfig is
not enough, is my point.

Behdad E. agrees:
http://lists.cairographics.org/archives/cairo/2010-January/018920.html

> > The reason is that you would get very bad kerning if you would enable
> > full hinting in a PDF.
>
> Hasn’t that been a solved problem for many years?
> http://fishsoup.net/articles/grid-fitting/

Theoretically yes. But not in practice. Not at all. It would look like
Fig.6. The worst part is that in a PDF you don’t get continuous runs of
text (viz. paragraphs) that the renderer is at liberty to layout itself.
You get chunks of glyphs that have precisely defined coordinates, and
unless to stick to »natural« metrics you will get bad looking text.

Stormking (marcus-klemm) wrote :

@Tobias Wolf

I installed the latest patched versions of libpoppler, libcairo and evince from your PPA but evince still does not use subpixels. Are there any config files I need to edit or something?

Tobias Wolf (towolf) wrote :

I missed a minor update to Evince that came through lucid-updates last week.
I uploaded a new patched package that takes precedence again.

Stormking (marcus-klemm) wrote :

@Tobias Wolf

That's not what I meant. I did notice that there was an official, unpatched package that was more recent than yours but I didn't install it. I'm sure I have your patched versions installed but PDFs are still rendered using greyscale-antialiasing. I checked with xmag.

Adobe Reader does it right (tested with the same file). Any ideas what couldbe wrong?

Ciao, Stormking

Tobias Wolf (towolf) wrote :

Did you try a number of PDF files? It seems that some types of PDF are always grayscale by virtue of how the fonts are embedded in them. PDF documents generated by OpenOffice are among those for instance.

I don’t feel terribly confident with these patches at all to be frank. It would be good if a person who knows what she is doing were to take a look at this and have a go at a proper solution.

Created an attachment (id=36194)
Set ft load flags depending on current font settings

This patch sets the ft load flags depending on current font settings. You can try with poppler-glib-demo.

Enabling sub-pixel hinted text turns out to be far tricker than one naively expects. This is due to the number of intermediate layers through which PDF is rendered, all supporting just a single alpha channel. At the moment, the only way I can think of supporting sub-pixel hinted geometry (why just limit it to text ;-) is through the use of auxiliary alpha maps, i.e. we need to preserve per-component alpha through the entire render pipeline in order to composite correctly onto the destination framebuffer. Tricky, but not impossible.

I've noticed that in Poppler 0.14, there are a lot more fonts that are not subpixel-rendered with this patch. In the 0.12 series, pdfTeX documents for instance were subpixel-rendered fine, but not in 0.14. Is this something that could be addressed, or is there currently no way?

By the way, this is the exact patch I'm using to force subpixel-rendering:

http://aur.archlinux.org/packages/poppler-qt-lcd/poppler-qt-lcd/0003-Forcing-subpixel-rendering-in-Cairo-backend.patch

Created an attachment (id=37991)
poppler-python demo left, popper-glib demo right

Chris, if what you’re saying is that there is a fundamental obstacle, why is it that python-poppler render with proper LCD filtering by default?

This is evident running its test script demo-poppler.py. Compiled against latest Poppler.

(In reply to comment #27)
> Created an attachment (id=37991) [details]
> poppler-python demo left, popper-glib demo right
>
> Chris, if what you’re saying is that there is a fundamental obstacle, why is it
> that python-poppler render with proper LCD filtering by default?

because python poppler demo fills in white before rendering, while we do it after rendering using DEST_OVER operator. We need to do that for blend modes to work.

> This is evident running its test script demo-poppler.py. Compiled against
> latest Poppler.

Changed in poppler:
importance: Unknown → Wishlist

Sadly, it would appear that this patch no longer works with Cairo 1.10.0:

/home/dannpg/Projects/pkgbuilds/poppler-qt-lcd/src/poppler-0.14.0/poppler/CairoOutputDev.cc:191:51: error: ‘CAIRO_LCD_FILTER_FIR5’ was not declared in this scope
/home/dannpg/Projects/pkgbuilds/poppler-qt-lcd/src/poppler-0.14.0/poppler/CairoOutputDev.cc:191:72: error: ‘cairo_font_options_set_lcd_filter’ was not declared in this scope

Any suggestions?

Changed in poppler:
importance: Wishlist → Unknown
Changed in poppler:
importance: Unknown → Wishlist

Hello guys!

(In reply to comment #29)
> Sadly, it would appear that this patch no longer works with Cairo 1.10.0:
> Any suggestions?

Have any plans for fixing this bug?

Thomas Hotz (thotz) on 2012-10-01
Changed in poppler (Ubuntu):
status: Triaged → Confirmed

Created attachment 84143
poppler-0.22.5 Set ft load flags depending on current font settings

The old patch doesn't work anymore with actual versions of Poppler. The updated patch was created for Poppler-0.22.5. Haven't been tested with Poppler-0.24.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.