Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Overlapping glyphs on export to pdf with openoffice.org (Arial)|
|Product:||[Fedora] Fedora||Reporter:||Laurent Goujon <laurent.goujon>|
|Component:||openoffice.org||Assignee:||Caolan McNamara <caolanm>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||2.2.1-18.2.fc7||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-04 04:08:16 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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): 2.2.0-14.11 How reproducible: Always Steps to Reproduce: 1. Launch OpenOffice.org 2. 3. 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 7500] 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 freetype-2.3.4-3.fc7 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 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 positions. 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.