SVG export creating a box with incorrect dimensions

[prikhi]

From dgasa...@gmail.com on February 08, 2013 15:09:47

What steps will reproduce the problem? 1. Create a drawing that is not square
2. Export to SVG

What is the expected output?
An SVG with dimensions matching the drawing. So, if I load the SVG into inkscape, and tell it to fit the page to the content, then I get a page that fits what was in the original drawing.

What do you see instead?
An SVG that seems to use the width of the drawing as the height. So when I do the above procedure in InkScape, the page ends up with a bunch of white space at the bottom (because my drawing is wider that it is tall). This seems to manifest in two places in the SVG file. What version of the product are you using? On what operating system? Version 2.0.3 on Windows XP Please provide any additional information below. My source .ep file has
[...]16241304[...]

The exported .svg has
<svg
[...]
width="1624"
height="1624"
[...]

The "rect6" object in particular is what's causing the problem for Inkscape. If I edit the height of rect6 to 1304 (the height from .ep), Inkscape behaves as I expected.

Original issue: http://code.google.com/p/evoluspencil/issues/detail?id=538

[prikhi]

From dgasa...@gmail.com on February 08, 2013 13:09:41

Correction: It appears the "rect6" object is something created by Inkscape, using the dimensions set on the object. So now it appears the height is causing the problem. If I edit the height attribute before opening in Inkspace, then everything works as expected.

[prikhi]

From dgasa...@gmail.com on February 08, 2013 13:25:26

More corrections (eventually I'll get it right :). In the original exported SVG, the problem is a object:

So, please ignore the XML I pasted earlier. In addition, I see know that the original has a different width and height, which doesn't seem to be related to canvas size:

<svg xmlns=" http://www.w3.org/2000/svg " width="744.09448819" height="1052.3622047"

[prikhi]

From jay.ga...@DataMgmtSvcs.com on May 25, 2014 13:52:50

The size of the created SVG document appears to be coming directly from usr/share/pencil/content/pencil/exporter/Pencil2SVG.xslt, where it is hard coded as:
<svg width="744.09448819" height="1052.3622047"

So, either there is no code which is modifying these defaults to the correct dimensions for the document, or it is not working correctly.

[mvdw]

In the SVG export file, the first element is:
<svg xmlns="..." width="744.09448819" height="1052.3622047" .....

These dimensions are wrong. Adapting these two values fixes the problem.

This is a severe bug, also for me.

This patch solves it:

--- Pencil2SVG.xslt.original    2014-05-28 16:51:41.000000000 +0200
+++ Pencil2SVG.xslt 2015-06-08 10:46:32.000000000 +0200
@@ -40,7 +40,8 @@
     <xsl:output method="xml"/>

     <xsl:template match="/">
-        <svg width="744.09448819" height="1052.3622047"
+        <svg width="{/p:Document/p:Pages/p:Page/p:Properties/p:Property[@name='width']/text()}" 
+            height="{/p:Document/p:Pages/p:Page/p:Properties/p:Property[@name='height']/text()}"
             id="exportedSVG"
             version="1.1"
             pencil:version="1.2.2"

[mvdw]

See this pull request:
solve bug fixed size in svg export #718

[prikhi]

#718 is merged.

I did some quick googling so I don't know if it's feasible for us but I saw that SVG has a pageSet element:
http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html

Do you think we could use that?

[mvdw]

Hmm, I was thinking that initially, too. But then I read at
https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Introduction :
« "Full" SVG 1.2 was meant to be the next major release of SVG. It was dropped for the upcoming SVG 2.0, which is under heavy development right now and follows a similar approach to CSS 3 in that it splits components in several loosely coupled specifications.»
So, I guess we better don't.

IMHO we should export multiple pages as separate SVG files, and not combined in one file. Even using the inkscape layers is a bad solution, since they are not meant to be layers probably - the semantics differs.