Red Hat Bugzilla – Bug 244656
Overlapping glyphs on export to pdf with openoffice.org (Arial)
Last modified: 2007-11-30 17:12:07 EST
Description of problem:
OpenOffice.org has several problem of font displaying/printing. For example, all
r characters in menu are strangely blured and documents are rendered poorly when
printed or exported into PDF
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch OpenOffice.org
Poor font displaying : see the attached screen captures
Tried stock version 2.2.0 from openoffice.org: the problem doesn't occur. Menus
are clean and generated pdf/printed documents are rendered as it might be expected.
Created attachment 157275 [details]
Screen capture of openoffice.org main window
Created attachment 157276 [details]
screenshot of the pdf exported by fedora OOo
Screenshot of the pdf exported by fedora OpenOffice.org as rendered by evince.
Created attachment 157277 [details]
Screenshot of the pdf exported by legacy OOo
Screenshot of the pdf exported by the OpenOffice.org version of OO.o Writer
Possibly freetype is b0rked again. What happens for you on the openoffice.org
version if you delete /opt/openoffice.org.whatever/program/libfreetype.* and
repeat the test with the upstream version ?
Though the "r" on screen display might also be an ati radeon related thing, do
you have an ati radeon ?
Created attachment 157278 [details]
my screen shot
I can't reproduce a similar problem, it all works fine for me :-(
Yes, it is a radeon...
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon
About the freetype library, only found one in
/opt/openoffice.org/program/filter/libfreetype.so.6. Removal didn't change
anything about the problem.
Can you try this for me, it requires an X restart. Add
Option "RenderAccel" "Off" to your xorg.conf
Nice one. Disabling the render acceleration solves the garbled menu problem (but
of course not the export/printing problem)
Created attachment 157279 [details]
Test-case opendocument file
The test-case document triggers this problem.
Created attachment 157280 [details]
Screenshot of the test-case as rendered by evince
ok, so lets divide and conquer, the ati radon "r" bug is split off as bug 244675
as it's clearly the cursed xrender problem back again. The remainder of this
issue will be regarding the remaining pdf export problem.
I still can't reproduce the 2nd part either, my output still looks good, so some
more information may help. My leading suspect here is freetype as I've seem
something like this before which had a freetype trigger :-), so what's...
a) rpm -qf rpm -qf /usr/lib/libfreetype.so.6
b) and what does fc-match "Arial" say ?
c) and can you attach the output .pdf which isn't rendering correctly for you so
I can make sure that it also renders busted for me, i.e. that the pdf has
captured the problem as a snapshot.
You *may* find that changing the zoom in OOo by using the scroll wheel
inwards/outwards might cause this bug to sort of move about the place as the
calculation of character position is done with differently scaled figures.
Created attachment 157283 [details]
Test-case rendered as pdf
a) rpm -qf /usr/lib/libfreetype.so.6
[goujonl@jaeger ~]$ rpm -qf /usr/lib/libfreetype.so.6
[goujonl@jaeger ~]$ fc-match "Arial"
arial.ttf: "Arial" "Normal"
c)Didn't use scroll wheel so not sure if is it relevant...
ah!, you actually *do* have Arial installed, while I've got the liberation-fonts
replacement instead. That's probably the vital difference.
reproducible with Arial
Possibly in the same arena as bug 224539 and bug 235341
Created attachment 157291 [details]
after fiddling with freetype
Reverting the autofit changes from freetype 2.3.1 to 2.3.2 gives the superior
rendering attached above => moving to freetype
Created attachment 157292 [details]
patch -p1 -R this patch
i.e. this bit makes it work a lot better
This really belongs to upstream.
More digging seems to show that what we have here is a difference in one part of
OOo's default spacing and some other part detecting that this default spacing is
actually not default spacing and trying to recover the positioning and slapping
the second part of the string of text overlapping the other part of the string.
Presumably if the two default spacings can be reconciled then there would be
just a single string in the pdf and just the initial x,y written, and the it
would all work out fine, instead of multiple sequences with slightly incorrect
Alternatively forcing the pdf export to always position every glyph separately
would do it too, but make big big pdfs. Let me see if I can see why the default
spacing test fails.
I think I have it, will be in next update.
openoffice.org-2.2.1-18.1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.