https://bugs.documentfoundation.org/show_bug.cgi?id=91252
--- Comment #9 from Armin Le Grand (CIB) <[email protected]> --- Checked example from comment 8, it contains a polygon usin ga fill pattern. The fill pattern is defined using geometry (not pixels), thus re-inserting to the office and breaking up will reveal the clipped fill pattern in geometry quality. What the browsers seem to do with fill patterns is to prepare them as bitmap tile, then render a tiled fill of it, probably for speed reasons. That single tile bitmap shows AA-ed edges of the contained ellipses. To make that more obvious you may change the gradient steps to 12 or so, export to svg again and check in the browsers. Also a good test is to use inkscape, it also shows no moire. I do not say that often, but in this case the SVG export is not the reason, but more the browser's renderers. To really make sure I checked inside the SVG file. It contains SVG fill patters which use path objects with simple fill color and no stroke, thus the moire really comes from some AAing of the browsers, there is *no* stroke defined for the pattern fill. Still leads to that the SVG export creates no SVG gradients - as do ther exports. That is since SVG gradients do not 'reach' the exporter. We would need: (1) SVG gradients in primitives (already tasks for that I think) (2) SVG (and other) exports based on primitives, *not* on metafiles like now (3) the exporter use the higher geometry definitions Unfortunately a lot of work, bu tat least with the primitives the migration path is available and the current 'fallback' works as well as possible. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
