- Inkscape Devel - Inkscape Mailman

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