> 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 protected]> 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. -- No subpixel rendering https://bugs.launchpad.net/bugs/80921 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
