Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||PDF export problem with a Draw onject in Writer when color=automatic|
|Status:||CLOSED FIXED||QA Contact:||issues@sw <issues>|
|Priority:||P3||CC:||clippka, issues, kpalagin|
|Version:||OOo 2.2 RC3|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description tpesonen 2007-03-20 15:41:22 UTC
Found while testing 2.2 RC 3 on KDE 3.5.6 on SUSE 9.3. Standard KDE RPM's, provided by SUSE. OOo now adopts the desktop colour scheme correctly, unlike 2.0.4. But now a problem occurs: If the document contains a OOo Draw object with text elements in it, those texts are not exported correctly on PDF export if the text has its colour set to "automatic." To reproduce: 1. Start OOo 2. Open a Writer document with an embedded Draw object that contains text(s). The colour of the text in the Draw object should be automatic. OR created a Draw object with a text element using automatic colour for the text, type something in the element, and insert the drawing into the Writer Document. 3. The drawing is displayed correctly on the Writer document, using automatic colours. 4. File->Export as PDF, with the default settings. 5. View the PDF: The text inside the drawing now has the automatic colour as its colour, while all text in the Writer document have been transformed to black, and do not have the automatic display colour as its colour. If the displayed automatic colour is white, the texts inside a drawing will naturally disappaer, as they won't show against the white background of the resulting PDF document. On the other hand, Writer-generated texts will not export as white (automatic colour), but will become black. The automatic font colour in OOo on my systems is shown as white, as my desktop theme is such that UI widgets and elements are darkish, and texts are either pure white or of light colours. OOo shows the writer document with these colours if automatic colours are used. So: The automatic colours get transformed to the default colours of black and white for the Writer document -> black text on white background, unless set otherwise, despite what the automatic colours are. This is correct and makes sense. BUT the text inside a Draw object WILL NOT get tranformed to black, but rather retains the automatic font colour, in my case, white. This is exactly the opposite behaviour to Writer, and this is why I first though that the text had not been exported at all. The result: No text shown inside a drawing in the exported PDF, as they're white, and can't be seen. On other systems they would retain whatever happens to be the automatic font colour, I guess. Again, it should obviously not work like that, when compared to how Writer does this. How can objects from different components be combined if they treat automatic colours differently?
Comment 1 tpesonen 2007-03-20 15:46:57 UTC
A typo: onject -> object, in the summary field.
Comment 2 michael.ruess 2007-03-20 16:09:16 UTC
Reassigned to HI.
Comment 3 h.ilter 2007-03-21 12:44:10 UTC
Please provide a sample
Comment 4 tpesonen 2007-03-21 15:35:12 UTC
Found at the addresses below are three files: SampleDoc.odt -- The sample file with some notes written within. SampleDoc.jpg -- A screen capture showing the document on OOo with the automated colours 2.2 now adopts from KDE SampleDoc.pdf -- The exported PDF, showing how the texts inside the Draw object got the automatic white colour, while all Writer-generated text became black. www.lut.fi/~tepesone/OOo/SampleDoc.odt www.lut.fi/~tepesone/OOo/SampleDoc.pdf www.lut.fi/~tepesone/OOo/SampleDoc.jpg
Comment 5 kpalagin 2007-03-24 21:27:06 UTC
Confirming the problem with 2.2RC3 on Suse 10.2 (Gnome) - exporting www.lut.fi/~tepesone/OOo/SampleDoc.odt to pdf generates white page. Exporting with OO 2.0.4 (Novell's) on the same Suse installation produces expected result. Exporting with 2.2m14 on WinXP produces expected result too. Linux is pretty much default installation, without any customization.
Comment 6 h.ilter 2007-03-26 11:56:45 UTC
HI->PL: Could not reproduce. Please take a look.
Comment 7 philipp.lohmann 2007-03-26 12:59:45 UTC
hi: one can easily reproduce that by setting the KDE theme to "High Contrast White Text"; should work on Windows, too. pl->fme: is this your's or more for the drawing layer (probably aw ?)
Comment 8 frank.meies 2007-03-26 13:30:12 UTC
FME->TL: The evaluation of COL_AUTO in the edit engine looks faulty. In Writer, we default to black in case we do not paint to the window.
Comment 9 thomas.lange 2007-08-02 10:08:44 UTC
Setting target to OOo 2.4 as discussed with QA.
Comment 10 thomas.lange 2007-11-02 11:43:04 UTC
Created attachment 49376 [details] The mentioned resulting sample PDF
Comment 11 thomas.lange 2007-11-02 11:43:57 UTC
Created attachment 49377 [details] The mentioned screen shot
Comment 12 thomas.lange 2007-11-02 11:45:07 UTC
Created attachment 49378 [details] The mentioned sample odt document
Comment 13 thomas.lange 2007-11-02 12:32:56 UTC
TL->AMA: The sample document loads fine with OOo 2.3. But with a current version it fails to load... Can you have a look at this and fix the problem (if possible in CWS tl45) and then assign it back to me to look into the color issue? Thanks in advance!
Comment 14 thomas.lange 2007-11-02 12:41:03 UTC
TL->AMA: copying the content from the document via CTRL-A and copying it into a current version also reports some errors but the content looks still fine. However after saving the document with the current version it cannot be loaded anymore as well.
Comment 15 thomas.lange 2007-11-02 14:24:04 UTC
There is now the new issue 83248 about the load problem of the original document. I created a new document that can be used with SRC680m232 that seems to reproduce the very same problem. See following attachment.
Comment 16 thomas.lange 2007-11-02 14:24:49 UTC
Created attachment 49381 [details] New sample document showing the problem
Comment 17 thomas.lange 2007-11-02 14:31:05 UTC
TL->AW: When discussing the solution suggested by FME with CL he said that this one is probably a problem of the outliner (or Draw/Impress) when GetBackgroundColor() is called since it likely does not take into account that we currently may print or export to PDF... Thus please take over. Thanks! Note: PL said the way to determine if PDF export is going on right now would be to use vcl::PDFExtOutDevData* pPDFExtOutDevData = PTR_CAST( vcl::PDFExtOutDevData, pOutDev->GetExtOutDevData() ); If that pPDFExtOutDevData pointer is != 0 we will have PDF export ongoing.
Comment 18 Armin Le Grand 2007-11-05 11:18:27 UTC
AW->TL: No problem to detect PDF export, but explanation what to do then is missing. As You have obvoiusly discussed with CL and PL and You got a result and a wanted solution, please describe what should be done in case of PDF export.
Comment 19 thomas.lange 2007-11-05 11:31:03 UTC
TL->AW: Well what should be done is changing the font (foreground) color to one that is better readable with the current background. I asked FME what the Writer does. The implementation of it is in sw/source/core/txtnode/fntcache.cxx the function SwDrawTextInfo::ApplyAutoColor. FME said the core of it are the lines: // change painting color depending of dark/bright background Color aTmpColor( nNewColor ); if ( pCol->IsDark() && aTmpColor.IsDark() ) nNewColor = COL_WHITE; else if ( pCol->IsBright() && aTmpColor.IsBright() ) nNewColor = COL_BLACK; Thus the font color is changed to white or black depending on the background color. Since IsDark and IsBright don't cover all of the color spectrum it still is left uncared for if for example the background color is let's say gray5 and the foreground color is gray3 though... You should probably still check with CL if he is fine with it.
Comment 20 thomas.lange 2007-11-05 12:22:58 UTC
Comment 21 Armin Le Grand 2007-11-05 13:04:31 UTC
AW: Added to aw054
Comment 22 Armin Le Grand 2007-11-06 17:06:40 UTC
AW: I am not sure that i understand what we are talking about here. The Neu.odt document has very strange graphic elements: - At the top graphic, there is a Draw-OLE with white filled, rounded rectangles, no text. On top are two draw-text objects with AutoColor. - At the bottom graphic there is a Draw-OLE with white-filled graphic objects with text in AutoColor. I suggest that Neu.odt is not showing the described problem at all. Adding CL. Following the original description now...
Comment 23 Armin Le Grand 2007-11-06 17:41:55 UTC
AW: With hich contrast (Yellow text) i could reproduce Draw objects to export the text in Yellow, too. Unfortunately this has nothing to do with ImpGetTextEditBackgroundColor() and it's usage in SdrObjEditView::ImpMakeOutlinerView(). Have to look who/how the text is painted in that Yellow from VCL. Getting VCL with debug...
Comment 24 Armin Le Grand 2007-11-06 18:03:13 UTC
AW: In ImpEditEngine::SeekCursor(), ln 2675, when IsAutoColorEnabled(), the color is calculated. This is avoided for printer already and needs to be for Pdf-export, too. BTW: Some lines above (look for aStatus.DoNotUseColors()), a old 'Hack fuer DL' also changes the color. Maybe this is an error, too...
Comment 25 Armin Le Grand 2007-11-07 11:25:42 UTC
AW: ImpEditEngine::SeekCursor() needs the above metioned change, but still GetBackgroundColor() is on black which means that someone is also setting the BackgroundColor wrong in this case. Searching...
Comment 26 Armin Le Grand 2007-11-07 11:36:33 UTC
AW: BackgroundColor is set from sd::View::CompleteRedraw() and it uses SdrPage::GetBackgroundColor(). There, no possibility to decide between printing/pdf is not yet available, but this may get necessary.
Comment 27 Armin Le Grand 2007-11-07 11:43:20 UTC
AW: Indeed, this also happens when printing. Thus, SdrPage::GetBackgroundColor() definitely needs a value to decide between screen display and print/pdf export. Maybe also rename it to SdrPage::GetPageBackgroundColor() to better distinguish it from other GetBackgroundColor() methods...
Comment 28 Armin Le Grand 2007-11-07 16:40:52 UTC
AW: Changed name from GetBackgroundColor to GetPageBackgroundColor to make it distictable from other GetBackgroundColor() calls. Added a boolean hint value if the taget is screen display or not. Depending from that hint value, the AutoColor stuff for background color will be suppressed. Added code to SD where the print and the PDF export use GetPageBackgroundColor(). There, the hint value is filled and handed over. Tested with and without high contrast, works now. Checking in...
Comment 29 Armin Le Grand 2007-11-07 16:47:26 UTC
AW: Checked for SW and SC in high contrast and non-high contrast, printing and PDF export for DrawingLayer objects with text. Works as expected now. Setting to fixed.
Comment 30 Armin Le Grand 2007-12-05 11:26:38 UTC
AW: Tested after resync, works well. To review, You need to set High contrast, open SW,SC,SD, create (e.g.) an ellipse, enter text -> Yellow. When printing, it needs to be black again (and the object blue8). Same for PDF export.
Comment 31 Armin Le Grand 2007-12-05 11:39:54 UTC
AW->CGU: Please review as described.
Comment 32 Armin Le Grand 2008-01-23 10:22:48 UTC
AW: Moved to 3.0 due to CWS was moved.
Comment 33 wolframgarten 2008-02-08 08:37:43 UTC
Verified in CWS under Win and Lin.
Comment 34 christian.guenther 2008-07-03 13:27:33 UTC
CGU: integrated in dev300m22