Bug 426295

I'm sure I've fixed this about 8 times, and every time I look again the exact
meaning of the gnome/cairo settings wrt. what they map to, esp. the unset things
changes ever so slightly. I'll check this out tomorrow.

hmm, does adding that ~/.fonts.conf *really* make a difference. That perplexes
me. Is this with a freetype that has been recompiled to enable subpixeling ? I
can't see any difference in OOo with or without that.

I mean, we do render differently from gnome at the moment and I can see that and
it would be nice to enhance OOo in that direction, but I'm not sure I'm looking
at the same problem.

No it doesn't make a difference. I checked again. this workaround doesn't work.
I didn't examine the font carefully last time.
It helps QT4 but the OOo problem is still there.
I am really sorry.

Ah, that's good then. Both looking at the same thing. cairo has a complicated
set of stuff to achieve all this lcd targeted stuff, not just a simple flag
passed to freetype. In OOo we do honour all the various settings and pass them
down to fontconfig the same as cairo does, so that bit works. But we probably
need to use cairo directly to render glyphs from a given font for us to get the
desired intergration.

We're already using icu for portability reasons and a lot of the rest of our
stuff is based up on top of its other features, to I'm loathe to get into a port
to pango instead re-work, which'd be the knee-jerk solution.

But maybe we could function a bit like pango and use cairo to render glyphs from
font to our icu derived positions for us which would give us subpixel
antialiasing and we'd render each glyph the same as everything else, while
retaining the same positioning as we have already.

So what you mean is OOo uses its own layout and rendering engine even for the UI
elements?

It is reasonable to use its own engine for rendering the document. However if we
want OOo to be more OS integrated, for rendering the menus, toolbar, and
dialogs, it should use the OS's engine instead.

If the OS itself doesn't support internationalization well, neither should the
UI of OOo in that OS. The only thing need to keep invariant from platform to
platform is the document, but the UI elements.

It is OK for the Document font not to respect the OS's setting, though. Just
imagine if one sets the anti-alias option to subpixel, and when he/she type some
text in a GIMP image. The text should be rendered according to GIMP's options.
(usually) nobody expects to have some color stuff around the text in a gimp image.


I hope these arguments make some sense.

Yeah, but that's a truly monumental task. We have plans afoot upstream around
that, moving in stages first to a new widget description step and then
implementation of that directly with native widgets instead of the current
"render native widgets into non-native ones and then render our own text on top
of them" solution (i.e. the firefox style mechanism). Big task to untangle the
UI elements from the, shall we say, "core widget" inside the UI frame as there's
no clear distinction between one and the other today.

Nevertheless, even in the "core widget", while we want to hold to our exact
positions for text for wysiwyg cross-platform goodness, it still looks like a
good idea to use the native OS text rendered to render each glyph on-screen if
possible, so I'll hold this task back for myself to take a look at and not just
bundle it off as a dup to the upstream "widget layout" task.

checking in work-to-date into rawhide on an experimental basis enableable with
export SAL_ENABLE_CAIROTEXT=1

Will be in >= 2.4.0-4.1

Its the default now in rawhide/fc9 2.4.0-5.1, to disable use SAL_DISABLE_CAIROTEXT=1