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.
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 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.
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 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...
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.
https://savannah.nongnu.org/bugs/index.php?20209
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.
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.