Created attachment 54894 [details]
odg file with screen prints: 100 and 140 % zoom

(In reply to comment #1)
> Created attachment 54894 [details]
> odg file with screen prints: 100 and 140 % zoom

PLease look at the *second* page in the attachment.
(I forgotten that there was a first one, with not so clear set-up IMO)

Created attachment 54902 [details]
png showing part of the previous document at 170% zoom

Created attachment 54903 [details]
xmag prints, three in one

thanks for the tip about xmag :-)

Created attachment 54904 [details]
xmag comparing UI elements

I'd *guess* that its the upgrade of cairo from 1.8.0 to 1.10.2 which gives you different subpixel rendering between beta1 and beta2.

i.e.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6bd7d6c6691f22fca902bbd02bd26376c0265c72

Unfortunately its subjective which is "better" or "worse". I imagine we're just getting changes here because the version of cairo changed.

I'd like to see a side-by-side of the same text in writer and the same text in gedit (where gedit is configured manually to use the same text size and font as writer) to compare against what your "system" cairo does.

I'd echo Caolan's ask - we need to match what the system is doing; annoyingly my panel / pixel ordering is not the same as yours - so the text looks terrible anyhow. Do you see noticable false-coloring too ? If so perhaps your options are busted as well. It also appears that in the new "no settings" world the setting to tweak this has disappeared - most odd.

It seems that gtk+ gets those from the settings:

gtk/gtksettings.c-  g_object_get (settings,
gtk/gtksettings.c-                "gtk-xft-antialias", &antialias,
gtk/gtksettings.c-                "gtk-xft-hinting", &hinting,
gtk/gtksettings.c-                "gtk-xft-hintstyle", &hint_style_str,
gtk/gtksettings.c-                "gtk-xft-rgba", &rgba_str,
gtk/gtksettings.c-                NULL);

Which it seems come from various XSettings, which come from:

gnome-settings-daemon/plugin/xsettings/gsd-settings-manager.c (xft-settings-get):

        order = g_settings_get_enum (manager->priv->plugin_settings, FONT_RGBA_ORDER_KEY);

Where order is from dconf at:

org/gnome/settings-daemon/plugins/xsettings/

#define FONT_RGBA_ORDER_KEY   "rgba-order"

Which can be tweaked in dconf-editor to any of the value of that enumeration provided: which may perhaps help (if you're running GNOME).

Now - IIRC, Cor runs KDE - so ... perhaps this is also an issue; I wonder if gtk+ is relying on getting it's sub-pixel order from an XSetting that KDE is simply not providing - if so, it's rather a more problematic problem.

But - as Caolan says - we can tell that from seeing a screenshot of gedit on the same desktop quite easily ;-) give us a full-screen screenshot as a straight attachment with gedit and LibreOffice side-by-side if you would :-)

Thanks !

(In reply to comment #8)

> Now - IIRC, Cor runs KDE

You may remember that you suggested that before ;-) 
But also then, I had to tell you that I run Gnome (the 'old' one).

in passing I installed a recent ubuntu under virtualbox and indeed it looks like ass, if I copy the system libcairo2.so.2 which is libcairo2-1.10.2-6ubuntu3 over our internal copy then it looks fine.

its quite possible that the build environment controls this, i.e. the RHEL-X freetype headers that it gets built against that sort of thing

(In reply to comment #11)
> its quite possible that the build environment controls this, i.e. the RHEL-X
> freetype headers that it gets built against that sort of thing

When upgrading, I had to hardcode a value "4" for a missing fontconfig or maybe freetype enum in order to be able to build with the RHEL4 fontconfig/freetype combo. Look at the cairo patch. It is possible that I might have done something wrong there.

If I build our internal cairo on Fedora 15/Latest Ubuntu and copy that over, then it looks good, which suggests that its something external to the internal cairo affecting the output. e.g. freetype/fontconfig/xrender ifdefs or some such, but not that patch.

my money is on HAVE_FT_LIBRARY_SETLCDFILTER

That seems to be it alright.

re-building internal cairo on a RHEL-4 box with

http://cgit.freedesktop.org/libreoffice/core/commit/?id=79f5f4c97188e8584aceb6af98473c06f40f7500

applied and copying the resulting libcairo2.so over onto a modern ubuntu install and it does the right thing

proposed for 3-5