|
2006-12-05 15:33
|
|
|
2006-12-05 15:36
|
|
|
|
The first thing needed here is an overhaul of scribus graphic model. Svg import plugin is currently mostly limited by scribus graphics capabilities. |
|
|
Handling of svg 'switch' element is now implement in 1.3.3.7cvs. Most of those test cases which could not be imported at all were coming from illustrator and used that element to allow conditional handling of illustrator specific tags. Now supported parts of that 'switch' element are processed and thus most of those file can now be imported. |
|
|
Some of the files still can't be imported or let Scribus freeze. Following a short description of the issues: diary_costea_bogdan_01.svg: Will be imported, but doesn't display anything. paperbag2_juliane_krug.svg: Freezes 1.3.3.7cvs and 1.3.4cvs carnegie_library_building_01.svg: Takes a long time to import keyboard_key_yemu.svg: Can be imported, but doesn't scale correctly, fonts are shifted/misplaced due to incorrect scaling microchip_v.2_havok_redh_01.svg: Takes a long time to import If possible, the speed issues should be fixed, and Scribus should discard files that can't be displayed correctly (or at all) or that cause a freeze |
|
|
Added another archive with SVGs that can't be imported. |
|
2006-12-26 16:31
|
|
|
|
I had a look at svg-issues.zip svgs: - brozo_the_clown_enrique__01.svg : parsing bug of percentages, fixed in 1.3.3.7cvs and 1.3.4cvs, group opacity not correctly handled - cartoon_tree_01.svg : handling of <use> tag, added yesterday in 1.3.3.7cvs and 1.3.4cvs - coat_of_arms_of_anglica_01.svg : handling of width and height attributes when expressed as a percentag of viewbox width and height - discordian_sacred_chao_t_01.svg : same as previous - glass.svg and glass1.svg : bad handling of clipping path - jin-jang_multimotyl_01.svg : objects outside viewport should be ignored note: fix for coat_of_arms_of_anglica_01.svg also fix import of keyboard_key_yemu.svg from problem-svgs_3.tar.bz2 |
|
|
- discordian_sacred_chao_t_01.svg : styles info at svg root were not parsed and consequently not taken into account, fixed in 1.3.3.7cvs and 1.3.4cvs |
|
|
- glass.svg and glass1.svg : have now improved handling of clip paths in 1337cvs and 134cvs, however only 134cvs will be able to import those files correctly due to specific features for groups |
|
|
Jean, could you please test the uploaded glass1.svg? It lets Scribus freeze. |
|
2007-01-15 15:22
|
|
|
|
drawing is a bit long due to the files complexity, but no freeze here |
|
2008-03-04 23:23
|
Chrisdesign_Diamond.svg (534,895 bytes) |
|
|
Chrisdesign_Diamond can't be imported correctly. |
|
|
christoph_s : SVG filters are outside the scope of this bug. This SVG has also objects outside the drawing frame. |
|
|
I confirm for Diamond : it's probably the same bug as 0012187 which proposes a simple testcase, and where issue is with transform="scale(1,-1)" |
|
|
What is it you call a filter jghali ? How can testers recognise that a svg include a filter ? |
|
|
Answer is "SVG contains a filter when their source code includes the 'filter' string". Filter are part of SVG2 draft specs. More complete answer is : scribus can't import variout other sorts of SVG predicates/commands/attribute, even in the SVG1 specs (as, for example, the transform: scale (1,-1) attribute for images). Conclusion is : - SVG support for scribus is very partial and not reliable - Dont report bugs about "scribus dont import this SVG properly or truthfully" - Only report bugs about "scribus messes the document when importing this SVG" or "scribus crash when or after importing this SVG" |
|
|
"Conclusion is : - SVG support for scribus is very partial and not reliable" Yep, except for the "very". It's just like import filters for non-native formats in almost all programs. Nothing new here. There will always be limits. "- Dont report bugs about "scribus dont import this SVG properly or truthfully"" How do you reach this conclusion? "- Only report bugs about "scribus messes the document when importing this SVG" or "scribus crash when or after importing this SVG"" How do you reach the conclusion? It'll take a lot of work to "overhaul [the] scribus graphic model", and if you can do it or know someone who can *and* has the time, *and* is willing to contribute, please feel free to go forward. In the meantime, reporting SVG bugs of all kinds is absolutely OK. |
|
|
I reach these conclusions because IMO, in case a developper works some day on improving-overhauling SVG support, he will look at the code and find there exactly what attributes are dealt with - and it means all the other are not supported. This will be a more global and exact view than the one achieved in blindly collecting SVG that dont work. To start with, it would be interesting to create a detailed list of SVG attributes/features that are supported in Scribus. It would be a way to express more clearly to the wider public what can be expected of the SVG support today in scribus. And when a SVG with only these supported features goes wrong, then for sure that's a bug. But it looks like lots of effectless non-supported attributes are present in well-imported SVGs, that makes it difficult to sort "should be supported" svgs out of the lot. If you wish to collect all sorts of SVGs that dont work, even for not supported features, i suggest to create 2 reports : - one for unsupported features (= future overhauling test cases) - one for crashing bugs and bugs in dealing with supported features As with the "very not reliable", its because 1) ATM its not explained precisely what is supported and is not (not only filters which is SVG2 but also transform:scale with is SVG1) 2) I had a PDF that could not be riped probably because of too SVG imports - thats the only occurence of such a problem i've ever had with scribus. |
|
|
Since SVG standard is getting more complex I think we need to educate Scribus users that Scribus only has a certain range of support for SVG. How do we communicate that to people so they don't misperceive Scribus's capabilities. An example: 0009320 |
- Anonymous
