Apache OpenOffice (AOO) Bugzilla – Issue 123500
grafMode (watermark, gray, sw) on scaled svg use the unscaled bitmap
Last modified: 2017-05-20 10:33:59 UTC
Insert a small .svg graphic and scale it up to page size. Then apply any of the "Graphics Mode" filter, "Grayscale" for example. The generated grayscale bitmap is based on the tiny, original .svg graphic and then scaled up to page size. That results in ugly blocks. Request: Take the scaled .svg graphic to generate grayscale bitmap, for to get a better quality.
ALG: Yes, this happens since currently there is not yet a way to apply that filters on vector graphics, thus the fallback to bitmap. I already thought about adding filters for this for vector graphics...
ALG: Taking a 'bigger' bitmap as base for this is a good idea, but how much bigger without risking to get into memory troubles and runtime again? There is no good and simple way to define 'bigger' here. Best way would be to stay on vector graphics, but not all filters will be possible for this.
ALG: First trying to unify the way graphics get handled so that there will be only one place to work on getting the graphic modifications evtl. applied to vector data...
ALG: Checked PDF, print and other exports, works with crop and all GraphicAttr. Also checked if the transparency handed over to PDF writer when creating a PDFExtOutDevDataSync::EndGroupGfxLink is used in PDF export directly, but it is not (see PDFExtOutDevData implementation, case PDFExtOutDevDataSync::EndGroupGfxLink). Thus, transparency needs to be applied to ther graphic, one of the cases where it will not be possible to stay on vector graphic.
"alg" committed SVN revision 1537508 into trunk: i123500 unified Graphic processing to use GraphicPrimitive2D
ALG: Comitted that; now, handling of graphic attributes can be done central in GraphicPrimitive2D::create2DDecomposition, preparing this...
ALG: Changed the graphic content's associated transparency to be moved to an embedded UnifiedTransparencePrimitive2D and not being applied to the graphic (which ofetn leads to bitmaps being created). Works well with printing, but the pdf export seems to have trouble with single transparent objects inside transparency groups. Need to check PDF docu to see how the exporter could be adapted to do this better (besdies that it would be better to chenge it to primitive export...)
ALG: Tried to find out what exactly the PDF exporter is doing with transparence; it looks pretty correct, but when there are single transparent objects in a transparence group (a collection of objects all blended with the same transparency) the blending will not work. I do not know (yet?) enough abiut PDF, does someone know better...? Continuing with brightness/contrast/colormode/r/g/b/gamma modifications...
ALG: Working on relayouting the BColorModifier/BColorModifierStack mechanism in basegfx combined with the ModifiedColorPrimitive2D/ModifiedColorPrimitive3D to get the needed flexibility for the color modifiers to get the whole graphic in GraphicPrimitive2D in the form of a primitive color modifier stack; this will from then on allow vector and bitmap graphics to be modified in the primitive renderers and the decomposers, for vector graphics without the need to go to bitmap graphics...
"alg" committed SVN revision 1539043 into trunk: i123500 redefined ColorModifiers and ColorModifierStack, redefined GraphicAtt...
ALG: Graphics being modified using brightness, contrast, color mode, transparency, red, green, blue or gamma will now apply these to the underlying vector graphics. This increases rendering (screen) and export (PDF, print) quality if these attributes are used. The ugly blocks from the initial comment will now be avoided.