Could not reproduce with Linux 3-6-1 exporting to PDF.

Problem still exists in Version 3.6.1.2 (Build ID: e29a214) when saving to pdf via the OSX printing system dialog.

Damn. This is still valid in 3.6.2.2.

Tried it on Mac OS X 10.7 (Swedish) with
LibreOffice 3.6.0beta1: The bug was reproducible
LibreOffice 3.5.6: Not reproducible

Could confirm this with LibreOffice 3.6.1.2 (Build ID: e29a214) on Mac OS X 10.8.2.

Problem is only in the printed PDF (File > Print..., then in print dialog PDF > Save as PDF...), not in the exported PDF (File > Export as PDF...).

Also confirmed with LO 3.6.1.2 (Build ID: e29a214) and OS X 10.8.2. The same LO build on Linux (2.6.32-279.5.1.el6.x86_64) does not exhibit the problem.

Set status to NEW according to comments #4 to comment #6.

However I can NOT reproduce this when exporting directly to PDF file format (“File > Export as PDF...”), just as rl stated in in comment #5; cf. also comment #2: problem appears only when creating a PDF via the Mac OS X printing system.

So this is (mainly) a problem with printing, not with (native LibO) PDF export. Therefore I changed the summary. (NB: the version is not necessary in the summary, we have the version field for that.)

The test document prints normally on OSX 10.8.2 with :

LibreOffice 3.5.6.2 
Build ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0

Samsung Color Laser 3175 FN


and the same document does not print correctly, i.e. I reproduce the buggy behaviour, on the same printer with :

LibreOffice
Version 3.7.0.0.alpha0+ (Build ID: 5c02bb0)


So, this is a regression. Marking as such.



Alex

Adding Norbert and Thorsten to CC.

Alex

I would consider this to be a critical bug, after all, absent driver/OS/printing subsystem changes, the printed output is supposed to remain consistent between versions.



Alex

Added to 3.6 MAB

The problem seems to be independent of Style and Font, as I have tried several different Text styles and various fonts on LO-dev 3.7 and the problem remains.


Alex

@ Alex:

Thank you very much for testing this issue and taking the necessary steps!

Still valid for LO 3.6.3.

hmm... this needs somebody with a Mac to debug...

@Michael: If you install teamviewer we could do a session using my mac. I'd be very happy if this bug get's taken care of.

I have a Mac, but have not been able to build from master since Python 3.3 integration, so no debugging from me, sorry. :-/


Alex

SteveBell: Even if I don't think it's solved with 3.6.4.3 it's always interesting to give an update with last version.
There are daily builds 4.0 for Mac 10.7 here:
http://dev-builds.libreoffice.org/daily/libreoffice-4-0/MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm/current/
I don't know if it would work for MacOs 10.8

Also, do you this problem at preview too? (perhaps it may help to narrow the investigation)

hey Julien, I just tested this against the latest stable 3.6.4.3 and latest beta 4.0.0b2. Since the last daily build is from dec 18th and labeled 4.0.0b1 I'm not sure if it's newer than the b2 builds?

Still reproducible on both versions.

What do you mean by "preview"? I tested this by

* opening the file in question and then hit cmd + p (for printing)
* in the printing dialog select the "PDF" dropdown menu
* select any item, I did "Open PDF in Preview"
* when preview opens I see that the previously space between the letters has been removed

(In reply to comment #19)
> hey Julien, I just tested this against the latest stable 3.6.4.3 and latest
> beta 4.0.0b2. Since the last daily build is from dec 18th and labeled
> 4.0.0b1 I'm not sure if it's newer than the b2 builds?
I think you're right b2 must mean beta2 and obviously beta2 is more recent than beta1 :-) 
> 
> Still reproducible on both versions.
> 
> What do you mean by "preview"? I tested this by
> 
> * opening the file in question and then hit cmd + p (for printing)
> * in the printing dialog select the "PDF" dropdown menu
> * select any item, I did "Open PDF in Preview"
> * when preview opens I see that the previously space between the letters has
> been removed
Menu File, page preview.

Alex: about your building problems due to Python3, did you get by about this?

(In reply to comment #20)

Hi Julien,

> 
> Alex: about your building problems due to Python3, did you get by about this?


Nope, the problem appears to lie with a command in the build script/makefile that tries to strip something from the build after invoking xcrun --strip, and which doesn't exist in the path used by the script. This is with XCode 4.5.2, the latest available version for OSX 10.8.2. I guess that current OSX builds are using an earlier version of XCode which doesn't produce this error (or which drops it silently). The end result is that I still can't build LO on OSX, so I can only use the daily builds, and AFAIK, they are not debug builds.


Alex

I build LO with Xcode 4.5.2 on 10.8.2 and don't notice any build problem with python3 lately... Please send email to the developer list describing your problem in detail.

(In reply to comment #22)
> I build LO with Xcode 4.5.2 on 10.8.2 and don't notice any build problem
> with python3 lately... Please send email to the developer list describing
> your problem in detail.

Hi Tor,

I actually posted this problem twice to the dev mailing list, the first time on December 3rd, and then again on December 8th, with the output of the build failure.

Alex

please STOP polluting this bug with utterly off-topic Python Mac build problem discussion.  use the dev mailing list instead.  thanks.

Version 4.1.0.0.alpha0+ (Build ID: 989863d849b1e703e78afc413088c3ae5109313)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-01-06_10:52:34


Export to PDF : OK, no deletion of spaces around date.
Printing to networked Kyocera FS-C5150DN colour laser printer : wrong output, spaces deleted around date, so that it looks like this :

"den07.09.2012,date"


Alex

(In reply to comment #25)
> Version 4.1.0.0.alpha0+ (Build ID: 989863d849b1e703e78afc413088c3ae5109313)
> TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time:
> 2013-01-06_10:52:34
> 


> Printing to networked Kyocera FS-C5150DN colour laser printer : wrong
> output, spaces deleted around date, so that it looks like this :
> 
> "den07.09.2012,date"
> 


Printing to a PDF file from the Apple print dialog also shows the same error.

Alex

The problem is even worse now with the version of LO daily I tested from Jan 6th, because both dates in the same line have their end spaces removed when the document is printed or printed to a PDF file.


Alex

This is still valid in LO 4.0RC1.

Removed mab4.0 due to <https://wiki.documentfoundation.org/Most_Annoying_Bugs#Overview_of_MAB_tracking_bugs>

Currently I do not see this one NEW due to <https://wiki.documentfoundation.org/QA/BugTriage#Set_Status_.26_Prioritize>, I can't see info concerning
a) Also in other documents reproducible
b) under what conditions does problem happen?
c) all date formattings affected? I really wonder why the PDF export cares about 
   something like a "logical date", I would have expected that only a String in
   the text containing some numbers and dots would be printed.
d) really limited to Writer?
e) may be other (number) formattings also affected?

But may be Michael already knows?

Modified Version due to Comment 4

Well, looking inside the content.xml, one sees that the ODT structure of the text with the two dates is a bit different. (Some pointless styles used for the date that gets rendered broken.) Unfortunately I am not able to see these differences just in LO's UI. (I hate GUi tools that aren't capable of showing what actually is present in a document...) So presumably the PDF export code gets confused by that, or something. What would *really* be helpful is to have a *minimal* reproduction case, of course. (The attached sample file, even if as such quite small, is far from minimal.) Will try to come up with a such myself.

As the reporter of this bug, I'd like to add: if I recall correctly, this might have been a file which originated from a doc file. So maybe the problem was introduced during the conversion? I know this is a bit late for that info, but better late then never.

Also I never encountered this in any document created with LO itself. So maybe playing around with different date formats in word and then opening that with LO gives a clue?

Otherwise feel free to mark this not reproducible and close this thing.

Hah, a recent build of the master branch on the Mac throws up the ah-so-useful "Geeral Error" dialog when trying to load the attached document. But then still opens it. Fun. Might be because of the way I built it, though. (I built using the latest Xcode and Clang, against the 10.7 SDK; the TDF builds are built using an ancient gcc 4.0 from Xcode 3.something.)

I don't see any way to print to PDF in the OS X 10.8.2 print dialog?! What am I missing? I do see "Print to File" but that has only the choice of PostScript.

Hi Tor,

* open document
* cmd + p
* in the left pdf dropdown menu either choose "open as PDF in preview" or "save as pdf"
* then have a look

I don't have any "pdf dropdown menu" in the print dialog. This machine has no printers defined at all, could it be that then you can't print to PDF either? That would be silly.

I'm confused :P

To give you an idea: http://cl.ly/image/3F091m3A1x0P
This would be really wired if it was only available for people with a printer. Others are not allowed to save to pdf or what?

Created attachment 73449 [details]
screenshot of the print dialog

Anyway, isn't is misleading to talk about "export to PDF" in the title of this bug, if it isn't LO's own export-to-PDF functionality where the problem is, but that of the OS?

Ah, ignore my previous comment; don't know why I thought that this bug's subject mentioned exporting to PDF, hmm.

Tor you are absolutely right about this. Sorry, I didn't even know LO had it's own "export to pdf" option. I'm mostly using shortcuts if I can manage to recall them. So was using cmd + p.

Sorry for causing so much hassle about a non-LO bug. Should I report this to apple? Again, feel free to close this if no other users have reported so far. Maybe I can re-open or so should I run into this with a second document?

Well, it is hard to say what the bug actually is without having been able to reproduce it... I will try a bit more, I do have a printer, I just need to add it to the Mac as a remote Windows printer (I don't keep my noisy Windows box running except when necessary, so I haven't bothered adding it to the Mac in question).

Ha, interesting, indeed as soon as I added a printer to the machine the print dialog started looking completely different, and it now has the PDF drop-down button.

OK, now I can reproduce.

The sample document is so overly complex with pointless tables and headers and uses styles in such a weird fashion that I wonder if this isn't mostly a case of GIGO... Why does the character format of most (?) of the text specify Expanded spacing? Is that on purpose? Sure, I guess LO should still not make the print output look different than what displayed on the screen (i.e. it should display it as "broken" on the screen, too, but...)

The problem is clearly related to the use of letter-spacing in the style of the paragraph. "Letter-spacing" is the term used in ODF for what in LO shows up on the Format>Character>Position dialog as "Spacing".

I will attach a more minimal sample document. It contains the text "a, b". It displays like that in LO, with a "space" after the comma. But when printed on the Mac, it looks like "a ,b".

If you edit the styles.xml inside the .odt and remove the fo:letter-spacing="0.004cm" attribute from the "Standard" style, the problem goes away.

Created attachment 73497 [details]
Minimal sample document

OK, so the "styles.xml" is not that minimal, it contains tons of styles not used in the document. I didn't bother to clean that up.

Note that the comma is in no way special; the same problem appears if the text is "aa b", when printed it looks like "a ab".

Note that the "and PDF export" in the "Component" field of this bug refers to LO's *own* PDF export; this bug does not show up when doing that, so it is a bit misleading. This bug is related to printing, which then on OS X has the system-level possibility to also print to PDF.

Nah, I have been adding debugging printouts here and there but haven't figured out anything, sigh. Is this really a "most annoying" bug? How many people intentionally use letter-spacing? Remember what Frederic Goudy said, "Anyone who would letter space lower case would steal sheep." ;)

I have no Mac to reproduce this bug.
can anyone confirm it on recent 4.0.4 or 4.1.0 releases?
if yes, I'll move it to the mab4.0 list since 3.6.x is EOL.

tommy27, thanks for pinging on this.

I can happily announce that after 50 comments and almost a year later this bug if FIXED in 4.1.1.1. Setting to WORKSFORME. I tried the LO internal PDF creation as well as the OS X PDF creation. Tried printing the document. All show fine.

Great work everybody. :)

Not sure what patch fixed this, maybe related to the core text changes?

@James
nice to hear that!!!

@Tor
can you confirm this?

WFM

64bit LO from master :
Version: 4.2.0.0.alpha0+
Build ID: 22d1beb78a475e4846af945afde1c4d6c263b5d6

Alex