markers must take object's stroke color (SVG 1.2 feature)

A really ugly emergency workaround:
1 - select the marked item
2 - in the XML editor,
    - look for its <style> attribute, there'll be a marker-*
tag with the
      tag's name
    - look (under <defs>) for the item <marker> whose tag
"id" matches
      the tag name; it should have a subitem <path>; edit
the latter's
      "style" attribute, adding a "fill" tag with your color
of choice
   - go back to the marked item, change the marker-* tag
with something
     else, then to the original marker name, so Inkscape
repaints the
     item

YMMV. This is a very poor hack, since all users of that
marker will
have it with the same color - also, I bet it won't load when the
developers fix the bug.

Maybe they should also also take the object's stroke style...

If you need this Right Now, for a workaround, you can edit
their style in the XML editor -- they're under "defs" --
just duplicate the one you want, and copy in its style from
the object, being careful to remove the stroke bits having
to do with arrows (unless you want to crash Inkscape via
infinite
recursion).

furuti: This will work, it won't affect system-wide markers,
only those in the current file. So it's a valid workaround,
even if cumbersome.

<simarilius> need to sort making arrows match the line
color, been asked for a couple of times on the list
[12:23:45] <bbyak> this requires copying a marker and
painting it some color, then relinking the path to the new one
[12:23:59] <bbyak> and this also requires that all original
markers have no colors in them
[12:24:21] <bbyak> (anything without color is shown as black
by default)
[12:24:50] <bbyak> and each marker should also be one item
at the top level
[12:25:03] <bbyak> i.e. if it has several shapes, they
should be in group
[12:25:24] <simarilius> right, and if all the shapes below
that have no fill setting the group fill should mean they
inherit it right?
[12:25:25] <bbyak> then it's easy to automatically
add/change color on the top item to repaint the whole marker
[12:25:29] <bbyak> yes
[12:25:52] <simarilius> then just need to add a hook into
the line color change bit
[12:26:12] <bbyak> yes, but also copying, so that other
users of the marker are not affected
[12:26:48] <bbyak> and don't forget to make such auto-copied
markers auto-collectable
[12:27:02] <bbyak> so that they are removed when not used
[12:27:32] <bbyak> and they should also store a reference to
the original marker in some extension attr
[12:27:54] <bbyak> so that the list of markers in
fill&stroke would only show the black originals, not colored
copies
[12:28:40] <bbyak> it's similar to what is being done for
patterns, except that patterns chain on transform, while
markers on repaint
[12:29:43] <simarilius> I'll take a look at the patterns
code and see whats involved
[12:31:21] <bbyak> and so that when you select a shape with
copied/colored marker, the list in the dialog is updated to
show the source black marker
[12:31:33] <bbyak> having traced it by the reference in the
extension attr
[12:32:08] <bbyak> and ideally, when you select another
marker for a colored shape, it should be recolored into the
same color on assigning
[12:32:54] <bbyak> i.e. you select a blue stroke with blue
marker, the dialog shows that marker black, you select
another black one from the list, and it's applied blue not black

[12:36:00] <bbyak> simarilius: really svg makes this all
much harder than it should be :(
[12:36:06] <bbyak> but it's doable

I'll paypal US$10 to whoever fixes this elegantly (or to the
project, if they prefer it). Others should of course feel
free to add their own offers on top ot this :).

I despretely need this functionality, so I will throw in
US$20 on top of the 10 already offered.

If someone is interested in doing it soon, I might be
tempted to offer even more, and up front.

these markers have some more limitations. if i have a line with
them, i
usually want to convert it to outlines, to make smal corrections.
no-go.
i tried using 'make bitmap copy' and trace, markers don't get
exported by
default, because they reach outside of line borders.

so anyway, markers are nice, but should really be more flexible
to use.

regards, bostjan

It turns out SVG 1.2 will have facilities that make solving
this bug trivial. So I think we don't need to do any of the
messy workarounds described below. Instead we should spend
the resources on the support of shadowInherit and
currentFill/currentStroke from 1.2, as described here:

http://lists.w3.org/Archives/Public/www-svg/2005Jun/0136.html

Is the fix on the way? The actual behavior is really annoying ;)

Many thanks for this great app!

This is surely priority 9, altough I would classify it as 99
at least myself...

Inkscape is a great app, but having a white line terminating
in a black arrowhead is a COMPLETE show stopper that makes a
user close the application and never look back. But I'm
stubborn... :-)

I used furuti's workaround and it worked - although I don't
know what would happen if I had different arrows with
different colours, since there was only one ArrowSstart and
one ArrowSend in the markers section, but I had two arrows
in the drawing.Since both of them changed colour, even when
I changed one path only, I guess ALL arrowheads ArrowSstart
would be white, no matter what the colour of the object, but
would have to test that to be sure.

I hope this gets solved soon, because no serious user will
ever consider messing around an XML editor to do anything,
let alone something as fundamental as this.

Again, thanks for the great app, and keep up the good work.
BTW, I'm running Inkscape 0.43, SuSE 9.2

J

I concur. This has been the number one reason why I'm not
using Inkscape regularly, and this bug will be two years old
(!) soon. I'm not sure of the reason, but it's a little
disheartening to see its priority getting lowered.

I understand that this will be fixed automagically when SVG
1.2 is implemented (see last year's comment from buliabyak
below); but then again, I bet many potential users
(actually, probably the whole casual and technical artists
bunch) have already looked away and dismissed Inkscape. This
is sad, considering that Inkscape has a strong potential to
be one of the best graphical tools on multiple platforms.

From
http://wiki.inkscape.org/wiki/index.php/Release_Notes#Markers:

Converting stroke to path now correctly processes dashed
strokes. For paths with markers, this command now creates a
group containing the stroke converted to path and all its
markers as independent objects (i.e. they are not markers
anymore, but instead you can easily transform them or paint
them any color, as a workaround for the "markers don't take
the color of the stroke" bug; to be properly fixed, this bug
requires implementing some SVG 1.2 features).

Somebody today complained to me that this is the reason they
don't use inkscape. Sorry, but I'm bumping up the priority
again!

Hi,

I was about to report about this problem but luckily I did
a search if someone had made it :)

I like Inkscape very, very, very much because of its
feature rich and it is so natural when doing free style
drawing. It just make me feel so comfortable drawing even
with a clumsy mouse! and not with my flexible 5 fingers and
wrist.

Okay, let's get to the point. I wonder why Inkscape can do
other magics which I think are non-trivial but fail on this
trivial one? To amend it one is asked to manually edit the
XML -- a ridiculous solution for such a powerful software!

One example which I found myself incredibly upset with is
when I drew a fat and short arrow line with some bluish
gradient colour which came out so nice and eye-soothing,
but a big black arrow head sticking out at the other end!
It just did not look right!

I beg someone to fix this. PLEASE!

Originator: NO

We now have a Python extension that colors the markers to match the line,
in Effects > Modify Path. Works nicely, although of course it's not the
final solution. So this need not be a level 9 bug.

Originator: NO

Nobody seems to have mentioned that the markers also do not inherit the
lines transparency and blur properties as well. Effects->Modify Path also
has no effect on blur and transparency.

To the previous comment: marker transparency and blur are fixed in 0.46

Collecting all related (or potentially identical) bug tickets after the SF->launchpad migration:

markers must take object color (SVG 1.2 feature)
    https://bugs.launchpad.net/inkscape/+bug/165865

arrows/Markers should inherit path color
    https://bugs.launchpad.net/inkscape/+bug/171015

Color Arrows/markers and other improvements
    https://bugs.launchpad.net/inkscape/+bug/171284

Color arrows/markers with stroke color
    https://bugs.launchpad.net/inkscape/+bug/171361

I've got a PDF/PS export bug which appears to be related

https://bugs.launchpad.net/inkscape/+bug/181560

Add my +1 for a fix for this please. I've run into the markers not inheriting transparency quite a bit.

I'm working in version 0.45 on a Windows Vista machine and even though the user manual says "As of v0.45, Inkscape includes the Color Markers to Match Stroke effect for changing the color of markers to match the stroke color." It still doesn't work. I hope it gets fixed in the next release.

I'm not sure if I see myself using this feature a lot so the XML Editor solution is Ok with me for the few times I may use it. Mmm I have been known to change my mind though so it would be great to get this fixed.

This works for me in Inkscape 0.46. Simply select the object and select Effects -> Modify Path -> Colour Markers to Match Stroke.

Yes. But that effect is only a workaround as mentioned earlier before all required SVG features are implemented in Inkscape.

I've stumbled upon this bug in Inkscape 0.46 and it's really annoying. I hope those SVG features get into Inkscape as soon as possible.

OMG, this bug is almost four years old! I had very little time to make an illustration so I just left my arrows black and added white cloudy background. :-D Now I also noticed that with command Colour Markers to Match Stroke one can get markers in different colours so that start and end markers are in different color and also that the line color doesn't match them. But... I'd rather be without this "feature"/bug. ;-)

although there is a work-around, i'd happily work on this after my gsoc project. remind me in september this year.. :)

One comment that has not been mentioned yet:

It seems like the current trend is to make a marker the same color as its line. However, a tool of Inkscape's caliber should definitely have an option to color markers independent of the corresponding lines, so instead of forcing a color (which still is a good idea as a default), the marker menu should give more flexibility like choosing color, stroke/fill, etc for markers as well as lines.

Micrografx Designer has this feature for ages, and if I remember correctly, even before Inkscape was born.

Keep up the good work!
Cerno

Interested in getting this implemented in the SVG 1.2 way, but no time till October. If something is in progress by then, I might join if feasible, otherwise I'll try to have a look at the whole thing.

That bug nearly has it's 5th anniversary - it really should be fixed soon!

It's also affecting the efforts for technical drawing and the DXF import.

A pre-release of the upcoming Inkscape 0.47 is now available in Ubuntu
Karmic for testing. Because *so* much stuff has changed compared with
the version you reported your bug against, would you mind re-testing
this new version and see if this bug is now resolved?

Karmic Alpha CD ISO images are available at:

  http://cdimage.ubuntu.com/releases/karmic/

If you're not testing Karmic yet, there are .debs of this new Inkscape
for Jaunty, Hardy, and Intrepid here:

  https://launchpad.net/~inkscape.testers/+archive/ppa

You might find further bugs when testing this alpha release. If that is
the case, please file a NEW bug report here:

   https://edge.launchpad.net/inkscape/+filebug

Thanks ahead of time for your testing efforts, and enjoy the new Inkscape!

Successfully reproduced this bug in 0.47 pre-release as downloaded from Bryce's link. I've attached a screenshot.

To reproduce, draw a square filled with any color, set it as a pattern, then make a larger rectangle-shape and fill with that pattern.

As you move the pattern-filled object and/or resize it, small seams appear. This also shows up in exported images.

Screenshot attached.

Still seeing this bug in karmic alpha 4. End arrow markers on a red line appear black

As-described, this is not really a bug. It is a wishlist/feature request.

Comments #20 and #21 imply (I'm happy to be corrected) that implementing this feature would fix several outstanding bugs. So whilst you may consider this to be a wishlist/feature request, please bear in mind that it's also a fix to several bugs which have the common theme that Inkscape does not handle end-of-line markers the way some users expect it should.

They said it would be "trivial" in version 1.2. Why don't we have this yet? A, I mourn the lack occasional pitfalls of projects being not-for-profit. But for that very reason I love it so. :-)

The solution "Effects->Modify Path" (which is in fact "Extensions->Modify Path" under Inkscape 0.47) does work if you want to use an arrow, but it does not with InfiniteLineStart & InfiniteLineEnd.

A very annoying problem which is not, according to me, a wish but a real bug !

@Arnaud - this is already filed as 'real' bug:
Bug #479644 “"Color Markers to Match Stroke" doesn't work for "InfiniteStartLine" marker”:
<https://bugs.launchpad.net/inkscape/+bug/479644>

Not having markers match the stroke is definitely seen as a bug to new users (especially for the default set) -- I've been embarrassed by this several times when advocating Inkscape's use. "Effects / Modify Path / Color Markers to Match Stroke" is too obscure a workaround.

I've following "jasonphysics" advice to get start/end markers same color. However a new problem arrives. The list of "recently used start/end markers" seems to grow by adding the same style, but different name everythime I select start marker or I'm pasting style.

Inkscape 0.47-3 (windows)

Image:
http://i47.tinypic.com/23w90kk.png

I'd like to second the 'bug' fraction, since I share jasonphysics' experience.

While it's not a 'classical' bug in the sense that something breaks spectacularly or that the SVG spec is interpreted wrongly, it definitively *is* a bug regarding user interface and user expectations (including me as Inkscape user).

However, when fixing this bug, an interface to *deliberately* change the marker color to be different from the stroke color (preferably in the "Fill and Stroke" pane) should not be forgotten.

I also like to second that this should be classified as a bug.
It's very tiresome to create diagrams that use colored markers.

Try to sell inkscape to other people as a serious tool for creating diagrams, when this problem still exists.

I would like to request this as well. Without reading this bug description all the way, I wouldn't have figured this out. I was drawing on a black background, and the markers of course did not show up. So as mentioned several times above, this can be a show stopper.
Thanks,
---
Inkscape 0.47 on Linux, i386.

Hi!
Wow, this bug is very resistent.
First request in 2004, pretty soon after Inkscape startup, still alive in version 0.48 (August 2010, 6 years)
It is also interesting what the script "Color Markers to Match Stroke" does with such an arrow:
Simply taking a look in the modified SVG-file with a text editor
and comparing it with a file with a standard black arrow head...it is not really much.
For me it would be good if the markers would have the same color as the body of the arrow by default.
I never used such two-colored arrows. And I think most apps draw arrows in one color.
If someone needs this feature (like Cerno) THIS should be a an optional add-on, IMHO.
Not that is now a problem for me to get my arrows right,
but promoting inkscape in my workgroup is not that easy
if arrow handling with other apps like Corel Draw is much more intuitive.
This was a knock-out criterion because arrows are one of the most used graphic elements
to explain our scientific stuff and inkscape's behavior really slowed down our work-flow.

Anyway great application and thanks,
Mat
---
Inkscape 0.48 on Linux, Win XP, Win 7

Hello guys.

I really appreciate open source software, and I don't want to sound ungrateful, but hey,
I concur with some of the previous comments that something as basic as single color arrows
_does_ give people food for hating a program.

Having to install a 3 MB package (lxml) to use a macro that changes the color of the arrowhead to
match the line, and takes 3 seconds to do it on a single instance, in a very simple drawing,
is just not a solution. (on an AMD64 machine).

importance: Undecided → Low ???

I don't even see this bug on the path to 0.49. Isn't it time to solve this?

Hi John,

The "Low" importance refers to Ubuntu as a whole, not just to the Inkscape package. If you compare an annoying bug in Inkscape with something like a crash in the Linux kernel or the Xserver, it will clearly be of relatively low importance to the Ubuntu developers.

You would probably be more interested in the upstream importance for the Inkscape project, which is currently set to "Wishlist"

I agree with John #45. This is awkward behavior that seems like it shouldn't be hard to fix. This should be a bug, not wishlist, and it's relative importance to ubuntu is out of scope here. Could someone please attend to this (sorry, I can't)?

6.5 year old bug. Hope the priority can be raised.

Still present in version 0.48.1. Almost 7 years old now.

This Bug should get fixed. It's really annoying trying to make coloured lines with this.

I'll give another $50 to someone who fixes this bug, in addition to the $30 pledged above.

And I'll add another $20. That's $100 now for the guy who fixes the bug. And yes, it should be considered a bug, not a wishlist.

The SVG editor on googlecode seems to do this just fine, but Inkscape can't? Are you guys really serious?

http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html

7½ years old bug now. I will also throw in 5$ (over PayPal or wire transfer within European Union) to the person who fixes the bug.

Fix attached.

Marker color should match the line color when created.
If you change the color of a line the markers do not get updated - this gives you the option of having markers a different color to the line.
If you want to match the line color after a line color change, unselect and reselect the marker.
Markers are unique, a change in one line does not affect others.

This is obviously not a perfect solution, but a first step forward.

Any ideas for improvement more than welcome.

Technical details:
svg:marker top level group fill and stroke attributes both set to line stroke color
svg:markers's forked on creation
Unused markers are auto garbage collected
Markers combobox only shows original markers
SVG 1.2 shadowInherit/currentFill/currentStroke not yet supported

Testing 165865.v1.patch with Inkscape 0.48+devel r11573 on OS X 10.7.4:

John Smith wrote:
> svg:marker top level group fill and stroke attributes both set
> to line stroke color
Doesn't work well with stock markers which use a custom fill color (e.g. white), or open unfilled stroked paths, or filled unstroked paths:
- EmptyDiamond{L,M,S,Lstart,Mstart,Sstart,Lend,Mend,Send}
- EmptytriangleIn{L,M,S}
- EmptyTriangelOut{L,M,S}
- SemiCircle{In,Out}
- Curve{In,Out,Cross}
- Scissors
- Legs
- Torso
- InifiteLine{End,Start}
(see also: related discussion in bug #692582)

> svg:markers's forked on creation
Allow users to opt out of the new feature (and keep markers unforked)?

AFAICT current patch breaks "Custom markers" (menu 'Object > Objects to Marker') [1]:
- Newly created custom markers are not added to list of available markers anymore (can't be applied).
- Custom markers already existing in the <defs> section (e.g. from the user template file, or when editing an existing file) are listed, but don't stick when selected as {start,mid,end}-marker (immediately reverts to 'None').

To be tested:
- Any unintended side-effects on markers modified with the enhanced extension 'Marker Colors…' (bug #692582) in current trunk?

[1] <http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Attributes-Stroke.html#id1188586>

The attachment "165865.v1.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

> AFAICT current patch breaks "Custom markers" (menu 'Object > Objects to Marker'):
> - Newly created custom markers are not added to list of available markers
> anymore (can't be applied).

My mistake - this broke much earlier in current trunk (between r11072 and r11084, based on tests with archived builds - probably when replacing the deprecated GtkOptionMenu with GtkComboBox. I'll file a separate report about this.

> - Custom markers already existing in the <defs> section (e.g. from
> the user template file, or when editing an existing file) are listed,
> but don't stick when selected as {start,mid,end}-marker (immediately
> reverts to 'None').

Again using a sloppy test case: the custom template file (attached) used for testing contains a 'hybrid' custom marker with a 'stockID' attribute added manually:

    <marker
       style="overflow:visible"
       id="DotEmptyL"
       refX="0"
       refY="0"
       orient="auto"
       inkscape:stockid="DotEmptyL">
      <path
         transform="matrix(0.8,0,0,0.8,5.92,0.8)"
         style="fill:none;stroke:#ff0000;stroke-width:1pt;marker-start:none;marker-end:none"
         d="m -2.5,-1 c 0,2.76 -2.24,5 -5,5 -2.76,0 -5,-2.24 -5,-5 0,-2.76 2.24,-5 5,-5 2.76,0 5,2.24 5,5 z"
         id="path3802" />
    </marker>

This marker is not applicable in trunk+patch (reverts to 'None'), but works ok in unpatched trunk r11573.

v2 patch attached

> Doesn't work well with stock markers which use a custom fill color
Should be improved. Changed the logic of the color selection as below

Marker stroke color is always set to line stroke color.
Fill color :
1. If the line has fill, use that for the marker fill,
2. If the marker has no fill and no stroke assume its solid, use line stroke for both fill and stroke the line stroke
3. If the marker has fill color, use the marker fill color

There are also a few differences between this and the MarkerColor extension
* MarkerColor defs are not marked auto-collectable, this patch is (see comment #4 <bbyak> and don't forget to make such auto-copied markers auto-collectable)
* MarkerColor "name" as seen in marker list gets changed every time the color is updated, this patch tries to preserve the original name (original name is set in inkscape:stockid)

> Custom markers ... are listed, but don't stick when selected
Should be fixed.

> Allow users to opt out of the new feature
Will add a preference for this

> Newly created custom markers are not added to list of available markers
I will fix this is a separate patch (probably bug #903671)

> the custom template file (attached) ... not applicable in trunk+patch
This should be fixed

> > Newly created custom markers are not added to list of available markers
> I will fix this is a separate patch (probably bug #903671)

Thx, much appreciated - I filed bug #1030239 yesterday about the regression.

Latest patch attached, should compile after some recent fixes to the Stroke style dialog.
Please let me know if you have any comments about the way fill and stroke is applied to the markers (see comment #58)

With adding this patch on top of r11595 adding or modifying any markers seems to spam the custom markers section of the other markers lists with duplicates.

1) Create path
2) Apply mid-marker
3) Re-open mid-marker list and only one custom entry exists
4) Open either the start or end marker lists and there are two custom entries
5) Apply an end or start marker
6) Now compare the lists again

Thanks ScislaC for finding that.
Attached patch should solve the duplicate issue.

Also added a User Preference (Behavior->Markers) to turn off the marker coloring.
Could add some more options there if needed such as :
* Copy opacity from line to marker or not.
* Change color of custom markers or not.

Fixed in new patch. Those options would be very welcome.

New observations:

1) Create path
2) Assign marker (I did a mid)
3) Change stroke color

Result is that the marker color is not changed. Two things about this: I would think a lot of people would prefer the marker color be updated in sync when changing the stroke color if possible. I will be honest, I like the marker color not being locked to the stroke color yet relatively easy to change. Maybe an option to "Update colors on object color change" enabled by default? (unless this is actually not intended and a bug)

Now:

4) Change that marker to a different one
5) Change marker back to first one assigned from the custom list

Result is that it forks the existing first custom marker with the new color rather than actually using that marker as-is (and as displayed in the custom section)... I could see your second proposed option fixing that and to me it seems like not changing custom markers by default would be preferable.

Issue 1: There is an actual problem though if you toggle between markers in the custom section it continues (forking) even if the color has not changed which leads to a lot of unnecessary duplicates.

Issue 2: I also noticed that if I toggle between the custom markers enough and it keeps creating dupes it eventually gives them different names (not a complaint, just seemed odd that initial ones retained name for multiple dupes before starting the unique names). Perhaps it should just give unique names from the get-go?

Other observation:

Things get fun when using gradients on strokes. :)

I'm attaching a file. It shows two different lines where I assigned gradients to the strokes. I really don't know what the desireable behavior would be for this use case, but I'll give you the fun stuff:

Bottom line created, added gradient on stroke, changed gradient colors, switched to the Selector tool so no knots were selected, assigned mid-marker. Now when you change the start gradient knot color it updates the marker colors immediately with that color.

The difference with the top line is that I did not deselect the end gradient knot before assigning mid-marker. That object's marker colors are controlled by the end gradient knot. I can't seem to reproduce oddity by using the same steps however.

Just interesting behavior I figured I would report since people are bound to use gradients on strokes with markers at some point.

Forgot to mention an actual issue regarding the gradient controlled markers. Their previews are not reflecting what's on-canvas (the marker in the preview isn't shown at all).

New patch with the following changes

User Preference : Behavior->Markers->Change color of custom markers (default off)
When off custom markers are used as-is, color not changed, and not forked.
Preview for gradient markers shown in list

> Result is that the marker color is not changed (when changing line color)
Yes this is by design and is consistent with the Color Marker extension. This seemed like the best way to allow the user to set the marker color and line color separately. There are some other complications of having auto updates - if you have several lines all using the same color marker, then you update one line color - do you then update all the marker colors or not ? Could add an option for this later.

> Result is that it forks the existing first custom marker with the new color rather than actually using that marker as-is
Should be fixed by new User Preference

> Issue 1: There is an actual problem though if you toggle between markers in the custom section it continues (forking)
Forking only happens now with the user Preference above "on"

>Issue 2: .... it eventually gives them different names
Should be fixed

> gradients on strokes
If you check the def of the marker, it actually has the same gradient link as the line. Linear gradients seems to mostly render the first stop color, radial gradients dont work well. Not sure how to deal with this, since there is no way to independently tweak the gradient of the marker (stops, location etc) i dont think there is a perfect solutions to this. Any ideas ?

> Gradient previews are not reflecting what's on-canvas
Should be fixed

v5 tested

Issue 1: It appears that it's adding two copies of markers to the custom section when forking. One duplicate of the original one from the list as well as the correctly colored one.

Issue 2: If you assign a swatch (flat fill) to the stroke and then change that swatch color, the preview does not update.

> Yes this is by design and is consistent with the Color Marker extension. This seemed like the best way to allow the user to set the marker color and line color separately. There are some other complications of having auto updates - if you have several lines all using the same color marker, then you update one line color - do you then update all the marker colors or not ? Could add an option for this later.

I'd like to see other opinions, but I'm pretty sure the "average" user will expect all markers assigned to auto-update with the stroke color. The current implementation definitely is awesome and more powerful (and I like it), but something tells me that it will not be obvious enough and there will be a number of bug reports filed. As for the lines all using the same color marker, I say not to update the markers on other lines... but I imagine it would get ugly pretty fast with all the potential additional forking (if someone is using lots of markers and lots of different colored lines).

As for the gradient issues... Hmmm... I can't think of a really elegant solutions. Does this code at all interact with the function to create a marker from an object? If not, you could always detect if a gradient is on the stroke and just not change anything (with a note by the first preference that it doesn't work with gradients).

v6 attached, we should be getting close now ...

>> Issue 1: .. adding two copies of markers to the custom section
Should finally be fixed

>> Issue 2: change that swatch color, the preview does not update.
Previews should update on all color changes

> expect all markers assigned to auto-update with the stroke color
Auto update preference added (on by default). To stop other lines with the same marker from updating all new markers are forked (but auto collectible) on combo selection. This is the simplest efficient option, otherwise we would have to check the whole doc for other users of markers on every update - which is probably unnecessarily costly.

> gradient issues
Object to markers (custom markers) with gradients should work fine.
For objects (like lines) with gradient fill or stroke - instead of copying the gradient to the marker which doesnt seem to render - copy the gradients stop color (first stop for start marker, last stop for end marker). This should give fairly good results in the most common cases.

If there are no major bugs, i think we should commit this for wider testing and cleanup other issues as they arise.

The only issue that still exists is as follows:

Forking where it doesn't make sense (same line, same marker, all have the same style)...
1) Apply Arrow1Lstart as the start marker.
2) Change stroke color
3) Apply the same (custom) Arrow1Lstart marker to the mid marker
4) Go to apply the same custom marker to End and there are more than 1 copy of the custom marker in the list.

I don't know that it's a major bug as I agree it should hit trunk for wider testing. You get my vote to commit as-is if the issue I mentioned isn't an easy one to squash.

Committed to trunk r11614.
Included ScislaC's suggestion (#69) to not fork when same marker is used more than once on the same item.
Please test if you can ...

When you are talking about duplicates, I am not sure if you are talking about this (0.48+devel r11664):

1. Draw path
2. Add marker
3. Duplicate path
4. Select only one path and change fill color - after that markers on BOTH paths change fill color (but only visually); if you select the other path, markers on BOTH paths get the fill color of that marker

If this issue is already observed, sorry - there is too much to read so I probably missed it.

Same unexpected behavior (r11664, default prefs) with these steps:

1) Draw multiple paths
2) select all, add marker (arrow)
3) deselect all
4) select a single path and change the stroke color
--> all markers from step 2 change color
5) select a different path
--> all markers change color to the one used for the currently selected path

or:
1) Draw multiple paths
2) assign a different stroke color to each of them
3) select all, add marker (arrow)
--> all markers take the color of the first path in the selection (stack order)
4) deselect all
5) select random individual paths (use e.g. <Tab> to cycle through the current objects in stack order)
--> on each new selection, the marker colors for all paths are updated to the stroke color of the currently selected path

Commit r11671 should fix the problem with duplicates (comment #71 and first case in comment #72).

Duplicate fix confirmed on Ubuntu 11.04. Thanks!

John Smith wrote:
> Commit r11671 should fix the problem with duplicates

When quitting Inkscape after having changed the color of a duplicate, I now get these kinds of console warnings:
** (inkscape:89410): CRITICAL **: void Inkscape::GC::Anchored::release() const: assertion `_anchor' failed

Steps to reproduce:
1) Draw path
2) add marker
3) duplicate path
4) change stroke color of duplicate
5) quit inkscape

@~suv, thanks for noticing that, should be fixed in r11699.

The original bug was reported in 2004....after 8 years I start to believe I can only make black arrows...lol

Another very small bug related to multiple selection:

1. Draw two paths with markers.
2. Select all.
3. Modify the stroke color of the selection.

-> The color change only applies to the first selected object. The other one keeps its original color.

Workaround: selecting the second object automatically updates its marker color.

Who gets the bounty?

I mean: hooooooray! Finally!

... and who gets the bounty? :D