Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||PDF: font formatted as "Times;Times New Roman" becomes exported as if has extra character spacing|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||hdu, issues, michael.ruess|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description triplemaya 2010-01-26 12:11:01 UTC
When I export to pdf, an extra space appears at a random point. The same happens if I copy and paste to a plain text document. If I paste the text back into the odt doc and then export a pdf the space is not there. BUT, whenever I insert a footnote, there is a mystery space in front of the footnote anchor. Exploring this problem I saved the file as an rtf file. This results in an empty file!? So it seems like a serious bug. It appears to be new in 3.0. Hoping for a workaround I opened the affected file on a different machine, windows 7 instead of my linux box, where it looked exactly the same as on the other machine, and exported the pdf in that environment. The resulting file has a space between every character! The footnotes, however, are not affected. Clearly this is not a trivial issue! Help urgently sought as I'm hoping to send out the pdf shortly and the spaces make it look very amateurish. Thanks in advance. I have a very small file with the problem but I can't see any way to attach it to this issue.
Comment 1 triplemaya 2010-01-26 12:12:41 UTC
Created attachment 67420 [details] Shows extra char in front of footnote anchor - saves to rtf as empty file
Comment 2 michael.ruess 2010-01-26 15:47:30 UTC
Can confirm on Windows. Export attached document to PDF and open in Adobe Reader -> the font looks very ugly. Export is better when I reformat the text in Writer to simply "Times New Roman".
Comment 3 philipp.lohmann 2010-01-28 13:57:10 UTC
@hdu: please have a look
Comment 4 triplemaya 2010-01-28 15:34:55 UTC
Sorry for my ignorance, how do I do that? I don't know where the xml files are stored, and for some reason at present neither google desktop search or the gnome search tool are working!? (Not a good sign) Or have I got this all wrong and all I need to do is change a setting in the standard interface? Whatever this setting is I have no knowledge of setting it. Cheers.
Comment 5 email@example.com 2010-06-17 13:14:14 UTC
Created attachment 70051 [details] resulting PDF from DEV300_m70
Comment 6 firstname.lastname@example.org 2010-06-17 13:27:18 UTC
Looking at the resulting PDF it seems that the PDF-specific base14-font handling has problems with a non-default font width so the glyphs in the PDF get squeezed. The glyph positions themselves would be fine if the glyphs were not squeezed. The glyphs being squeezed only in the PDF on WIN platforms probably has to do with WIN being the only platform on OOo where the obsolete "average char width" concept is still used for backwards compatibility. The bugdoc isolates the problem nicely, thanks. It is always a good idea to attach something (screenshot, PDF, etc.) where one can see the problem directly in the issue. Having to setup test environment, loading a document etc. delays this a lot.
Comment 7 email@example.com 2010-06-17 14:53:13 UTC
The easiest solution would be to avoid the squeezing at all. For some reason the stretch factor of this text is 101% as can be seen in Format->Character->Position->ScaleWidth. The story behind the problem with stretching is that this is very dependent on the font on WIN. The stretch factor is not stored explicitely, but as the ratio with an "average char width". Due to some bad design decision 20years ago and some million documents later this too-direct-to-the-GDI approach is causing very tricky problems once in a while: When several font faces are selected in one font request (such as in "Times;Times New Roman") and the same font width request is used for fonts with different "average char widths" problems are bound to happen, especially if the reference device and the target device (PDF) resolve the request differently. Long words->short summary: finding the code in footnote handling where this superfluous and problematic stretching gets introduced and getting rid of that, is the best solution reassigning to OD as the footnote-code owner(?)