- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Opacity inheritance
by Guillermo Espertino 11 Apr '09

11 Apr '09

> Actually I can't reproduce this. It seems to remember the last solid > color I used. (When drawing rectangles at least.) Jasper, my bad. I tried with a recent compilation and it doesn't do that anymore. However, the opacity=0 is still inherited when you creat an object with that opacity, and that doesn't make much sense, imo. > Imagine being used to drawing an object, changing its style, then > drawing another object and seeing that it has the same look as the > earlier shape. Wouldn't it then be very weird if opacity was NOT > remembered? You'd then probably get bug reports (again) about how new > shapes have a different color from previous shapes, etc., etc. As far as I could see, most of the users doesn't consider the opacity as one of the atributes of the color. Opacity is considered commonly as an extra property, and not part of the color. That's why several users think their colors look "pale" when they're actually semi-transparent. The alpha value is commonly misinterpreted as a "tint" value. People use it when they want to make the color lighter, not transparent. Of course you have the HSL sliders and you can do a sort of tinting raising the value of the L slider. But both opacity and tinting are commonly applied as transformations over the color, not coloring itself. Don't get me wrong. I'm not saying that they aren't related to the color mixing, but people usually tend to see them as some kind of post-processing over the color. For instance, they take a red swatch and want to have tints of that red swatch. They don't look for a pink swatch with the same hue than the red swatch. That's why I think that opacity is commonly mistaken as tinting. > It would be ten times nicer if we could simply make it more obvious > what's going on, and make things more consistent (in one of the bug > reports the confusion started because paths behaved differently from > shapes for example). Yes, I agree. But how? What I mentioned is my idea of a fast workaround to avoid a common usage mistake. Of course it would be much better if we find a better way to make it clearer. But that would take some work, and my suggestion was intended to work around the issue, in the most elegant way possible.

1 0

Opacity inheritance
by Guillermo Espertino 11 Apr '09

11 Apr '09

In the bug report # 285966 (avoid inheriting transparency when it's set to 0) I commented about the problems of the style inheritance in new shapes. New users seem to be very confused by this feature, and in the particular case of creating a shape after setting a gradient (the style of the last stop is preserved, so the last style memorized is A=0) it leads to recurring bug reports because people don't get it and tend to think that there's something broken. I've been thinking about the inheritance of opacity and honestly, I find it rather annoying in most of the cases. At the moment is marked as a wishlist item, but I'm starting to think that it's probably an usability bug. I think that should be better to avoid opacity inheritance as default and make it optional via preferences (i.e.: preserving fill and stroke but not opacity unless the user select the proper option in the prefs). What do you think?

3 4

Improvements for ICC/CMYK Workflow
by Felipe Sanches 11 Apr '09

11 Apr '09

This is my GSoC application. Please, give me feedback so that I can improve it. *Project idea* My project proposal consists of a set of improvements in the user interface that would improve user workflow when dealing with CMYK color space and ICC color management. Last year I was invited (and received some funds) by Brazilian Government to participate in an event where a couple free software developers and some users of free software graphics applications such as GIMP and Inkscape had the oportunity to exchange ideas and brainstorm about issues related to printing. From these brainstorms I have gathered a set of issues that I believe are of high priority for the inkscape team. I propose that in my SoC project this year I would focus on these activities: - store CMYK color values in the SVG file using icc-color - create a default target device color profile option in the document properties dialog (color management tab) - automatically color transform the color palettes using the selected target device icc profile - automatically color transform the color picker widgets using the selected target device icc profile - brainstorm a way of properly displaying "out of gammut" colors in the user interface - implement "out of gamut" user interface - colors using an alternative color profile should be the exception case (thus, only this case would require the user to explicetely chose the icc profile in the CMS tab at the fill&stroke dialog). Other colors should automatically use the target device profile. JucaBlues

4 4

GSoC 2009 Preliminary slot allocations
by Josh Andler 10 Apr '09

10 Apr '09

Hey mentors, The preliminary allocations netted us 5 slots. Please take that into account with any rankings or reviews that need to be finalized. Cheers, Josh

1 1

LGM
by Alexandre Prokoudine 10 Apr '09

10 Apr '09

Hi, Inkscape is listed as main project at Libre Graphics Meeting, and yet Ivan Louette seems to be the only guy who signed up. Is anybody else coming? Ted? Bryce? Jon? Bulia? Mental? Alexandre

4 3

Refactoring freeze: tomorrow!
by bulia byak 10 Apr '09

10 Apr '09

Guys: I understand that coding is addictive, but we must finally move ahead with the release. So, unless there are serious objections, I declare a refactoring freeze starting tomorrow at noon EST! Please do all your refactoring commits before then. To refresh your memory, a refactoring freeze means: > no lib migrations, no rewriting and rearranging code "for general correctness", and no 2geom syncs "just in case" until the release. I realize this is all done for good reasons, but experience shows that each such wave of changes brings bugs that keep popping up long after the wave has passed. So, let's stop refactoring and start bugfixing in a serious way. Thanks for cooperation! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

SVG Open Call for participation
by Ted Gould 10 Apr '09

10 Apr '09

Hello, For those who are interested the Call for participation for SVG Open this year has gone out. Very exciting, and specifically I can comment on how nice conferences are on the Google campus. All the information is in this mail, of course Inkscape related SVG topics would be interesting to most of the participants. http://lists.w3.org/Archives/Public/www-svg/2009Apr/0052.html It would be cool to have a good showing at the conference. --Ted

1 0

Couple of text bugs
by Thomas Worthington 09 Apr '09

09 Apr '09

I went to print a piece of text on a path last night and nothing appeared. Once the text was converted to paths itself it printed fine. Version 21051. Another, long-standing bug, is that text behaves strangely when aligning. I generally find that of several pieces of text the one used for "relative to" is fairly random; certainly the choice in the alignment menu is frequently ignored. I've not found a pattern yet - the object's ID does not seem to be the basis of the choice nor does the type of alignment (baseline, left, top etc) seem to matter. The order of the objects on the page seem to have something to do with it. Anyone else seeing this? -- Thomas Worthington Tech Nouveau 32 Bangor Road Groomsport BT19 6JF 07748 792333

1 0

Conditional compilation in 2geom
by unknown＠example.com 09 Apr '09

09 Apr '09

Hi all, Recently in 2geom, "HAVE_GSL" and "GPL_TAINT" #defines were created, to optionally leave out certain parts of 2geom. How should Inkscape handle these things? Should the make script define those things on the commandline? Or should 2geom provide hooks to a 'config.h' of its own that Inkscape can tweak? Thanks for thoughts, Johan

3 2

The bias property for feConvolveMatrix
by Jasper van de Gronde 08 Apr '09

08 Apr '09

The SVG standard defines a "bias" property for feConvolveMatrix to offset the result of the filter. It specifies that this value should simply be added to the result for each channel. Implicitly the standard defines that these are premultiplied color values, however, this seems to make little sense, as the bias has very little meaning without taking the alpha channel into account. The standard also says that one of the applications of a bias is "to have 0.5 gray value be the zero response of the filter", this seems to be directly contradictory with adding bias to the premultiplied values (as then the same bias could suddenly stand for white if alpha was 0.5). So, what to do? Batik doesn't seem to support bias!=0 at all, so there is also no precedent. I currently let feConvolveMatrix make bias relative to alpha.

2 1