Bug 92849 - Text background is lost when exporting Impress to PDF, SVG, WMF or EMF
Summary: Text background is lost when exporting Impress to PDF, SVG, WMF or EMF
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.0.0.3 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
: 95815 96507 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2015-07-21 01:54 UTC by Ofir
Modified: 2024-11-05 03:16 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation with text background (10.19 KB, application/x-zip-compressed)
2015-07-21 01:54 UTC, Ofir
Details
PDF export with missing background (9.90 KB, application/pdf)
2015-07-21 01:55 UTC, Ofir
Details
SVG export with missing background color (23.17 KB, image/svg+xml)
2015-07-21 01:55 UTC, Ofir
Details
1st try to solve (8.30 KB, patch)
2015-11-06 11:13 UTC, Armin Le Grand (allotropia)
Details
current, non- complete state. Do not integrate. (13.01 KB, text/plain)
2015-11-09 10:00 UTC, Armin Le Grand (allotropia)
Details
Text box as it appears in LO Draw 5.1.1.0.0 (7.17 KB, image/png)
2016-01-20 00:20 UTC, David
Details
As it appears after export to pdf from LO Draw 5.1.1.0.0 (13.50 KB, image/png)
2016-01-20 00:21 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ofir 2015-07-21 01:54:41 UTC
Created attachment 117349 [details]
Presentation with text background

The text background is missing from the PDF and SVG exports.
Comment 1 Ofir 2015-07-21 01:55:14 UTC
Created attachment 117350 [details]
PDF export with missing background
Comment 2 Ofir 2015-07-21 01:55:37 UTC
Created attachment 117351 [details]
SVG export with missing background color
Comment 3 V Stuart Foote 2015-07-21 14:37:07 UTC
On Windows 7 sp1, 64-bit en-US with
Version: 5.1.0.0.alpha1+ (x64)
Build ID: 14257152b19c08618a107c6eb0f684de11483da8
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-17_03:23:36
Locale: en-US (en_US)

Confirming, with attachement 117349 (or a newly created slide) an Impress export to PNG, or to JPG retains the character text background color.  But with export to SVG or to PDF, as well as to WMF or EMF does not retain the text background color.
Comment 4 Armin Le Grand (allotropia) 2015-11-05 16:47:34 UTC
The FontBackgroundColor is set at the Font and recorded in a metafile when the font is set at the OutputDevice. Export to PNG and JPG uses Vcl to paint the stuff or metafile, thus the info remains and the vcl text renderers in OutputDevice (DrawTextArray and DrawText) will do the necessary and draw the text background.
For SVG and PDF the model data is accessed and the information that text bachground color is used has to be used explicitely. Not sure about SVG export.

For PDF export a metafile is recorded and then the single actions get exported to PDF. Probably at text export, the test and code to add text background color fillings is missing. Checking there...
Comment 5 Armin Le Grand (allotropia) 2015-11-06 08:07:40 UTC
Debugging the pdf export in draw/impress, PDFWriterImpl::playMetafile is the place to look at, there the text functions strting at line 838. Bubli checked that writer does it right, so will probably take a look there, too.
Comment 6 Armin Le Grand (allotropia) 2015-11-06 08:42:45 UTC
Writer works since it draws the text itself in any aspects in SwFntObj::DrawText, including own calculation and rendering of the TextBackgroundColor using SwTextPaintInfo::DrawBackBrush. It circumvents using the FontBackgroundColor mechanism which is available at the Font completely.
This circumvents the necessity to handle that cases in export filters using metafiles and solves the problem. Question is if it is better to also circumvent (and create explicit metafile actions for the textbackgroundcolor) or to fix the errors in the exporters (svg and pdf at least)
Comment 7 Armin Le Grand (allotropia) 2015-11-06 11:13:54 UTC
Created attachment 120321 [details]
1st try to solve

More complicated as on 1st look. Tried to handle TextBackgroundColor self in VclProcessor2D, added needed code. Already not simple to get the correct rectangle, text may be transformed in various ways. Added patch with working version.
Problem is that the rectangle created based on the TextLayouter's getTextBoundRect method is too tight - not identical with the rectangle used by Vcl or Writer, need to check how it gets created there.
This solves the pdf export, but not yet the svg one.
Comment 8 Armin Le Grand (allotropia) 2015-11-09 09:28:34 UTC
Creating now the correct rectangle, works as expected. This creates the exact rectangle vcl is using. I checked the vcl code doing this and tested with various mixed texts and vertical in draw/impress/calc/writer with DrawObjects. This solves the PDF case.
The on-screen tests show that the geometry is correct, but it looks bad in actual PDF export. Possibly there is an unwanted/erraneous offset in PDF export between text and geometry in general?
Another aspect: Checked the TextPrimitive decomposition by forcing bForceSimpleTextDecomposition to true. This shows that th etext decomposition does also *not* create the needed TextBackgroundFill if set. This is missing from the beginning, I am wondering how that could stay hidden for so long.
Comment 9 Armin Le Grand (allotropia) 2015-11-09 10:00:28 UTC
Created attachment 120404 [details]
current, non- complete state. Do not integrate.

Solution so far, not complete (!)
Comment 10 Maxim Monastirsky 2015-11-14 23:25:53 UTC
*** Bug 95815 has been marked as a duplicate of this bug. ***
Comment 11 Buovjaga 2015-12-21 18:16:31 UTC
*** Bug 96507 has been marked as a duplicate of this bug. ***
Comment 12 David 2016-01-08 22:30:45 UTC
Still present for me using LibreOffice_5.1.0.1_Linux_x86-64_deb
Comment 13 David 2016-01-20 00:19:09 UTC
Bug still present in development version LibreOffice 5.1.1.0.0, 64bit Linux

I've attached evidence:
original.png (how it looks in Draw)
pdf version.png (how it looks after export to pdf)
Comment 14 David 2016-01-20 00:20:20 UTC
Created attachment 122105 [details]
Text box as it appears in LO Draw 5.1.1.0.0
Comment 15 David 2016-01-20 00:21:10 UTC
Created attachment 122106 [details]
As it appears after export to pdf from LO Draw 5.1.1.0.0
Comment 16 Armin Le Grand (allotropia) 2016-01-20 17:01:16 UTC
Yes - as written in comment 9 - it's not done yet
Comment 17 David 2016-03-23 20:31:22 UTC
Any progress yet on this, Armin?
Comment 18 David 2016-03-24 05:59:26 UTC Comment hidden (obsolete)
Comment 19 Armin Le Grand (allotropia) 2016-03-24 08:29:29 UTC
Hi David, no, unfortunately not - this is more work as expected. Main problem is that e.g. Writer handles all of this on it's own, not using the TextBackgroundColor at all in the Metafile stuff - sigh.
Comment 20 Xisco Faulí 2017-09-11 08:26:24 UTC
Dear developer,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 21 QA Administrators 2018-09-12 02:38:05 UTC Comment hidden (obsolete)
Comment 22 Ofir 2019-05-24 22:00:37 UTC
PDF is OK.

Other formats (SVG) still reproducible in:

Version: 6.3.0.0.alpha1
Build ID: 547edd20e527fb02900f6174973770d26306e2e7
CPU threads: 1; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: en-US (en_IL); UI-Language: en-US
Comment 23 QA Administrators 2021-07-30 06:23:14 UTC Comment hidden (obsolete)
Comment 24 Rajasekaran Karunanithi 2022-11-05 23:55:25 UTC
In LO 7.4.2.3 under Windows 10(x64), pdf export is fine. Other formats weren't getting exported as expected.

Version: 7.4.2.3 (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: ta-IN (en_IN); UI: en-US
Calc: threaded
Comment 25 QA Administrators 2024-11-05 03:16:06 UTC
Dear Ofir,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from https://downloadarchive.documentfoundation.org/libreoffice/old/

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: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug