Bug 426295 - Openoffice.org doesn't render text with subpixel antialiasing
Openoffice.org doesn't render text with subpixel antialiasing
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-19 15:35 EST by Feng Yu
Modified: 2008-02-01 05:04 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-01 05:04:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 46020 None None None Never
OpenOffice.org 85470 None None None Never

  None (edit)
Description Feng Yu 2007-12-19 15:35:51 EST
Description of problem:
Setting gnome's antialias to subpixel has no effect on openoffice programs.

Version-Release number of selected component (if applicable):
2.3.0-6.7.fc8

How reproducible:
Always

Steps to Reproduce:
1. Goto Look and Feel -> Appearance and set antialias to subpixel
2. Open openoffice writer.
  
Actual results:
font in other gtk programs are subpixel antialiased, while font in openoffice
are not. This create an inconsistent appearance.

Expected results:
Openoffice respect the gnome settings.

Additional info:
If I Add a new line in ~/.fonts.conf to force fontconfig set antialias method to
rgba:
    <match target="font">
        <edit name="rgba" mode="assign">
            <const>rgb</const>
        </edit>
    </match>
openoffice will be happy.

both before and after adding the fonts.conf line, "xrdb -q |grep Xft" shows:
Xft.antialias:  1
Xft.dpi:        96.000000
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.rgba:       rgb

So I guess the underline reason is that Openoffice doesn't respect Xrdb
settings. However since Xrdb contains the most current info, any X program
should respect it.

This bug also affects QT4.
Comment 1 Caolan McNamara 2007-12-19 15:47:28 EST
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.
Comment 2 Caolan McNamara 2007-12-20 11:06:23 EST
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.
Comment 3 Feng Yu 2007-12-20 12:38:42 EST
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.

Comment 4 Caolan McNamara 2007-12-20 13:05:14 EST
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.
Comment 5 Feng Yu 2007-12-20 13:46:34 EST
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.

Comment 6 Caolan McNamara 2007-12-20 14:02:11 EST
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.
Comment 7 Caolan McNamara 2008-01-23 08:15:41 EST
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
Comment 8 Caolan McNamara 2008-02-01 05:04:10 EST
Its the default now in rawhide/fc9 2.4.0-5.1, to disable use SAL_DISABLE_CAIROTEXT=1

Note You need to log in before you can comment on or make changes to this bug.