Lines with arrowheads (marker-end) draw incorrectly

[Wim Lewis]

A straight line (<line> element) draws incorrectly if given a marker-end:
it looks like the endpoint of the line moves to one corner of the
arrowhead's abounding box. I'm attaching a small SVG file which
demonstrates this, a screencap of the incorrect behavior by Inkscape 0.45.1
(macos x, ppc, 10.4.9), and a correct rendering by batik-squiggle
(1.7beta1, same platform).

[Wim Lewis (wiml)]

Originator: YES

File Added: inkscape-0.45.1-macppc.png

[Wim Lewis (wiml)]

Originator: YES

File Added: batik-1.7beta1.png

[Yfarjoun (yfarjoun)]

Originator: NO

hi,

I guess inkscape is ignoring the viewbox information and only looking for
the refX, refY (which are missing). This seems to be the source of the
bug...because adding a refX=1, refY=8 fixed this problem and the "origin"
of the view box are -1 -8....

[Wim Lewis (wiml)]

Originator: YES

Hmmm ... Explicitly setting refX=0 and refY=0 doesn't change the display
in either Batik or Inkscape (which is good: TR SVG 1.1 20030114 11.6.2 says
"If the attribute is not specified, the effect is as if a value of "0" were
specified.").

Maybe Inkscape is interpreting the refx/refy values relative to the
minimum (x,y) values of the marker's view box, rather than relative to the
coordinate origin (which is (0,0) by definition and can be anywhere in the
view box).

[Yfarjoun (yfarjoun)]

Originator: NO

This seems to be cause by an incorrect interpretation of the viewbox (by
inkscape). Setting the viewbox to 0 0 14 16 makes the arrows show in the
"correct" place. However, this is (again) incorrect rendering.

(confirmed on linux, inkscape 45.1 and svn HEAD May 22)

[Yfarjoun (yfarjoun)]

Originator: NO

hmmmm.

I read the SVG spec carefully, and the svg code of your example as well,
and I'm starting to think that inkscape actually rendered that code
correctly.

Notice that taking out the viewbox attribute (in the marker def) puts the
arrowhead in the right place. since the default refX refY point is 0,0 this
seems to be the correct rendering. a viewbox that has a non-zero min-x
min-y will cause a translation in addition to the scaling. In your example,
the viewbox has the effect that what used to be 0,0 (the end of the line)
should now be named -1 -8. thus, the upperleft most point in the marker
(0,-7) is one pixel down and right of the original origin, and this is
exactly how inkscape renders it.....

Does this make any sense? can you explain why you think that the code you
submitted should be rendered differently than it does?

Cheers,

Yossi.

[nightrow (jb-benoit)]

Well, as firefox seems to renders the svg in the same way that your "erroneous insckape rendering", i'm rather confident that this is not an inkscape bug.
I may be wrong, feel free to correct me in that case.

[hash (hash-g)]

I've looked at the svg file, and in Firefox 3 beta 2 it renders like in batic, in Inkscape 0.45.1 is like in attachment, and in Inkscape 0.46dev+devel, built Dec 14 2007 end marker is not rendered at all.
I think because the used end marker is not standard Inkscape end marker from inkscape/share/markers/markers.svg.

[Thomas Holder (speleo3)]

Patch attached that results in the same rendering as batik. It just drops the viewBox reference frame shift. I think this is the correct behaviour, and that the SVG spec [1] is misleading here with its phrasing.

[1] http://www.w3.org/TR/SVG/painting.html#MarkerElementRefXAttribute

[su_v (suv-lp)]

I just tested a few files with the patch and compared one with displaced
markers to Inkscape 0.47pre3 and Inkscape r22476 without patch. The
patch leads to further misrendering of this (randomly picked) testcase:

gsoc-testsuite/tester/testcases/svgtestsuite-1.1/painting-marker-01-f.svg

download from sf.net
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/gsoc-testsuite/>

[su_v (suv-lp)]

…but with the patch the example from comment #0 <http://launchpadlibrarian.net/10578713/hedz.svg> is rendered correctly in Inkscape r22476 (same as the Batik screenshot and same as current Firefox 3.5.3 renders it).

[Thomas Holder (speleo3)]

I cannot confirm displacement of markers in painting-marker-01-f.svg
Tested with r22485 + patch

That's weird, the red markers on first and second path are actually the same, but on your screenshot only the first path displays correct. Can you send me this particular file?

[su_v (suv-lp)]

attaching the local copy I used for the screenshots (downloaded 2009-08-23, iirc from <http://inkscape.svn.sourceforge.net/viewvc/inkscape/gsoc-testsuite/tester/testcases/svgtestsuite-1.1/>)

[su_v (suv-lp)]

… and a screenshot of 'hedz.svg' rendered with Inkscape r22476+patch.

[su_v (suv-lp)]

To reproduce my example ("168663-test-r22476+patch-osx.png") with the patched version you need to set the bounding box to 'geometric' in the 'Tools' preferences. I just checked again, if I set it back to 'visual' bbox, the file renders the same in the patched and unpatched version.

Sorry I missed the difference before - however I'd expect Inkscape to render the markers the same - irrespectively of the bbox selection setting.

[Thomas Holder (speleo3)]

thank you ~suv. Unfortunately, I still can't reproduce :-( Bounding box setting makes no difference here.

But: The file preview in file-open dialogue does show misplaced markers with the patch! Not exactly like your screenshot, but similar.

[Thomas Holder (speleo3)]

all my fault, sorry! How could I assume floats to be zero by default? I need more C++ practice ;-)

Patch attached, can you test it please, suv?

[su_v (suv-lp)]

quick test 'painting-marker-01-f.svg' with Inkscape r22498+patch2 compared to reference png:
- correct with both visual and geometric bbox
- correct in preview and on-canvas

only bug (with all bbox settings, in 0.47pre3 and with your patch): lower left path, the bottom arrow seems turned -90° (points to the right). Could that be a similar issue as reported in bug #452568?

I'll leave the patch in for the moment - if anything concerning markers is rendered unusual, I'll add a comment here ;-)

[Thomas Holder (speleo3)]

great, thanks for testing!

About the -90° turn: It's not a bug, it's a feature :-) The blue marker on the middle path has orient="0" and the blue marker on the lower left path has orient="auto".

[su_v (suv-lp)]

*blush* - compared to to the wrong PNG… yep - test passed ;-)

regarding bug #452568 - I see that the marker in question also has
...
       inkscape:stockid="Arrow2SendvTST"
       orient="auto"
       refY="0.0"
       refX="0.0"
...

Is support of this feature new in Inkscape 0.47(pre)? Because it looks like this breaks upward-compatibility of old documents that rendered visually as expected in Inkscape 0.46 (even if not according to the specs…).

[su_v (suv-lp)]

answering the question myself ;-) - Inkscape 0.46 also passes the test with 'orient="auto"', hence bug #452568 must be an unrelated issue.

[Thomas Holder (speleo3)]

fixed in revision 22589