|
|
Rotulo.svg (17,885 bytes) |
|
|
Issue is with `fill='url("#rough-1609495203056042")'` being ignored. Imported shape is OK but content is empty |
|
|
Confirmed. The result of importing this SVG currently looks like: ``` Manjaro 23.1.0 Scribus Version 1.5.9.svn Build ID: C--T-F-C1.15.10-64bit Built: 13 August 2023 Companion Programs: Ghostscript: 10.02.1 Libraries: cairo: 1.15.10 Harfbuzz: 1.7.2 littlecms: 2090 podofo: 0.9.5 poppler: 0.62.0 ``` Screenshot_20231222_110318.png (24,628 bytes) |
|
|
I checked the SVG plugin. Patterns are parsed in void SVGPlug::parsePattern(const QDomElement &b) Scribus renders all patterns as an image. Especially for the "GIMP" example, the rendered pattern image is 1x1 px, because the pattern width and height is 1 px too. What is missing is the processing of the viewBox attribute. See here: https://www.w3.org/TR/SVG11/pservers.html#Patterns If I hard code the pattern size in the SVG plugin I get the result below. The pattern is correct, but it is blurry and the clipping is messed. Bildschirmfoto vom 2023-12-26 20-03-54.png (100,534 bytes) |
|
|
I must add that LibreOffice fixed issue, maybe their patch could take into account to fix in Scribus this issue. Thank you |
|
|
Hello Rafael, in case that might help, could you provide the url for the LibreOffice commit ? |
|
|
I imported the GIMP SVG file in Inkscape and LibreOffice Writer to check how it looks like. Both applications are importing the pattern as vector path. Scribus renders it as image. I think to make a correct fix, we should rethink the rendering / display of the pattern in Scribus. The SVG plugin creates the pattern correctly as PageItem_Polyline, but then it renders it as image to "unify" it for a later usage. Perhaps we should store the vector path information in a ScPattern object and render it at runtime correctly on canvas. In that way, the output renderer can decide how to render the pattern (as image, as vector graphic, as whatever). It seems like it is a bigger research to check how LibreOffice implemented the import. I just found the SVG pattern parser, but it only reads the data in SVG file. BTW the parser handles all attributes defined by WC3, Scribus missed some. https://github.com/LibreOffice/core/blob/master/svgio/source/svgreader/svgpatternnode.cxx Object creation for canvas is somewhere else. I guess LibreOffice implementation doesn't really help us here, because Scribus has a good implementation. It only needs fixes for size calculation of the pattern and perhaps a better way how to import patterns. The clipping issue is not related to patterns, because it doesn't work for solid colors too (at least for the GIMP SVG file). |
|
|
Hi Jluc I put the LibreOffice bug link to the thread I opened in "Additional information". Simply click that link and you will see how they fixed issue. nitramr, I'm totally agree with you. Scribus should not convert SVG to bitmap. In fact, I always thought Scribus respect SVG content to let user to rescale and reuse vectorial objects. |
|
|
it looks like the issue for libreoffice was because of the doublequotes in the fill value. AMOF it doesnt make any difference for scribus... but here is the SVG without doublequotes in fill value. Rotulo_nodoublequotes.svg (17,883 bytes) |
|
|
> it looks like the issue for libreoffice was because of the doublequotes in the fill value. is this then an upstream Libreoffice issue that should accommodate the doublequote edgecase ? |
|
|
Nope luzpaz. LibreOffice had an issue with doublequotes and fixed it. Scribus has a more complex issue as described by nitramr and raphael, and i i can't sum it up. |
|
|
The ticket probably needs a rename to highlight @nitramr diagnosis |
|
|
Perhaps I, who reported the problem a long time ago (2022), could change it, but logically, if there is a more appropriate title, it should be the forum administrators who read the responses and rename the ticket accordingly. |
|
|
rafael, there are a lot of other tickets that are generically named that haven't been renamed. If you don't mind, would you please rename it yourself? |
|
|
Sincerely, I don't know what to put instead my original title. |
|
|
jluc has now modified the title and the relevant information seems to be there. btw, the administrator can fix titles that are technically wrong, but if the title should be edited to match new insights on the ticket, then it makes much sense, that it gets fixed by people who understand what is going on. and, even as a reporter, we are all entitled to not understand what is going on behind the scene, and have the feeling that we cannot come up with a better title! and, anyway, two years does not make a scribus ticket old! there are patches that have been setting in here for waaaaaayyyyyy loooooooonger! : - ) |
|
|
Perfect then. It will always be better if an English speaker changes it, as they will use the most appropriate words. Regarding the time it takes to resolve issues with free software, I am already very clear that time passes in a completely different way for developers than for users, but that is another topic we better not discuss here... :( |
|
|
Recently I had some more problems with SVG import. There are some things missing in the current implementation (e.g. more clipping path types, vector-based patterns, effects like the Gaussian blur). At first I tried to fix the problems, but the more I worked on the topic, the more I realized that parsing SVG can become very complex. I think we should consider an external library that acts as a preprocessor. In theory, we would then only have to write an adapter that transfers the simplified structure into Scribus elements. The biggest problem at the moment is resolving inherited or linked styles. I have looked at some libraries, such as lunaSVG or usvg, that could possibly be suitable. However, it needs some testing. Especially since these libraries have some dependencies that are already implemented in Qt (e.g. QImage or QTransform). References: https://github.com/styluslabs/usvg https://github.com/sammycage/lunasvg |
|
|
Using a library reads like the way to go for such a complex but standard job |
|
|
> external library Sounds like a good idea |
- Anonymous
