- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-user] Re: pdf2svg, xmlns bug
by MenTaLguY 12 Jan '05

12 Jan '05

On Mon, 2005-01-10 at 20:43, bulia byak wrote: > On Tue, 11 Jan 2005 12:24:16 +1100, Trent Buck <fubarbaz@...405...> wrote: > > I noticed Inkscape refuses to read their example SVGs; it appears > > Inkscape *needs* the xmlns attribute in the <svg> tag. Without an xmlns > > attribute, Inkscape brings up an error dialog ("Failed to load the > > requested file foo.svg"), but prints nothing to stdout or stderr. > > Mental, this seems to be a rather urgent problem. I'm not likely to be > working on it in the near future, so if you can fix it, please do. I can try, but with present work demands I can't promise quick progress. I would like to see it fixed before the release; a high-priority bug ought to be filed if one has not been already. -mental

1 0

changing font size within text
by David Christian Berg 11 Jan '05

11 Jan '05

Hey guys, just wondering, if there's a way to change the font size within a <text> element. Basically I guess I need a <tspan> but they create new lines, which I don't want. Thanx in advance! David

3 8

Animation
by Ashwin Bharambe 11 Jan '05

11 Jan '05

Hi all, Quick question: does Inkscape support animation? If not, is the support planned? Thanks, Ashwin

6 9

Re: SVG presentation tool (fwd)
by Bryce Harrington 11 Jan '05

11 Jan '05

Ashwin, Cairo also has a SVG presentation type tool. Here's some info on it. Bryce ---------- Forwarded message ---------- Date: Tue, 03 Aug 2004 18:39:09 -0700 From: Keith Packard <keithp@...579...> To: Bryce Harrington <bryce@...1...> Cc: keithp@...579... Subject: Re: SVG presentation tool Around 18 o'clock on Aug 3, Bryce Harrington wrote: > What tool did you use to give your presentation at OLS? Was it > Cairo-based? Yes, the tool was 'xsvg'; our simple svg viewer application which can be found in cairo CVS. It's far from a complete presentation tool, but it suffices for our needs. We use an xslt transformation to convert a simple slide xml format into svg. All of that is in cairo-artwork module. It's quite broken and has to be hacked extensively to restyle it for a new talk. -keith

1 0

[Fwd: Re: [Inkscape-devel] Proposal for bug fixing for 0.41]
by Felix Rabe 11 Jan '05

11 Jan '05

2 1

nightly builds issue
by Alexandre Prokoudine 11 Jan '05

11 Jan '05

Hi, I have a problem compiling Inkscape from nightly builds in GNU/Linux: after ./configure: --- Configuration: Source code location: . Destination path prefix: /usr/local Compiler: g++ CPPFLAGS: CXXFLAGS: -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 LDFLAGS: Use Xft font database: yes Use gnome-print: no Use openoffice files: yes Use MMX optimizations: yes Use relocation support: no --- I do: --- [avp@...33... inkscape-0.40cvs]$ make make: *** No rule to make target `configure.in', needed by `Makefile.in'. Stop. --- I have: [avp@...33... scribus-1.3.0cvs]$ rpm -qa | grep auto | sort autoconf_2.5-2.59-alt3 autoconf-common-0.2-alt1 automake_1.6-1.6.3-alt6 automake_1.7-1.7.9-alt1 automake_1.8-1.8.5-alt1 automake-common-0.2-alt1 I don't have that problem with usual CVS snapshot I get with cvs up -Pd, but I don't have a possibility to grab CVS myself very often. What could be reason for that error message? Alexandre

2 1

Some more icons to fill the gaps
by Andreas Nilsson 11 Jan '05

11 Jan '05

As promised, here are scalable replacements for cap_butt.xpm, cap_round.xpm and cap_square.xpm http://ramnet.se/~nisse/diverse/temp/cap_butt.svg http://ramnet.se/~nisse/diverse/temp/cap_round.svg http://ramnet.se/~nisse/diverse/temp/cap_square.svg - Andreas

1 0

AGG backend?
by Chris 11 Jan '05

11 Jan '05

Has anyone looked into using AGG (http://www.antigrain.com) as the low level back-end? AGG itself seems very low-level in some places, which might cause problems but it seems very functional. I searched this list and found another reference that said it might be good for being able to add the SVG filter support. Personally, I would love to finally have that functionality. I made a real quick look at the code and it looked nice and seems flexible. In my limited testing I found that it was extremely fast. It doesn't have much in the way of SVG support though. There is an example SVG viewer but barely has any functionality. I suppose Inkscape would just keep its current SVG stuff anyway. I was just wondering if anyone had looked into it and if they found any serious issues. I assume Inkscape switched from librsvg to livarot for some good reason and I'm just wondering if AGG was a consideration. -- // Chris

4 5

svgs versions of join_miter, join_bevel and join_round
by Andreas Nilsson 10 Jan '05

10 Jan '05

Did some more svgs to fill the missing holes. http://ramnet.se/~nisse/diverse/temp/join_miter.svg http://ramnet.se/~nisse/diverse/temp/join_bevel.svg http://ramnet.se/~nisse/diverse/temp/join_round.svg Coming up are the caps. Probably tomorrow. - Andreas

2 3

First try at multiple tracing
by Bob Jamison 10 Jan '05

10 Jan '05

Hi, all, Today I finally got an initial (very rough) ability to scan an image multiple times, and produce multiple paths. The trace option I added today does: 1) Quantizes a bitmap into a reduced number of colors or shades of gray 2) Separates out each color, and traces it (much like taking four-color art to your local print shop). 3) Scans each one, applies the color to it. 4) Assembles them as a <g>roup. It seems to do fairly well with simple images, but complex ones have a "Potrace problem". What I mean is that since Potrace traced an estimate around each region, the reassembled curves do not exactly tile together again. You might need a background shade or something to keep the white background from peeking through. But give it a try. It should be a bit of fun. If anyone can think of a good general algorithm for stitching together two adjacent curves, give it a try. There will be more stuff later, of course. The 'differing levels of brightness' thing will be added soon. Bob

4 9

problems linking on win32
by Adib Taraben 10 Jan '05

10 Jan '05

Hello, I got problems linking on win32: ... ranlib libinkscape.a mingw32-g++ --export-dynamic -o inkscape.exe main.o winmain.o inkres.o libinksca pe.a -Lc:/gtk/lib -lgtkmm-2.4 -lgdkmm-2.4 -lglibmm-2.4 -latkmm-1.6 -lpangomm-1.4 -lsigc-2.0 -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpan goft2-1.0 -lpangowin32-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -Lc:/gtk/perl/lib/CORE -lperl58 -Lc:/gtk/python/libs -lpython24 -lxm l2 c:/gtk/lib/iconv.lib -lfreetype6.dll -lfontconfig-1.dll -lpng -lpopt c:/gtk/l ib/zdll.lib -lgc -mwindows -lws2_32 -lintl libinkscape.a(prefdialog.o)(.text+0x14e):prefdialog.cpp: undefined reference to `Gtk::Socket::Socket()' libinkscape.a(prefdialog.o)(.text+0x1b8):prefdialog.cpp: undefined reference to `Gtk::Socket::add_id(unsigned int)' libinkscape.a(prefdialog.o)(.text+0x50b):prefdialog.cpp: undefined reference to `Gtk::Socket::Socket()' libinkscape.a(prefdialog.o)(.text+0x575):prefdialog.cpp: undefined reference to `Gtk::Socket::add_id(unsigned int)' collect2: ld returned 1 exit status mingw32-make[1]: *** [inkscape.exe] Error 1 mingw32-make[1]: Leaving directory `E:/projekte/inkscape/src' mingw32-make: *** [all] Error 2 any ideas ? Is there a more recent gtk32 needed ? Thanks Adib.

3 4

New rotate icon
by Andreas Nilsson 10 Jan '05

10 Jan '05

I saw there were currently no svg icon for rotate. Here ya go: http://ramnet.se/~nisse/diverse/temp/rotate.svg - Andreas

1 0

[Fwd: Re: [Inkscape-devel] Suggestion for the preferences dialog]
by Felix Rabe 10 Jan '05

10 Jan '05

This is actually a rather "old" email, sorry.

3 3

Save as.../Export etc.
by Alexandre Prokoudine 10 Jan '05

10 Jan '05

Hi, Bryce told me that some dialogs need redesigning and "Export to bitmap" is one of them. After some serious thinking I came to conclusion that redesigning "Export to bitmap" is not enough. The issue is actually with Save as.../Export dialogs themselves. IMO, there are some inconviniences that need to be fixed. Let's look at these functions through the user case glass. Designer A has done a nice sketch. Though he likes it, he wants to make another version. He saves it under some other name and keeps working on the new file. Designer B has done several sketches. Now he wants to send them to his customer in some easy to view file format. He needs to save copy of each original file in a different file format in the same directory, where originals are. Now let's look closer. In the first case he wants to go to "File - Save as..." and specify name of the new file in the same directory, without changing file extension. The only reason to "save as" into, e.g. AI is when he was told that the new version has to be done in AI from ground up -- and only if his $VECTOR_GRAPHICS_EDITOR supports direct editing of AI files. I wonder how smooth Inkscape is at editing AI/EPS/EPSI/POV/PS instead of native SVG :) In the second case he wants to go to "File - Export as..." and: 1) specify name of the new file; 2) specify its extension; 3) specify export parameters. I don't even doubt that Inkscape will have export parameters dialog for EPS and PostScript (and TIFF as soon as someone writes it). Users are not supposed to see "Export to EPS", "Export to TIFF" etc. menu items in "File", don't you agree? ;) The GIMP model I'm talking about is quite nice, but its has a PITA drawback -- The GIMP doesn't remeber the last directory it went to. If you find a way to work around it, we will need the following: 1. Add "Export as..." menu item to "Files". 2. Add "Export to" dialog in a GIMP style with - a file name entry box; - a combobox to switch between directories from gtk bookmarks; - a hidable large "Specify directory" file panel; - a hidable "Choose export format" panel. 3. Move current "Export to bitmap" dialog to a new dialog "PNG export settings" which will appear, if a user chooses PNG as export format. Adding export settings to other file formats will be easier then. Guys at Novell have good points in their DesignWiki (http://primates.ximian.com/~glesage/wiki/doku.php?id=gimp:png_export). I really like their idea, so I suggest: 4. Add "Fast export" (or "Save for Web") menu item to save a PNG to the same directory, where the sketch is, or to a "fast export" directory specified in Inkscape's preferences. It will make decision on saving region from the selection context: - export the whole page, if nothing is selected; - export current selection, whatever is selected. Honestly, I don't remember myself ever saving a "special" region -- only current selection or the whole page. If I want something to be absent in exported bitmap, I either don't select or move it away out of the page. But my use case may be different from yours. I can imagine a situation when a designer needs to export "slices" from his design. I really hope that this proposal makes some sense to you :) Alexandre

6 8

inkscape rpm second patch (fwd)
by Bryce Harrington 10 Jan '05

10 Jan '05

Could someone apply this patch if still needed? Bryce ---------- Forwarded message ---------- Date: Thu, 30 Dec 2004 07:43:58 -0500 From: D. Scott Barninger <barninger@...639...> To: Bryce Harrington <bryce@...260...> Subject: inkscape rpm second patch Bryce, Here is a second patch against the 1.14 CVS spec file. It adds build choices for both SuSE 9.2 and Fedora Core 3. Regards, Scott

1 0

problems
by David Christian Berg 09 Jan '05

09 Jan '05

I had a cvs version of Inkscape running, and it would not have working flowtext... so that is problem number one. Number two is, that after downgrading to the Debian package my guides were at the wrong spot due to the change of units. Both really annoying... Also I've noticed that quite often I just can't grab objects, to move them, but have to use the keyboard first, and then, after moving them a little, I can move them with the mouse. I've no idea, how to reproduce this, but it bothers me a lot, so maybe someone else has experienced this? Another point, I noticed, when creating the icons, is that the scaling mechanism works kinda weird with objects with strokes... when you try to set a specific size, it will not work via snapping to guides nor via the tooloptions bar. Just try on very small scales... because that is where you'll notice. That's it for now... I'll be writing another mail soon, I guess. After some feedback I'm also in for doing the needed bug reports. David

2 2

autopackages now statically linked
by Mike Hearn 09 Jan '05

09 Jan '05

Hi guys, I'm now statically linking the GTKmm stack as well as Boehm GC into the Inkscape nightly autopackages, and will do so for the next release. So we should have no more problems with them blowing up on people with mixed/broken distro setups. I also added dep checks for libxml2 and libxslt. thanks -mike

1 0

Broken string trimming
by Jon A. Cruz 09 Jan '05

09 Jan '05

I just saw this in the jabber logs (01:20:33) *bryce:* to delete the first N chars off the start of a string s, is it ok to do s += N? The answer, for most of our stuff, is a big resounding "NO!" Remember, when multibyte encodings come into play, doing something like that is liable to break things mid-sequence and corrupt data. Or to get the wrong count and trim fewer characters that you'd expect. In most places our code is using the 'standard' GTK+ encoding of UTF-8. That's multibyte, with from 1 to 6 bytes per character. Of course, if you're at the point where raw data is entering the app via some means other than UI widgets, the bytes will be in whatever the local encoding is. So just remember, characters no longer match bytes one-for-one. Sometimes they'll happen to align, but other times not.

5 7

Draw Icons
by David Christian Berg 09 Jan '05

09 Jan '05

For all those of you who like a more Adobe-ish look for the drawing tool icons: Attached is a icon set that covers the drawing tools. The groups are named correctly, so you only need to delete the icons in the icons.svg and insert the attached file (you might have to ungroup the inserted file afterwards) Enjoy! David

7 8

0.41 About Artwork
by Andy Fitzsimon 09 Jan '05

09 Jan '05

attached is a png snapshot .. you can grab the svg from the url below (56 warning ) http://andy.fitzsimon.com.au/about41.svg let the controversy begin :-) This style was pretty trendy in 2004. its a hybrid of the distressed/metro-sexual looks. And I'm embarrassed to admit I think I have a pair of jeans & shirt somewhere with the same 2second mongrel print-work on it. So... why did I slaughter the comfort of your eyes ? Because Inkscape makes it so easy ! Thanks to the calligraphy pen, inset/outset and simplify commands this style is more easy to emulate with Inkscape than any other vector illustration program. There are starving indie-punk kids out there right now making their band t-shirts with this stuff. And they are paying ( or at least their universities are ) for the proprietary software their art is made with. Anyway i thought id just throw this around as an idea. let me know if it gets approval note: I'm happy to create a completely different about page. I understand there are several conferences coming up and it might be useful to have our next release looking as professional as possible.

4 3

version numbers: 0.41, 0.42, Gtkmm, and 0.50
by Derek P. Moore 08 Jan '05

08 Jan '05

I've been helping Bryce recently with the experimental Gtkmm codebase. Today I was thinking about all the work involved, what it means, and version numbering... A top-level UI replacement in Gtkmm is a pretty big change in the architecture of Inkscape; and though creating it isn't terribly difficult, tying the existing application (the canvas/viewport, tool and feature implementations, etc.) and all its functionality into the hollow shell of the Gtkmm UI will present more of a challenge. And it may take longer than we hope (a quarter of a year, maybe). If 0.4* stayed stable for a while, that might be nice. We could probably use more than one stable release before the work of transitioning Inkscape to the new top-level GUI is up to snuff with what we've got now in the 0.4 tree. There's going to be a lot of things to hunt down and tear out of Inkscape to make way for The New Way(tm)... And I imagine it's going to be fairly tedious hooking everything up. But I think we can wrangle two codebases at once, as they're not all that radically different. And many development communities are familiar with the concepts of separate "stable" and "development" trees. The people working a lot on 0.4 can keep working a lot there. In about a month or so, we'll probably be ready for 10% of your coding time to help move your bits to the development tree. Once everything is moved over to the new shell, and is stable and ready for general users, we could then tag and release the development tree as 0.50. I could see us getting well into 0.45 before 0.50 is ready to replace the old codebase. But I also imagine that the 0.5 codebase could become stable and interesting enough early on in the process to attract new developers and alpha/beta users. I just thought going about the next major release this way might give us developers more room to breathe, instead of trying to cram all this work between 0.41 and 0.42 (although that approach might be more "exciting" :). Any thoughts? Derek

9 25

oops: metadata bug
by Kees Cook 08 Jan '05

08 Jan '05

Since the "svg:" prefix change, there was another bug with metadata where every time you opened an SVG, it would add another empty "metadata" tag. I've fixed this now, but please check your files. icons.svg, for example, had like 40 extra metadata's in it. ;) -- Kees Cook @outflux.net

5 6

ANNOUNCE: Scribus 1.2.1
by Plinnell 08 Jan '05

08 Jan '05

The Scribus Team is pleased to announce the release of Scribus 1.2.1 - Open Source Desktop Publishing. The Scribus team urges all users and distros to use this latest release. This release also marks the first public offering of commercial support by members of the Scribus Team. This support is primarily intended for printers, publishers and other interested parties in receiving expert implementation and migration support. Building on the first stable 1.2 version released in August 2004, 1.2.1 intergrates new import/export features, python scripter additions and rendering speed improvements : * A new OpenOffice.org importer. The new importer imports OO Writer files,complete with OO.org Writer styles retained. The OpenOffice.org Draw importer inserts Draw files onto the page as native Scribus objects. * Substantial improvements in the Python Scripter, including added functionality and enhanced error handling. * Numerous improvements to SVG import/exporter. *Over 100 bug reports and user feature requests have been squashed. *The 1.2.1 release also adds updated English documentation, along with a new easy to navigate help browser. *The Scribus GUI is now translated into 30 languages Downloads: Mirrored: http://sourceforge.net/project/showfiles.php?group_id=125235 http://www.scribus.org.uk/downloads/1.2.1/scribus-1.2.1.tar.bz2 md5sum: 002cb629e817722f4123df7a41fc824b size 6436083 bytes GPG signature for source tarball: http://www.scribus.org.uk/downloads/1.2.1/scribus-1.2.1.tar.sig Template package: http://www.scribus.org.uk/downloads/1.2.1/scribus-temp-all-1.2.1.tar.bz2 md5sum: 19d102ff16c295e29bb7a051c66c2c58 size 1435895 bytes Scribus home page : http://www.scribus.net Document Site: http://docs.scribus.net Features http://bugs.scribus.net Enjoy!

1 0

Thanks
by Matthew Colyer 07 Jan '05

07 Jan '05

I know that this list is mainly used for development but I wanted to tell the developers how thankful I am for having Inkscape. At the end of last semester I needed to make a poster for a final project quickly (think less than twenty four hours). I didn't know what to use and then I thought of Inkscape but I wasn't sure whether it was up to the task. I bravely plowed ahead not knowing if the dimensions and resolution of the poster would be too big to handle. However, when the deadline came Inkscape performed and the poster was totally sweet (the final result is attached). Being as I am only a poor college student I can't offer you guys any money, but I thought a kind email would be better than nothing. Rock on and thanks again, -- Matt

2 1

loading of anon namespace documents is broken
by bulia byak 07 Jan '05

07 Jan '05

Mental, after your changes to namespace handling, we can no longer load documents without any namespace declarations, e.g. simply <svg> <g style="fill: ;"> <path d="M1 979.362L1 1051.362L73 1051.362L73 979.362L1 979.362z"/> </g> </svg> This used to work before, and it also works in Batik, so I think we must restore that. Can you please fix?

2 1

removing "SP* Properties" dialogs
by bulia byak 07 Jan '05

07 Jan '05

I want to remove "SP* Properties" dialogs that are listed in the right-click menu of shape objects. Reasons: - they use technical terms without any explanations and are therefore confusing - they don't stay on top (I just didn't bother with them, planning to remove them eventually) - they're very limited (no units, no live update from selection) - most importantly, they're now completely redundant: if you want access to the raw attributes, use the XML editor; if you want convenient units, explanations, and live update from selection, use the controls bars of the corresponding tools. So I'd like to know if anyone is really using them, and if so, why and what needs to be done to help these users move away from this ancient remnant to more modern facilities. In other words, is there any unique functionality or convenience in them that I'm failing to see?

3 4

Toolbox as window
by David Christian Berg 06 Jan '05

06 Jan '05

Hi guys, I've wondering this all over Gnome since quite a while: When I detach a toolbar, why wouldn't it be in a resizable toolbox à la gimp, with a window manager frame around it. That would really be cool for a palette as well, when you could attach it to the bottom or right hand side like in Corel or have it as a floating palette as in InDesign. A detached toolbar with all the buttons in _one_ row is really annoying, because it simply clutters the screen. I'm sure this is not quite inkscape related, really... everything you'd do would be a workaround, I guess. But maybe you could hint me to where to file a RFE? Take care! David

3 6

GIMP Gradient Bug
by Ted Gould 06 Jan '05

06 Jan '05

Hey, So, once there was a bug that some people were having crashes with the GIMP gradient plugin. Does that bug still exist? Are people still seeing it? If so, are those people using relocatable binaries support? I'd like to see this fixed for 0.41. Thanks, Ted

4 5

Simplifying groups of shapes
by Bob Jamison 06 Jan '05

06 Jan '05

Hi, all, Since the tracer can now make <g>roups of paths, the existing ability to select the result and simplify it with a <ctrl>L has temporarily been lost for them. I added a few lines of code to splivarot to be able to descend into a group of paths and simplify them, too. The only trick necessary for breaking out the code into being recursive was this rule: a) If it is a shape, then the item has been replaced and the selection has changed. ...or ... b) If it is a group, and an item in it has been replaced, then the selection has -not- been changed. I tested it on many curves before committing. I don't think I did anything to break it, but some of Fred's code can be a mystery. Please give it a try and let me know. Bob

2 1

Re: Questions on Inkscape change events
by bulia byak 06 Jan '05

06 Jan '05

On Wed, 5 Jan 2005 18:39:05 -0500, Brandi Soggs <soggsbh@...635...> wrote: > 1) Every time that a user changes an object, we will need to make the same > change on the same object in for the other users. For our purposes, > document changes are visible changes- changes to the objects drawn or the > creation of new objects. We've seen in the documentation that there is no > central place that gathers changes. Ishmal suggested to us that we use the > sp-canvas as an area that always gets "hit" by document changes. When a > change reaches the sp-canvas, does it actually know all the details (what > happened to which sp-item) or does it just know "A change has occurred! > Redraw!" ? No, SPCanvas is way too low in the hierarchy for your purposes. I think what you need to watch is the SPRepr system. It's similar to DOM, i.e. it stores a representation of the source document, and is changed whenever everything is changed on canvas and elsewhere (and remember that "invisible" changes may affect visible objects, e.g. if you change a gradient definition in <defs> that will change all visible objects that use this gradient). Also reprs are what maintains the undo stack, so in principle you can hook into sp_document_maybe_done (a function which is called as soon as an undoable action is finished) and sync your repr copy with the master repr tree. Or you can look into the topmost undo stack record and see what exactly has changed. Or, if you are interested in one particular node, you can attach a listener to that node and you will be called whenever that node changes. > 2) We're curious how and where (both the techinque and the place in the > code) object ids are generated. We've had some trouble tracing it > ourselves. We're going to need to control object id generations well > enough to prevent two users from attempting to make two objects with the > same id. When sp_object_invoke_build is called (which happens both when the object is built from source on document load and when a new object is created), it runs sp_object_get_unique_id. That function checks if there is already an object with that id and if so, generates a new unique id and assigns to that object, otherwise leaves the old id alone and returns. > 3) We're not certain how all of the arguments to the functions > (sp_item_build, sp_item_set, sp_item_write, sp_item_commit, > sp_item_transform, and equivalent functions in sub-classes of sp-item). > Presumably these arguments are the actual details of a change that has > occurred. SPItem is a subclass of SPObject. SPItems represents all objects that are visible on canvas. All SPObjects, in turn, are generated from SPRepr nodes (though one repr may have more than one SPObject attached to it). All the functions you listed are standard methods of SPObjects and its subclasses, that are called at various stages of their lifetime, not necessarily associated with some user action. For example, sp_item_write and other *_write functions update the repr of this object, i.e. if the object has changed they bring the repr to sync. This may happen in lots of different situations, and the different levels of hierarchy handle their corresponding aspects of repr updating. For example any SPObject must have an id, and therefore sp_object_private_write writes the object's id into its repr: sp_repr_set_attr (repr, "id", object->id); Then, if this spobject is also an spitem, sp_item_write runs. It sets those attrs which are common to all visible items, i.e. transform and style. Then, SPRect is a subclass of SPItem, and sp_rect_write updates those attributes which are specific to rects (x, y, rx, ry). It does not have to worry about the id or transform because that was already taken care of by its parents. Similar hierarchies work for other standard methods (build, write_transform etc). However, you probably don't need all this. What matters for you is that SPRepr ends up with complete updates from all changed objects, and you can take what you need from there. It's the easiest for those new to the code, because the SPRepr tree is the closest thing we have to the actual SVG code, yet it is always up-to-date in memory (e.g. the XML editor is simply a visualization of the SPRepr tree). P.S. I'm posting a copy to the inkscape-devel list, hope you don't mind. Please feel free to ask any other questions on that list, me and others will be glad to help.

1 1

Re: [Inkscape-devel] proposed change to icons
by Andreas Nilsson 05 Jan '05

05 Jan '05

Alan Horkan wrote: > On Thu, 30 Dec 2004, Bob Jamison wrote: > > > >> Date: Thu, 30 Dec 2004 05:33:00 -0600 >> From: Bob Jamison <rwjj@...127...> >> To: Jon A. Cruz <jon@...18...>, >> inkscape <inkscape-devel(a)lists.sourceforge.net> >> Subject: Re: [Inkscape-devel] proposed change to icons >> >> Actually, varying the icons should be easier in the future >> when we have better support for CSS styles. Keep one icon >> file, and a set of stylesheets to tweak it. This would allow >> icon families, much the same as font families. >> > > > I really hope that the developers will not reinvent theming and that the > move to gtkmm and the greater use of standard widgets will make it easier > to support the existing standards for icons and themes as GTK already > includes support for SVG themes. > > I agree that theming from whitin the program is unessesary bloat. But it would be nice to have specific icon themes for the windows and osx builds, (much like Firefox has) to let them blend in with the rest of to the enviorment better. - Andreas

11 33

restore ruler units
by Aaron Spike 05 Jan '05

05 Jan '05

There has been some talk about units lately and I have a question. Please excuse me if this is what you've been talking about and I didn't catch it. The units in my template are mm. If I create a new document and change the units to inches the rulers change to inches. But If I save that document, close and open it again the ruler units are once again mm. And even more I have so far been unable to change them back to inches. I think Inkscape thinks they are already inches. Do other people experience this? Aaron Spike

6 14

Gtkmm screenshot (showing new Toolbox widget)
by Derek P. Moore 05 Jan '05

05 Jan '05

Since I uploaded that previous screenshot for all to see the current state of the Gtkmm work, I thought send up a screenshot showing off the toolbars. In this screenshot, the Tools and the Tool Controls bars are detached. The Tools bar is changed from a vertical orientation to horizontal. The Tool Controls bar is "minimized" into an arrow menu thingy. And the Commands bar (still attached) overflows beyond the size of the window, so you get a convenient arrow menu to access the those icons. As time goes on, we ought to be able to extend this Toolbox widget to include functionality people have requested in various mock-ups posted to this list.

3 6

Interesting problem
by Joshua A. Andler 04 Jan '05

04 Jan '05

I have a file that was originally an Illustrator file, and I saved it as SVG in Illustrator. I went to open the SVG file in Inkscape .40 & .40+ (today's CVS) and the log window popped up with: "WARNING: Requested update while update in progress, counter = 4" The end # (4) varied between 4-8, and there were probably 50+ instances of that message. One time, it eventually opened the file, and when I went to save it as an Inkscape SVG, Inkscape crashed. I figured I'd check here first to see what that message is about before filing a bug, but my guess is the file would be handy for debugging purposes. http://www.scislac.com/inkscape/cammy-mix.svg (1.6 megs) (it's an old project I wanted to get converted to SVG) On a side-note... I think I understand how Illustrator does it's drop-shadows now. It appears that it creates an embedded bitmap image for every shadow (almost like a clone though, since it updates with modifications to the original object). If this copy of the file loads, you'll see the missing image "red Xs" on the left ones face and behind her... where there were drop shadows before. It seems like a good method that we may want to take into account for our own use. If I should file a bug on this let me know. -Josh

1 0

Re: version numbers: 0.41, 0.42, Gtkmm, and 0.50
by Robert Staudinger 04 Jan '05

04 Jan '05

Hi, wrt. to the recent discussion about gtkmm i would like to humbly suggest the use of libglade or even libglademm when moving the ui-related parts of the codebase to c++. As briefly discussed on jabber today this should further simplify the code and make tweaking of the dialogs easy. Additionally it's the suggested way for gnome-related software. Thanks for your time, - Rob

5 6

Re: [Inkscape-user] Results of librsvg bug: Inkscape action?
by MenTaLguY 04 Jan '05

04 Jan '05

On Tue, 4 Jan 2005, Andrew Conkling wrote: > Well, I reported the bug about having to resave gradients to render > correctly with librsvg: > http://bugzilla.gnome.org/show_bug.cgi?id=161467 *sighs* Apparently they're still convinced that librsvg is conformant to the standard (it's not). I added a comment. [ Those following along at home are invited to read the SVG 1.1 specification themselves, in case I missed something. ] > But they make a good point about reordering gradients: > > Is there any way that Inkscape can reorder gradients according to number? The numbering is sort of arbitrary, so that approach wouldn't work consistently. Ordering objects in <defs> according to their dependencies (what they're really asking for) would require some serious work, which I don't think is worth it for the sake of a non-compliant viewer. If the librsvg folks want to go off and make up their own vector markup language based on SVG, fine, but we're not obligated to go out of our way to support it. -mental

1 0

namespace handling fixes
by MenTaLguY 04 Jan '05

04 Jan '05

I just comitted some code that should handle namespaces properly when saving. I've removed all the manual xmlns declarations that were stuck in the code; instead, they are now generated automatically and inserted into the output document on save. The new code can also use a specified namespace as the default namespace in a saved document, when it is possible to do so. Under normal circumstances we now save documents with SVG as the default namespace. Test and let me know if anything broke (it seems okay on my end). -mental

2 4

Re: [Inkscape-user] Results of librsvg bug: Inkscape action?
by bulia byak 04 Jan '05

04 Jan '05

On Tue, 04 Jan 2005 16:02:03 +0000, Andrew Conkling <andrewski@...633...> wrote: > ------- Additional Comment #5 From Dom Lachowicz 2005-01-02 16:32 ------- > it is best, in my opinion, if the SVGs are emitted in a "streamable" > format, which means that gradient 578 should appear before gradient 581 in > the file. 1. Sorting ids is not sufficient, generally. Gradients can have arbitrary ids. Their links can be arbitrary trees, not only linear chains. 2. Since sorting ids is sufficient in most cases but not in all, I don't want to code this partial solution into the application. This seems to be a good use case for output extensions. Thus, sorting elements is trivial in XSLT; you can write an XSLT stylesheet that rsvg-ifies our SVG and submit it, and someone will then hook it up as an extension. 3. Though we have fixed most of the same problem in Inkscape, some pieces still remain unfixed (bug 989084). I'd rather that we spend effort on fixing these.

1 0

NEW: invert selection, -in-all-layers
by bulia byak 04 Jan '05

04 Jan '05

The new Invert Selection command (the `!' key) inverts selection (deselecting what was selected and selecting everything else) within the current layer. Both Invert Selection and Select All now have "in all layers" variants that act across all visible and unlocked layers (Ctrl+Alt+A for Select All in All Layers, Alt+! for Invert Selection in All Layers).

1 0

Re: [Inkscape-user] FlowText line height and justify
by bulia byak 04 Jan '05

04 Jan '05

On Sun, 02 Jan 2005 22:47:51 +0100, Martin Ždila <zdila@...631...> wrote: > Hi friends > > Is there a way to set line spacing (line height) between lines of flowed > text? line-height in flowPara element doesn't work. That's one of the reasons why flowtext is not yet officially supported. The problem is, I don't see in the SVG 1.2 draft any mechanism for line height! I just recently ran into this, so I'm cross-posting this to the devel list hoping that someone can share some insight on this. I could not even find a mention of line height here: http://www.w3.org/TR/SVG12/ If someone is more lucky than I, I would be grateful for a pointer. Now, I'm reasonably sure that the mechanism SVG has in mind is the line-height CVS property. However it is not mentioned anywhere in the draft, which worries me. I can implement line-height support but I want to be sure first. > And for text > justification / alignment text-align doesn't work too. That is less problematic, SVG draft mentions the text-align property which we must support.

2 3

proposed change to icons
by Ben Crowell 03 Jan '05

03 Jan '05

Bryce wrote: >Since our development policy is "patch first, discuss later", I don"t >think we should make a decision about the defaults until the options >were all available for review. I've committed changes to eight of the icons (rotate, flip, raise, and lower), and that's all the changes I want to make. I'll leave it up to others to decide whether keep these new versions as is, tweak them further, or revert them completely to Bulia's versions. AFAIK, there is currently no mechanism for maintaining multiple versions of the icons from which users can choose. Mine are the current defaults, but if someone else wants to create a multiple-icon-option mechanism, and then debate which set should be the default, that's fine.

3 4

Re: [Inkscape-devel] Suggestion for the preferences dialog
by Bryce Harrington 03 Jan '05

03 Jan '05

On Tue, 28 Dec 2004, Andreas Nilsson wrote: > >What approach did you use to create this mockup? > > > >I gave a shot at trying to mock up something with glade, but with > >disappointing results. However this definitely looks doable. > > > >Bryce > > > > > Well, I used the Gimp... Cool, it looks really good. I'm not sure if we'll be able to replicate it exactly, but I think we should strive to get as close as we can - this looks extremely good. > I am trying to learn Glade, but so far, all my attempts have been > unsuccesfull. Yeah same here, I thought it might provide a shortcut to having to implement the tree management stuff, but no such luck. It does not appear to generate code for managing tree widgets, and the stuff that it can do well is reasonably straightforward to do by hand. Anyway, so I'd say, stick with gimp. ;-) > I do really hope that I have not created an uncodable monster here. :) > - Andreas Nilsson Nah, it'll just be a considerable challenge. :-) In fact, I had noticed earlier that we needed tree-oriented editing dialogs for several other purposes - the XML tree, layers, extensions, and possibly keyboard layouts. I was going to emulate the XML editor design, but what you've done for the preferences dialog looks like it provides the same basic capabilities, and I'm thinking that if we can implement this design, we can reuse it in at least 4 places. One alteration I'm considering in order to support the other kinds of dialogs is a toolbar on the top of the dialog (see the XML editor). For the XML editor this is used for adding/moving/deleting nodes. How do you think we could use this in the preferences dialog? Perhaps the help button could be moved up there (saving some space on the bottom of the screen?) Perhaps an 'export preferences' function? 'restore defaults'? The other thing I'm wondering is that some people are going to really like the extra space between widgets in the dialog (and it helps us adhere to the HIG, as you point out), however others will prefer more concise use of space in order to maximize the dialogs they can have open at once. Preferences are unlikely to be something people will want to have up all the time, and same with extensions, however with the XML editor and layers I'm not as sure - what do you think? Bryce

6 12

Volunteer work and an idea how to get into existing code bases
by Felix Rabe 03 Jan '05

03 Jan '05

Hi Bryce, It's a shame that I only saw your calls for volunteer work now that you replied to them yourself... But I think this is an excellent idea to invite new developers! There needs to be more of it, or maybe it just needs to be more visible (like with a tag in the subject, eg. "[CFV]" for "Call For Volunteers"). In fact, I was looking for an easy way to familiarize myself with existing (poorly or barely documented) code bases and came up with this (as yet sadly unimplemented) idea: Look for a bug that has been fixed sometime in CVS and get a diff for the fix. I think it might be another good invitation and might add value to code documentation if some good (ie. easy) fixes and enhancements were pointed out in the Wiki by the developers that commited them to CVS or by the newbies that found the diffs and found them to be straightforward. If I someday get to implement this idea, should I start a Wiki page? (This might take a few months though...) Or is somebody else willing to do it? Or is it a not-so-god (bad) idea altogether? Greetings, Felix

4 3

Open Clip Art Library Release 0.09 Announcement :: http://www.openclipart.org
by Jon Phillips 03 Jan '05

03 Jan '05

*PLEASE FORWARD* Open Clip Art Library Release 0.09 Announcement http://www.openclipart.org Release 0.09 of the Open Clip Art Library is now available for download on the site as an individual package: http://www.openclipart.org/downloads/openclipart-0.09.tar.gz http://www.openclipart.org/downloads/openclipart-0.09.zip This new package is 20MB and contains 3104 unique user-submitted files, an increase from previous releases. The Open Clip Art Library is also browsable at www.openclipart.org where one might find specific clip art by searching through categories such as animals, education, transportation, or geography. Thank you to everyone who sent encouraging e-mails while the Open Clip Art Library's hosting project, freedesktop.org, underwent necessary maintenance due to a server break-in. freedesktop.org now has a much stronger server management system in place and our services are now completely back on-line from the incident. This intermittent downtime caused our developers to consider mirroring strategies. If you have any server space available and would like to host a mirror, please e-mail our mailing list. In the end, these events bolster an open source project and make it much stronger. To start the new year right, we decided to restart our montly release cycle, and begin to focus our attention to the project roadmap (http://openclipart.org/cgi-bin/wiki.pl?Roadmap). For the upcoming 0.10 release, we encourage submission of Valentine's Day themed artwork, to help users with their love life. Behind the scenes, we will be integrating Bryce Harrington's Document Management System (DMS) to mediate the submissions we receive. DMS is a real breakthrough in document management, which is akin to source code management (CVS, SVN, etc), but for everyday practical group projects, versioning, and collaboration using various file formats. Our core developers have also been discussing a few different sub-projects such as adding support to our services for Font submissions (http://openclipart.org/cgi-bin/wiki.pl?Open_Font_Library) and also a way to auto-generate greeting cards (http://openclipart.org/cgi-bin/wiki.pl?Greeting_Cards). Please add your comments to the aforementioned wiki pages and help us realize these ideas in the coming year! If you are interested in this project, please join our mailing list (http://freedesktop.org/mailman/listinfo/clipart), check out the roadmap (http://openclipart.org/cgi-bin/wiki.pl?Roadmap), and continue to submit your clip art! As the new year starts we are hoping to attract new developers and artists to work on the project. Happy New Year! Visit the Library at http://www.openclipart.org/

1 0

Re: [Inkscape-devel] Inkscape 0.41 release plans
by Ben Crowell 03 Jan '05

03 Jan '05

>Also Ben Crowell's Perl >scripts and XSLT scripting are very nice features that should be more >accessible, if possible, via the Scripts dialog or otherwise. Incorporating some of the Perl scripts would be fun, and I'd like to do it. However, IIRC there is still only a sketch of an API? Give me an API, and I'll get to work. Basically I need: - a way to get an svg file as input, and send it back as output - a way to report errors (including errors due to not having the right CPAN modules installed) - a way to get input strings from the user - a way to display some documentation to the user about what this script does - provisions for internationalizing all the strings the user will see Also, some of my scripts have known unixisms, which I can clean up, but I will still need help with testing on Windows, since I don't have a Windows box.

3 2

CVS not compilable
by bulia byak 03 Jan '05

03 Jan '05

1. In src/io/Makefile_insert, several files are listed with InitialCaps but they are actually all-lowercase, so make fails. 2 After fixing 1, I get: io/xsltstream.cpp: In member function `virtual void Inkscape::IO::XsltOutputStream::flush()': io/xsltstream.cpp:183: error: `xmlErrorPtr' undeclared (first use this function) io/xsltstream.cpp:183: error: (Each undeclared identifier is reported only once for each function it appears in.) io/xsltstream.cpp:183: error: syntax error before `=' token io/xsltstream.cpp:184: error: `err' undeclared (first use this function) Please fix these ASAP, and please be careful to not leave CVS in uncompilable state, especially on holidays when it may be hard to reach people.

4 6

Re: Inkscape interface
by Jon Phillips 02 Jan '05

02 Jan '05

Joshua wrote: > Good day, Jon, Alan and Peter. > > > > Attached to this e-mail is just a simple little mock up of an idea for an alternate Inkscape interface. > > > > Since most users like the current interface, there would, of course, be no need to change it. But when I read that, amazingly, future versions of Inkscape will incorporate SVG animation, (!) I thought the interface might need a little adjustment to incorporate future features (like the animation feature, filters, anything else that could be used to display the power of SVG). > > > > I could be way off with this, but it's just an idea. > > > > Thanks for the great work. > > Great, I've forwarded ths onto the Inkscape mailing list. I think the draggable toolbars that can be repositioned is a good idea. We do need to come up with a scheme for re-attachable menus, and your mockup is a step in the right direction. Please attach your email and screenshot to the RFE related to this: http://sourceforge.net/tracker/index.php?func=detail&aid=862662&group_id=93… Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

5 6

Re: non-uniform text scaling
by vellum 02 Jan '05

02 Jan '05

Peter wrote: > For the moment I've backed out my change, as I consider this a worse > bug. I hope to fix things later. > Fair enough. I got the impression earlier from Bulia that the non-uniform scaling area was a little messy to work in. Anyway my original needs have been addressed for which I'm really happy, and I raised that bug for the record. Will you reinstate the bug? Since it will still be there until the code is fixed properly. When you do decide to fix it let me know and I'll be happy to test and compare with other programs. vellum

4 6

the big removal of 0.8s and 1.25s
by bulia byak 02 Jan '05

02 Jan '05

As discussed recently, I have changed the zoom levels so that at 100%, one px unit is equal to one screen pixel. This change led to switching all internal calculations from a mix of px and pt to pure px. This simplified code in many places and got rid of lots of ugly 0.8 and 1.25 multipliers that were scattered throughout the codebase. Correspondingly, the default template now uses the px units. I think that makes sense, given that most people use Inkscape for screen graphics. Now zoom to 100% (the `1' key) and you'll see your graphic exactly as it will look when exported with default resolution (now 90dpi, not 72dpi as before). This is a pretty big change. I tested everything I touched, but I may have missed something. Please test thoroughly. All old files with saved zoom will now load at 1.25*zoom, but that's inevitable; if you see any other problems, please report here.

3 4

CFV: Update Inkscape FAQ
by Bryce Harrington 02 Jan '05

02 Jan '05

Here's another Call for Volunteers... The Inkscape FAQ is pretty good, but it's been a long time since someone did a thorough review of it and brought it up to date. We need someone who is reasonably knowledgeable about Inkscape to go through it and bring it a little more up to date. I think it probably also ought to have a table of contents with links to the Q's... 1. Save this webpage to your disk: http://inkscape.org/faq.php 2. Open it in a text editor 3. Review/revise each question 4. Add new questions you think are worth putting in 5. Remove any questions that are obsolete 6. Post your results here for a web guy to put on the site If you already have access for updating the Inkscape site, feel free to commit and update directly. Bryce

4 5

Inkscape Status 2005-01-01
by Bryce Harrington 02 Jan '05

02 Jan '05

Saturday, January 1, 2005 With 0.40 still warm from the presses, we've decided to press on with a 0.41 release in mid to late January. ScislaC and myself have prioritized the bugs, identifying 21 high criticality bugs. We've not decided the strategy for attacking these bugs but one way or another we must fix a large proportion of these before our release. At the prompting of new members in the Inkscape development community, I've written up a set of 'Call For Volunteers' posted to the mailing list at the end of December. Meanwhile, Derek (aka Jizzbug) and myself have been pounding out the Gtkmm code. The plan is to see this integrated into the main codebase immediately after the 0.41 release. The stats are steadily improving, and we're seeing continued growth in both our development and user communities. Welcome, new folks. :-) The translation ratio has notched up a bit more, however our bug ratio has slipped down a percent from 15% in Dec to 16% now. However, I'll bet we knock it back down for the 0.41 release. Statistics Nov 1 Dec 1 Jan 1 ========== ===== ===== ===== Lifetime Rank on SourceForge: 684 636 598 (95.2%) (95.6%) (95.8%) Max Week's Rank on SourceForge: 62 16 45 (99%) (99.9%) (99.8%) Total SF Page Views 1,487,659 1,921,981 2,213,324 Total SF Downloads 69,078 89,345 110,182 Total Freshmeat URL Hits 11,849 13,351 14,291 Total Freshmeat Subscriptions 125 141 149 Lines of Code in src/: 306,602 309,285 321,883 Code lines 217,198 218,803 227,114 Comment line 53,262 53,798 56,048 Blank 42,699 43,249 45,398 Lines of Docs in doc/: 16,841 17,901 17,901 Lines of content in website: 8,121 8,732 9,234 Size of the Inkscape wiki: 18,977 21,379 21,030 Bugs open/total: 104/683 119/774 135/829 Features open/total: 279/426 307/467 340/514 Patches open/total: 7/130 5/143 5/145 CVS Commits (as per inkscape-cvs) 8,279 8,878 9,450 Inkscape-devel membership: 108 120 132 Inkscape-announce membership: 113 137 147 Inkscape-user membership: 144 162 172 Num Translations: 33 33 33 Ave Translation Ratio: 38.5 42.2 43.7 * - Statistics unavailable

1 0

CFV: Inkscape Examples Webpages
by Bryce Harrington 02 Jan '05

02 Jan '05

Hi all, Felix made a good suggestion to start posting some 'Call For Volunteers' on tasks that new folks would find straightforward to work on. Here's the first. A while back I started an 'Inkscape Examples' section on our website. We've got a couple things posted, but it's been largely neglected. We need a volunteer to take charge of beefing this section of the website up. This task requires good HTML skills (PHP helps too). No Inkscape development knowledge is needed. Art/design talents will also be pretty important. The purpose of the Inkscape Examples site is to show off different _ways_ Inkscape is used. It's needs to go beyond just showing off new features (we use the Screenshots page for that), but must be complete works. It's not intended to be simply a place for users to post their work (we have a Gallery section, plus OCAL and Deviant art for that), but rather to provide _one_ example of different _type_ of use. It's not intended to teach people how to use Inkscape (we have the Tutorials for that), but more to inspire and entice people into using Inkscape in new ways. Ideally, the site should have a listing of different types of things that can be made with Inkscape, with each having a link to a set of pages describing that thing. (Sort of like a woodworking magazine article showing how to build a cabinet.) For example: * Web site design * CD booklet * Portrait * Presentation * Cross-stitch pattern * Icon set * Landscape design * Org chart * Company logo * etc. Also, there could be examples of different art "styles". For instance, creating 'distressed' art like Brisgeek is into right now, or using the Trace Bitmap feature to artify a photo, or creating three dimensional effects via spherical gradients. "Presentations" could have a link to a page containing an example presentation that someone made, a set of steps for how the user created their presentation, problems/solutions encountered, and the source files for review. Sort of like an article in a woodworking magazine explaining how the author built a table. I think this effort could be done by just collecting examples of work other users have done and posted, interviewing the creator, and writing it up into a decent example, and putting it onto the website. I'd bet, if done well, you could also get it published in an online magazine like OS News. If you want to work on this, your first step will be to go ahead and put together an example of something, and post it here. We will also need someone to take care of editing/reviewing examples and posting them into the website, so if you're interested in doing that, send me your SourceForge ID. Bryce

3 2

[Fwd: Inkscape interface]
by Jon Phillips 02 Jan '05

02 Jan '05

Here is an email I received a few minutes ago... Jon -------- Original Message -------- Subject: Inkscape interface Date: Sat, 1 Jan 2005 14:07:12 -0500 (EST) From: Joshua <jwar@...629...> Reply-To: jwar@...629... To: jon@...235..., horkana@...44..., Peter.Moulder@...38... Good day, Jon, Alan and Peter. Attached to this e-mail is just a simple little mock up of an idea for an alternate Inkscape interface. Since most users like the current interface, there would, of course, be no need to change it. But when I read that, amazingly, future versions of Inkscape will incorporate SVG animation, (!) I thought the interface might need a little adjustment to incorporate future features (like the animation feature, filters, anything else that could be used to display the power of SVG). I could be way off with this, but it's just an idea. Thanks for the great work. -Joshua / Jiaxiang _______________________________________________ No banners. No pop-ups. No kidding. Make My Way your home on the Web - http://www.myway.com -- Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

2 1

Fw: non-uniform text scaling
by vellum 02 Jan '05

02 Jan '05

Bulia wrote: >What was the change and what was the bug? Bulia, Peter will probably get back to you. The original bug was a record of non-uniform scaling of text causing incorrect pt size designation of font. Peter made changes to correct this and I tested a day or so later as reported below. The new bug was that transformed text could not be transformed again back to a known pt size. This was worse than the original. Hence Peter removed his changes. The original bug should be reinstated in the bug list. vellum ----- Original Message ----- From: "vellum" <kaver@...68...> To: "Peter Moulder" <Peter.Moulder@...38...> Sent: Saturday, January 01, 2005 3:51 PM Subject: non-uniform text scaling > Peter, > I have tested your changes using 0412311700. The changes you have made seem > to work to cure the original bug. However, I think they have created or > uncovered another one. That is: The transformed texts cannot be transformed > back to the original point size. > > In Xarax. Transform say a 10pt text non-uniformly to some other value say > 37.32pt. Select the transformed text and choose 10pt as the font size, > apply. The text will go back to 10pt. > > In Inkscape transform the 10pt text non-uniformly to 38.6pt. Select > transformed text, choose 10pt, apply. The text goes back to 14.3pt. Further > attempts to change it to 10pt are to no avail. > > When the text is transformed uniformly then there is no problem with > Inkscape. And that seems to be the case whether the width/height lock is on > or whether it is done with Ctrl drag. > > In your second comment on the bug sheet 041231 4:41. I think I understand > what you are saying regarding the translation and the other two columns of > the transformation matrix. However, I do not know what the other two columns > are called and each of the other programs tends to have these values hidden, > or if shown it is not clear what they are. When I change values in the > transformation matrix the text seems to go all over the place since I do not > know what I am changing. > > Can you tell me what Column 1 and Column 2 are called? Then I can get onto > your request. > > regards, vellum > >

1 0

[Fwd: Re: [Inkscape-devel] CFV: Inkscape Examples Webpages]
by Felix Rabe 01 Jan '05

01 Jan '05

I'm still not used to this strange kind of replying :/

2 2

elongating lines doesn't work anymore
by David Christian Berg 01 Jan '05

01 Jan '05

Hey guys, first of all let me wish you a wonderful year 2005! May it be rewarding not only concerned the Inkscape development. Now: I don't have latest CVS, so maybe this is fixed again. My RFE "[ 1036484 ] Elongating straight lines" that was fixed by Bulia seems to have to be reopened. At least I don't manage elongating lines using a modifier key anymore. Any clues? David

2 2

dividing the inch
by Aaron Spike 31 Dec '04

31 Dec '04

It is customary to divide inches in halves, fourths, eighths and sixteenths, right? In Inkscape dark grid lines (love that feature by the way) and ruler marks appear in halves, fifths and tenths. sp_ruler_metrics in sp-metrics.h has it all right. But sp_ruler_set_metric is only called in desktop.cpp and SP_PT is hardcoded as the metric. To make the divisions follow the document preferences the call to sp_ruler_set_metric would probably have to be moved farther down the line into sp_desktop_widget_update_rulers and some math would need to be changed. I don't know if Inkscape would want to do this. A really feature bloated app might even let you work in your prefered unit and configure you own arbitrary divisions. Then I could divide inches in thirds. I tried hacking out a change for this a while back and started to get the idea that messing with units probably wasn't appropriate for a newbie with now knowledge of C++. It seems messing with units actually means messing with the fundamental assumptions on how Inkscape should deal with units. So I don't have a question, as such, I would just like to see what others think. Aaron Spike

2 1

CFV: Gtkmm - Develop a Context Menu
by Bryce Harrington 31 Dec '04

31 Dec '04

Okay, last Call for Volunteers today, I promise! This one will be quite tricky and requires good knowledge of C++, Gtkmm, and the Inkscape codebase. The menu needs to be very dynamic and well tied in with Inkscape's internals, so if you don't already know Inkscape code thoroughly, you'll need to be prepared for a lot of digging and learning. Fortunately, you can start simple and build up as you go. :-) 7. Context Menu ================ The current context menu in Inkscape is not very powerful. We can do better. First skim through the tutorial on context menus on the gtkmm.org site: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch10s03.html In the Gtk+ codebase, the context menu is implemented in the function sp_ui_context_menu, in the file interface.cpp. Review that function to see how the context menu works currently. As a general rule, there should be no more than about ten items total on the context menu. The context menu, by definition, should customize the set of items it displays to the user based on what the user has right clicked on. It should tie in with the Actions system, and should display appropriate menu items for the selected context. The context menu must check the context item against the current selection. The context item is the thing directly under the mouse cursor when the right-click action occurs. The current selection is the item or items selected by the left-click menu. Note that it's definitely possible for these to be different - the user may left click to select a circle, then right click over a rectangle to change its properties. It is also possible to have no selection, or to select multiple items. Each of these implies a different type of context, and would be handled differently. If the context item is completely different from the selection, then display only actions which don't require the object to be selected. For instance, do not display the 'Delete' action, since that will cause the _selected_ item to be deleted rather than the context item. Same thing for cut, copy, etc. Note that context commands should *not* change the selection to get around this. If the context item is the same as the selected item, then detailed operations should be shown for that item, including actions that can be performed on selections. In this case, you'd display Delete, Cut, Paste, etc. If multiple items are selected, and the context item is one of the items in the selection, then present actions that can be performed on multiple selected items. Delete, cut, copy, duplicate should act on all selected items, for instance, and commands for group, Text-on-path, booleans (Union, Difference, etc.) should be presented. If the context item is part of the chrome (i.e., a toolbar button, the status bar, etc.) then display a context menu appropriate to that item, plus some commands specific to the inkscape application itself. For instance, it should allow all of the actions available through doubleclick, shift-click, alt-click, etc. with the button, and inkscape preferences, view/hide the chrome item, etc. Think about the context menu in three sections. The top third and bottom third should have the most commonly expected commands, and the middle should have the less common commands. The top (and sometimes the bottom) will be the closest to the mouse cursor when popped up so it will be most convenient for common actions to be located there. The middle is less accessible so rarer functions should be placed there. Strive to always place the same command in the same location in the context menu. The top portion of the menu should have actions which are common, frequently used commands needed for any shape or context. The bottom portion should consist of the commands that are common for the specific shape or context selected. The middle portion should consist of commands specific to the shape or context, but less commonly used. Any action available in the context menu should also be available through other means, but you can include actions that otherwise require several clicks. For instance, in the context of a font item, you could include actions for changing the font size; this is normally available only by first opening the text and font dialog, then selecting the font size from the font size widget. To get the Gtkmm codebase: $ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape Bryce

1 0

CFV: VDX and PDF extensions
by Bryce Harrington 31 Dec '04

31 Dec '04

For those interested in learning more about extensions, here are two that might be worth incorporating: http://vdxtosvg.sourceforge.net/ http://www.solidcode.net/pdf2svg/ Try them out - do they actually look useful and compatible with Inkscape? If so, add them to our extensions. You'll need to create a .inx file (see /usr/share/inkscape/extensions/ for examples), and test it out on a variety of files to make sure it's not too buggy. Then post a patch to the patch tracker (or report back if it looks like a no-go). Also, if you can find any other xxx2svg filter programs out there, go ahead and test out adding them too. Good places to look include svg.org and Freshmeat.net. You can also create your own filters pretty easily using packages such as perl's SVG.pm. I had good luck at hooking together SVG.pm and Perl's POD converter to create a pod2svg filter. ;-) Bryce

1 0

grid (and ruler) units
by Aaron Spike 31 Dec '04

31 Dec '04

I've seen it in my web logs a few times now. People are searching google to find out how to change the ruler units in Inkscape. I'm not surprised because that was one of my first questions. I ended up finding the answer in the release notes. If the "Document Preferences" dialog said "Grid and Ruler units" instead of just "Ruler units" the answer would be more apparent. If that isn't acceptable it could go in a FAQ. Aaron Spike

2 1

CFV: Performance measuring/testing
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's a much more techie task we need done. Over the past several releases there's been some observations of slowness in the Inkscape renderer. We'd all like Inkscape to be nice and snappy, even for huge documents. However, we've not really had good, standardish ways of measuring performance. A good way of measuring it would be helpful in several ways: It'd help developers quickly see if a change improves or degrades performance; it'd enable us to track performance from release to release; and, it'd be a tool we could add new performance "Problem Cases" to as we go. The task is to create a collection of scripts that one can run on a copy of inkscape, that exercise it in some different ways and records the speed it did each thing. Right now, you can do some testing by just running Inkscape in cmdline mode on a large .svg file, and time how long it takes for Inkscape to startup, create the .png, and exit. (Later, maybe we can add some testing triggers inside the code so we can better measure performance of particular pieces (like just the startup time, just the gui init, etc.) Also, later hopefully we'll have some internal scripting or Atk support to allow further automated testing of the app. But static runs should be enough to give us some good info to start with.) It would be interesting to run this performance suite against older versions of the software, and measure how performance has changed over time. It'd be especially cool if this could produce an SVG graph. :-) Bryce

1 0

CFV: Update Roadmap
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's another task... This one needs to be done fairly soon; I'm hoping to get to it later this weekend if nobody else can. We've decided to have an accelerated 0.41 release in mid to late January. This means that we need to shuffle the roadmap. Wiki skills are needed. Some knowledge of Inkscape's development activities would be helpful, but if you're good at asking questions you won't need much depth. http://inkscape.org/cgi-bin/wiki.pl?Roadmap * Tasks related to gtkmm need to be moved from Milestone 7 (0.41) to milestone 8 (0.42). * Most development tasks for 0.41 will also need to be bumped forward to 0.42 (speak with bulia, mental, etc. if you have questions - or ask them to update their tasks directly) * Most or all tasks listed for Milestone 8 (0.42) need to be bumped up one number, to Milestone 9 (0.43). Also bump all the subsequent tasks up one release number, too. * Also update the website copy of the roadmap: http://inkscape.org/roadmap.php Thanks, Bryce

1 0

Re: [Inkscape-user] proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

After posting on inkscape-user and increasing the sample size, it seems to me that there is a clear consensus in favor of the new style. Bulia wrote: >There's no need to argue. Ben, you can continue working on the new >icon set, and when you are ready we will ship your icons.svg alongside >the old one, so people can choose whichever they like. Trent, the same >for you: you are welcome to develop a set of icons that work best for >your black background, and we'll ship them also. When there's at least >one complete set besides the old one, we can make a preference with a >UI to choose one of them on load. The real issue is whose icons will be the defaults. Since most people seem to like mine better than yours, I think mine should be the defaults. I would like to request a clear decision on this from the core developers before I invest a lot more time on the icons.

3 3

about inkscape in FreeBSD
by Albert 31 Dec '04

31 Dec '04

Dear developers, I have found that surprigsingly the new ports tree for FreeBSD 5.3 can only install and run inkscape 0.38 The mantainer claimed that there are several memory leaks issues because of the usage of boehm-gc, as explained here : http://lists.freebsd.org/pipermail/freebsd-gnome/2004-December/ 009256.html Are the developers aware of this issue? Is there any hope to have a FreeBSD running 0.40 version any time soon? Thank you. Albert

3 2

proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking.

7 9

Help needed with UI work in Gtkmm codebase
by Bryce Harrington 30 Dec '04

30 Dec '04

If anyone's interested in contributing some time to the new Inkscape UI work, we can use some help with setting up the menus. It's extremely straightforward work, there's just a lot of it to do. Basically, for each menu item we need to write code to establish things like handlers, signals, descriptions, etc. I've coded up a examples for several menu items, so you'd just copy and extend that for all of the menu items. If you're interested in working on this drop me a line and I'll fill you in. The task writeup is in the PLAN document in the 'experimental' module in CVS, under bryce/inkscape_gtkmm/. Bryce

1 1

Volunteer needed for bug prioritizing
by Bryce Harrington 30 Dec '04

30 Dec '04

One of the first tasks needed in the lead-up to the 0.41 release is to go through the new bugs in the bug tracker and prioritize them. This is a straightforward task, and takes one evening to do. I usually tackle this myself but since I've been rather busy with gtkmm lately, I'd love to encourage someone else to take it on. The new bugs are the ones that are listed at Priority '5'. The task is read them and then change their priority to 3/6/9 depending on if they are low/med/high. High priority bugs are those that cause data loss or application crash. In addition, if the bug reports are too terse I try to add a note requesting more info. If it looks easy to reproduce and I have some extra time, I sometimes give it a shot and comment if I see the problem too. That's pretty much it. If you'd like to help with this task let me know, and I'll set your admin privs for the bug tracker so you can do this. Thanks, Bryce

1 1

Newsforge Inkscape article (fwd)
by Bryce Harrington 30 Dec '04

30 Dec '04

---------- Forwarded message ---------- Date: Thu, 30 Dec 2004 07:16:33 -0800 (PST) From: Jiaxiang <jwasheville@...36...> To: Bryce Harrington <bryce@...260...> Subject: Newsforge Inkscape article Good day, Bryce. Did you catch this article about Inkscape on Newsforge.com? http://www.newsforge.com/article.pl?sid=04/12/23/1638201 -Joshua __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com

1 0

Re: [Inkscape-user] proposed change to icons
by bulia byak 30 Dec '04

30 Dec '04

There's no need to argue. Ben, you can continue working on the new icon set, and when you are ready we will ship your icons.svg alongside the old one, so people can choose whichever they like. Trent, the same for you: you are welcome to develop a set of icons that work best for your black background, and we'll ship them also. When there's at least one complete set besides the old one, we can make a preference with a UI to choose one of them on load. As for me, I prefer the crisp, bright, and laconic style and, when I create new icons in my set, I will continue developing that style. Everyone can use what they like.

1 0

proposed change to icons
by Ben Crowell 30 Dec '04

30 Dec '04

On inkscape-devel, I've proposed some changes to some of Bulia's icons. Some people seemed to like the new versions better, and some didn't. We didn't seem to have a statistically significant sample of opinions, so I'm reposting now to both inkscape-devel and inkscape-user. I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking. The svg from which the icons were constructed is here: http://www.lightandmatter.com/icons.svg Please give an on-list opinion in binary, 0=don't change, 1=change. (The icons can be tweaked more later, of course, if there is a consensus for it.)

3 2

save as format
by bulia byak 30 Dec '04

30 Dec '04

Recently save and save as started to default to Plain SVG instead of Inkscape SVG. Very annoying. Those who touched this code recently, could you please look into it?

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

>> What I would like to see is that when I load a document that I've >> explicitly set dimensions to - such as a woodworking project set to >> inches, or a game map set to km, or my website layout set to px, that >> they show up that way, but by default if I start a new drawing or open >> one that has not had any units specified for it, that it defaults to my >> preference (cm or whatever). >This is exactly how the current system works. Except for the last part >- it always defaults to pt if no units specified, but this can be >changed. I think it should be changed. I agree with Bryce -- it should be possible to set a per-user pref that would automatically be applied to new documents.

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

IMO it would be more useful to be able to set the default units on a per-user basis, rather than on a per-document basis. The method of storing the preference in a standard piece of stationery requires extra steps from the user. Personally I just want millimeters, always, and never anything but millimeters :-)

4 6

NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

First of all, as an American, let me just apologize to the rest of the world for being the only country in the world stupid enough not to have embraced the metric system. Anyhow, I'd like to propose doing what Adobe Illustrator does (or what I think I remember it does). Every user has a preference for the unit he likes to use by default. When he creates a new document, everything in that document is by default measured in those units, but he can change that on a per-documet basis.

2 1

Re: [Inkscape-devel] Suggestion for the preferences dialog
by Ben Crowell 30 Dec '04

30 Dec '04

The mockup looks nice! I would really like to have a way to set my prefs so that the units of measurement always default to mm rather than points.

3 7

Spam!!! Fw: [Inkscape-devel] Дешево
by Anatoly Podlesnuk 30 Dec '04

30 Dec '04

This is a spam! Please block this email dalpiger@...329... -----Original Message----- From: "Latisha Kline" <dalpiger@...329...> To: inkscape-devel(a)lists.sourceforge.net Date: Wed, 29 Dec 2004 00:13:06 -0700 Subject: [Inkscape-devel] Дешево > Нoвыe cотовые, ноутбуки, КПК за З0проц. oт cтоимocти wB8. > > jD http://198.66.213.30/?6T1sDmrBU4psZ zJD > > Санкт-петербург,карта www.meteo-tv.ru > >

2 1

NEW: units, misc
by bulia byak 29 Dec '04

29 Dec '04

* Document units: now you can set the default units for each document in the Document Preferences dialog. These units apply to the rulers and the statusbar coordinates (previously unchangeable) and are preselected in all unit menus (such as in the Selector controls bar). The units are saved with the document, so you can make yourself a default template with your preferred units. * The px (pixels) unit is added to most unit menus. This is what is called "user unit" in the SVG specification, and in SVG code it is written either with the px suffix or (more often) without any suffix. Inkscape converts most dimensions to user units when writing them to SVG, and now you can use this unit via the GUI as well. Note however that the conversion ration from px to absolute length units may vary in different SVG renderers and different output media (e.g. Inkscape uses px/pt = 0.8 for screen editing), so you should not use px and absolute units in the same document. If you want one px to correspond to one bitmap pixel on export, use the export resolution of 90 dpi. * In Selector, the statusbar now reports not only the number of selected objects but also the number of layers in which they are selected and, if there's only one, the name of the selection layer.

2 3

Initial checkin of stream package
by Bob Jamison 29 Dec '04

29 Dec '04

Hi, all. Today I added the /src/io dir to the automake tree. It has some new interfaces and implementations whose purpose is to make it easier to read and write streams of data. Basically they are lightly based on java's input and output streams and readers and writers, and -not- on iostreams, which turned out to be too much of a burden for too little benefit. It is intended that they can be subclassed and/or chained together to get the desired effect. Also, they encourage people to use Inkscape::URI's instead of char *filenames and FILE *. This has been discussed for months for the purpose of referring to resources, but has been slow in appearing. These two are based on bytes (unsigned char) ================================= InputStream -- reads unformatted (aka binary) data OutputStream -- writes unformatted data These are for formatted unicode IO (gunichar and Glib::ustring) ============================= Reader -- formatted (aka text) data input like stream >> data; Writer -- formatted output like stream << data. Also has a printf() InputStreamReader -- uses an inputstream as its source OutputStreamWriter -- uses an outputstream as its destination So far there are =========== (these need to be filled out, but work for files now) UriInputStream --reads data from an Inkscape::URI UriOutputStream -- writes data to an Inkscape::URI need to be implemented: ----------------------------- UriReader UriWriter These work in the tests: ================= XsltInputStream XsltOutputStream GzipInputStream GzipOutputStream StringInputStream StringOutputStream These need to be fleshed out and tweaked, but basically they are usable already. I need to run to an appointment, so I'm making this brief. I just wanted people to know that this is available. Bob

3 4

NEW: background color spillover
by bulia byak 29 Dec '04

29 Dec '04

Inspired by a recent message in the Sodipodi list, I did this: * The page background color is now applied to the entire canvas, not to the framed page only as before. Makes more sense than before IMHO.

1 0

Inkscape 0.41 release plans (Debian)
by Ben Crowell 29 Dec '04

29 Dec '04

Sorry, I'm new to Debian and still learning the ins and outs of apt-get :-)

1 0

��
by Latisha Kline 29 Dec '04

29 Dec '04

Mob{e cnrnb{e, mnsrasjh, JOJ g` G0opnv. or crnhlocrh wB8. jD http://198.66.213.30/?6T1sDmrBU4psZ zJD Q`mjr-oerepaspc,j`pr` www.meteo-tv.ru

1 0

Inkscape 0.41 release plans
by Ben Crowell 29 Dec '04

29 Dec '04

An 0.41 release would be very helpful. I'm collaborating on a book with someone, and he's intimidated by having to compile the latest CVS in order to get a certain crucial bug fix. He could download a nightly build, but I'm not sure if he'd have problems with libraries. Once 0.41 comes out, I can just tell him to download the statically linked binary. It would be interesting to hear from some of the packagers about how things are going. IIRC the person handling the FreeBSD port is struggling to fix some memory leaks introduced by the new garbage collector (OS-specific, apparently), so the BSD port is still at 0.38. I think the debian package is also lagging?

2 1

Spiro / Raph Levien
by Bryce Harrington 28 Dec '04

28 Dec '04

---------- Forwarded message ---------- Date: Wed, 29 Dec 2004 00:17:07 +0100 (CET) From: Jose Hevia <100026838@...625...> To: clipart@...330... Subject: Re: [Clipart] OCAL identified by IBM as resource for Linux migrations >From http://www.advogato.org/person/raph/ 16 Nov 2004 » Spiro I've tentatively chosen a name for my curve editor: Spiro. I posted a "code escape" here and on the Typophile forums. So far, I've gotten little or no response from my posting here, but lots of people checking it out and sending feedback on the Typophile board. Interestingly, many of the commenters are encouraging me to patent the idea and/or otherwise try to make money off it. I'll have a new code snapshot soon. In the meantime I've been tracing the miniscules from 72pt metal Centaur (see screenshot). There's nothing like trying to use the thing for real to point out what needs improving :) There's no rush, as I'm still tweaking the core algorithms, but obviously this is something that should go into other free software applications, most especially Inkscape. What I'm most inclined to do is release all the core code as GPL, package up nice Win32 and MacOS versions with refined GUI's (especially cut'n'paste with the dominant apps on those platforms) as commercial apps, and also try to license the code for inclusion in proprietary apps. We'll see how all that plays out. ->I'd been reading his diary for long 17 Oct 2004 » [...]If I go this route, I'll need to factor the code into UI dependent and UI independent parts. That's probably good discipline in any case, especially if I'm hoping for the code to be adapted into other apps that need curve editing (Gimp paths, inkscape, etc.).[...] Jose Hevia _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart

1 0

Changing helper/sp-intl.h refs to glibmm/i18n.h
by Bob Jamison 28 Dec '04

28 Dec '04

It was discovered by one of the guys in the Jabber room last night that sp-intl.h's wrapping of gettext() in the _() macro is redundant. It is already defined by glib/g18n.h, or more proper for us, glibmm/i18n.h. After getting the concensus that making the change was ok, I went ahead and did a mass search/replace, followed by a build to test it. I removed helper/sp-intl.h, and removed its entry in helper/Makefile_insert. I changed all of the #includes from helper/sp-intl.h to glibmm/i18n.h in the 169 files listed below. Sorry about the big commit, but anything that can remove unnecessary legacy code must be helpful. The build seems to be fine, but if anyone sees any problems, please tweak it. Bob ./arc-context.cpp ./desktop.cpp ./desktop-events.cpp ./dialogs/align.cpp ./dialogs/clonetiler.cpp ./dialogs/debugdialog.cpp ./dialogs/desktop-properties.cpp ./dialogs/display-settings.cpp ./dialogs/docker.h ./dialogs/export.cpp ./dialogs/filedialog.cpp ./dialogs/fill-style.cpp ./dialogs/find.cpp ./dialogs/item-properties.cpp ./dialogs/layer-properties.cpp ./dialogs/object-attributes.cpp ./dialogs/object-properties.cpp ./dialogs/rdf.h ./dialogs/scriptdialog.cpp ./dialogs/sp-attribute-widget.cpp ./dialogs/stroke-style.cpp ./dialogs/text-edit.cpp ./dialogs/tracedialog.cpp ./dialogs/transformation.cpp ./dialogs/xml-tree.cpp ./document.cpp ./draw-anchor.cpp ./draw-context.cpp ./dropper-context.cpp ./dyna-draw-context.cpp ./event-context.cpp ./extension/db.cpp ./extension/extension.cpp ./extension/init.cpp ./extension/internal/eps-out.cpp ./extension/internal/gnome.cpp ./extension/internal/ps.cpp ./extension/internal/svg.cpp ./extension/system.cpp ./file.cpp ./help.cpp ./helper/units.cpp ./helper/units-test.cpp ./inkscape.cpp ./inkview.cpp ./interface.cpp ./knot.cpp ./main.cpp ./node-context.cpp ./nodepath.cpp ./object-edit.cpp ./object-ui.cpp ./path-chemistry.cpp ./pencil-context.cpp ./pen-context.cpp ./print.cpp ./rect-context.cpp ./select-context.cpp ./selection-chemistry.cpp ./selection.cpp ./selection-describer.cpp ./select-toolbar.cpp ./seltrans.cpp ./slideshow.cpp ./sp-anchor.cpp ./sp-ellipse.cpp ./sp-guide.cpp ./sp-image.cpp ./spiral-context.cpp ./sp-item.cpp ./sp-item-group.cpp ./sp-line.cpp ./splivarot.cpp ./sp-offset.cpp ./sp-path.cpp ./sp-polygon.cpp ./sp-polyline.cpp ./sp-rect.cpp ./sp-shape.cpp ./sp-spiral.cpp ./sp-star.cpp ./sp-text.cpp ./sp-tspan.cpp ./sp-use.cpp ./star-context.cpp ./text-chemistry.cpp ./text-context.cpp ./text-editing.cpp ./toolbox.cpp ./tools-switch.cpp ./trace/trace.cpp ./verbs.cpp ./widgets/dash-selector.cpp ./widgets/font-selector.cpp ./widgets/gradient-position.cpp ./widgets/gradient-selector.cpp ./widgets/gradient-vector.cpp ./widgets/layer-selector.cpp ./widgets/paint-selector.cpp ./widgets/sp-color-gtkselector.cpp ./widgets/sp-color-notebook.cpp ./widgets/sp-color-scales.cpp ./widgets/sp-color-selector.cpp ./widgets/sp-color-wheel-selector.cpp ./widgets/spw-utilities.cpp ./widgets/sp-xmlview-attr-list.cpp

1 0

Suggestion for the preferences dialog
by Andreas Nilsson 28 Dec '04

28 Dec '04

(This might have been fixed in 0.40, but since I run Debian testing I still use 0.39. If that is the case, ignore this mail.) I currently find the preferences dialog a bit hard to navigate, partly because it feels a bit crowded, but mostly because it presents the usability problem of tabs in tabs. See for example the Interface Hall of Shame: http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/tabs.htm The tools/shapes creates the most trouble of navigation. (see http://ramnet.se/~nisse/diverse/temp/inkscape_tabsintabs.png) So, I did a little gimping and came up with a new preferences dialog similar to the one beep-media-player uses. http://ramnet.se/~nisse/diverse/temp/inkscape_new_prefs_mockup.png The icons are ones that I found on jimmacs site and thought somewhat fitted, or ones I drew very quickly. What do you think? - Andreas Nilsson

5 7

Inkscape 0.41 release plans
by Bryce Harrington 27 Dec '04

27 Dec '04

Hi all, After chatting with Ishmal, Mental, Bulia, and others, it sounds like we ought to shoot for cutting a near-term release, in the mid- to late-January timeframe. The reasoning for this is that we already have some noteworthy new features that would be worth getting out to users, and because the Gtkmm work, while progressing along well, won't be finished that quickly. If no-one has any serious objections to this proposal, we would go back into a feature freeze within the first week or so of January, focus on bug fixing for a couple weeks, and try to push out the 0.41 release by the end of the month. (As a side PR benefit, there are a number of conferences and symposia in the Feb/Mar period, so this would give fresh bits for folks to play with.) In parallel to the above release effort, the focus on the Gtkmm work will continue (and hopefully intensify), with the objective of merging immediately after the 0.41 release. The code won't be finished at that point, and won't be used for the primary UI (you'll have to use a special flag to activate the Gtkmm), but we'll finally have the code in the main codebase proper, which will hopefully enable the remainder of the work to get done swiftly. Bryce

4 5

possible bug
by Makurin Roman 26 Dec '04

26 Dec '04

When I trying to export my *.svg into *.png and path contains white spaces I`ve got an error. -- JID: drolyk@...189... ICQ: 105266647

1 0

SVG prefix commit
by MenTaLguY 25 Dec '04

25 Dec '04

Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g". Important note: attribute naming has not changed, it's just elements I was pretty careful not to break anything, but I can't guarantee it; it was a pretty wide-ranging change. Let me know if anything broke. -mental

2 5

brief history of namespace support in Inkscape
by MenTaLguY 25 Dec '04

25 Dec '04

Just as a bit of background... Originally, in Sodipodi, namespaces were ignored entirely. Any element without a prefix was assumed to be SVG, xlink: was always assumed to be XLink, and sodipodi: always Sodipodi stuff. We did add xmlns declarations just to keep parsers happy, but that was it. Obviously that was deeply wrong to do. It was difficult for me to get buy-in for a sweeping change, however. What I did finally did get accepted was a simple hack -- I remapped the prefixes on load to what Sodipodi expected. So, at that point, if you loaded a document where the SVG namespace was bound to the blah: prefix, "blah:g" would become "g" in memory. Similarly, if ook: were bound to the Sodipodi namespace, "ook:namedview" would become "sodipodi:namedview" in memory. This is the code we inherited from Sodipodi, and the approach I refer to as "normalized qnames". Now, there were a couple shortcomings that remained: One, this was only done on load. The serialization code still didn't know anything about namespaces and we simply relied on stuffing a bunch of xmlns attributes in the document and hoping that covered everything. Not a simple thing to fix, unfortunately. Two, non-namespaced elements would appear to be in the svg namespace. This means that some non-SVG elements would get interpreted (and saved) as SVG elements. Thankfully, that was trivially fixable by normalizing svg elements to use the prefix svg: instead of none. As I noted on the Sodipodi list at that time, I did want to go back and address those two shortcomings, but Things Happened, and a year or two later I'm writing this. We did inherit both shortcomings, so it's high time I did something about them. I just knocked out the second one, and I'm hoping I can spend some time on the first one soon. The serializer improvements shouild actually afford a lot of opportunity to make our XML output prettier, including using shorter prefixes (e.g. maybe just i: for inkscape's namespace) in serialized files. And of course using SVG as the default namespace again, where practical to do so. -mental

1 0

I'm leaving a debug message in
by Ted Gould 25 Dec '04

25 Dec '04

Hey, I know that this is annoying, but I think it is important for a short while. The message that I'm leaving is a notice that an extension is being unloaded. This is because now extensions are getting unloaded if they aren't used for a while -- and this code has never been used before. But, since it happens seemingly randomly, I don't want people to start debugging something that is actually a bug in these unload routines. Now, I think that I've tested all the cases, but I'd like to keep it in for a while to make sure. -- Ted

1 0

Problems with XML Editor
by Valentin Cristescu 24 Dec '04

24 Dec '04

Hi, I can't start the XML Editor. The message is: Inskcape encountered an internal error and will close now. I'm using Fedora Core 3.

2 1

Non-coder tasks
by Bryce Harrington 24 Dec '04

24 Dec '04

Today a question came up regarding how non-coders can help improve Inkscape. This info has been added to the Inkscape FAQ, under 'Are there non-coding ways to help?': http://www.inkscape.org/faq.php Let me know if you have other ideas we could list there. Bryce

2 2

element namespaces
by MenTaLguY 24 Dec '04

24 Dec '04

FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past. This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though. Important things to remember: * this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones) * only elements in the SVG namespace will be affected; the remainder are already named unambiguously * there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents -mental

5 16

[cairo] Very slow performance (fwd)
by Bryce Harrington 23 Dec '04

23 Dec '04

---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 09:54:59 -0500 From: Chris <fltk@...78...> To: cairo@...278... Subject: [cairo] Very slow performance I have some fairly complex SVG artwork that I created. I have noticed that the performance of Cairo is quite a bit slower than some other svg libraries. My image has about 3500 paths and on my machine this image takes less than a second to load and render in Inkscape (librsvg/libart based?). Even Inkscape feels slow compared to commercial applications when handling this file. I made a simple test program that loads this file and renders it to an image buffer in Cairo. It takes over 30 seconds to do this. That's incredibly slow and makes me wonder about the usability of Cairo in everyday applications. Would rendering to OpenGL or xlib be faster? I'm planning on adding SVG support to FLTK by using Cairo so even if those are faster that might not help me as FLTK has it's own cross-platform drawing functions that I will be using. Where is the bottleneck? Is libart just that much faster at doing the rendering? The source code for my simple test is here: http://www.functionalfuture.com/radical/cairotest.c The SVG image I'm using is here: http://www.functionalfuture.com/radical/centi_unfinished.svg.gz -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

3 2

Linking suggestion
by Bob Jamison 23 Dec '04

23 Dec '04

Hi, all, again. Now that Ted and I are going through the headaches of linking, extensions, shared objects, and their ilk, I have a suggestion about how we are linking Inkscape. Currently, the main Makefile.am is built at automake time to Makefile.in by reading all of its Makefile_insert files from the various subdirectories. The final 'inkscape' target is made as the result of libinkpre.a, all of the sub-libraries from each of the Makefile_inserts, then libinkpost.a. This is because of link-order problems. This is just my opinion, but wouldn't it be easier/cleaner to make one large libinkscape.a by concatenating it from each of (pick one) libBlah_a_SOURCES or libBlah_a_OBJECTS ... in each of the Makefile_inserts??? Then we would have one nice reference library that can be used by other projects, can be made into a .so or .dll, and that can more easily export its symbols. And best of all, there would be no link-order problems. This would in no way alter the set of Makefile_inserts that we have in the build tree. The main Makefile would merely use different information from them. The small .a's would still be built (or be buildable) and everyone can still do their private testing. It would only change the makeup of the large libinkscape.a lib. Any thoughts? This would not affect the majority of devs, but would -GREATLY- simplify the world for those of us who need to worry about link issues. Bob

5 7

problem compiling from CVS, python-related
by Ben Crowell 23 Dec '04

23 Dec '04

Thanks, Bob, for the hint about --with-python=no. I'm now experiencing a different error, shown below, which seems to be related to Perl. I'm trying now with both python and perl disabled. I actually have a modicum of Perl expertise, so if you can tell me what it is about my Perl install that's causing this failure, I might be able to add something to the configure script to autodetect it and give an informative error message. ============================================================== /bin/sh ../libtool --mode=link g++ -Wall -W -Wpointer-arith -Wcast-align -WsignWswitch -Wno-unused-parameter -g -O2 -o extension/plugin/libgimpgrad.la -rpatns extension/plugin/gimpgrad.lo -lgc -lpthread -ldl -Wl,-E -L/usr/local/lib /r/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -lpthread -lc -lcrypt *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against *** static library /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a is not portabl g++ -shared -nostdlib /usr/lib/gcc-lib/i486-linux/3.3.4/../../../crti.o /usr/libginS.o extension/plugin/.libs/gimpgrad.o /usr/lib/libgc.so -L/usr/local/lib /u/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lpthread -lcrypt -L/usr/lib//lib/gcc-lib/i486-linux/3.3.4/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc-libr/lib/gcc-lib/i486-linux/3.3.4/../../../crtn.o -Wl,-E -Wl,-soname -Wl,libgimpgrbs/libgimpgrad.so.0.0.0 /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make[2]: *** [extension/plugin/libgimpgrad.la] Error 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2

5 7

Re: [cairo] Very slow performance (fwd)
by Bryce Harrington 23 Dec '04

23 Dec '04

Whoa, it amazes me what people are doing with Inkscape these days... ---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 12:54:22 -0500 From: Chris <fltk@...78...> To: Carl Worth <cworth@...573...> Cc: cairo@...278... Subject: Re: [cairo] Very slow performance On Thu, 2004-12-23 at 12:34 -0500, Carl Worth wrote: > It is slow, and we'll need to fix that. > > But cairo does render the whole thing correctly, right? That's > encouraging. Actually, it doesn't render quite right. At least compared to Inkscape. Inkscape render: http://www.functionalfuture.com/radical/centi_unfinished.png Cairo render: http://www.functionalfuture.com/radical/centi_test.png It seems like it draws everything OK. At least for the stuff you can see. However, the layering/ordering is not correct and some things are hidden that shouldn't be. -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

io compile problem
by Bryce Harrington 23 Dec '04

23 Dec '04

<ddiaz> i'm getting: io/GzipStream.cpp:17:20: zutil.h: No such file or directory io/GzipStream.cpp: In member function `bool Inkscape::IO::GzipInputStream::load()': io/GzipStream.cpp:160: warning: unused variable 'srcCrc' io/GzipStream.cpp: In constructor `Inkscape::IO::GzipOutputStream::GzipOutputStream(Inkscape::IO::OutputStream&)': io/GzipStream.cpp:256: error: `OS_CODE' undeclared (first use this function) io/GzipStream.cpp:256: error: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [io/GzipStream.o] Error 1 make[1]: Leaving directory `/elresto/inkscape/inkscape.win32/src'

2 1

Fwd: Re: [Inkscape-devel] element namespaces
by bulia byak 23 Dec '04

23 Dec '04

On Thu, 23 Dec 2004 12:48:28 -0500, MenTaLguY <mental@...3...> wrote: > http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0412221011… It needs to be explained that this builds uses a version of boehm that may fix the Windows freeze bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1073459&group_id=9… So Windows folks who experienced this bug, please test this build and report your results here.

1 0

Build errors in CVS
by Trent Buck 23 Dec '04

23 Dec '04

I just tried to build Inkscape from CVS for the first time in a couple of weeks. I noticed the following Debian-specific problems: - AFAICT, python-dev and libperl-dev are now build dependencies; they should be added to the Build-Depends line in debian/control. - After building, dh_strip attempts to strip an ar archive, causing packaging to fail. From the build log: $ dpkg-buildpackage -rfakeroot [...] dh_installmime dh_link dh_strip strip: debian/inkscape/usr/lib/inkscape/plugins/stcstnTn/DynaLoader.a: Invalid operation dh_strip: command returned error code 256 make[2]: *** [binary-arch] Error 1 make[2]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' make[1]: *** [buildpackage] Error 2 make[1]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' -- -trent Look -- a diversion! It's shiny! -- Daniel Stone

4 4