- Inkscape Devel - Inkscape Mailman

wmf import/export and uniconvertor
by the Adib 11 Apr '09

11 Apr '09

Hello, I saw a wmf_input.inx using uniconvertor so I created a corresponding wmf_output.inx as well :-) However in the code src/xml/rep-io.cpp there are some sections protected by #ifdef HAVE_LIBWMF that call sp_wmf_convert (localFilename). I have libwmf-dev installed on my computer (Ubuntu 8.10) On windows there is a system specific emf/wmf importer/exporter. Uniconvertor can not handle text for now. Questions: 1) is this code abandoned? I did not found any definition HAVE_LIBWMF using grep -R HAVE_LIBWMF * 2) How can we disable the uniconvertor extension on windows? Thx, Adib.

2 1

State of the Icons
by Guillermo Espertino 10 Apr '09

10 Apr '09

Bug #312993 proposed the Tango set for Inkscape 0.47 https://bugs.launchpad.net/inkscape/+bug/312993 This has already been discussed but nothing happened. The general consensus seemed to be that the majority wanted the default theme but that it needed to be fixed. The original Tango Icons didn't have much support, although an alternative version with toolbar icons similar than the defaults but "tangoified" had better luck. An improved version of the default set was presented in this list some time ago without much repercussion. Besides, the default set has been converted to a separated icons set but the work isn't finished yet and the possibility of use custom icons has gone. What's the current state of this? Is there a reason for not replacing the default set by the much improved version presented on the list? Would it be possible to commit the finished versions of both Tango (art libre) and Tango Colors icons in SVN? The reworked default theme, and both tango versions are complete and work fine with most of the GTK themes. They need improvements for very dark themes but it is possible that a new theme for that particular situation has to be created. In the bug report you can find the icons files and samples created by dopelover displaying the issues in dark themes. In my oppinion, every proposed set performs better than the current default. What do you think? Gez.

5 7

(no subject)
by worms invasion 10 Apr '09

10 Apr '09

Hello I noticed that in the "Save as" dialog, when you save a new file, the fields order when you do TAB is: File Name Type Save Cancel Title So you more likely will hit "Save" before you get a chance to fill in "Title". I remember a discussion about this on IRC, and the goal of adding the Title field was that it shouldn't "get in the way" of the user, or something, even though the "Title" field is part of the SVG specification (or something like that) So I'm wondering... would it make a big difference to have the order: File Name Type Title Save Cancel For people using the mouse to go from field to field, it won't make a lot of difference (I think), but for those like me who use TAB in that dialog, it would (3 TAB instead of 5, but 4 TAB instead of 3 for save) Also, it's a "Save as" dialog, so if you change the File name or the Type, there are chances that you would also change Title maybe, but the current order makes it more likely that you hit "Save" first. The same comment applies to the "Save a copy..." dialog. Anyway, that's only a question - I'm curious about why the current order is as it is, that is all :-) What do you people think? Regards

3 2

GSoC, KML-SVG - what is needed?
by Piotr Kopczyński 10 Apr '09

10 Apr '09

Hi. I've been playing with Google Maps for a moment. Actually, only "visually" interesting things there seem to be: - placemarks, with choosable icons - polygons, with customizable style - fill color and opacity, border (stroke) color, opacity and width - lines (paths), customizable like polygon's stroke above All these may (or must) have names and descriptions; the latter may be plaintext or html ("rich text"). I assume these elements are a minimum to be done. I can handle that easily (I guess :-) ). How close to your expectations is this subset? Did I miss some essential features? Another thing: what is the expected resulting SVG if the input KML contains, say, just a placemark with name, description and point with coordinates? Is it going to be a placemark's image (icon) and a rectangle (or something) with the texts? Or is it going to involve some background graphics (terrain's map)? Greetings, Piotrek

2 1

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

10 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 10 Apr '09

10 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 10 Apr '09

10 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 09 Apr '09

09 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