Color markers to match stroke extension does not copy the fill mode

Sorry, I forgot to include the affected Inkscape version: I've tested it on Inkscape 0.48.0 r9654, but it'll affect all versions of Inkscape that use the old extension file.

By the way, this fix also directly affects bug #165865 ("markers must take object's stroke color (SVG 1.2 feature)"), but I don't know how to link this fix to that bug.

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

IMHO the current behavior is a not bug: the extension does exactly what is intended to do and what it tells it does in its name:
"Color markers to match stroke" (i.e. match stroke, not match style).

Maybe your changes could be added as separate variant or integrated into the current one as option (by adding a dialog)?

@JazzyNico - what do you think?

As explained in Bug #165865, this extension is just a (persistent) workaround. But we could surely improve it by adding that kind of option. We could indeed add a dialog with a stroke/style option, and also take the fill and stroke alpha channels and the object opacity into account (by default or with an additional option).

I'd opt to keep the current mode as default (see attached example: for technical drawings or diagrams - using Inkscape's stock markers - I doubt that unfilled arrows and dots is what users expect or really intend).

As for the stroke/style issue not being expected or intended by the user: There's a wide range of default markers, some with a solid black colour, others empty. So the user already has to actively select which one they want.

Unfortunately -- with the current patch -- you have to select an actual fill colour for the path before executing the extension to get a "proper" empty/solid marker, and afterwards remove the fill colour from the path to get a proper line path again. That sucks, but it's the only way the user can currently specify what kind of marker she wants.

The reason for that is that the patch chooses transparent white (#00000000) when no fill-style is set; which is true for the default line paths and thus results in transparent markers. But changing that to opaque-white would be counter-intuitive because the original chooses transparent white for "stroke" when no stroke colour is set, so the currently patched behaviour exactly mirrors that behaviour.

Ideally, the script would detect what kind of marker the user has chosen (empty/not-empty) and alter behaviour accordingly. That means on "empty" markers to set the fill colour to opaque white (or an opaque version of the path's fill) and on "solid" markers to use the stroke colour. Unfortunately, my Python skills are only good enough to read and comprehend, but not enough to implement completely new features. So if you could alter my patch to include that check, that'd be great! The crudest, most hack-ish but simplest solution would probably be to check the marker name (which is already queried, I think) and see if it contains the phrase "empty" (case insensitive).

I agree that the optimum solution is to implement colouring markers "natively" without the use of an extension. But at the moment, the extension's all that's there, so it seems sound to improve it as far as possible.

Hi again.

I've taken the liberty and implemented the crude "empty/non-empty" distinction. The new patch-file is called "markers_strokepaint_fillfix_v2.patch"

Hi Martin,

Your empty/non-empty idea is good, but should not be implemented by comparing the id of the marker. Attached is a modified version of the extension (inx file included) that allows users to choose the fill type (stroke, fill, or transparency) and to apply the alpha channel or not.

Looks great. I've played a bit with it, and that change does much more than I originally wanted and greatly simplifies handling markers.

Thanks again!

I'd like a lot having markers automatically take the line's stroke and fill (or stroke and stroke or whatever) when you first assign them to their line. Then you can further change the line colors (having the marker keep the original) or use this nice extension to achieve more elaborate effects.
I think that in most cases you simply want to add an arrow or another "decorative accessory", so it would best have the line's color (IMHO only line's stroke is relevant). Limiting the markers to this scenario would be wrong, but giving to it a little more evidence shouldn't break anything. I see no reason in having them default to black: if you are drawing white lines over a black background it can be really misleading.
Regards.

@JazzyNico - thx, great enhancement!
Nit-picking detail - with these settings:

  Replace marker fill with 'White'
  [x] pick alpha

the fill-opacity is ignored and the marker filled fully opaque white. One might expect that the fill-opacity in this case is picked up too, since the stroke opacity is picked up?

@~suv - Well, my first version applied the fill opacity to the white color, but I found it a bit illogic to apply a color and an opacity from another one. Maybe we should replace "White" with "Opaque white"? Or would you really prefer to pick the fill opacity?

@JazzyNico - maybe too late, but here are some of my thoughts:

Maybe the dialog needs two tabs [1]:
a) use color / opacity from object
b) set marker style independently

In the first tab, stroke and fill style (color, opacity) are taken from the selected object (mimicking style inheritance):
- solid marker (fill & stroke use object stroke color)
- filled marker (fill & stroke use object fill & stroke color)
- inverted marker (fill & stroke use swapped object fill & stroke color)
optionally pick opacity from object (for both fill and stroke)

In the second tab, markers can be colored independently:
- stroke color with alpha (color chooser or list of presets)
- fill color with alpha (color chooser or list of presets)
optionally no fill / no stroke

[1] similar to the latest version of the 'Guide creator' <http://code.google.com/p/inkscape-guides-creator/>, or the extension 'Replace fonts', each tab applies a different command (i.e. the settings don't add up between tabs).

@~suv - Hey, stop reading my mind ;)

That's more or less something I've planned to do. I just hesitate between improving the existing extension and adding a new one (a kind of Markers Fill & Stroke dialog).
If we choose to keep one extension only (which has my preference), we'll probably need to rename it ("Color Markers"?).
Note that the extension color widget is simpler than the F&S dialog one and that we can only choose flat colors (no gradients, no patterns - see the custom predefined filters).

BTW, the files attached comment #9 are available in the trunk as for revision 9977 (the only change is that "white" is now "opaque white").

New version attached, renamed 'Color Markers' and modified according to comment #14 (except the invert option which is implemented as a boolean option).

I've tried to keep how the 'none' attribute is handled (in the original extension 'none' values are not overwritten), but had to adapt the extension a bit:
1. If the marker has a 'none' fill attribute and the first tab is used with a 'solid' marker type, the extension doesn't apply the fill and fill-opacity attributes.
2. If the marker has a 'none' stroke attribute and the first tab is used with a 'filled' marker type, the extension doesn't apply the stroke and stroke-opacity attributes.
3. In all other cases, all color and opacity attributes are modified.

Comments are welcome!

Updated extension committed in the trunk, revision 9982.

Inkscape 0.48+devel r9982, OS X 10.5.8, using Python 2.6.6:
Initial tests with 'Custom' work fine, but 'From Object' fails with:

Traceback (most recent call last):
  File "markers_strokepaint.py", line 158, in <module>
    e.affect()
  File "/Volumes/green/mp-inkscape/src/inkscape-trunk/Build/share/inkscape/extensions/inkex.py", line 227, in affect
    self.effect()
  File "markers_strokepaint.py", line 149, in effect
    if (not(self.options.tab == '"object"' and cstyle['fill'] == 'none' and self.options.fill_type == "solid")):
KeyError: 'fill'

Oh, I forgot to test when a fill or stroke attribute doesn't exist...
Should work as expected as of revision 9983.

Fix in r9983 tested and confirmed - what a fancy extension this turned into ;)

If there's something that warrants the expression of "snowballed into an avalanche", then the work on this extension seriously fits!

I'm amazed at what my simple bug report brought into motion. Now, the only wish I could still have is if this facility could eventually be moved from a python extension into Inkscape's core functionality for markers.

Apart from that, much kudos from me for your great work!

I am new to Inkscape and have the arrow color problem discussed above. I tried to use the extension installed in 0.48.2 (OSX Lion) and got the following error: The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, ...
I then tried to download and install the libxml2 and found I needed an installer. I found Distribute and tried to install it through the Terminal using the instructions in the install file and got :
OSError: [Errno 13] Permission denied
Can you help? Keep in mind I am not very Terminal/linux literate. Thanks- Dave

@David Knecht: Unfortunately, python-based extensions don't work with the official Inkscape app (0.48.2) on OS X 1.7 Lion. The issue is tracked separately in
 Bug #819209 “Extensions do not work with Mac OS X Lion”
 <https://bugs.launchpad.net/inkscape/+bug/819209>
and will hopefully be addressed in the next bug-fix release (or the next major release).

It is nothing about "fortune" while we are still suffering from a bug which has been reported and listed for over 8 years. Users couldn't say that it's about intentional negligence or discrimination of users of OS other than linux because they have to show their respect and maintain politeness to open source ware makers, but could make their decisions.

Hi all,

I've patched the extension on my Inkscape 0.48.4 r9939 (Windows) and noticed that arrow ends with white background now had no background. :-( So I patched the patch :-).

I haven't got the original file any more, but it's only small, so I'm attaching the revised version. It affects the second bit of the patch on line 72.

This concerns only one file: markers_strokepaint.py.

Cheers
Elena

Hmm, having re-read the comments in this thread, I may have been solving something that's already been solved. My starting point was however the current distribution, and I applied patch from comment 1. :-s

Anyway, you now have another way of doing it. :-)

Thanks
Elena

Extension disabled in 0.91. Targeting the fix to 0.92.