Bug 244656

Summary: Overlapping glyphs on export to pdf with openoffice.org (Arial)
Product: [Fedora] Fedora Reporter: Laurent Goujon <laurent.goujon>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: 2.2.1-18.2.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-04 04:08:16 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 244675    
Description Flags
Screen capture of openoffice.org main window
screenshot of the pdf exported by fedora OOo
Screenshot of the pdf exported by legacy OOo
my screen shot
Test-case opendocument file
Screenshot of the test-case as rendered by evince
Test-case rendered as pdf
after fiddling with freetype
patch -p1 -R this patch none

Description Laurent Goujon 2007-06-18 08:16:40 EDT
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):

How reproducible:

Steps to Reproduce:
1. Launch OpenOffice.org
Actual results:
Poor font displaying : see the attached screen captures

Expected results:

Additional info:
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.
Comment 1 Laurent Goujon 2007-06-18 08:16:40 EDT
Created attachment 157275 [details]
Screen capture of openoffice.org main window
Comment 2 Laurent Goujon 2007-06-18 08:19:14 EDT
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.
Comment 3 Laurent Goujon 2007-06-18 08:20:46 EDT
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
Comment 4 Caolan McNamara 2007-06-18 08:26:52 EDT
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 ?
Comment 5 Caolan McNamara 2007-06-18 08:34:57 EDT
Though the "r" on screen display might also be an ati radeon related thing, do
you have an ati radeon ?
Comment 6 Caolan McNamara 2007-06-18 08:52:30 EDT
Created attachment 157278 [details]
my screen shot

I can't reproduce a similar problem, it all works fine for me :-(
Comment 7 Laurent Goujon 2007-06-18 09:12:34 EDT
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.
Comment 8 Caolan McNamara 2007-06-18 09:18:56 EDT
Can you try this for me, it requires an X restart. Add 
Option "RenderAccel" "Off" to your xorg.conf
Comment 9 Laurent Goujon 2007-06-18 09:33:34 EDT
Nice one. Disabling the render acceleration solves the garbled menu problem (but
of course not the export/printing problem)
Comment 10 Laurent Goujon 2007-06-18 09:36:28 EDT
Created attachment 157279 [details]
Test-case opendocument file

The test-case document triggers this problem.
Comment 11 Laurent Goujon 2007-06-18 09:37:23 EDT
Created attachment 157280 [details]
Screenshot of the test-case as rendered by evince
Comment 12 Caolan McNamara 2007-06-18 09:58:36 EDT
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.
Comment 13 Laurent Goujon 2007-06-18 10:12:20 EDT
Created attachment 157283 [details]
Test-case rendered as pdf
Comment 14 Laurent Goujon 2007-06-18 10:14:02 EDT
a) rpm -qf /usr/lib/libfreetype.so.6
[goujonl@jaeger ~]$ rpm -qf /usr/lib/libfreetype.so.6

b) fc-match
[goujonl@jaeger ~]$ fc-match "Arial"
arial.ttf: "Arial" "Normal"

c)Didn't use scroll wheel so not sure if is it relevant...
Comment 15 Caolan McNamara 2007-06-18 10:16:24 EDT
ah!, you actually *do* have Arial installed, while I've got the liberation-fonts
replacement instead. That's probably the vital difference.
Comment 16 Caolan McNamara 2007-06-18 10:27:28 EDT
reproducible with Arial
Comment 17 Caolan McNamara 2007-06-18 11:01:30 EDT
Possibly in the same arena as bug 224539 and bug 235341
Comment 18 Caolan McNamara 2007-06-18 11:52:53 EDT
Created attachment 157291 [details]
after fiddling with freetype
Comment 19 Caolan McNamara 2007-06-18 11:54:20 EDT
Reverting the autofit changes from freetype 2.3.1 to 2.3.2 gives the superior
rendering attached above => moving to freetype
Comment 20 Caolan McNamara 2007-06-18 11:55:09 EDT
Created attachment 157292 [details]
patch -p1 -R this patch

i.e. this bit makes it work a lot better
Comment 21 Behdad Esfahbod 2007-06-18 16:24:00 EDT
This really belongs to upstream.
Comment 22 Caolan McNamara 2007-06-19 03:48:53 EDT
Comment 23 Caolan McNamara 2007-06-25 10:54:44 EDT
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.
Comment 24 Caolan McNamara 2007-06-26 10:10:18 EDT
I think I have it, will be in next update.
Comment 25 Fedora Update System 2007-07-30 12:58:35 EDT
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.