|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | PDF export problem with a Draw onject in Writer when color=automatic | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Writer | Reporter: | tpesonen <teropesonen> | ||||||||||
| Component: | save-export | Assignee: | christian.guenther | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||||||||
| Severity: | Trivial | ||||||||||||
| Priority: | P3 | CC: | clippka, issues, kpalagin | ||||||||||
| Version: | OOo 2.2 RC3 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux, all | ||||||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||||
| Developer Difficulty: | --- | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
tpesonen
2007-03-20 15:41:22 UTC
A typo: onject -> object, in the summary field. Reassigned to HI. Please provide a sample 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 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. HI->PL: Could not reproduce. Please take a look. 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 ?) 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. Setting target to OOo 2.4 as discussed with QA. Created attachment 49376 [details]
The mentioned resulting sample PDF
Created attachment 49377 [details]
The mentioned screen shot
Created attachment 49378 [details]
The mentioned sample odt document
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! 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. 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. Created attachment 49381 [details]
New sample document showing the problem
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. 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. 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.
. AW: Added to aw054 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... 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... 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... 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... 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. 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... 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... 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. 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. AW->CGU: Please review as described. AW: Moved to 3.0 due to CWS was moved. Verified in CWS under Win and Lin. CGU: integrated in dev300m22 |