Issue 123500 - grafMode (watermark, gray, sw) on scaled svg use the unscaled bitmap
Summary: grafMode (watermark, gray, sw) on scaled svg use the unscaled bitmap
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: formatting (show other issues)
Version: 4.1.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-19 22:03 UTC by Regina Henschel
Modified: 2017-05-20 10:33 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2013-10-19 22:03:18 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.
Comment 1 Armin Le Grand 2013-10-24 16:01:20 UTC
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...
Comment 2 Armin Le Grand 2013-10-30 10:19:30 UTC
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.
Comment 3 Armin Le Grand 2013-10-31 12:51:56 UTC
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...
Comment 4 Armin Le Grand 2013-10-31 14:40:54 UTC
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.
Comment 5 SVN Robot 2013-10-31 14:43:23 UTC
"alg" committed SVN revision 1537508 into trunk:
i123500 unified Graphic processing to use GraphicPrimitive2D
Comment 6 Armin Le Grand 2013-10-31 14:45:07 UTC
ALG: Comitted that; now, handling of graphic attributes can be done central in GraphicPrimitive2D::create2DDecomposition, preparing this...
Comment 7 Armin Le Grand 2013-11-01 11:12:10 UTC
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...)
Comment 8 Armin Le Grand 2013-11-01 16:53:51 UTC
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...
Comment 9 Armin Le Grand 2013-11-04 19:45:26 UTC
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...
Comment 10 SVN Robot 2013-11-05 16:13:14 UTC
"alg" committed SVN revision 1539043 into trunk:
i123500 redefined ColorModifiers and ColorModifierStack, redefined GraphicAtt...
Comment 11 Armin Le Grand 2013-11-05 16:15:22 UTC
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.