Apache OpenOffice (AOO) Bugzilla – Issue 15437
Distorted Text in Palatino Linotype Text
Last modified: 2005-02-15 09:07:43 UTC
It looks like the quality of the pdf export has dropped badly in the beta 2, comparing it to beta 1 (which has an overwhelming PDF export, indeed!). The loss of quality becomes increasingly apparent when using small fonts. It is already significant with a 9pt font, but with a 3pt font (yes, really I use that sometimes) it is obvious. This effect is always reproducable. Create an empty drawing and place some text in it and export it to PDF. It seems to me that this problem always occurs.
This is not reproduceable here. Please attach a sxd file and the exported pdf file where the defect is visible. Which font do you use? Thanks in advance.
Created attachment 6764 [details] Two example files which show the problem in OO Beta 2.
Sorry, I cannot attach the cracked PDFs as I already uninstalled OO Beta 2 and erased them. My fault, but the problem should occur when you export the example files provided to PDF. I use the Font "Palatino Linotype". It comes with OO, I suppose.
I recall that the Text already looked distorted in Draw's Window before exporting the graphic. Perhaps this issue is not related to the PDF export at all.
Could you please attach a screenshot of the exact text parts that look distorted? Thanks.
Created attachment 6771 [details] Screenshot at 622% mag. The 3pt font in the background is scratched.
Do you mean with "scratched" that the distance between the characters is different? I can see nothing else that seems to be wrong. Thansk for your help.
Sorry for being unspecific. Yes, I mean: 1. The distance between the characters is wrong. 2. The position of the text as a whole is wrong. It should be within the bounds of the rectangles. With OO Beta 1, both of the above problems disappear.
Ok, now I see. Change the Summary line.
This looks wrong in a current internal version, too. Reassigned to Malte.
If Wolfram repeated it, us external triage folks don't need to, I think, so I'm marking this NEW...
P1? A little bit crazy, changing to P3... MT->FL: Problem occours since we format for screen instead of for printer. Screen has much less DPI than Printer/PDF. This is more a general descission for your team: We could reformat for the PDF, but then you might have other line breaks, same like changing the printer. There are several options you can discus: 1) Should we always format for PDF instead of for Window, if you don't use printer metrics? 2) Reformat for PDF-Export, and don't care if line breaks differ? 3) Offer to add PDF-Export as a printer, and the user can use 'Printer Setttings...' for choosing this. If he doesn't use that 'printer' and starts PDF export, you can give a message that line breaks can differ, and suggest to choose PDF-Export-Printer for WYSIWYE (E=Export).
I do not understand these suggestions. In my opinion, a document must be as accurate as the targeted device can be. Increasing the accuracy only for the PDF export is not sufficient since on the screen still a deviation would be noticable. In a WYSIWIG environment all devices should show the same. This was the case for OO 1.1 beta 1, why not reestablish this behaviour? I still think it is a P1 issue since it is present in all Draw documents with text on the screen and in the printouts.
I should have mentioned that this issue is still present in OOo 1.1 RC.
FL->CJ: What do you think about this issue (sorry havn't seen this one in my intray before).
Reassigned
Here are my thoughts. ... Reformat for PDF-Export, and don't care if line breaks differ? ... Why should there be any dufferent line breaks? Currently I have no clue, but from a users point of view would I expect to see exacly that what I have on my screen. Do Corel, Illustrator or MS with a PDF Export do have the same problems? I think not. We should give the reformat a try, but when differences occour, we have to think about an other soulution. Frank do you agree?
FL->WG: We have already changed the algorithm for SO 7 PP1. We now use 2400 DPI instead of 600 DPI for the virtual device for formatting our documents. Please have a look if this problem still occurs in a current build. Thank you!
Having a closer look at doc UmlDiSVG.sxd you can see that the font already looks distorted before exporting to pdf, so this has nothing to do with PDF (like Jens Fransson suggested 2003-06-10 03:24 PDT). Please have a look at it with a 6.0. Maybe this is connected to internal bug #112335?? Please take a look. Reassigned to Andre.
Issue is still present in release 1.1.0. Looks like I have to stick with 1.1 beta 1...
Set to Office later by demand of AF.
Changed to target 1.1.1 again. That was a mistake, sorry.
Setting the target to Office later and back again was my fault. I'm sorry about that. We are now using the VirtualDevice::SetReferenceDevice() method to increase the resolution used for screen formatting from 96 DPI to 600 DPI. The resulting text formatting is much better.
I am pleased to hear that! Is there any way (other than building from cvs) for me to get an OO version where this issue is fixed? Or do I have to wait for the next official release?
Please check.
The fix is not as good as the 6.0 was. Back to you. Please have a look at the normal, not exported file.
Back to me, my fault ;-) Set to fixed.
Back to me.
Fixed.
Verified in CWS.
*** Issue 20859 has been marked as a duplicate of this issue. ***
*** Issue 19357 has been marked as a duplicate of this issue. ***
*** Issue 22895 has been marked as a duplicate of this issue. ***
*** Issue 22607 has been marked as a duplicate of this issue. ***
Tested in master. Closed.
*** Issue 24877 has been marked as a duplicate of this issue. ***
*** Issue 15643 has been marked as a duplicate of this issue. ***
Created attachment 22635
Created attachment 22636 [details] French text document using the Palatino Linotype font