Created attachment 52347 [details]
Dia file

Created attachment 52348 [details]
svg file

The original Debian bug report can be found at http://bugs.debian.org/328220

Sorry, I fail to see what's broken in the SVG output. From the svg spec v1.0 :

"The value of the viewBox  attribute is a list of four numbers <min-x>, <min-y>,
<width>  and <height>, [...]". From my understanding the behaviour of Dia's c-svg
exporter - which seems to be used here - is correct. I'm even tempted to change
diasvg.py to behave the same.

This is an awful example, as there's a large amount of stuff to show a simple
bug.  Trimming it down to the least amount of objects that display the bug would
make it a lot easier to work with.

I'm suspecting that this is a duplicate of the well-known text width problems --
if the fact that text overshoots the box is indeed the issue.  I'm thinking we
could use the textLength attribute to force the SVG renderer to use the correct
length.

If the bug is something else, please inform us.

Interestingly, it seems to be a matter of font/size interpretation. Consider the attached example of the "Error" class of the above big example: Opening the svg file in inkscape shows an overflown box while opening in sodipodi does not.

Created attachment 64321 [details]
dia file

Created attachment 64322 [details]
svn file

reflect comments in subject

After getting inconsistent renderings of the SVG output produced by Dia, I had a look at its svg output today.

Here is part of the SVG output of a 3cm square produced by dia:

  :
  <svg width="3cm" height="2cm" viewBox="4 3 3 2">
    <rect style="fill: #ffffff" x="4.1" y="3.75" width="2.2" height="1.9"/>
  :

and here is a similar square output by inkscape:

  <svg ... width="30mm" height="30mm" ...>
  <rect ... width="105.20984" height="105.21541" x="63.081066" y="59.857193" />

There are two differences:

1. dia creates a viewport which according to the SVG specification is ok. It then gives the draw commands relative to the view port in user unit which is also ok. 

2. The magnitude of the numbers in the drawing commands.

And there lies the problem. The choice of the view port in cm units causes the distances to be small numbers. It turns out that various SVG reading software (rsvg and mozilla firefox, and even inkscape to a lesser degree) seem to round the distances to integer. This in turn causes huge quantization errors. It would be much better to multiply the viewport by a factor of 1000. Or to try to imitate inkscape, that doesn't set up a viewport at all, but uses default distance units. Though I must admit that I haven't been able to figure out what those mean...

Thanks for the analysis. I've just re-read
http://www.w3.org/TR/SVG11/coords.html#Introduction
and think we should probably follow your suggestion to scale the viewBox 
and all coordinates. [Apparently the viewBox needs to be in integer.]
I also don't understand why the Inkscape way works, so to me leaving
out the viewBox does not look like an option ...

Created attachment 67320 [details]
Perl script to fix scaling problem in svg produced by dia

Being too lazy to dig into the dia sources at the moment, I wrote a small perl script that transforms the svg output of dia, by multiplying all distances by a fixed factor. I'm attaching it here in lack of a better place to put it.

Unfortunately the script does not adjust the stroke-width.

I open the file in inkscape set units to px save again and run the following perl-script to get an appropriate svg-image that can be displayed in most programs (i.e. firefox).

Was a quick hack, is ugly but works (at least for me).

--- fixsvg.pl ---
while(<>) {
        /(style=|viewBox=|points=|d=|[xy][12]?=)/ && s/([^xy#0-9\.])(\d+\.?\d*)/$1.($2*100)/eg;
        print;
}

Yes, I realized that my script wasn't perfect. I fixed another few issues in it after I uploaded it, but I don't know if it is worth putting it on the site.

I had a look though at sources in cvs at home in order to fix it "for real", but was confused by the interaction between the svg related code in the plug-in directory and the svg related code in the lib directory. I got it to work by changing the sources in both places, but I was a bit confused about this split-up of svg output functionality. Could someone describe to me what the interaction of the code in these different directories are?

The code in lib/ is the svg rendering base class shared by two exporters. The pure SVG exporter this bug is dealing with and the Shape exporter. The latter creates a combination of SVG and Shape specific information which is useable for Dias facility to define new objects without writing C code.

I guess that means that if I change the svg code in lib, that will change the format output by the Shape exporter. Is it possible to make some changes to the Shape exporter codeto compensate for that? If not, do you have any suggestion what to do, Hans? Perhaps passing in a scaling parameter somehow into the svg rendering class? Is there any mechanism for that?

Created attachment 67865 [details] [review]
Patch that solves the scaling problem in the dia svg output

Here is a patch that solves the problem of the svg output. It introduces a new class variable "scale" into the svg render that is set either to 100 in the svg plug-in and to 1 in the shape plug-in. This scale is then multiplied into all the svg distances through a somewhat ugly modification of the dia_svg_dtostr macro in diasvgrender.c .

The patch further modifies the text size output by a factor of 0.7 to match the size that is output by dia when writing postscript directly.

Any progress with reviewing the patch?

Hello? Is dia still being maintained?

Sorry for the delay, but the thing turned out to be more time cosuming than original thought. Based on your patch I've finally something working which also fulfill the requirement to import again what was exported. See also
http://mail.gnome.org/archives/dia-list/2007-September/msg00023.html

2007-09-08  Hans Breuer  <hans@breuer.org>

	* lib/diasvgrenderer.[ch] plug-ins/shape/shape-export.c
	  plug-ins/svg/render_svg.c : based on analysis and patch by
	Dov Grobgeld the values written to SVGs are now scaled up, because
	many SVG interpreters don't cope very well with small values.
	The overall size of the image is kept by writing with and height in cm 
	but the viewBox scaled like the values in the file.
	For the Shape export the scale value is kept at 1.0 to avoid breaking
	Dia's Shape/SVG consumption. Fixes bug #316590
	
	* lib/dia_svg.[ch](dia_svg_parse_style) : allow to pass in user_scale	
	* plug-ins/svg/svg-import.c : implment some unit awareness and use it 
	to scale the input to Dia's internal cm. Adapt the user_scale with the
	viewBox as explained above. This not only gives almost correct 
	round-trip with Dia's own SVG writing, but also works better for the
	general case.
	* objects/custom/shape_info.c : adapt to API change

*** Bug 116098 has been marked as a duplicate of this bug. ***

*** Bug 543278 has been marked as a duplicate of this bug. ***