> 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 hinting completely. The reason is that you would get
very bad kerning if you would enable full hinting in a PDF.

The thing is, there are ways to improve upon unhinted fonts. Slight
hinting quantizes in y-direction only, which doesn’t affect kerning at
all. And LCD filtering can improve contrast without affecting the
advance widths of the glyphs.

This is why in PDF we should force some settings and not use the global
desktop settings.