________________________________ De : Tomaž Vajngerl <qui...@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.oll...@hotmail.fr<mailto:adr.oll...@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
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
