Issue 125012 - PDF Export Issues
Summary: PDF Export Issues
Status: UNCONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: 4.1.0
Hardware: Mac OS X 10.9
: P3 Major with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needmoreinfo
Depends on:
Blocks:
 
Reported: 2014-05-30 14:46 UTC by jason
Modified: 2017-10-02 16:15 UTC (History)
7 users (show)

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


Attachments
Text snippet from AOO410 Writer showing correct type (212.15 KB, image/png)
2014-06-26 14:50 UTC, dkistner
no flags Details
Test Snippet from PDF Export showing em dash and font bug (270.13 KB, image/png)
2014-06-26 14:51 UTC, dkistner
no flags Details
Text snippet of export to PDFA1a showing em dash and font bug (343.35 KB, image/png)
2014-06-26 14:53 UTC, dkistner
no flags Details
PDF: the em dash messes up following en dashes (69.42 KB, application/pdf)
2014-11-13 15:59 UTC, Chris Torrence
no flags Details
PDF: the en dash messes up following em dashes (69.18 KB, application/pdf)
2014-11-13 16:02 UTC, Chris Torrence
no flags Details
PDFs showing the bug in Ooo v4.1.0 & v4.1.1 against MS Word & OOo's Print option (466.23 KB, image/png)
2015-09-20 21:56 UTC, Nandhini
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jason 2014-05-30 14:46:27 UTC
I've been using OpenOffice Writer for many versions now. I've never had a problem with the PDF Export button in the main toolbar until now. I create a lot of PDF's through Writer and email them to my clients. Once I updated to version 4.1.0 (yesterday), my clients could not print the PDF's. All of them had the same errors...

"The document could not be printed." followed by... "There were no pages selected to print."

I had a disk image for version 4.0.1 which I reverted too. I tried exporting PDF's using the old version and it works like a charm.

I've also tried this on a windows 7 computer and experienced the same issue.
Comment 1 hdu@apache.org 2014-06-02 08:41:02 UTC
Could you attach a small test-doc and the resulting PDFs (from AOO401 and from AOO410) where the second PDF exhibits the problem?
Comment 2 dkistner 2014-06-26 14:48:22 UTC
I, too, am having PDF export issues with AOO 4.1.0 for the Mac. While the preflight in Adobe Acrobat reports the correct font has been embedded in the PDF, the font is different in the PDF and also the em dash sets wrong and with space after it. I've never had this problem before. It's critical we have reliable PDF export because we publish all of our books using Open Office (which we find superior to InDesign for our to-print/to-digital workflow).

I'm attaching a text snippet from AOO plus the exports via PDF and to PDF/A-1a.

What was the last version of AOO that I can install to correct this problem until the bug is resolved?
Comment 3 dkistner 2014-06-26 14:50:21 UTC
Created attachment 83605 [details]
Text snippet from AOO410 Writer showing correct type

PDF Export Issues File 1 of 3
Comment 4 dkistner 2014-06-26 14:51:46 UTC
Created attachment 83606 [details]
Test Snippet from PDF Export showing em dash and font bug
Comment 5 dkistner 2014-06-26 14:53:09 UTC
Created attachment 83607 [details]
Text snippet of export to PDFA1a showing em dash and font bug
Comment 6 Chris Torrence 2014-11-13 15:50:02 UTC
I can reproduce a similar "em dash" bug using OpenOffice 4.1.1 on Mac OS X (Yosemite). I'm using a font called Minion Pro.

The problem occurs with "Export as PDF", but does not occur with Print (to PDF).

If I use an em dash first in my document, then any en dashes that occur later in the document get converted to em dashes and actually overlap the following character. In other words, the space between characters is still an en dash.

Conversely, if I use an en dash first, then any em dashes get converted to en dashes. Again, the spacing is still "correct" for an em dash, which means there is a big gap.

The problem does *not* occur for Times New Roman or Palatino. For those fonts, Export as PDF gives the correct dashes. I have not tried other fonts.

Two workarounds: (1) use Print (to PDF). The problem is that you don't end up with a PDF/A-1a compliant document and you can't export the chapter bookmarks. Or (2) replace all en dashes with "minus" signs (U2212). This works but is obviously not ideal since it's so much easier to enter en dashes using option+hyphen.
Comment 7 Chris Torrence 2014-11-13 15:59:54 UTC
Created attachment 84190 [details]
PDF: the em dash messes up following en dashes

Attachment showing how using an em dash (with Minion Pro) messes up en dashes later in the document. This is with "Export as PDF".
Comment 8 Chris Torrence 2014-11-13 16:02:31 UTC
Created attachment 84191 [details]
PDF: the en dash messes up following em dashes

Attachment showing the opposite behavior: using an en dash (with Minion Pro) messes up em dashes later in the document. This is with "Export as PDF".

Note that the Palatino font seems to have trouble with Exporting that "arrow" symbol. Again, Print (as PDF) works fine.

What's going on with "Export as PDF" with all of these special characters?
Comment 9 Nandhini 2015-09-20 21:56:41 UTC
Created attachment 84924 [details]
PDFs showing the bug in Ooo v4.1.0 & v4.1.1 against MS Word & OOo's Print option

I was able to successfully replicate this bug in both 4.1.0 and 4.1.1 versions on MAC OS X Yosemite v10.10.5.

Tests: 
With the font face Time New Roman, I tried typing text that includes em, en, and hypen.
Then, I tried the 'Export As PDF' option. It worked.

I repeated the same procedure for different font face, New Waltograph. This time the exported PDF file had a different symbols instead of em & en.

For the font face, atlantix pro ssi & DK Crayon Crumble, the exported PDF had empty space instead of em & en.

Last 3 font faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble) are all installed by user. So finally, I exhaustively tried all font faces that came with OOo. It worked fine for all except the font face HeadLineA.

I tried 'Ctrl+P' and then Save As PDF instead of 'Export as PDF' for the 3 font faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble). It worked.

I tried this with MS WORD. It worked when I saved as PDF.


Summary:
Export As PDF messes up em & en for user installed font faces.

Conclusions:
I didn't experience any messes that caused variation in em & en lengths as experienced by other users. Instead, both em & en vanished leaving empty space. 
All user installed font faces had this bug. 
Only one of the existing font face (HEadLineA) had this bug.
Only Export As PDF combined with user-installed font face had this bug. Save As PDF worked fine.
Comment 10 Nandhini 2015-09-21 01:41:07 UTC
Continued...

The reported bug of unable to print files generated by 'Export as PDF' was also replicated.

I tried printing the exported PDFs. My observations are,
1. When I tried printing files with contents only in known font faces, it worked.
2. User installed font-faces resulted in the "There are no pages selected to print" message.

As stated in the report, I wanted to try the 4.0.1 version. But, unfortunately that wasn't available.
Comment 11 steph_bui 2016-09-26 03:24:12 UTC
I was able to replicate the same Export as PDF bug related to the em & en dash for user installed fonts, as well as the pre-installed font HeadLineA. 

I used Open Office version 4.1.2 on OS X Yosemite (Version 10.10.5) to replicate the bug. 

Steps to Reproduce the Bug:

Prerequisites: Install additional fonts onto your computer (Amsterdam Tangram, Arabella were used for this test). The bug can also be reproduced by repeating the same steps below, and selecting the pre-installed font HeadLineA.

1. Create a new document in Open Office
2. Select one of the installed fonts 
3. Type in "Something--Something" (make sure to hit space after to create em dash) 
4. Type in "1992 - 1995" (make sure to hit space after to create en dash) 
5. File->Export as PDF
6. Click Export 
7. Open exported PDF 

Result: Em & en dashes are different than the original document 

Possible Workaround: 

1. File->Print
2. At the bottom left hand corner, click the PDF dropdown and select Save as PDF...
3. Open exported PDF 

Result: Em & en dashes match the original document 

Additional Notes: As stated in the previous comment regarding all user installed fonts did not export the em and en dashes correctly, that is not the case for version 4.1.2. There were a few user installed fonts that exported the dashes correctly. The fonts tested were Alpine and Adine Kimberg Alternate. 

This bug is important to fix because customers may not be able to tolerate their document format changing when they decide to export their document as a PDF. While there is a workaround for it, it is not very convenient for the customer to go through several more steps to export their PDF, when there is already an option to achieve their goal in as little as 3 steps.
Comment 12 Andrew Steinheiser 2017-02-25 06:21:59 UTC
Test(s) performed with:

OS: OS X 10.12.3
Apache OpenOffice: 4.1.3 (Rev. 1761381)

I could not reproduce the issue with the following steps:

1. Open AOO, create new text document.

2. Select a user installed font (Phantom Stencil).

3. Typed 'Hello world'.

4. File -> Export as PDF.

5. Click Export.

6. Open PDF with no issues.

Was there something else that you guys did to get the crash?
Comment 13 Chris Torrence 2017-03-02 04:27:48 UTC
(In reply to Andrew Steinheiser from comment #12)
> Test(s) performed with:
> 
> OS: OS X 10.12.3
> Apache OpenOffice: 4.1.3 (Rev. 1761381)
> 
> I could not reproduce the issue with the following steps:
> 
> 1. Open AOO, create new text document.
> 
> 2. Select a user installed font (Phantom Stencil).
> 
> 3. Typed 'Hello world'.
> 
> 4. File -> Export as PDF.
> 
> 5. Click Export.
> 
> 6. Open PDF with no issues.
> 
> Was there something else that you guys did to get the crash?

Hi Andrew, thanks for testing! There actually isn't a crash. The problem is with "em" and "en" dashes. I don't think you can use the Phantom Stencil font, as that doesn't even have those characters. In my tests I used Minion Pro, while steve_bui used Amsterdam Tangram and Arabella.

Steve's reproduce case works well:
1. Create a new document in Open Office
2. Select one of the user installed fonts 
3. Type in "Something--Something" (make sure to hit space after to create em dash) 
4. Type in "1992 - 1995" (make sure to hit space after to create en dash) 
5. File->Export as PDF
6. Click Export 
7. Open exported PDF 

Result: Em & en dashes are different than the original document

Hopefully this can get confirmed and fixed soon? Thanks!
Comment 14 AndyGS 2017-10-02 16:15:00 UTC
While I can reproduce the spacing bug, as raised in the comments, with both the current release 4.1.3, and nightly build of 4.2.0, I am not able to reproduce the error when printing the generated PDFs as in the issue description, when trying from Acrobat. 

The typesetting issues might be unrelated and belong in a seperate bug tracker issue.

As a follow up test I also tried with 4.1.0 and still could not reproduce the printing error when opening the PDF with Acrobat and choosing to print.

Specific builds under test:
4.1.0:  AOO410m18(Build:9764)  -  Rev. 1589052
4.1.3:  AOO413m1(Build:9783)  -  Rev. 1761381
4.2.0:  AOO420m1(Build:9800)  -  Rev. 1810279
Acrobat DC: 2017.12