RE: tdf#74702 2/2

________________________________
De : Tomaž Vajngerl <quikee@gmail.com>
Envoyé : mercredi 10 juillet 2019 06:46
À : Adrien Ollier
Cc : libreoffice@lists.freedesktop.org
Objet : Re: tdf#74702 2/2

Hi,

On Wed, Jul 10, 2019 at 5:54 AM Adrien Ollier <adr.ollier@hotmail.fr<mailto:adr.ollier@hotmail.fr>> 
wrote:

Also, let's take a concrete example:
<https://opengrok.libreoffice.org/xref/core/canvas/source/vcl/canvashelper.cxx?r=c88f7603>https://opengrok.libreoffice.org/xref/core/vcl/source/control/edit.cxx?r=d00ee2cb
void Edit::Draw(OutputDevice* pDev, const Point& rPos, const Size& rSize, DrawFlags nFlags)
see l.1771

Can you tell me how you would remove the use of GetOutDevType?

In this case I would remove the condition "eOutDevType == OUTDEV_PRINTER" completely. No idea why 
it exists but color printers exist today and overriding the text color to black just because the 
output device is a printer is backwards and wrong. Anything that a printer can't handle should be 
modified in the output device itself and not outside of it. In this case, what would happen if the 
background of the Edit is set to black? Yup - the text would be drawn in black instead of the color 
that was set. I tried it with inserting a combo box into a writer document with black background 
and white font color to confirm and surely it printed it with black text. I think you actually 
found a bug, or a workaround for some assumption made in the past that's not relevant today 
anymore. ;)

Regards, Tomaž

--------

Hi Tomaž,

Thank you for your answer. That is very interesting.
This bug is very complex, and there are some major design errors, so it is hard to guess the good 
way for resolving this bug.

I'll do my best to improve LibreOffice.
Regards,
Adrien Ollier