Stroke to path squashes scaled lines (renderer is wrong)

[Luke-hutchison]

When you convert a stroke to a path (or output to .ps),
the conversion from strokes to paths happens *before*
applying transform matrices, but the SVG renderering
engine strokes shapes *after* applying transform
matrices. The result is that if you have a stroked
shape that you have nonisotropically stretched, the
path representation of the lines in Postscript format
has different line thicknesses for the shape, depending
on the orientation of the line relative to the
direction of greatest stretch. This creates unforseen
differences between what's on the screen and what is
written out to Postscript (and therefore what is printed).

You could make the PS output act like the screen
renderer, or alternatively provide a function for
"flattening" transform matrices, by applying matrices
to vertices of shapes and then setting the matrices to
the identity. This could be applied prior to
conversion from stroke to path, so that the current
stroke->path conversion acts on transformed strokes,
not on untransformed strokes.

[Buliabyak-users (buliabyak-users)]

Actually PS output and Outline get it right, while our
renderer is broken, according to the spec. See this bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=851008&group_id=93438&atid=604306

I can easily change Outline so it produces the same output
as you have on-screen before running the command. But I
don't see much point to it, given that the on-screen display
is wrong.

Fixing the renderer is another (long and painful) story...

[Luke-hutchison (luke-hutchison)]

Hmm. Well I have a bunch of PS figures in a paper now which
don't look "right", because the lines are squashed
(specifically, several graphs generated by
Gnumeric->SVG->inksape->PS, which I wanted to resize to a
different aspect ratio). I can see situations where you
would want things to follow the spec, and situations where
you wouldn't, because you want to squash/stretch the shape,
but not the strokes.

Could you please consider adding an option to Outline to
apply stroking before or after applying the transform
matrices? The default, of course, should follow the standard.

Thanks...

[dcberg (david-sipsolutions)]

At least for Stroke to path this should be working.
Ehm, how do I upload an attachement, to illustrate the
problem? Can't I?

[Buliabyak-users (buliabyak-users)]

What must be working? Not squash lines? Not really, because
actually the squashed look is correct, while non-squashed is
not. So it's the display which is wrong, while Stroke to
Path gets it correct.

[dcberg (david-sipsolutions)]

If so, we definitely need "apply transformations" back...
with this the transformation will be applied to the object,
not the stroke.
Still I don't see, why the stroke should be transformed...
that is inconsitent with any software I know.

[Buliabyak-users (buliabyak-users)]

> If so, we definitely need "apply transformations" back

No because:

- You will still be unable to "apply transformation"
completely to a shape (such as an ellipse) without
converting it to path.

- For a path, the default mode already is "Store
transformations optimized", i.e. it applies them as much as
it can.

- Even if for some reason you have "Store transformations
preserved", all you need to do is switch it to "optimized",
then do some no-op transformation to the path (e.g. move it
back and forth). Transformation will become applied. I don't
see a need for a special command for this because it's very
obscure and rarely need operation, and because it's already
doable as I explained.

As for "any software you know", try Postscript. SVG is
absolutely consistent with PS in that respect.

[dcberg (david-sipsolutions)]

Well, please take a look at:
http://home.tu-clausthal.de/~dcb/linux/stroketopath.png
That is not the result, I'd expect... that's basically all
I'm saying.

[Buliabyak-users (buliabyak-users)]

I have explained how you can work around this and get the
same result in the second line as in the first.

[Lucychili-users (lucychili-users)]

Hi
My screen distorted shape with stroke looks like my PS
output file. Should this bug be closed?
lucychili

[Lucychili-users (lucychili-users)]

Sorry im using ubuntu breezy with
Inkscape 0.43+devel, built Apr 10 2006

[Luke-hutchison (luke-hutchison)]

Yes, this must have been fixed when they implemented the
option buttons to control whether or not to transform
strokes. Thanks.

[Buliabyak-users (buliabyak-users)]

Nope. It works only for "optimize" transforms mode but fails
in "preserve". Reopening.

[Martin von Gagern (gagern)]

After reading comment #1, I had assumed that the bug mentioned therein, by now imported into launchpad as bug #165376, would be the one handling the renderer problem, but it seems I was wrong, as that has been closed invalid while this problem here persists.

Is anybody going to work on this before the inkscape renderer is switched over to Cairo? When is that scheduled? Do we have to wait for inkscape 0.51?

Attached is a simple, small, handwritten test case.

[Irenimus (bradypteris)]

I believe I've come across another instance of this bug in Inkscape 0.46 built 8 Apr 2009.

1) Make an ellipse of unequal width and height
2) Convert into a regular circle (i.e. width=height)
3) Stroke to Path OR save as a PDF.

Is there a relatively 'quick fix' (like changing tags in the XML editor or fiddling with some other option) to prevent this from happening?

I've done this with a number of circles for a print-intended document and I'd rather not go back and redo it all :)

Thanks!

[Martin von Gagern (gagern)]

Irenimus, I believe what you want to do is to directly apply a transformation to the coordinates of a path, which requires some calculation, so simply editing the XML won't do the trick. One way to trick Inkscape into doing just that is to select multiple paths and the execute Path / Combine to turn them into a single path. You might then break them apart again if you wish to. You might have to assign new properties, especially a new stroke width, to the resulting path(s). But the nonisotropic scale will be gone, leading to the desired PDF output. The information about your paths being circles will be gone as well, so you won't be able to treat them as circles any more.

[Irenimus (bradypteris)]

Excellent!

Works well thank you.

[ciradrak (linux-dracoquies)]

I would like to reiterate as concisely as I can what's going on here, and how to avoid it.

The problem is that Inkscape renders objects on screen (and in png export) a little differently from the SVG specification, and from the engine used to send data to print. So, some graphics created in Inkscape don't print as expected, and don't render in a web browser as expected.

The problem is triggered when "Store transformation:" is set to "Preserved" in the preferences. Note, this is not the default. Any object with a stroke which is transformed by scaling, or shearing (according to the SVG spec [1]) should appear with the stroke altered by the transform. Somewhere internally Inkscape knows that this is true, and if you execute "Stroke to Path" on such an afflicted object, the 'correct' view will appear on screen.

Unfortunately, transforms are not / can not be applied to certain objects. Ellipses, stars, spirals, and text; always store their transforms. If they didn't they would loose their properties as special objects. So even with "Store transformation: Preserved", these objects can have problems if they have a stroke.

You can tell if you have a problem when your object has a transform="matrix(...)" or transform="scale(...)" in the XML. You can also see if your object has a non-identity matrix in the "Transform" dialog box if you choose "Edit current matrix". The "stroke-width:" in the style tag will typically disagree with the width reported in the "Fill and Stroke" dialog, as that value is the result of multiplying the "stroke-width:" in the style tag by the transformation.

Once the problem has arisen you can recover from it by getting rid of that transform tag. If the "Store transformation:" is set to "Preserved" change it to "Optimized". Any stroke bearing stars, ellipses, text, or spirals which have a transform will need to be reduced to path objects. Then as Bulia Byak says, you'll need to apply some kind of no-op transform to the afflicted objects; such as scaling by 200% and then by 50%. This will incorporate the transform in to the positions of the path nodes. Now, what you see on screen should be what will print or render in another SVG program.

Having said all that, I prefer the current Inkscape behavior. Meaning, I want to be able to transform my objects without the stroke being affected by the transform.

The problem seems to be rooted in that SVG was conceived as a presentation language similar to OpenGL, rather than as a manipulative language. This is in opposition to the way a program like Inkscape operates. Manipulative systems work by altering the current state, they have a history through which they arrived at the current state. There is no change allowed which would make future changes impossible. You can always apply another change to their state. In the case of SVG, transforms create variable thickness strokes in the output, but SVG has no premise to deal with variable thickness strokes. Therefore it can no longer be manipulated. That's overly simplistic and not entirely correct, it's more complex than that. (a variable thickness path doesn't create exactly the same shape as a transformed path) ...

[su_v (suv-lp)]

Raising importance to 'Medium' based on the number of duplicates (-> affected users). Please revert the change if you don't agree.

[ScislaC (scislac)]

This has been fixed in trunk, if you feel this bug has been incorrectly closed, please feel free to re-open it and explain why.

[pRototype (regeir)]

I'm agree with ciradrak.

I also want to be able to transform objects without having the stroke being affected by the transform.

I wish there where some options to change between those two transform behaviours.