Bug 73548 - text cut-off when exporting .odp to .pdf (OSX only)
Summary: text cut-off when exporting .odp to .pdf (OSX only)
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Mac OS X (All)
: medium major
Assignee: Not Assigned
Whiteboard: Confirmed:
Depends on:
Reported: 2014-01-13 10:32 UTC by Community
Modified: 2015-05-04 15:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screenshot of Impress source-document & exported PDF (53.08 KB, image/png)
2014-01-13 10:32 UTC, Community
LibreOffice Impress Source Document (81.02 KB, application/vnd.oasis.opendocument.presentation)
2014-01-18 09:59 UTC, Community
LibreOffice Impress Rendered/Exported PDF Document (358.59 KB, application/pdf)
2014-01-18 10:00 UTC, Community
Logo (40.43 KB, image/png)
2014-01-18 10:44 UTC, Community
Alternative Logo (18.04 KB, image/png)
2014-01-18 10:47 UTC, Community
Example of impress file that reproduces the issue (16.46 KB, application/vnd.oasis.opendocument.presentation)
2014-01-18 22:35 UTC, starwed
example output that demonstrates the issue (316.05 KB, application/pdf)
2014-01-18 22:37 UTC, starwed
ODP file of problem and work around (29.27 KB, application/vnd.oasis.opendocument.presentation)
2014-03-03 17:17 UTC, Vossman
PDF file of problem and work around (254.23 KB, application/pdf)
2014-03-03 17:18 UTC, Vossman
PNG of work around text (35.17 KB, image/png)
2014-03-03 17:19 UTC, Vossman
PNG of problem text (45.79 KB, image/png)
2014-03-03 17:19 UTC, Vossman

Note You need to log in before you can comment on or make changes to this bug.
Description Community 2014-01-13 10:32:34 UTC
Created attachment 91939 [details]
Screenshot of Impress source-document & exported PDF

When creating a document in Impress (using the fonts Papyrus and Comic Sans) everything is rendered fine, that is, sometimes the font size is getting decreased automatically/arbitrarily, filling the whole text box, but apparently using a font size bigger than indicated in the corresponding drop down box, and upon re-entering the very same text box, the text is displayed at the actual, smaller one.

Anyways, the issue at hand is, in Impress the document is looking perfectly fine, but when exporting as PDF the text is exceeding the right hand border by far, and the text is getting cut off! :(

Please see enclosed screenshots for some details.
Comment 1 tommy27 2014-01-18 08:48:28 UTC
please upload the source file as well
Comment 2 Community 2014-01-18 09:59:41 UTC
Created attachment 92320 [details]
LibreOffice Impress Source Document
Comment 3 Community 2014-01-18 10:00:19 UTC
Created attachment 92321 [details]
LibreOffice Impress Rendered/Exported PDF Document
Comment 4 Community 2014-01-18 10:02:23 UTC
Just uploaded two files

:: LibreOffice Impress Source Document; and
:: LibreOffice Impress Rendered/Exported PDF Document.

Somehow the issue appears to be linked to the graphics/logo in the top right-hand corner.

I've replaced this logo with the LibreOffice one, and the rendering/exporting turned out to be perfectly fine!
Comment 5 tommy27 2014-01-18 10:30:43 UTC
ok. reworded the summary since this is not an Impress rendering issue but rather a PDF-export bug.

I confirm that your PDF version shows text cut-off 
however convertit the ODP source file to PDF in LibO under Win7 64bit doesn't show that behaviour... output PDF is ok in multiple PDF readers

maybe a MacOS specific bug?

what about the original logo image? could you please upload it separately to allow analysis? which extension is it?
Comment 6 Community 2014-01-18 10:44:29 UTC
Created attachment 92322 [details]

Logo in png file format
Comment 7 Community 2014-01-18 10:46:41 UTC
Comment on attachment 92322 [details]

With this logo inserted into the master view, the unexpected behaviour when exporting from Impress to PDF is occurring.
Comment 8 Community 2014-01-18 10:47:57 UTC
Created attachment 92325 [details]
Alternative Logo

Replacing the original logo in the master view with this alternative one, all of a sudden the exported PDF is looking as expected.
Comment 9 retired 2014-01-18 14:04:17 UTC
Confirmed: -> NEW

tommy27: could you test with on win7? if there everything is fine, we know this is limited to OSX.
Comment 10 Community 2014-01-18 14:06:39 UTC
I'm afraid I've only got MacOS X boxes, not a single Windows one available at all.
Comment 11 tommy27 2014-01-18 16:25:45 UTC
works fine under Win7 64bit with Version:
Build ID: 88cd9632e081f5839cf9fddf60cbff0c099e2968
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-01-09_22:46:56
Comment 12 starwed 2014-01-18 22:26:07 UTC
I see this issue using on OSX 10.9.1.

To reproduce, I created a new presentation, switched the slide to the standard bullet-point format, and added the line of text: like "The quick brown fox jumped over the lazy dog."  

Exporting as a PDF cuts off the last portion of the sentence.

AFAIK it was using the default font setting: 32 pt Arial.

To my eye, it looks like the issue is related to letter spacing.  This is most obvious looking at the "ov" in over -- in Impress, the o and v are kerned such that they slightly overlap, but in the PDF document, they are distinct.

I'll attach the very basic example.
Comment 13 starwed 2014-01-18 22:35:51 UTC
Created attachment 92360 [details]
Example of impress file that reproduces the issue

This file contains text that runs close to the right border of the content area.

When exported to a PDF, the text is cut off.
Comment 14 starwed 2014-01-18 22:37:00 UTC
Created attachment 92361 [details]
example output that demonstrates the issue

The text is cut off on the right.
Comment 15 starwed 2014-01-18 22:41:22 UTC
If I make portions of the text bold, they will overlap the existing text.

For instance, if I make the last word in my example file (dog) bold, it will appear overlapped with the previous word. 

I would guess it's appearing where it *should* appear in the first place, and the non bold text is appearing incorrectly.

Comment 16 tommy27 2014-01-19 08:37:46 UTC
again, not reproducible under Windows. MacOS bug.
Comment 17 starwed 2014-01-24 17:06:23 UTC
A couple of odd things I've noticed:

-  If I make a selection of text bold, and then unbold it, the font weight seems to have changed slightly.  This didn't seem to have an affect on the PDF output, though.

- The text cursor is misaligned with regular text.  It'll often appear in the middle of words.  This doesn't occur with bold text, or with text I have unbolded as described above.
Comment 18 starwed 2014-01-28 22:55:40 UTC
Might be related to Bug 69968.
Comment 19 Vossman 2014-03-03 17:17:53 UTC
Created attachment 95044 [details]
ODP file of problem and work around
Comment 20 Vossman 2014-03-03 17:18:26 UTC
Created attachment 95045 [details]
PDF file of problem and work around
Comment 21 Vossman 2014-03-03 17:19:29 UTC
Created attachment 95048 [details]
PNG of work around text
Comment 22 Vossman 2014-03-03 17:19:47 UTC
Created attachment 95049 [details]
PNG of problem text
Comment 23 Vossman 2014-03-03 17:21:16 UTC
Here is my situation, if the text box is not filled vertically then the text is stretched and when exported becomes cutoff. If the vertical size of the text box is reduced then everything is good, but it is a pain to adjust all text boxes. Additionally if autofit text is turned off then it is fine.
Comment 24 Joel Madero 2014-03-03 17:25:12 UTC
@Vossman - please don't nominate bugs to MAB unless you know procedures regarding MAB. Removing from MAB list
Comment 25 Joel Madero 2015-05-02 15:44:04 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.2 or later)

   If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   Update the version field
   Reply via email (please reply directly on the bug tracker)
   Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)


2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword

Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Comment 26 Vossman 2015-05-04 13:37:03 UTC
I have not experienced this problem since I switch from OTF fonts to TTF fonts and I do not plan to switch back.