Issue 75566 - PDF export problem with a Draw onject in Writer when color=automatic
Summary: PDF export problem with a Draw onject in Writer when color=automatic
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOo 2.2 RC3
Hardware: PC Linux, all
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: christian.guenther
QA Contact: issues@sw
Depends on:
Reported: 2007-03-20 15:41 UTC by tpesonen
Modified: 2013-08-07 14:43 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

The mentioned resulting sample PDF (35.38 KB, application/octet-stream)
2007-11-02 11:43 UTC, thomas.lange
no flags Details
The mentioned screen shot (433.13 KB, application/octet-stream)
2007-11-02 11:43 UTC, thomas.lange
no flags Details
The mentioned sample odt document (11.62 KB, application/octet-stream)
2007-11-02 11:45 UTC, thomas.lange
no flags Details
New sample document showing the problem (24.77 KB, application/octet-stream)
2007-11-02 14:24 UTC, thomas.lange
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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
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.
Comment 5 kpalagin 2007-03-24 21:27:06 UTC
Confirming the problem with 2.2RC3 on Suse 10.2 (Gnome) - exporting 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
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