- Inkscape Devel - Inkscape Mailman

Two icon issues
by Jon A. Cruz 13 Apr '09

13 Apr '09

Hi, just a quick note on two current icon issues. The first is that some of the icons when rendered from our internal svg are blurring out at different sizes. This one is due to changes made on Saturday, but I should have a handle on fixing very shortly. The other one is a bit of a spill-over issue in icons on some versions of GTK. This mirrors an issue I saw before where some icons in the same setup were being cropped. For default with a size set to 18 pixels, the GTK theme is using 16 pixel icons and causing issues. I'm not sure if this was a bug with those older versions or just not quite setting things up well. With the same setup, I do not see a problem if the gtk theme sets the size to 12 or 14 or 16 or 22, etc. Just that one main size is triggering it for me. So to sum up... if anyone sees the first issue, don't worry; it's being fixed. However, if anyone sees either cropping or junk on the right or bottom on icons of the second issue, please drop a quick response which which platform and which versions of GTK+ these problems are seen with. Thanks.

1 0

GSoC, KML-SVG: The proposal, version 2
by Piotr Kopczyński 12 Apr '09

12 Apr '09

I have made a more detailed proposal of what might be done, including a rough timeline (actually just the time amounts - I put the timeline into Google Calendar). The basic part is what I find both necessary and lasting to tell that KML files can be essentially displayed as SVG. There are also additional ideas for improvements but I don't feel like I should decide what is important or needed. This is where I am asking you for directions. Initially I was having many ideas of what could be made in this project. Now I'm afraid there is hardly any chance to touch exporting from SVG to KML (except for an extremely simple cases or some silly assumptions) or the import wizard for Inkscape, as in the first proposal. I would rather focus on the KML->SVG transform. Of course, I would like to know your point of view. As for the previous version of application: firstly, I realised that those "configuration options" are not really needed and may be considered as an extension or optional part. Secondly, the mentioned web server requirement issue is no more important. I have adjusted my "framework" for this project and it works fine for static XSLT's which may be enough for the project. I put the reviewed proposal as a comment to the application: http://socghop.appspot.com/student_proposal/show/google/gsoc2009/piotrekk/t… It is still just an estimation. I have taken into account the time needed for basic learning, preparing tools, debugging and unpredicted situations, thus the timeline may be quite realistic. The next comment contains some ideas how the basic part can be extended or improved. I would need some advice about that "optional" parts, as well as a revision of the "minimal" set. Any clues are welcome :-) The plan (basic part) seems to be finishable before the mid-term evaluation, so I am asking for suggestions what else should be done. In the meantime I will keep investigating the SVG and KML secrets :-) Best Regards, Piotrek

1 0

multipage inkscape
by Albert Cardona 12 Apr '09

12 Apr '09

Hi all, Are there any news on old plans to add multipage support to Inkscape? Having multiple pages would be fantastic. We could then use Inkscape for the formatting of books and magazines, and pdf slides for talks. No existing open source tools (except pure latex + beamer) can be used comfortably for the task (and I have been using them for years now.) Albert -- Albert Cardona http://albert.rierol.net

5 4

Re 2: GSoC, KML-SVG - what is needed?
by Piotr Ko 12 Apr '09

12 Apr '09

> I think KML also allows you to specify image overlays. > Fine, I'll take it too (there's a <GroundOverlay> element in KML, I believe this is what you mean). Regards, Piotrek

1 0

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