Created attachment 117349 [details] Presentation with text background The text background is missing from the PDF and SVG exports.
Created attachment 117350 [details] PDF export with missing background
Created attachment 117351 [details] SVG export with missing background color
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.
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...
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.
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)
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.
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.
Created attachment 120404 [details] current, non- complete state. Do not integrate. Solution so far, not complete (!)
*** Bug 95815 has been marked as a duplicate of this bug. ***
*** Bug 96507 has been marked as a duplicate of this bug. ***
Still present for me using LibreOffice_5.1.0.1_Linux_x86-64_deb
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)
Created attachment 122105 [details] Text box as it appears in LO Draw 5.1.1.0.0
Created attachment 122106 [details] As it appears after export to pdf from LO Draw 5.1.1.0.0
Yes - as written in comment 9 - it's not done yet
Any progress yet on this, Armin?
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.
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.
** 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 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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