Bug 108963 - Original bounding box of rotated text shows as white overlay in the pdf file after exporting from Impress
Summary: Original bounding box of rotated text shows as white overlay in the pdf file ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.2.7.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.0.0 target:5.4.2
Keywords: bibisected, bisected, implementationError
Depends on:
Blocks:
 
Reported: 2017-07-05 07:46 UTC by ib-zoelch
Modified: 2017-09-13 19:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
LibreOffice Impress - white shadow bar - original file (20.28 KB, application/vnd.oasis.opendocument.presentation)
2017-07-05 07:52 UTC, ib-zoelch
Details
LibreOffice Impress - white shadow bar - result.pdf (19.69 KB, application/pdf)
2017-07-05 07:53 UTC, ib-zoelch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ib-zoelch 2017-07-05 07:46:23 UTC
Description:
In the exported pdf- file the grafic is overlayed in parts by a white bar.
In Impress I have drawn several geometric shapes with text inside. On of the shapes is rotated (40,81 °) and overlayed to the others (90 °).
In the exported pdf- file the 90° rotated shape is overlayed with a white bar.
It looks like the bar is the 'editing fild' when you edit the text in Impress (means by editing the text in a rotated shape the text is shown in normal orientation for editing; after editing the text 'wents back' to the rotated position (in this case 40,81 °).

Steps to Reproduce:
in the original impress-file
1. first shape with text (Calibri 16 fat black; shape with no fillig, line 1,0 pt black, 90°) already exists
2. draw a second shape with text (Calibri 16 fat black; shape with no fillig, line 1,0 pt black, 40,81°)
3. overlay the second shape over the first shape
4. export do pdf -> white shadow in 0° direction above the text of the first shape

in a new file
a) doing the procedure like discibed above i can't see this bug
b) copying the shapes from the original file to the new file the bug is the same -> export do pdf -> white shadow in 0° direction above the text of the first shape

original file
redrawing the two shapes in the original file doesn't solve the problem

Actual Results:  
In the exported pdf-file the first shade is overlay from a white bar;
the with bar seems to be the 'text editing fild' of the second shade (but the second shade is rotated)

Expected Results:
the first shade should be shown completly without an interrupted line


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Comment 1 ib-zoelch 2017-07-05 07:52:34 UTC
Created attachment 134487 [details]
LibreOffice Impress - white shadow bar - original file

This is the original LibreOffice impress file.
Comment 2 ib-zoelch 2017-07-05 07:53:48 UTC
Created attachment 134489 [details]
LibreOffice Impress - white shadow bar - result.pdf

This is the rult of the pdf-exort.
The 'Textfield shade 1' is overlayed with the white bar.
Comment 3 Buovjaga 2017-08-07 11:12:48 UTC
Repro, but not in 3.6.7.2.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 7915f35d7fca5d0720d96954beaa97c00a2c3821
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 7th 2017

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 4 Aron Budea 2017-09-06 06:39:27 UTC
This is not actually a regression, previously highlight color wasn't exported to PDF at all. Bibisecting with repo bibisect-win32-5.3 revealed the backported commit, originally implemented in the patch referenced below.
Adding Cc: to Miklos Vajna.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ee32c7d8083ae1449d6b379034be92995c142da9
author		Miklos Vajna <vmiklos@collabora.co.uk>	2017-02-01 09:52:19 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2017-02-01 12:04:34 (GMT)

"tdf#105461 PDF export: handle text fill color"
Comment 5 Miklos Vajna 2017-09-06 19:10:26 UTC
I plan to look at this.
Comment 6 Commit Notification 2017-09-12 07:13:06 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=da705eff910f512623a689aaf28604270fb8f1c4

tdf#108963 PDF export of editeng text highlight: handle rotated text

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2017-09-13 19:52:18 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=da421e63733bffd064eeabb4a2106adae2fdca03&h=libreoffice-5-4

tdf#108963 PDF export of editeng text highlight: handle rotated text

It will be available in 5.4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.