Issue 108674 - PDF: font formatted as "Times;Times New Roman" becomes exported as if has extra character spacing
Summary: PDF: font formatted as "Times;Times New Roman" becomes exported as if has ext...
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: DEV300m70
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-01-26 12:11 UTC by triplemaya
Modified: 2017-05-20 11:17 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Shows extra char in front of footnote anchor - saves to rtf as empty file (697.19 KB, text/plain)
2010-01-26 12:12 UTC, triplemaya
no flags Details
resulting PDF from DEV300_m70 (11.32 KB, application/pdf)
2010-06-17 13:14 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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
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 2010-06-17 13:14:14 UTC
Created attachment 70051 [details]
resulting PDF from DEV300_m70
Comment 6 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 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(?)
Comment 8 Marcus 2017-05-20 11:17:37 UTC
Reset assigne to the default "".