Does not display most elements within an imported SVG file

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Import the file svg-role-play-valid+link.svg (this is attached)

I expect to see something taht looks visually similar to the attached jpeg file 
(role-play.jpg).

In what browser did you experience this problem? : Firefox 3.6, Chrome 5.0.3 
(imported by pasting into svg code).

The svg file itself  will open and be rendered ok  using file/open in Firefox, 
Chrome and IE (using the adobe plugin).

Additional info:
The svg file has been generated using the Apache Batik toolkit, which I am 
trying out with CompendiumLD http://compendiumld.open.ac.uk

Original issue reported on code.google.com by andrew.x...@gmail.com on 7 Jul 2010 at 3:51

• Blocked on: #595

Attachments:

• svg-role-play-valid+link.svg
• role-play.jpg

[GoogleCodeExporter]

Looking at your file, I see the following elements we don't support yet:
- <glyph>
- <missing-glyph>
- <font>
- <font-face>

Though I noticed that removing them from the original file doesn't affect the 
output, so they may not actually be used...

I suspect the problem(s) may lie with the following issues:
- Width and height are set to 100%, which we currently don't deal with terribly 
well. Zooming out ought to at least make the image appear correctly, however.
- No proper clipPath support (see Issue 549), though we do allow import and so 
it should at least appear correct...
- Transforms might not be processed correctly by recalculateDimensions

There may be other issues too, am investigating now. We'll see how far we can 
come into making this file open in SVG-edit 2.6, but it may take some time...

Thanks for bringing this to our attention!

Original comment by adeve...@gmail.com on 8 Jul 2010 at 1:21

• Changed state: Accepted

[GoogleCodeExporter]

Ah, the main reason most of the content is hidden is because we recalculate the 
position of shapes based on the transform given to their parent group...but the 
clipPaths they all have are left unchanged. So that results in shifting the 
defined visible areas from the elements they're supposed to reveal.

I suspect the clipPaths are auto-generated by CompendiumLD, and removing them 
manually makes the image look a more like it's supposed to. That's just a 
solution for testing purposes, of course. 

Anyway, I think I'll spin a new issue off this that deals with un-translated 
clipPaths. More issues probably to come too.

Original comment by adeve...@gmail.com on 8 Jul 2010 at 1:53

[GoogleCodeExporter]

Thanks for looking into this.
The clipPaths were generated by CompendiumLD using the Batik scg library, and 
yes, the image does look more like it's supposed to when they're removed. 

Original comment by andrew.x...@gmail.com on 9 Jul 2010 at 3:19

[GoogleCodeExporter]

Okay, added first one: issue 595.

Original comment by adeve...@gmail.com on 12 Jul 2010 at 3:58

• Added labels: Interoperability