- Inkscape Devel - Inkscape Mailman

Redesigned Inkscape Preferences dialog and release notes
by David Yip 18 Apr '06

18 Apr '06

Just a quick question: Has the redesigned Inkscape Preferences dialog not yet been written up / given a stub in the release notes for 0.44, or am I just not seeing the writeup? - David

2 1

RE: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
by Charles Moir 18 Apr '06

18 Apr '06

> From: bulia byak > Sent: 15 April 2006 02:06 ... > Doing these things via bitmaps may be acceptable as temporary > workarounds (one of which I myself use, see > doc/inkscape-shadow.README), but in the long run we should > really concentrate on doing things the Right Way, which means > the Vector Way. > I know that, for example, Xara can use Photoshop plugins to > process bitmaps, and it's good for eyecandy, but it never > appealed to me because of its lack of genericity and overall > clumsiness. No, Xara does bitmap processing the Right Way, which means all bitmap effects can be applied to vector graphics in a completely transparent way. And that includes Photoshop plug-ins and built-in bitmap effects, and Xara bitmap plug-ins. You can still fully edit your vector graphics and the system automatically, and transparently re-renders the bitmap effects. What's more the effects that can be resolution independent, so they are more like real vector effects - such as shadow, blur, feather etc. (Some Photoshop effects don't allow this because of their API) . And you can apply multiple successive bitmap effects, and have full control over the order, and can edit or delete any effect in the effects stack. All these bitmap effect are applied and updated as you edit the underlying vectors. It took us more than a year to implement all this. Clumsy it is not - it's been described as the best implementation of Live Effects that exists in any vector graphic product out there. As far as I know we're the only package than can apply resolution independent bitmap effects on the fly. (This whole Live Effects system is new in Xara Xtreme and replaced all the old bitmap processing and all the old Photoshop plug-in interface code of Xara X, which is probably what you know Bulia) Checkout the Live Effects tool next time you're near a Xara Xtreme (XaraLX doesn't have this ported yet, but now we've seen native Photoshop plug-ins working on Linux (at the Libre event) it looks as if we should be able to port it all. I believe the source code for all this is now public and GPL, just not ported or got working on XaraLX. Now if you wanted a suggestion for some Google sponsored code that would benefit everyone, it would be a cross-platform open API to allow vector graphics products, such as our two products, to apply bitmap effects transparently to vector graphics. The Photoshop plug-in API is not just closed, it's over-complex, outdated and been superseded by an entirely closed new API from Adobe. This would then allow us to call GIMP effects or ImageMagick effects or any third party effect plug-ins (the Photoshop plug-in system, although now outdated, was hugely successful. There are said to be more than 3000 different Photoshop plug-ins out there.) Adobe has gone the closed, proprietary API for their plug-ins now. There is a gaping hole for a simple bitmap effects plug-in system that would work for both bitmap graphics programs and vector graphics ones. Just my two penny's worth. Charles

11 11

Chase service
by Chase Online Banking 18 Apr '06

18 Apr '06

1 0

export dialog patch
by Osei Poku 17 Apr '06

17 Apr '06

Hi All, I have attached a patch that uses GtkFileChooserDialog instead of GtkFileSelection when you click browse in the export dialog. I realize after reading the roadmap that the export dialog is due for an upgrade to gtkmm. However, I figured that it wouldn't hurt to have this in anyway until then. Otherwise, thanks for a great piece of software. -- Osei Poku Graduate Student, Dept. of ECE, CMU

4 6

Inkscape Summer of Code 2006 - Mentor signup
by Bryce Harrington 17 Apr '06

17 Apr '06

Hi all, The next step for us is to get mentors registered. If you are willing to serve as a mentor, please go to the following link to sign up. http://code.google.com/soc/mentor_step1.html This lets you specify T-shirt size and other such important info. ;-) Thanks, Bryce ----- Forwarded message from Leslie Hawthorn <lhawthorn@...819...> ----- Date: Sun, 16 Apr 2006 18:01:06 -0700 From: Leslie Hawthorn <lhawthorn@...819...> To: Bryce Harrington <bryce@...961...> Reply-To: lhawthorn@...819... Subject: Re: Invitation to Participate in Summer of Code 2006 Bryce Harrington wrote: >Hi Leslie, > >My Google account is 'bryceharrington', and we would be honored to >participate in the 2006 Summer of Code. :-) > >Bryce > Hi Bryce, We've enabled your access for the SoC site using bryceharrington@...400... for your Google Account information. Please take a moment to update your personal information and your organization's information at http://code.google.com/soc/mentor_step1.html; you can login subsequently at http://code.google.com/soc/mentor_home.html. If you already have project ideas available to publish, that's great; if not, you can update them later. We've left the mentor sign up URL off the main SoC page to discourage spam mentor applications, so please let your fellow mentors know that they can sign up at http://code.google.com/soc/mentor_step1.html. As the organization's administrator, you will need to accept each mentor application and decide which mentors to grant administrator status to. Once your mentors are signed up they can use http://code.google.com/soc/mentor_home.html to interact with student applications once they start to arrive. You'll also be invited to join the Summer Administrators 2006 Google Group; we'll invite your fellow mentors to the group periodically once they sign up with your organization. Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc. ----- End forwarded message -----

1 0

Shorcuts do not work anymore
by Lucas Vieites 17 Apr '06

17 Apr '06

Hi, Last week I saw a few messages regarding the keyboard shortcuts and right now I have done an update from svn and new compilation to find out that the shortcuts no longer work, and they don't appear on the menus either. Does this have anything to do with the latest additions? the shortcuts.xml file or something? Thanks for you help -- ¡No olvide visitar nuestra tienda On-line! <http://www.asixinformatica.com/tienda> =================================================== Lucas Vieites Fariña <lucas@...212...> Web: <http://www.asixinformatica.com/users/lucas/> Blog: <http://www.asixinformatica.com/blog/>

3 4

Next Version?
by Alan Jones 16 Apr '06

16 Apr '06

It has been a while since the last formal version of Inkscape. Any chance of a new one coming out anytime soon? I have been watching the mailing lists, but not see much about a new version. thanks Alan

5 5

NEW: calligraphic tremor
by bulia byak 16 Apr '06

16 Apr '06

Even when using a graphics tablet with pressure sensitivity, the Calligraphy pen's strokes often look too smooth and artificial. To enable a more natural look, the new Tremor parameter is added to the Calligraphy tool in this version. Adjustable in the Controls bar from 0.0 to 1.0, it will affect your strokes producing anything from slight unevenness to wild blotches and splotches. This significantly expands the creative range of the tool. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

7 17

Menu structure changes
by Joshua Blocher 15 Apr '06

15 Apr '06

We never really resolved the menu restructuring last release and Inkscape has some new functionality add since my last proposal, so i have add,updated, and rearranged the menus according to the last input. I have also attach the original menu dump edited out of the menus-skeleton.h since there is no easy way to get the menu setting out. josh blocher verbalshadow

1 0

Just canna take it captin!
by Martin Owens 15 Apr '06

15 Apr '06

Oil the email mchine! it's gonna blow! btw... keep up the good work, I can see loads of really cool things taking place and I proud to be snooping in on them :-) -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

NEW: Xara keyboard shortcuts
by bulia byak 15 Apr '06

15 Apr '06

Thanks to Mental's work, we now have shortcuts configurable by editing a simple XML file. I changed the format of that file, commented and categorized the shortcuts, and also listed there all Inkscape verbs that don't have shortcuts, so that it's easier for the user to bind them to keys. Also there's much work ahead to convert as much non-verb commands as possible to verbs, so that they can be configurable as well. I also added an alternative keymap that emulates the keyboard of Xara X/Xara Xtreme/Xara LX. Since Inkscape has considerably more shortcuts than Xara, those keys that are not used by Xara retain their Inkscape bindings, thus making it easier for users to migrate from Inkscape to Xara or back. Of course, some of Xara's keys are not enabled because Inkscape does not yet have corresponding tools or commands. The files in share/keys are: inkscape.xml - Inkscape bindings default.xml - initially this is a copy of inkscape.xml, but you can overwrite it with any other profile; xara.xml - Xara bindings; to enable, copy it to default.xml; to disable, copy inkscape.xml to default.xml again. Later, Inkscape installer and/or preferences dialog will need to be enabled to switch keymaps without the user having to copy files (coding help welcome, as always). You can also customize some of your keybindings without overwriting the main default.xml. If your profile directory (~/.inkscape on Linux) contains a keys subdirectory with a default.xml file, the keybindings from that file will overlay (i.e. add to, and override in case of a conflict) the default bindings. This file may list just a few keybindings that you want to change; the format of your own default.xml is the same as that of the main default.xml. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 9

ODF drawing output
by Bob Jamison 15 Apr '06

15 Apr '06

Hi, all, Just FYI, for the next week or so we will be working on ODF drawing (.odg) output from Inkscape. If anyone is interested in helping map svg elements to <office:drawing> elements, we would certainly appreciate it. Here is an initial export of the tiger.svgz file to odg. Please note that it is a -very- early example, and most things require a lot of tweaking. This is paths-only, which will evolve into smarter exports later. Note that a lot of the style attributes still need to be translated, too. Also note that the coordinates were flipped in the Y-direction, so I fixed it manually. http://inkscape.org/win32/ink-oo.png To see what work is involved, compare the original .svg file to the content.xml file in any odg that you save. bob (ishmal)

5 6

[[Inkscape-tester] inkscape build report]
by Bryce Harrington 15 Apr '06

15 Apr '06

Thanks ishmal! All of the new warnings have been eliminated, and we're back down to our usual count. Bryce ----- Forwarded message from root <root@...1070...> ----- Date: Fri, 14 Apr 2006 17:21:24 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Fri Apr 14 17:09:38 2006 (Run 2128) Snapshot: inkscape-20060414-1600.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 10 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == sp-flowtext.cpp:339: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-item.cpp:744: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:733) sp-shape.cpp:609: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:486: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:650: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:729: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0

New DOM warnings [inkscape build report]
by Bryce Harrington 14 Apr '06

14 Apr '06

Some new warnings from the DOM code... ----- Forwarded message from root <root@...1070...> ----- Date: Fri, 14 Apr 2006 05:21:24 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Fri Apr 14 04:37:05 2006 (Run 2115) Snapshot: inkscape-20060414-0300.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 21 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == sp-flowtext.cpp:339: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-item.cpp:744: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:733) sp-shape.cpp:609: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:486: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:650: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:729: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) dom/io/domstream.h:241: warning: `virtual void org::w3c::dom::io::BasicOutputStream::put(short unsigned int)' was hidden dom/io/base64stream.h:111: warning: by `virtual void org::w3c::dom::io::Base64OutputStream::put(int)' dom/io/domstream.h:241: warning: `virtual void org::w3c::dom::io::BasicOutputStream::put(short unsigned int)' was hidden dom/io/gzipstream.h:104: warning: by `virtual void org::w3c::dom::io::GzipOutputStream::put(int)' dom/util/ziptool.cpp:1542: warning: comparison between signed and unsigned integer expressions dom/util/ziptool.cpp:1665: warning: unused variable `int cm' dom/util/ziptool.cpp:1670: warning: unused variable `bool ftext' dom/util/ziptool.cpp:1683: warning: unused variable `time_t mtime' dom/util/ziptool.cpp:1688: warning: unused variable `int xfl' dom/util/ziptool.cpp:1693: warning: unused variable `int os' extension/internal/odf.cpp:188: warning: long unsigned int format, guint32 arg (arg 5) == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

2 3

Possible performance improvement
by Andrius Ramanauskas 14 Apr '06

14 Apr '06

Hey, I could not resist a temptation to do some optimisations and achieved about 10 times faster rendering in some situations (complex drawing zoomed to 1000-5000%). The idea of optimisation - eliminating nodes outside of rendered area, so no bezier calculations and other stuff is needed, so rendering of zoomed image consume less memory and is also faster. The question is - should I continue work on that (solve last minor issues) and try to commit it or I'm the only one who uses Inkscape with complex drawing and zooming in to the finest detail? The fix make code somethat less readable/maintainable, so there is a price for performance improvement. But if there will be support for such thing, I will try to finish it after Easter holidays and see how it works. Andrius

7 7

[root@...1070...: [Inkscape-tester] inkscape build report]
by Bryce Harrington 14 Apr '06

14 Apr '06

The errors are gone now. :-) ----- Forwarded message from root <root@...1070...> ----- Date: Wed, 05 Apr 2006 05:22:15 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Wed Apr 5 05:11:42 2006 (Run 1900) Snapshot: inkscape-20060405-0400.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 12 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == sp-flowtext.cpp:324: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-image.cpp:516:8: warning: extra tokens at end of #endif directive sp-item.cpp:730: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:719) sp-shape.cpp:611: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:472: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:644: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:723: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) trace/trace.cpp:196: warning: unused variable `Inkscape::XML::Node*imgRepr' == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

3 4

UberConverter test tarball and *.inx files now available
by Eric Wilhelm 13 Apr '06

13 Apr '06

Hi inkscapers, I've got some working XAR import/export .inx files for inkscape and a fairly usable two-way conversion of paths and basic properties. I have tested the following instructions on a clean (base plus a configured cpan) chroot'd debian sarge. They should work as copy/paste installation on most *nix machines. http://scratchcomputing.com/uc/trunk/INSTALL If won't work for you, the tarball is at the following link. http://scratchcomputing.com/code/UberConverter/UberConverter-0.00_02.tar.gz The build process is fairly straightforward, the copy/paste instructions are more convenient though because the bundle automagically fetches all of the prereqs off of cpan. The exception is Image::Magick -- this is not currently a hard prerequisite, but you should really install it if at all possible. Not an issue on most machines with inkscape already installed? Note the *.inx installation instructions at the bottom of the INSTALL file. The *.inx files don't install via the build at the moment. Please let me know if that works for you or not and what platforms you're using. Thanks, Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------

3 3

Item ID
by cedric GEMY 13 Apr '06

13 Apr '06

Has it is sometimes very important to give id to object or to lock them, wouldn't it be nice to add a filed and a button in the selector option bar ? Cedric

1 0

RFE: [ 1469070 ] Allow dialogs to be closed by same shortcut that opened them
by Hans Nieser 13 Apr '06

13 Apr '06

Hello, I just submitted te following RFE at http://sourceforge.net/tracker/index.php?func=detail&aid=1469070&group_id=9… and was also asked to drop a note on this list, so here it is! :) > I often need to quickly adjust a grid or fill setting > (and so on) and still have my 'keyboard hand' on the > shortcut keys. What I propose is, to also allow the > dialog to be closed again by pressing the same shortcut. > > The window manager's close button can sometimes be just > a bit too small (obviously depending on which window > manager and theme one uses) for frequent use. This may > also improve workflow a bit for keyboard-lovers like me > and is hopefully trivial to implement :)

2 2

Patch: Undo History dialog
by Gustav Broberg 12 Apr '06

12 Apr '06

Hi, I have recently uploaded a patch[1] which provides an undo history dialog. It is similar to those found in e.g. GIMP[2] and Photoshop[3] (I don't know if it's in Illustrator, CorelDRAW, etc). To get an idea what it looks like without having to apply the patch, here's a screencast (in flash, sorry ;) showing it in action: http://www.csc.kth.se/~broberg/undo-history.html First of all, I'm not sure if this is a requested addition to Inkscape -- I can't recall any discussion about it on the list and I didn't find anything in the wiki. Personally, however, I do find it useful (at least occasionally), so I went ahead and implemented it. Secondly (if it's found to be of value), this patch could use some rather heavy reviewing. It's my first patch and I'm not confident enough with the code base to feel sure about what the "right" solutions are. Here are some additional concerns: * To get the type of an event I rely entirely on the current event context. This obviously not (always) a correct assumption. An example of this problem: setting an object's color while the node tool is the current context. * In order to populate the tree with icons I added a help function to widget/icon.cpp to get the internal Pixbuf of an icon. This could be solved in much a better way when the gktmmified stock icon system is in place, but for now, this was easiest way for me to solve it. * There are bugs lurking which I have not been able to reproduce. Some seem to be the result of problems with undoing of certain types of events; i.e. the bugs are in the current code. I'm looking into this... For now, here is at least one I managed to nail down and put in the tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1423038&group_id=9… 1. http://sourceforge.net/tracker/index.php?func=detail&aid=1423034&group_id=9…) 2. http://docs.gimp.org/images/dialogs/dialogs-undo-history.png 3. http://homepage.cs.uri.edu/tutorials/PhotoshopEl/Help/images/wa_11.gif -- Gustav Broberg

6 9

DOM update
by Bob Jamison 12 Apr '06

12 Apr '06

Hi, all, This morning we updated the /dom directory. Basically we ripped up the old one, and added a new one. So there will be a large svn update tonight. We worked toward making sure that the build is not broken, but there might be minor details on Linux or OSX. Please let me know if there are any problems. This was necessary to move forward with .odg output, which should start taking shape soon. Considerable thanks to Aaron and Cornelius for helping me with this. bob

2 1

[Fwd: Vektorgrafik-Test in der c't]
by Adib Taraben 12 Apr '06

12 Apr '06

Hello all, I got a message from Peter Koenig an writer for the german computer mag C't. C't is a 2 weekly high level computer mag. They are doing a comparison of free and cheap (does not cost much) vector-graphics-software. So they are also dealing with Inkscape. The article will be published on May 15th. They give all originators the possibility to review the test-results. The results will be delivered until April 18th and they need feedback until April 27th. As the time-frame is tight the writer ask for point of contact for the test-results and upcoming technical questions. Me: As the paper is in german I will ask him to write the results to me and Colin (another german). I think the results should not go to the wild before issuing the mag on the kiosk. Technical issues should go to inkscape-devel. So stay tuned, Adib. -------- Original Message -------- Subject: Vektorgrafik-Test in der c't Date: Wed, 12 Apr 2006 11:12:02 +0200 From: Peter König <pek@...883...> To: Adib Taraben <taraben.a@...50...> Hallo, voraussichtlich in c't-Ausgabe 11/2005 (Erstverkaufstag am 15. Mai) wird ein Test preiswerter und kostenloser Vektorgrafik-Software erscheinen, wobei Inkscape im Testfeld vertreten sein wird. Wir möchten allen Herstellern Gelegenheit geben, die Abschnitte und Tabelleneinträge, die ihr Produkt betreffen, vor Drucklegung zu prüfen. Diese Auszüge aus dem Testbericht verschicken wir per E-Mail, voraussichtlich bis zum 18. April. Ihr Feedback sollte uns bis spätestens 27. April erreicht haben. Da dieser Zeitplan einigermaßen eng ist, würde ich gerne wissen, ob ich mit dieser Anfrage bei Ihnen an der richtigen Adresse bin und wer sich genau bei Ihnen mit dieser Angelegenheit befassen wird. An wen soll ich die Auszüge aus dem Testbericht schicken und wer kann während des Test eventuell auftauchende technische Fragen beantworten? Vielen Dank und mit freundlichen Grüßen, Peter König c't - Magazin für Computertechnik http://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH & Co.KG phone: 0511-5352-763 Helstorfer Str. 7 fax: 0511-5352-417 D-30625 Hannover, Germany eMail: pek@...883...

1 0

WEBFORM for an update
by marcus y 12 Apr '06

12 Apr '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: marcus y email: marcus-yass@...1231... submitted the following: Just a sujustion in case you release an update to inkscape. Perhaps you should treat gradient lines more like objects(allow for grouping to the objects they are aplied to). Also, if you can, have the four corners of an imported bitmap treated as nodes, to allow for perspective style deforming. Oh, the pattern converter doesn\'t seem to have much use, the way the program illistrates the spaces beetween objects that are exactly \"touching\" is intrusive, there\'s no way to get around it so it needs fixing. Thanks (that is, if you listen)

1 0

inkscape build report
by Bryce Harrington 10 Apr '06

10 Apr '06

Some new warnings in dom/ziptool.cpp. ----- Forwarded message from root <root@...1070...> ----- Date: Mon, 10 Apr 2006 05:21:15 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Mon Apr 10 05:20:20 2006 (Run 2020) Snapshot: inkscape-20060410-0400.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 16 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == sp-flowtext.cpp:339: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-item.cpp:744: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:733) sp-shape.cpp:609: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:486: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:650: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:729: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) dom/ziptool.cpp:1531: warning: comparison between signed and unsigned integer expressions dom/ziptool.cpp:1654: warning: unused variable `int cm' dom/ziptool.cpp:1659: warning: unused variable `bool ftext' dom/ziptool.cpp:1672: warning: unused variable `time_t mtime' dom/ziptool.cpp:1677: warning: unused variable `int xfl' dom/ziptool.cpp:1682: warning: unused variable `int os' == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0

Icons.... ?
by Jon A. Cruz 09 Apr '06

09 Apr '06

So... Who cares about icons? Themes, styles, names, fallbacks, matching FDO and CREATE and Tango!, etc... In squashing the Evil Giant Eyeball (which mutated from the horrid large eyeball), I've landed square in the middle of icon code again, so was wondering if anyone has things to be addressed while I'm in there. references: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec- latest.html http://tango-project.org/Tango_Desktop_Project http://tango-project.org/Standard_Icon_Naming_Specification Supplemental: http://tango-project.org/ArtLibreSet

5 7

presentation functionality
by Rick 08 Apr '06

08 Apr '06

This is a probe to see if there is any thought being given towards automation of presentation (a la powerpoint) functionality in InkScape. A a whole lot can be done now for static presentations. But some simple scripting features would be really useful. For instance: I like to add popup text boxes which can be handled by adding simple mouseover/mouseout calls to toggle visibility on a caption. This works in FireFox, (although it would be 'really' nice if SVG fonts worked too) I imagine that this would be ways down the road, and probably fairly complicated to integrate, but is there a plan for this type of functionality? -- Cheers! Rick

2 1

Translatable SVG document support
by Andrius Ramanauskas 08 Apr '06

08 Apr '06

Hi, I am currently planning to add support for internationalized (translatable) SVG documents. And I guess it is better to share my thoughts before going deep to implementation, so everyone will be aware of my plans and maybe someone will criticize or adjust my plans. My current plan is to implement this in steps: * 1 step - <switch> support. I already tested prototype of semi-working switch element support, but there still some work to do. Currently switch element works just like <g>, but I will make it work according to SVG standard - to render only first element which conditional properties evaluate to true (I will implement support for "systemLanguage" property for a start, which will evaluate to true if property is not set or contains current document language). I plan to make SPSwitch a subclass of SPGroup, so user can enter switch element (turn it into a temporery layer, which will show all contained items, not just first) * 2 step - bitmap export by language (ability to define language to use for <switch> in command line) * 3 step - export/import of texts. Import will also create <switch> elements if not already created * 4 step - UI support for language. I don't know for sure how it should be implemented, but I guess there should be a menu item to turn text to switch ("Make translatable") and language combo in Text dialog (to be shown only if switch is selected) Anyway, I'm open for there are any suggestions or objections. Andrius

3 3

Markup in verbs.cpp
by Jon A. Cruz 08 Apr '06

08 Apr '06

I just noticed a problem in verbs.cpp The tooltips in the toolbar show raw escapes instead of the character being represented. That is... I see "Rotate selection 90° clockwise" instead of "Rotate selection 90º clockwise" I noticed that one went in on a checkin for fixing things inside of menus. That seems to work for me. However, it appears to be at the expense of the tooltips. Since GTK+ is all UTF-8 based, I tried changing it to escaped literal UTF-8 values. "Rotate selection 90\xC2\xB0 clockwise" now makes it work in both locations for me. Sooooo..... does anyone else see the problem? And/or does anyone know of a better correction for it?

1 0

Announcing InkscapeSVG
by unknown＠example.com 07 Apr '06

07 Apr '06

Greetings fellow Inkscapers, This announcement is a couple of days late due to problems establishing our new project web site.... but as the say, better late than never. Much hard work has gone into developing Inkscape, the world's best free vector drawing program. But times are a-changing. The world is being Googled. Applications must be web based. We, who firmly believe in the open SVG standard, must move on too. Thus it gives us great pleasure to announce that our future efforts will be towards creating InkscapeSVG, a web based vector drawing program written in... ta-daa... SVG itself! Already a prototype exists including several basic shape tools and a swatches pallete. You can check out development at: http://inkscapesvg.free.fr Make sure you check out the nifty text tool too! Sincerely, Your InkscapeSVG team.

5 7

Large checkin for sizes
by Jon A. Cruz 07 Apr '06

07 Apr '06

I just did a checkin of 22 files to start cleaning up the icon size issue. Although there were many files touched, the actual line count is fairly low. The main thing is to switch off of use of the GtkIconSize enum. For end programmers out there, the change is only from "GtkIconSize" to "Inkscape::IconSize" and from "GTK_ICON_SIZE..." to "Inkscape::ICON_SIZE...". Thus it should be a very low-impact one. So please give things the once-over to make sure nothing snuck in as far as side-effects go (it did pass 'make check' and all the other smoke tests I ran, but it's always good to check). The thing this checkin should have achieved is isolating use of GtkIconSize to just two main files. That way the work to change some icons smaller can go in easily. For those who care about details... The calls for themeable stock items use GtkIconSize as a base, but then allow for arbitrary string-based sizes to be registered for new int values. Thus we can't simply extend their enum with +1 and use that directly. Instead we need to add in a lookup to translate at run- time from our extended enum to the types registered dynamically. This buys us quite a lot of functionality, and only needs extra work in a single file. First phase was to encapsulate the use of GtkIconSize in those two main locations. The second phase is to add the dynamic mapping of enum/int values. Then the third stage will be to change selected things (like the eye and the lock) to use Inkscape::ICON_SIZE_DECORATION.

1 1

Windows XP: Interface very slow
by Michael Gorbach 07 Apr '06

07 Apr '06

I am trying to use inkscape on winxp pro sp2 and the program does not run well at all. The drawing of widgets by gtk is very slow. I can see black rectangles appearing where the menu should be before the menu is drawn. Is this a known issue of some kind? Is there a fix? Michael Gorbach

4 5

Do a CVS visualization study, GET CASH
by Eric Gilbert 07 Apr '06

07 Apr '06

Hi, I am a graduate student at the University of Illinois at Urbana- Champaign. I am doing a study soon on the effects of CVS and mail visualization on open source communities. Check out my work here: http://social.cs.uiuc.edu/people/gilbert/research.html (info on the projects) http://social.cs.uiuc.edu/people/gilbert (info on me) If you are a developer, I could use your help. Look at the visualization, do some surveys and we give you a $20 gift certificate to newegg.com. I am not ready quite yet; still waiting on IRB approval (http:// www.irb.uiuc.edu/). Please keep us in mind if you are interested... I will ask again soon, and then that's all the spam. Contact me if you want more information now. Thanks, Eric -- "Tyranny is tyranny, let it come from whom it may." -- Revolutionary conscripts, 1776

1 0

svn 11251 dumps core
by inkbottle 07 Apr '06

07 Apr '06

Here is a reproducible crash on svn revision 11251. My 12-year old found this crash running .43 on FC4. I reproduced the problem on FC5 at the tip of svn, rebuilt inkscape debug and produced a stack trace from the core file. The crash is caused reliably in the following way. Enter some text. Zoom in on the text, or make it big enough to work with easily. The text I used was "This is some text". Select the text tool. use that tool to select,say, the initial T. Change the size of the text to something else noticeably different, it doesn't matter what. The T changes size appropriately. Then place a gradient on the text string as a whole. Now select, say, the s in 'some' with the text tool. Change the size of that s to any other size. Poof! inkscape dumps core, and vanishes. Here is the gdb backtrace. It is a bit beyond me at the moment. This has something to do with text, gradients and, from the backtrace, selection and styles. I'm hoping someone can make more sense of the backtrace than I. (gdb) where #0 0x005ec402 in __kernel_vsyscall () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #1 0x00e22159 in raise () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #2 0x00e236e3 in abort () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #3 0x082d1ca8 in inkscape_segv_handler (signum=11) at inkscape.cpp:375 #4 <signal handler called> #5 0x08648c53 in Inkscape::UI::Widget::SelectedStyle::update (this=0xa74e800) at ui/widget/selected-style.cpp:893 #6 0x086495e1 in ss_selection_changed (data=0xa74e800) at ui/widget/selected-style.cpp:46 #7 0x08649618 in ss_selection_modified (selection=0xa6affc0, flags=11, data=0xa74e800) at ui/widget/selected-style.cpp:52 #8 0x0838d6da in sigc::pointer_functor3<Inkscape::Selection*, unsigned int, void*, void>::operator() (this=0xa7a6110, _A_a1=@0xbfa52be4, _A_a2=@0xbfa52bf4, _A_a3=@0xbfa52af4) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:185 #9 0x08662e17 in sigc::adaptor_functor<sigc::pointer_functor3<Inkscape::Selection*, unsigned int, void*, void> >::operator()<Inkscape::Selection* const&, unsigned int const&, Inkscape::UI::Widget::SelectedStyle*&> (this=0xa7a610c, _A_arg1=@0xbfa52be4, _A_arg2=@0xbfa52bf4, _A_arg3=@0xa7a6114) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:123 #10 0x08662e4e in sigc::bind_functor<-1, sigc::pointer_functor3<Inkscape::Selection*, unsigned int, void*, void>, Inkscape::UI::Widget::SelectedStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()<Inkscape::Selection* const&, unsigned int const&> (this=0xa7a6108, _A_arg1=@0xbfa52be4, _A_arg2=@0xbfa52bf4) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1144 #11 0x08662e78 in sigc::internal::slot_call2<sigc::bind_functor<-1, sigc::pointer_functor3<Inkscape::Selection*, unsigned int, void*, void>, Inkscape::UI::Widget::SelectedStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void, Inkscape::Selection*, unsigned int>::call_it (rep=0xa7a60f0, a_1=@0xbfa52be4, a_2=@0xbfa52bf4) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:173 #12 0x082e7d19 in sigc::internal::signal_emit2<void, Inkscape::Selection*, unsigned int, sigc::nil>::emit (impl=0xa7a3ca8, _A_a1=@0xbfa52be4, _A_a2=@0xbfa52bf4) at /usr/include/sigc++-2.0/sigc++/signal.h:832 #13 0x082e7de2 in sigc::signal2<void, Inkscape::Selection*, unsigned int, sigc::nil>::emit (this=0xa6afff0, _A_a1=@0xbfa52be4, _A_a2=@0xbfa52bf4) at /usr/include/sigc++-2.0/sigc++/signal.h:1924 #14 0x082e661a in Inkscape::Selection::_emitModified (this=0xa6affc0, flags=11) at selection.cpp:93 #15 0x082e6651 in Inkscape::Selection::_emit_modified (selection=0xa6affc0) at selection.cpp:85 ---Type <return> to continue, or q <return> to quit--- #16 0x00d8b6e1 in g_list_remove_link () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #17 0x00d8d09d in g_main_context_dispatch () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #18 0x00d9032f in g_main_context_check () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #19 0x00d906d9 in g_main_loop_run () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #20 0x03b39a6b in gtk_dialog_run () at /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../../include/c++/4.1.0/exception:56 #21 0x082d25ef in inkscape_segv_handler (signum=11) at inkscape.cpp:525 #22 <signal handler called> #23 0x08648c53 in Inkscape::UI::Widget::SelectedStyle::update (this=0xa74e800) at ui/widget/selected-style.cpp:893 #24 0x086495e1 in ss_selection_changed (data=0xa74e800) at ui/widget/selected-style.cpp:46 #25 0x086495fd in ss_subselection_changed (dragger=0xa659a00, data=0xa74e800) at ui/widget/selected-style.cpp:58 #26 0x084f9f96 in sigc::pointer_functor2<void*, void*, void>::operator() ( this=0xa7a61a8, _A_a1=@0xbfa538c4, _A_a2=@0xbfa53804) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:147 #27 0x08662ea4 in sigc::adaptor_functor<sigc::pointer_functor2<void*, void*, void> >::operator()<void* const&, Inkscape::UI::Widget::SelectedStyle*&> ( this=0xa7a61a4, _A_arg1=@0xbfa538c4, _A_arg2=@0xa7a61ac) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:103 #28 0x08662ed3 in sigc::bind_functor<-1, sigc::pointer_functor2<void*, void*, void>, Inkscape::UI::Widget::SelectedStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()<void* const&> (this=0xa7a61a0, _A_arg1=@0xbfa538c4) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1122 #29 0x08662ef7 in sigc::internal::slot_call1<sigc::bind_functor<-1, sigc::pointer_functor2<void*, void*, void>, Inkscape::UI::Widget::SelectedStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void, void*>::call_it (rep=0xa7a6188, a_1=@0xbfa538c4) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:137 #30 0x0837e5ae in sigc::internal::signal_emit1<void, void*, sigc::nil>::emit ( impl=0xa7a6158, _A_a1=@0xbfa538c4) at /usr/include/sigc++-2.0/sigc++/signal.h:686 #31 0x0837e66f in sigc::signal1<void, void*, sigc::nil>::emit (this=0xa6aef94, _A_a1=@0xbfa538c4) at /usr/include/sigc++-2.0/sigc++/signal.h:1812 #32 0x08377605 in SPDesktop::emitToolSubselectionChanged (this=0xa6aee00, data=0xa659a00) at desktop.cpp:1017 ......

3 2

[root@...1070...: [Inkscape-tester] inkscape build report]
by Bryce Harrington 07 Apr '06

07 Apr '06

Bunch of new warnings today in knot.cpp. Bryce ----- Forwarded message from root <root@...1070...> ----- Date: Thu, 06 Apr 2006 17:21:33 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Thu Apr 6 17:10:56 2006 (Run 1936) Snapshot: inkscape-20060406-1600.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 27 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == Warnings == knot.cpp:109: warning: invalid access to non-static data member `SPKnotClass::event' of NULL object knot.cpp:109: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:118: warning: invalid access to non-static data member `SPKnotClass::clicked' of NULL object knot.cpp:118: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:127: warning: invalid access to non-static data member `SPKnotClass::doubleclicked' of NULL object knot.cpp:127: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:136: warning: invalid access to non-static data member `SPKnotClass::grabbed' of NULL object knot.cpp:136: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:145: warning: invalid access to non-static data member `SPKnotClass::ungrabbed' of NULL object knot.cpp:145: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:154: warning: invalid access to non-static data member `SPKnotClass::moved' of NULL object knot.cpp:154: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:163: warning: invalid access to non-static data member `SPKnotClass::request' of NULL object knot.cpp:163: warning: (perhaps the `offsetof' macro was used incorrectly) knot.cpp:172: warning: invalid access to non-static data member `SPKnotClass::distance' of NULL object knot.cpp:172: warning: (perhaps the `offsetof' macro was used incorrectly) sp-flowtext.cpp:339: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-item.cpp:744: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:733) sp-shape.cpp:609: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:472: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:644: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:723: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) trace/trace.cpp:196: warning: unused variable `Inkscape::XML::Node*imgRepr' == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0

Clipping and masking bugs
by Tavmjong Bah 06 Apr '06

06 Apr '06

Hi, I've begun to update my book for 0.44. Should be a great release! But, I have run into a few bugs with a version of Inkscape from SVN a day or two ago. The following file can be used to illustrate the problems: http://tavmjong.free.fr/INKSCAPE/DRAWINGS/ClipMask2.svg The raw objects for clipping and masking are on the left, the clipped and masked objects (blue rectangles) are on the right. In the case of the first two items, the file is displayed correctly in Firefox trunk. 1. Clipping using stroked text without fill doesn't seem to work. 2. The masked object is invisible when the file is saved and reopened. The masked object can be restored by selecting the object, unmasking and remasking. 3. Sometimes the display of the gradient is not updated when the gradient tool is used to adjust it. Try editing the gradient in the above document by dragging a gradient node. 4. Not really a bug... but very confusing. The gradient editor does not switch to the gradient selected with the the gradient tool. This behavior is different from all other dialogs. If needed, I'll file bug reports but I thought I would bring them up here first. Tav

2 3

IO::Resource vs. Binreloc
by Aaron Spike 06 Apr '06

06 Apr '06

I was going to build an autopackage this morning for those who would like to play with the new keymaps but the build errored out with the following message. I'm assuming that it is caused by Binreloc because that is something that is different in the autopackage build. I understand some of the words but it is still a little beyond me. mental? Aaron Spike io/resource.cpp: In function ‘Inkscape::Util::ptr_shared<char> Inkscape::IO::Resource::get_path(Inkscape::IO::Resource::Domain, Inkscape::IO::Resource::Type, const char*)’: io/resource.cpp:38: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:39: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:40: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:41: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:42: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:43: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:44: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:45: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:46: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:47: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:48: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:49: error: invalid conversion from ‘const char*’ to ‘gchar*’ io/resource.cpp:50: error: invalid conversion from ‘const char*’ to ‘gchar*’

2 2

[new] configurable keymaps
by MenTaLguY 06 Apr '06

06 Apr '06

I've just committed basic support for configurable keymaps. You'll probably need to do a fresh ./configure to get share/keys -- and a 'make install' to install share/keys/default.xml and get your keyboard shortcuts back! share/keys/default.xml contains the default key configuration for Inkscape; until I document the format further, you can use it for reference when developing your own keymaps. The key names in it are GDK keysym names. share/keys/default.xml gets loaded first, followed by ~/.inkscape/keys/default.xml if it exists. At present, a user keymap is overlaid on the system keymap rather than clearing it completely. -mental

1 0

Icons, and cursors, and multiples... oh my
by Jon A. Cruz 05 Apr '06

05 Apr '06

I was skimming through my log, and noticed a few things that could be brought up here... First is reusing the icon code for cursors. This is probably a good idea, and for even more reason than thought. One of the additional benefits would be nice fallback to CREATE assets, etc. I'm fairly up on the various bits of code involved, and also cursor stuff, so definitely hit me up about it. Oh... and a minor point... the XPM spec (what we use for our cursors currently) allows for the hot X and Y to be in the XPM file itself. I was looking at this a bit, as it would take the position hardcoding out of our source code that loads icons. The default routines don't give you X and Y, but I can add it easily. We probably could fold this in to the other cursor work with minimal effort. Then there's the whole thing about multiple export. It's actually not to hard to do... and something I'm doing in the Icon Preview dialog. With just a little bit of tuning, that can be refactored to also support multiple-res export. This would be good for icons and cursors, and is very low-hanging fruit in that I can probably get it going in a day or so. Plus there've been enough user requests to make something like that worthwhile. So... start thinking about how this could be done for the most effect with the least effort. Hitting cursors and icon needs would be the minimum. Roughing this out could help both the export and the preview. Oh, and one of the other features I was looking at was adding librsvg rendering to the icon preview window. Again, I've done all the research on it and it will take only a small bit of coding (perhaps less than hooking in LittleCms took). I'm wondering if this might be useful as an option for the multi-export, in addition to the preview window. Anyway, start thinking about all this. There's a lot we can do to combine a few simple things and end up with some powerful workflow tools. UI, command-line invocation and use cases of different types of users could all be helpful.

1 0

printing
by Mickael Drean 05 Apr '06

05 Apr '06

Hi there, Recently i started to develop with Gtkmm and I need to print and export custom Widget to picture file. As Inkscape is capable of doing it, i 'd like to know how you dit it. Do you use an external librairy? or have you developped the functionnality? Please, could you help me to achieve my goals? Thanks, Mick PS: my english may be unclear, do not hesitate to say it...

2 1

[root@...1070...: [Inkscape-tester] inkscape build report]
by Bryce Harrington 05 Apr '06

05 Apr '06

Build system is picking up an error in svg-color-test.h... Bryce ----- Forwarded message from root <root@...1070...> ----- Date: Tue, 04 Apr 2006 17:21:16 -0700 From: root <root@...1070...> To: inkscape-tester(a)lists.sourceforge.net Subject: [Inkscape-tester] inkscape build report = Analysis Report for inkscape = Report Time: Tue Apr 4 16:54:55 2006 (Run 1886) Snapshot: inkscape-20060404-1400.tar.bz2 Status: finished Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 12 2 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == svg/svg-color-test.h:26: error: `assert' undeclared (first use this function) svg/svg-color-test.h:26: error: (Each undeclared identifier is reported only once for each function it appears in.) == Warnings == sp-flowtext.cpp:324: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-image.cpp:516:8: warning: extra tokens at end of #endif directive sp-item.cpp:730: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.cpp:719) sp-shape.cpp:611: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) sp-text.cpp:472: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:644: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) dialogs/export.cpp:723: warning: `sp_item_bbox_desktop' is deprecated (declared at sp-item.h:215) display/canvas-arena.cpp:85: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:85: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp:132: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:132: warning: (perhaps the `offsetof' macro was used incorrectly) trace/trace.cpp:196: warning: unused variable `Inkscape::XML::Node*imgRepr' == Environment Summary == ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-tester mailing list Inkscape-tester(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-tester ----- End forwarded message -----

1 0

[Portland] File dialog as trusted desktop service
by Bryce Harrington 05 Apr '06

05 Apr '06

----- Forwarded message from "Bastian, Waldo" <waldo.bastian@...1100...> ----- Date: Mon, 20 Mar 2006 08:26:45 -0800 From: "Bastian, Waldo" <waldo.bastian@...1100...> To: portland@...626... Subject: [Portland] File dialog as trusted desktop service FYI Waldo Bastian Linux Client Architect - Channel Platform Solutions Group Intel Corporation - http://www.intel.com/go/linux OSDL DTL Tech Board Chairman -----Original Message----- From: gtk-devel-list-bounces@...45... [mailto:gtk-devel-list-bounces@...45...] On Behalf Of Mark Seaborn Sent: Saturday, March 18, 2006 9:22 AM To: gtk-devel-list@...45...; gtk-list@...45... Subject: ANNOUNCE: Plash 1.16, with Powerbox for Gtk Hi folks, I have released a new version of Plash, which is available from: http://plash.beasts.org Plash is a system for sandboxing GNU/Linux programs so that they can be run with minimum authority/privileges. Plash can be used with GUI applications: you can dynamically grant a GUI application access rights to individual files that you want to open and edit. This happens transparently through the Open/Save file chooser dialog box. Plash replaces Gtk's GtkFileChooserDialog so that the file chooser is implemented outside the application in a separate process, as a trusted component. This file chooser is known as a powerbox, because it delegates additional power to the application. For example, Inkscape can be launched in a sandbox using the following command. Initially it won't have access to anything in your home directory. Choosing a file using File->Open grants Inkscape access to the file, attaching the file into Inkscape's file namespace. pola-run --prog /usr/bin/inkscape \ -B -fl /etc --x11 \ --env LD_PRELOAD=/usr/lib/plash/lib/powerbox-for-gtk.so \ --powerbox --pet-name "Inkscape" The main change in this release is a reimplementation of the powerbox/Gtk integration. In the previous version, the replacement GtkFileChooserDialog class inherited only from GtkObject, which caused various problems. The new version inherits from GtkDialog (and hence from GtkWindow, GtkWidget, etc.), just as the ordinary GtkFileChooserDialog does. This works with a lot more Gtk applications. The new GtkFileChooserDialog replacement prevents its parent GtkWindow from opening a window by overriding the GtkWidget "map" method with code that does not pass the call on to GtkWindow. Instead, the "map" method invokes the powerbox API, which causes the powerbox manager to open a file chooser instead. You can see the code for this at: new: http://svn.gna.org/viewcvs/plash/trunk/src/gtk-powerbox.c old: http://svn.gna.org/viewcvs/plash/trunk/src/gtk-powerbox-noninherit.c This still works as an LD_PRELOADed library, which replaces gtk_file_chooser_* functions. Would there be any interest in merging this functionality into mainline Gtk, so that the powerbox code can optionally be compiled in, and optionally be enabled at run time? Mark _______________________________________________ gtk-devel-list mailing list gtk-devel-list@...45... http://mail.gnome.org/mailman/listinfo/gtk-devel-list _______________________________________________ Portland mailing list Portland@...626... http://lists.freedesktop.org/mailman/listinfo/portland ----- End forwarded message -----

1 0

next about screen
by Jon Phillips 04 Apr '06

04 Apr '06

Who is doing the next about screen? It seems like it should be added in here soon...is there a time-table for this? Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)

5 7

WEBFORM TurboMilk Blog
by Dmitri Joukov 04 Apr '06

04 Apr '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Dmitri Joukov email: dmitri@...1228... submitted the following: We wrote about Inkscape in our blog. Please check it out http://blog.turbomilk.com/archives/000058.html. Thanks for attention! -- Dmitri Joukov

2 1

Inkscape and others on newsforge
by cedric GEMY 04 Apr '06

04 Apr '06

have a look at that http://business.newsforge.com/business/06/03/09/2238246.shtml?tid=37 !! cedric

2 1

Inkscape now has ICC support
by Jon A. Cruz 04 Apr '06

04 Apr '06

I've just finished base support for the <color-profile> element and for the 'color-profile' attribute on <image> elements. Among other things, this means that Inkscape in SVN now passes the W3C's compliance test on this (color-prof-01-f). http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-color- prof-01-f.html It's currently off by default. To turn it on, one needs to configure with --enable-lcms Give it a spin and see what needs improving. I'm moving on to working on support for fills like "#FF00FF icc-color(base, 0.0, 1.0, 0.0, 0.3)", then on to some named color support.

3 2

LittleCMS in win32
by Bob Jamison 04 Apr '06

04 Apr '06

Hi, all, A couple of guys wrote to me yesterday about how to enable JonCruz's integration of LittleCMS in Win32. I built LittleCMS 1.15 with Mingw and MSYS, added it to the gtk28 bundle here: http://inkscape.org/win32/gtk28-060403.7z ...but this link is certainly faster/better: http://inkscape.modevia.com/win32libs/gtk28-060403.7z If anyone is interested in using LittleCMS for other Win32 projects, I uploaded the separate LittleCMS build also. Here is the Mingw-built LittleCMS DLL/.h/.a developer file set: http://inkscape.modevia.com/win32libs/lcms.7z ...or... http://inkscape.org/win32/lcms.7z I committed the makefiles to use it in Inkscape, so builders will likely need to do a 'make clean' and rebuild with the new makefile flags. bob

1 0

test updating
by Jon A. Cruz 04 Apr '06

04 Apr '06

I just did a commit to change attributes-test to CxxTest. Also, I added the attributes now supported by adding <color-profile> If anyone gets a chance, see if "make check" works now. I think there are two unknown attributes that show up, but it should build and run the test now. Thanks.

1 0

WEBFORM website looks bad in firefox
by Peter Doornbosch 04 Apr '06

04 Apr '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Peter Doornbosch email: pieterbauke@...1224... submitted the following: Hi, Let me start with saying that i think Inkscape is great software. Thanks for sharing this with us. Then, i little remarkt about the website (www.inkscape.org). When you view it in firefox, it looks ok, until you press Ctr-+ (increase text-size), which makes the menu move towards the middle of the page. Ok, it is still readable, but it doesn\'t look that nice (and i guess people who write graphics software, realy care about how something looks ;-)). Cheers, Peter.

4 3

WEBFORM
by Radek Turek 02 Apr '06

02 Apr '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Radek Turek email: rture@...1225... submitted the following: Enter your message or news here.

1 0

Adding LittleCms
by Jon A. Cruz 02 Apr '06

02 Apr '06

I just did a commit to add LittleCms as an optional feature. If anyone could give the configure.ac changes a look, that would be helpful. I'm not too expert on config changes yet. I've also talked over various aspects with Peter, so have a good idea on first steps of actually using the library, and we should see bits using it fairly quickly. We might even be able to get <colorProfile> and friends working for the general case within a week or so.

3 4

WEBFORM
by Masa T 02 Apr '06

02 Apr '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Masa T email: masa_tukuda@...1026... submitted the following: Enter your message or news here.

1 0

Coordinate System Transformation Matricies
by Aaron Spike 01 Apr '06

01 Apr '06

Or whatever they are called. Functions like sp_item_i2r_affine(), sp_item_i2doc_affine, sp_item_i2root_affine are a fearful inhibitor for incoming developers and a stumbling block even for experienced developers. It would be really cool for a few of us to sit down and add some enlightening comments (perhaps an example every now and again would help). Aaron Spike

1 0

NEW: more nodetool optimization, tweak in node type change
by bulia byak 01 Apr '06

01 Apr '06

* Node tool optimization is addictive - I just can't stop doing it :) Now _most_ of node tool operations, including curve and node dragging and move/scale/rotate operations on multiple selected nodes, are much faster as well. Please test it thoroughly - I might have broken something. * In the Node tool, when you switch the type of the selected node to Smooth or Symmetric (by Shift+S/Shift+Y), you can now preserve the position of one of the two handles by hovering your mouse over it, so that only the other handle is rotated/scaled to match. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Re: please check whether current svn compiles again with gtkmm-2.4
by jiho 31 Mar '06

31 Mar '06

On 31 Mar 2006, at 12:38 , Peter Moulder wrote: > Ted has addressed some of the things that caused the compile > failure you > reported. Can you confirm whether this is enough for it to compile > for > you, assuming you haven't upgraded libgtkmm-2.4-dev in the meantime? sorry I supposed that once more I forgot to reply to all and replied to ted only instead of replying to the list. yes it compiles like a charm with gtkmm 2.4.10 now and I am using it right now. thank you for the reminder... and for the software. > Thanks, > > pjrm. > > > ----- Forwarded message from Ted Gould <ted@...11...> ----- > > X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on > bowman.csse.monash.edu.au > X-Spam-Level: > X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00, > RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.0 > Envelope-to: pmoulder@...89... > Delivery-date: Thu, 30 Mar 2006 16:49:16 +1100 > From: Ted Gould <ted@...11...> > Subject: [Inkscape-devel] Unparents removed > To: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > X-BeenThere: inkscape-devel(a)lists.sourceforge.net > X-Mailman-Version: 2.0.9-sf.net > List-Post: <mailto:inkscape-devel@lists.sourceforge.net> > List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ > inkscape-devel>, > <mailto:inkscape-devel-request@lists.sourceforge.net? > subject=subscribe> > List-Unsubscribe: > <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, > <mailto:inkscape-devel-request@lists.sourceforge.net? > subject=unsubscribe> > List-Archive: > <http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel> > List-Help: <mailto:inkscape-devel-request@lists.sourceforge.net? > subject=help> > List-Id: <inkscape-devel.lists.sourceforge.net> > > > I removed the unparent, so it should (in theory) compile on GTKmm > 2.4.x > now. > > --Ted > > > > ----- End forwarded message ----- JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

1 0

Playing with colors
by Jon A. Cruz 30 Mar '06

30 Mar '06

I just checked in a change to start some experimentation with linked colors. There are various technical things this will let me play with internally, but the immediate visible effect is that palettes can be edited and can have linked colors. To enable things, a .gpl palette file needs to have some 'magic' strings in its names. I'm looking for "*{" and "}*" as delimiters. Within those some letters can go in 'E' will make the color editable. This allows you to drop colors onto the palette entry. 'S' will make a color a 'shade' or 'tone' of another color. It requires parenthesis with two or three comma-separated integer values in it. the first number is the index in that palette to link to the second number is the percentage to mix with either black (for shades) or some gray (for tones). the optional third number is the gray percentage to mix with. (if present, makes it a tone. If missing, this will make it a shade) 'T' will make a color a 'tint' of another color. It requires two comma-separated integer values in it the first number is the index in that palette to link to the second number is the percentage to mix with white. Some examples: ... 204 255 102 CCFF66 *{E}* 102 255 255 66FFFF *{ES(4,25)}* lkj 102 255 51 66FF33 *{ES(4,25,33)}* 102 255 0 66FF00 *{ET( 4, 25 )}* 51 255 255 33FFFF *{ET(4,75)}* This markup is very temporary, and was only put in as a way to enable testing of some of the color things themselves. (Also... the actual color manipulations might be off right now, as color change accuracy is not as important as the initial linking behavior.) Oh, and if you tweak a palette successfully, then you should see magic arrows show up in the swatches UI.

4 8

Unparents removed
by Ted Gould 30 Mar '06

30 Mar '06

I removed the unparent, so it should (in theory) compile on GTKmm 2.4.x now. --Ted

1 0

compilation error on debian
by jiho 30 Mar '06

30 Mar '06

hello, tying to compile latest svn on debian got me this. is this a change in inkscape that requires a recent version of gtkmm? mine is: 2.4.10-1 make[2]: Entering directory `/home/jiho/softwares/inkscape/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/freetype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I../cxxtest -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT ui/dialog/extension-editor.o -MD -MP -MF "ui/dialog/.deps/extension-editor.Tpo" \ -c -o ui/dialog/extension-editor.o `test -f 'ui/dialog/extension-editor.cpp' || echo './'`ui/dialog/extension-editor.cpp; \ then mv -f "ui/dialog/.deps/extension-editor.Tpo" "ui/dialog/.deps/extension-editor.Po"; \ else rm -f "ui/dialog/.deps/extension-editor.Tpo"; exit 1; \ fi /usr/include/gtkmm-2.4/gtkmm/widget.h: In member function `void Inkscape::UI::Dialog::ExtensionEditor::on_pagelist_selection_changed()': /usr/include/gtkmm-2.4/gtkmm/widget.h:2440: error: `void Gtk::Widget::unparent()' is protected ui/dialog/extension-editor.cpp:163: error: within this context /usr/include/gtkmm-2.4/gtkmm/widget.h:2440: error: `void Gtk::Widget::unparent()' is protected ui/dialog/extension-editor.cpp:175: error: within this context /usr/include/gtkmm-2.4/gtkmm/widget.h:2440: error: `void Gtk::Widget::unparent()' is protected ui/dialog/extension-editor.cpp:187: error: within this context make[2]: *** [ui/dialog/extension-editor.o] Error 1 make[2]: Leaving directory `/home/jiho/softwares/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jiho/softwares/inkscape' make: *** [all] Error 2 thank you in advance for any help. -- Jean-Olivier Irisson --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- Personal address: Château St Martin, 66200 Elne, France Professional address: EPHE- UMR CNRS 8046, 52 av Paul Alduy, 66860 Perpignan Cedex, France Mobile: 06 21 05 19 90 Web site: http://jo.irisson.free.fr/work/

4 4

Re: [Inkscape-devel] Copy and Paste
by Martin Owens 29 Mar '06

29 Mar '06

It would save a menu space and work through standard copy/paste keys. On Wed, 29 Mar 2006 16:39:28 +0200 , David Christian Berg <david@...407...> wrote: >Hey Owen, > >could you please elaborate in how this is different from "Paste Style" >in the edit menu? > >Take care! > >David > >On Tue, 2006-03-28 at 10:23 +0100, Martin Owens wrote: >> thinking about this new functionality, >> >> What I would is to beable to go to the styles pannel, have an icon or keyb which fill copy the style (border, fill, everything) and allow you to paste it onto another object, the other object would understand the information on the clipboard was a style and not an object or a size ect. > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

Followup to earlier Linux Format post
by Alan Horkan 29 Mar '06

29 Mar '06

There was an earlier message about tutorials posted in Linux Format magazine which I meant to reply to but I deleted the message. Please add a link in the Wiki including the issue number and dates. When/if the tutorials are later release we can add them in too but by keeping track of when the tutorial happened it might make it easier to track them down later. http://wiki.inkscape.org/wiki/index.php/ArticlesAndPresentations http://wiki.inkscape.org/wiki/index.php/ArticlesAndPresentations#Print_Arti… Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/

1 0

Copy and Paste
by Martin Owens 29 Mar '06

29 Mar '06

thinking about this new functionality, What I would is to beable to go to the styles pannel, have an icon or keyb which fill copy the style (border, fill, everything) and allow you to paste it onto another object, the other object would understand the information on the clipboard was a style and not an object or a size ect. -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

NEW: node tool speedup
by bulia byak 29 Mar '06

29 Mar '06

Switching to and from the Node tool (with a path selected), as well as selecting nodes in that tool, have been significantly optimized and are now about five times faster than before. This is especially noticeable when working with complex paths; with these optimizations, paths containing several thousand nodes, though still slow, are much more usable. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 5

Errors compiling on FC5 with gcc 4.1
by Tavmjong Bah 28 Mar '06

28 Mar '06

Hi, Got a few compile errors using svn with Fedora Core 5 which uses g++ 4.1. I could fix the first one by a cast but I am afraid my c++ is a bit too rusty when it comes to the second. Tav ui/dialog/align-and-distribute.cpp:1077: error: conversion from ‘int’ to non-scalar type ‘std::_List_iterator<SPItem*>’ requested ui/view/edit-widget.cpp: In member function ‘void Inkscape::UI::View::EditWidget::initEdit(SPDocument*)’: ui/view/edit-widget.cpp:1560: error: ‘_namedview_modified’ was not declared in this scope

3 4

NEW: paste size
by bulia byak 28 Mar '06

28 Mar '06

Especially in technical drawings, often you need many different objects to have the same size. It's very tiresome to copy/paste the numbers in the W/H fields. So: A number of commands are added to easily scale selected objects to match the size of the object(s) previously copied to the clipboard. They are all in the Paste Size submenu in Edit menu: * Paste Size scales the whole selection to match the size of the clipboard object(s). * Paste Width scales the whole selection horizontally so that it matches the width of the clipboard object(s). * Paste Height scales the whole selection vertically so that it matches the height of the clipboard object(s). * Paste Size Separately scales each selected object separately so that it matches the size of the clipboard object(s). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 13

Where has the tool set gone?
by erikhalbert 28 Mar '06

28 Mar '06

I have not seriously played with Inkscape for about six months so I thought I'll do a complete reinstal. My system is Win2000. I cleaned out old copies of Inkscape and brought down Inkscape-0603271700 (43.5M). It appeared to install OK but when I opened it I find that I cannot not use it because the toolset is missing many of its functions. All that is there is: Create rectangles and squares Select and transform Create circles, ellipses and arcs Flip vertically Flip horizontally Edit path nodes and Convert selected object to path This seems so bizarre. Either 1. There is a dialog somewhere that sets up a specific toolset. 2. Something is borked. 3. I am doing something really silly because I've been away from Inkscape too long. I've had a look around and cannot see anything that looks promising. Can someone help me out here. I've been using Inkscape for years so I know how it should behave and it certainly is not doing it now for me. Thanks, Erik

2 2

Re: [Inkscape-devel] NEW: paste size
by Martin Owens 28 Mar '06

28 Mar '06

It would be nice to get more copy paste style elements, or even a copy paste that works with the apple command key instead of the ctrl key. On Mon, 27 Mar 2006 07:37:57 -0700 , "Joshua A. Andler" <joshua@...533...> wrote: >Joshua A. Andler wrote: >> This qualifies as one of those enhancements that I never knew I >> needed. FANTASTIC! This is easily one of the greatest improvements >> I've seen in a while. It has all options I'd need and is everything >> I'd hope it would be. Rock on Bulia! > > >Of course I spoke too soon about all the options I'd need. ;) I thought >of two more size related paste options, what about pasting width or >height and constraining proportions? I know that sometimes I need the >width to match, but need the height scaled proportionally with it (such >as a logo). What are your thoughts on this? > >-Josh > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

4 3

Bug in the command line interface of Inkscape on Windows 32 platform
by Gilles Foucault 27 Mar '06

27 Mar '06

Hello guys ! Thanks to the answer from bulia byak (See http://wiki.inkscape.org/wiki/index.php/FAQ#Q:_I.27m_on_Windows.2C_and_comm… ) I compiled Inkscape under MinGW-Win32 using the good options to make the command line interface work under windows, just as Bulia wrote in the FAQ. Now it works as expected. I put my customized build to the following URL : executables only : http://gillou.cjb.net/research/files/inkscape-Win32-CLI-0.43.zip sources and executables : http://gillou.cjb.net/research/files/inkscape-Win32-CLI-devel-0.43.tar.bz2 Makefile rule to transform Inkscape SVG file to EPS format : %.eps : %.svg $(INKSCAPE) --export-eps=$@ $< Best regards, Gilles

1 0

CVS build performance issues with AMD ??
by stinky wizzleteet 27 Mar '06

27 Mar '06

Hi all, On my laptop medion MD4130, AMD k7, radeon IGP320 I've tried inkscape-LATEST, compiled it with mingw, compiled it in debian(unstable) , but: There is a significant performance loss when moving about a group of elements, moreover, this performance even deteriotates further when one moves the group a couple of times. I have seen this performance issue also in the official build in windows, but I fixed it by moving away the gtk dlls I already had installed. In debian, the official debian deb did not have the performance issue. It leads me to, well, guess that the issue is related to gtk/cairo vs AMD. Help appreciated, sander

3 3

downloads page
by Alexandre Prokoudine 27 Mar '06

27 Mar '06

Greetings, http://www.inkscape.org/download.php still tells people about anonymous CVS access. It would be great if somebody whi has appropriate access to the web-site added information how to grab copy of SVN repository instead. Alexandre

2 3

Font weight and style variants
by Denis Jacquerye 27 Mar '06

27 Mar '06

Inkscape is not handling style variants in any flexible way. Right now it can only handle what style_name_compare() recognizes, everything that does not correspond to that is mixed up. Right now only Regular, Roman, Normal, Plain, Medium, Book, Italic, Oblique, Slanted, Bold, and Caps are understood. Fonts that have Light, Thin, ExtraLight (or its variants), UltraLight, Hair, Demi, Demi-Bold, Semi-Bold (etc.), UltraBold, Black, Heavy, Fat and UltraBlack are not handled properly. These could be added as valid style but that's just part of the problem. Some fonts have non standard style like Contour, Sketch or Bubbly. The font dialog should allow the user to select between the CSS weights of a typeface without having to select the styles. libnrtype/nr-type-pos-def.[cpp|h] seems to have the proper structure for multiple weights. I opened a bug report https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1448618&group_… and made some sample fonts if you want to test multiple weights and styles http://home.sus.mcgill.ca/~moyogo/fonts/test/ Denis Moyogo Jaquerye

1 0

Re: [Inkscape-devel] Xarification
by Tobias Jakobs 26 Mar '06

26 Mar '06

> On 3/23/06, MenTaLguY <mental@...3...> wrote: > > - Xara is considerably faster > Xara's renderer is fast, but Cairo with OpenGL is even faster. > But if Cairo gets Xara renderer, it will be just as fast. > Carl Worth (Cairo) talked a lot with the Xara programmers at the LGM. And as far as I know the plan was to make Xara's renderer GPL and then write an Caito backend. > Anyway, so far it's premature, since Xara's renderer is the part which > is not opensourced yet (it remains a binary lib in their source > tarball). > An other reason to use Cairo is, we will get PDF and PS export for free. Tobias __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

3 3

Nice Tutorial in Linux Format
by John Taber 26 Mar '06

26 Mar '06

fyi: This month's Linux Format magazine has a really nice tutorial on Inkscape shapes (becoming a regular feature like their great Gimp tutorial series). Maybe it's just a copy of the existing shapes tutorial (didn't have my laptop with me to compare), but if not, I wonder if there's a way to get permission to put links on the website to the actual articles like this? It's often frustrating to search for documentation and find articles that are months, even years old locked away in subscription only files. Maybe there's a better way to have a linkage between commercial publishers (or even bloggers, the line is blurring) and free software in order to get more how-tos and documentation (some sites do variations on this) One way is to give special promotion on the website to mags that promote the existing tutorials as articles or maybe so many months after publication have excuarticles that become open and part of the software's tutorial or website - this provides magazines with steady stream of great articles, first to market advantage, and exposure on software websites, authors become regular celebrated columnists and even fabulously wealthy on the speaker circuit, and Inkscape and it's users get more freely available docs, everyone wins.

2 1

Inkscape Development
by Dale Harvey 26 Mar '06

26 Mar '06

Hey After a rather long break, I have started again at trying to do some development with inkscape, I was wondering if there was a few quick questions I could ask. debug statements - Im currently trying to get the hang of the code by basically going through and adding debug statements to try and follow the program flow, however g_warning (and g_print/printf/g_debug etc) messages are not being sent to stdout when they are called, I only recieve them after inkscape has been closed, a grep on "g_set_print_handler" gives me nothing back and its supposed to default to stdout, Im assuming the command line interface is interfering in some way but having problems finding how, and how to fix it. complication - compiling the application takes a little more time than is really usable to be developing with, my machine isnt great, 1.6Ghz, 512Ram, but I expect im not compiling it in the right way for development, i tried turning off optimisation with export CXXFLAGS='-g -O0 -Wall' export CFLAGS='-g -O0 -Wall' and trying to use ccache export CXX='ccache g++' the optimization does not seem to have affected much, and using the CXX flag gives me configure errors about not being able to find libraries that are installed. it takes me around 4 minutes to do a make / make install, im not really sure if this is an acceptable / usual time for recompiling. inkboard - after having to give up last time, im going to try finding the bug on my platform with inkboard that I mentioned in http://sourceforge.net/mailarchive/forum.php?thread_id=9660890&forum_id=360… when I left last time, I could invite another user to join an inkboard session, which worked perfectly, however I could not recieve connections, either from another instance of inkscape, or another user. I was wondering if anyone who is working with inkboard had anytime on or after sunday ( any time suitable, I will be making myself permanently free from then on) would be able to join me in the inkscape jabber room, as the problem is quite hard to debug with a single session, that doesnt work. Thanks Dale

3 3

article on Inkscape
by Alexandre Prokoudine 26 Mar '06

26 Mar '06

Hi, Both offline and online versions of popular russian computers magazin "Computerra" now feature a review of Inkscape written by Sergey Tokarev: http://www.computerra.ru/online/files/259519/ It looks like he did his best to present most actual and precise information, but unfortunately in some areas he failed (e.g. he stated that Inkscape's developers are already working on support for CMYK and CIE LAB colorspaces :)). However, Inkscape is rated as best vector graphics editor for Linux that, in case of merging codebase with Xara, will have all chances to be the best free vector graphics editor on all platforms. Btw, he also wrote that the same guy who introduced support for tablets is working on vector brushes now. Is that true? Alexandre

2 3

Xarification
by MenTaLguY 24 Mar '06

24 Mar '06

I've been thinking about our Cairoification plans today, and I think we might be much better off incorporating Xara's rendering engine instead. Two main reasons: - Xara provides a lot of stuff that we would otherwise have to write ourselves atop Cairo (e.g. gaussian blur) - Xara is considerably faster I don't want to simply borrow code from Xara, though -- ideally, I'd like to componentize the relevent portions of Xara so that both projects could use and jointly maintain them, as a sort of "common pot". Xara would benefit from this, since (in the long term) to fully implement the SVG specification we'd need to contribute additional capabilities which Xara Extreme could then exploit. To make the task managable, we'd want to approach this on a bottom-up basis: begin with the lowest-level components (e.g. the rasterizer), and work our way up to ultimately componentizing and incorporating the retained-mode graphics layer. The eventual goal would be to replace both livarot and NRArena with components shared with Xara. I'm going to start seriously looking into the technical aspects of this once I'm done with the current spate of layers work (probably post-0.44/0.45). -mental

3 7

Fwd: Re: [cairo] filters/image processing
by MenTaLguY 24 Mar '06

24 Mar '06

-------- Original Message -------- Subject: Re: [cairo] filters/image processing Date: Fri, 24 Mar 2006 08:31:17 -0800 From: Carl Worth <cworth@...573...> To: MenTaLguY <mental@...3...> On Fri, 24 Mar 2006 10:23:31 -0500, MenTaLguY wrote: > > We've been discussing "Cairoification" in Inkscape recently again, Sounds like fun! > If we adopt Cairo, should we expect to always have to implement > things like e.g. gaussian blur ourselves using intermediate image > surfaces, or will Cairo eventually provide image processing > operations like that in ways which can be accelerated in hardware? We already have an API for specifying that a given filter should be applied to a pattern, (cairo_pattern_set_filter), but the current selection of filters is fairly limited here. So I see two things that need to be done: 1) We need to add more filter types. Gaussian blur is an obvious first one that needs to be added, and something I've been giving some thought to lately. One trick with this is that it requires at least one parameter, so the current cairo_filter_t enum is not going to be sufficient. Oh, look, there is even a CAIRO_FILTER_GAUSSIAN there already. I'm not sure if that does anything useful or not yet. 2) We need to add support for filtering the implicit masks that cairo generates. This is the right place to put a filter for doing something like a drop shadow or for applying what Xara calls "feathering" to a filled shape. There's still a mask pattern involved here, but the user doesn't get to see it since it is implicitly created by cairo. So I think all we need here is a simple new API: cairo_public void cairo_set_mask_filter (cairo_t *cr, cairo_filter_t filter); (Modulo the same enum limitations we discussed above.) So this filter would be applied to the implicit masks created by cairo_stroke, _fill, _show_text, and _show_glyphs. It would not apply to cairo_mask where the user has a pointer to a pattern already and can call cairo_pattern_set_filter. As for what filter types to add, I think that "can be accelerated in hardware" is a pretty good criterion for inclusion in cairo. I think we've got Gaussian blur stuff just sitting there waiting in some existing backends already. As for a bunch of the other SVG filter types, I'm less confident that we'll see a lot of hardware support for them. I don't think it makes sense to complicate the cairo API for these if they're all going to end up in software anyway. (Though, if someone can convince programmable GPUs to do these, then there's a different question to be asked---so let me know if you know someone that has figured that out.) -Carl

1 0

Check up time
by Mike Hearn 24 Mar '06

24 Mar '06

Hey guys, I thought I'd pop in and see how you were getting on with autopackage. Are there any issues I need to be aware of? Are you happy campers? Are there any features you'd really like to have? I'm asking so I can get a better idea of where we should be going in future. Here is the current roadmap as relevant to Inkscape: * Get 1.2 released. This brings: * Better C++ support, that is, a build of the correct ABI will always be installed for the user. This resolves various obscure problems related to bugs in GCC and will allow for usage of gtkspell (finally!) * Better compression -> smaller Inkscape downloads * Better uninstall support, can now check for RPM/debs of Inkscape already being installed and (when safe) remove them. * New binreloc system. If it works out then this will make it totally transparent and the prefix location code could be dropped. * Further out, automatic online updates and maybe support for abstracting the Python unicode ABI so the python plugins support could be safely enabled. Any other features you guys want? thanks -mike

1 0

Educational contact(s)
by Jon A. Cruz 24 Mar '06

24 Mar '06

Hi, Just trying to track down what kind of interest there is for being point contact for .edu kind of people. So, who's interested? I can think of a few levels of involvement. There's working with people trying to develop open source based curriculum, and then also working with educators themselves. Also, both of those might be further broken down by various age groups, technical programs, etc. (I have various interests in this myself, but wanted to be sure to find out who all is also interested)

3 2

Libre Graphics Meeting - A Recap
by PLinnell 24 Mar '06

24 Mar '06

Hi all, For those who were not able to attend and/or also wondering about the quietness on IRC or the ML over the weekend, below is far from complete summary of the Libre Graphics Meeting held this past weekend in Lyon, France. First, this was the first ever meet of all the Scribus devels in the same place with the exception of Franz who could not attend. This meeting came about from the generous offer of Dave Neary from the GIMP team to bring in other graphics app developers such as Inkscape and it soon snowballed into a larger meet. Dave and the local Linux LUG group did a fantastic job organzing everything and a great time was had by all. One of the first presentations was by Øyvind Kolås aka pippin from the GIMP team demoing working code using GEGL,babl and gggl , the next generation of image libraries for the GIMP and other applications. Most impressive is the way Øyvind used oxide and bauxite, which are built from these components. For end users, GEGL, babl and gggl are a means to break the current limits in GIMP with 16bit and larger bit depths available, along with the ability to support other color spaces like CieLAB and CMYK. When can we see this in cvs ? The GIMP devs I spoke with said as soon as 2.4 is released. Next up was Marti Maria from littlecms and now HP. He gave an excellent presentation connecting how we see as humans with the nature of digital color in computing. Suffice to say, Scribus is as good as any at demonstrating littlecms' capabilities. Little known is indeed littlecms is used in the color management firmware in a number of high end HP specialty printers. We're hoping we can have that presentation on the docs site as a primer for beginning with color management. Gerald Friedland gave a demo of SIOX or Simple Interactive Object Extraction, which is in the current development version of GIMP. Simply put, SIOX is a clever new way of selecting objects in an image in a way which otherwise takes many manual steps. If you have a chance to get the latest GIMP beta, it is worth it just to see this in action. Who says open source folks do not innovate ? Cedric Gemy, better know for his new book on GIMP 2.2 in French 'Gimp 2 efficace' gave a demo of Tuxpaint in French. If you can read French, his new book is probably the most comprehensive book on GIMP 2.2.x Jon Phillips from Inkscape gave a talk on Create and how open source graphics applications are working to share things like brushes, color swatches and other image oriented media. Xara has been open sourced - a very bold move for a commercial graphics application company. Xara is an illustration application which has tremendous rendering speed on the canvas among other assets. One of the principal reasons for open sourcing the "crown jewels" as they put it, is to port Xara to Linux and MacOSX. It was obvious from the interaction with other teams and developers that not only the Xara folks were very much welcome there, but also they have taken the open source development model to heart. The Blender folks had a number of small talks and demos, but owning to other meetings none of us had much time to participate. One of the best parts of this meet was the time spent outside of the presentations to be able to meet and interact with other teams. Examples: Marti Maria from Littlecms gave us some hints on making Scribus more robust when handling corrupted icc profiles. We also had the chance to meet Carl Worth who developed Cairo. Sunday afternoon was a chance to meet with the Inkscape team and we looked over our mutual future plans. Jon Cruz from Inkscape showed off a drag and drop debugging tool, which should help us with Scribus to make drag and drop work easier with a more diverse group of applications. Similarly, we outlined how Scribus uses Ghostscript to import EPS and PS files with high fidelity. Adding this to Inkscape should be feasible without a major rewrite of Inkscape. The collaboration between Inkscape and Scribus teams has been good and should be even better in the future now we have met face to face. More to come later on. If there was one area lacking was simply time to meet and exchange with everyone there. We had less time to meet with some of the GIMP team than hoped, but we did have some informal one to one chats and we are much more attuned to future plans and wishlists. The GIMP team has been often unfairly criticized, in my opinion, for perceived shortcomings and unwillingness to address long standing feature requests. To the contrary, my sense is they are very well aware of these requests, but they are a small team indeed, not much larger than Scribus. That said, what I saw and heard gives me confidence that the GIMP will see major additions to its feature list in the future. The plans they outlines for future versions are ambitious. Other folks there included one of the Krita developers and folks from the Tango Project. One great surprise was to meet Nicholas Spalinger and Victor Gaultney, creator of the award winning typeface Gentium, which has been re-released under their newly written Open Font License. A few of us over a dinner had a chance to learn a great deal about Gentium, typography and future plans for enhancements and additions. The Open Font License has been carefully researched and written to maintain both openess and type creators desire for artistic integrity. This license avoids the kind of ambiguity discussed a few months ago on the list here about font embedding and the GPL. Summing up, the meet exceeded everyone's expectations I suspect. The atmosphere was fun, collegial and less a show and tell, than a chance for lots of face to exchanges. Attendance was roughly double the number anticipated. The simple fact this kind of event took place is a testament to the capabilities and maturity of open source graphics applications. Five years ago when Scribus was launched, one could hardly imagine an event like this. Already, it was decided amongst the teams to meet again next year and work is underway already on a venue. Discussion and plans will take place on the Create list on freedesktop. I'm sure I missed some important bits, but maybe we will see you there next year... Peter

3 2

Re: Live Effects Discussion
by Ricard Marxer Piñón 23 Mar '06

23 Mar '06

Hi there, I was at the LGM this weekend and one of the Inkscape developpers pointed me out to this list in order to discuss one of the concepts I talked him about: vector graphics shaders (as in 3D graphics shaders) It's an idea I have been thinking about and working on for a while. Today I had a look at the archives of the mailing-list and I just found the thread on Live Effects Discussion. Which seems to be exactly what I was looking for. I think my point of view is not that different from yours but maybe there are some new ideas. I basically try to recycle the work done on the 3D shader field to what could be the 2D shader field. >From my point of view we should define some perceptual data that should be accessible to a shader programmer and some principle drawing functions that he should be able to use. I haven't worked on it a lot yet but some of these ideas are: data accessible from a path: - point (given the % of the arclength) - tangent and / or normal (given the % of the arclength) - curvature (given the % of the arclength) (this could be given by the modulus of the tangent) (so it could be avoided) - color (given the % of the arclength) - stroke weigth (given the % of the arclength) I guess the only thing hard to do here is the reparametrization for the beziers or other curves in order to make this a function of the % of the arclength. But I think that this is something that would make this shaders powerful, since the shader shouldn't bother to know if the path is made of curves, beziers or whatever he only needs what's perceptually important about the vector graphic. What do you think? anyway here I post a little experiment with some experiments in vector graphics renderers that I made (feedback is greatly appreciated!!!!): http://www.caligraft.com -- ricard http://www.ricardmarxer.com

2 1

WEBFORM Professor switches OS X machines with Ubuntu machines
by Ryan B 23 Mar '06

23 Mar '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Ryan B email: giantmechanicalsquare@...400... submitted the following: This professor started teaching Inkscape instead of Illustrator and Scribus instead of Quark. I\'ve opened a discussion about it here: http://giantmechanicalsquare.blogspot.com/ and here is the article: http://business.newsforge.com/article.pl?sid=06/03/09/2238246&from=rss Thanks!

1 0

WEBFORM Professor switches OS X machines with Ubuntu machines
by Ryan B 23 Mar '06

23 Mar '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Ryan B email: giantmechanicalsquare@...400... submitted the following: This professor started teaching Inkscape instead of Illustrator and Scribus instead of Quark. I\'ve opened a discussion about it here: http://giantmechanicalsquare.blogspot.com/ and here is the article: http://giantmechanicalsquare.blogspot.com/ Thanks!

1 0

Font issues
by Jon A. Cruz 23 Mar '06

23 Mar '06

I was taking a peek at bug 1456620, and hit an interesting problem. There might be many other problems overlapping, but the name of one has issues right off the bat. One font name is 'Magnump.i.', but gets truncated at the first period. Does anyone have insight on this?

1 0

Live Effects Discussion
by Ted Gould 22 Mar '06

22 Mar '06

Hey all, Sorry, I've been effectively offline for over a week, so I'm catching up. I feel like I'm spamming the mailing lists :) Anyway, Aaron, I noticed that you made a branch for live effects. I've thought I little about this -- I was thinking perhaps we can all have a big friendly discussion about some of the ideas/features that would be required. (if there are any Xara developers on the list we'd love your comments on what worked and what didn't) If nothing else, so we don't overlap on any work. Here are some thoughts that I've had, feel free to destroy at will :) - Live Effects need to work with opening and saving a file, so they need to be stored somewhere. I was thinking we could add a "<inkscape:live-effect>" node in the defs section to define each live effect and read them when the file is opened. - Live Effects should be triggered when the original objects are edited, so we need to mark who those are. Probably by node ID. - If one of those nodes is deleted in the process of running the effect, then it should be stored in the live-effect node so that when re-running the effect it can be placed back on the canvas temporarily. - We need to keep track of the objects that are created by the effect, so we can delete them before rerunning the effect. I think this could also be accomplished through a node ID. - If any of the objects created by the live-effect are modified (ie moved) the live-effect is broken. I'm not sure if there should be some warning, or atleast a status bar message for this. I think it is simply to difficult to track the changes. - We need a way for the effects themselves to mark which nodes they created or deleted in their execution. I'm thinking that we can just add a inkscape namespace attribute for the nodes. When we reparse the file, we'll look for those. Then, in the inx file, we can mark whether an effect is "live effects aware" to keep the basic case simple. We may be able to accomplish this through comparing the before and after documents, but that seems likely to cause error (perhaps Mental has some ideas on this?) - I think that live effects should work for output and input extensions too. That way you could have an SVG document that you're working on constantly update the Postscript output copy that you want to have. Of course, this might be slow, but people will find it useful when they have 64-core computers :) - To make the performance reasonable, I think that we'll need to keep parsed copies of the scripts cached. I think I know how to do this with the python libraries. There is already the load/unload mechanism in the extensions to facilitate this. After I finish the extensions dialog, I'll start working on this. (unless someone really knows how to do it, I'd be happy to let someone who knows what they're doing go ahead :) Those are the things that I can think of right now. Comments and ideas are welcome! --Ted

5 10

NEW: better statusbar tips for multiple objects in selection
by bulia byak 22 Mar '06

22 Mar '06

For multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays 5 objects of type Group in layer LayerName. instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example: 5 objects of types Group, Path, Rectangle in layer LayerName. The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example: 5 objects of 4 types in layer LayerName. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 10

Objects not plugins
by Martin Owens 22 Mar '06

22 Mar '06

I was thinking of a way to manage my barcode plugin and was thinking that the way plugins currently run (i.e single process modifies document) is not how a barcode should be managed. it should be some kind of object plugin which allows you to modify the code and see the update in the bars, having the svg on the page will be a must, it would just have hooks so that if the plugin is there you can edit the object with some gui or what ever is required. Best Regards, Martin Owens -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

icon/swatch sizes
by bulia byak 22 Mar '06

22 Mar '06

Jon, Now I figured out why you're so reluctant to just make the swatches smaller as I proposed: because you used the GTK standard icon sizes for swatch sizes. I don't think this makes a lot of sense, honestly. A swatch is not an icon at all. However, I'll leave this up to you, but in any case I just want to reiterate the need for adding one or two smaller sizes that GTK does not have. You can even make them dependent on the existing sizes, for example by making them 75% and 50% of Gtk::ICON_SIZE_MENU. But we _really_ need them, both for icons and for swatches. The current "small" size of the swatches is NOT small by any stretch of the imagination. By the way, selecting the Huge size of the swatches in the bottom panel crashes Inkscape. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

round corners won't be resized on resizing a object
by Frank Wunderlich 21 Mar '06

21 Mar '06

Hi, i try to explain the behavior: i have 2 rects: 1 rect with round corners and 1 rect with normal corners inside the first one if i group this 2 shapes and try to make this group smaller, the shape is correctly resized (both rects), but not the corners of the round rect. the radius of the corners must be also adjusted... Greetings Frank

2 1

Clip path and mask UI patch - need guidance
by Joshua A. Andler 21 Mar '06

21 Mar '06

Knutux has made excellent progress with the clipPath/Mask UI patch (nice couple options in prefs to make it more robust too). However, there are two issues left that are related, but we couldn't figure out the best solution. Note that this is in comparison to both Xara & Illustrator as reference. 1) In Inkscape, currently you can not edit a clippath on canvas (presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem. 2) In Xara or Illustrator when you clip objects, they're "grouped" together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc. The more complicated of the two issues would be number 2. We kicked around a couple ideas, but neither seemed like the optimal solution so I figure I would ask for advice here. The ideas were having the clipping object in defs be a clone of a "normal" object on canvas. That original object can then be grouped and the clone/clippath would follow a move of the original, and it would theoretically also take care of the editing aspect too. And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas. Again, that object could then be grouped and would take care of the editing aspect too. To me, neither method seems clean and each would potentially introduce it's own set of issues. Bulia or Mental, do you have any suggestions? -Josh

5 19

Bug in the command line interface of Inkscape on Windows 32 platform ?
by Gilles Foucault 21 Mar '06

21 Mar '06

I run the Inkscape 0.43+devel, built Mar 20 2006 on Windows 32 platform I would like to export svg files via the command line interface of Inkscape : "C:\Program Files\Inkscape\inkscape.exe" --export-eps=out.eps in.svg But nothing happens, there is no error messages, and inkscape quit immediately. Could you help me with the command line usage in Win32 platform ? Thanks in advance, Best regards Gilles

2 1

LGM braindump
by Jon A. Cruz 21 Mar '06

21 Mar '06

Here's the first bit of braindump from LGM. (Please keep in mind that I typed this up while flying back to the States, and am not sure how jetlagged I was) -------------------------------- Overall, I think the whole get-together was an amazing success. Many different projects were represented, and a fair mix of end users and potential contributers were also in attendance. Although I would like to see more of the users and just curious there, enough were present to help give a good insight with fresh perspective. There were perhaps up to a couple hundred people in attendance, and it clearly seemed to be even a better turn out than Bryce or I had expected. We had four people with "Inkscape" on their badges, with a few extra people here and there like Cedric. The GIMP had a good presence, as did Scribus and even Xara. The atmosphere was one of the really good aspects of the whole meeting. Unlike many other conferences, this was not just a one-way dispersal of information. Though the presentations were similar, afterwards there was a lot of interaction between people with different groups, and even and users. Also, there seemed to not be any real conflicts or posturing, but rather a lot of genuine collaboration going on with win-win situations popping up all over. Probably the best illustration of this was with the SIOX presentation. Part of the presentation's purpose was to get the word out about the capabilities, and to try to spur more interest. That night one of the Blender guys got hooked, and by the next day had hacked together basic support for SIOX as a standard Blender effect. Each of the teams took advantage of the face-to-face time to have their own group meetings. For example, this was the first time that Craig had actually gotten to actually meet the other people on Scribus. But there was also a lot of communication with people of different groups, and most of the hitting dinner, etc, was completely inclusive. I know that some of the GIMP people expressed a little regret at not being able to get together with some of the non-GIMP people as much as they'd like, but this was only due to being able to get so much done in the various GIMP sit-downs going on. Even so, there was quite a lot that did get done, with various people in different groups each talking with others about all sorts of things. Xara had a booth outside the main amphitheater, and had three people showing what they've been doing. As you probably already know, they took the opportunity to release their source-code, and it seems like the delay 'till now was time well spent. I know that Carl Worth mentioned he downloaded it and not only did it build first try for him, but it actually ran too. The funny thing was that he didn't realize how much progress had been made since the initial demo, and that most of the tools are functional now. Their developers seemed like really good people, and very interested in the whole meeting and everything going on. I'd also met them on the bus from the airport the night before. So there was time spent talking with them on various Xara stuff, but then also a lot of time talking about all the other things going on, the stuff the other developers were talking about, and also some more questions on how best to fit in with the general open-source community. Charles from Xara made it down on Sunday, and after his presentation we had the opportunity to all sit down with him and discuss various Inkscape-Xara issues. The great news is that he honestly seems to "get it", and is working well to try to ensure the release of Xara has the best chance of being a win-win both for the business aspect and for the open-source community. By the end of things it was very clear that both Xara and Inkscape had their own focus, and each has their own reason for being around for quite some time. Probably the main issue for some will be the contributors agreement, however as everyone had time to drill down on things, and also others like Carl Worth from Cairo, it seemed to be a fair approach and my personal feeling is that it won't be a deal-killer for most. Speaking of Carl, he also had time to meet with Charles on his own, and they came away with quite a lot resolved, and a strong interest to see where things will go from here. Among other things, they were looking at various ways that Xara might get things to have Cairo to use their engine, so it will be *very* interesting to see how things progress in that area. One surprisingly inspiring presentation was Marti's talk on color management and littleCMS. Even though I'd been familiar with the concepts, and even had drilled down on littleCMS's API to figure out how to hook it into Inkscape, the talk suddenly made all the pieces fall into place. More importantly, it did so with several groups, and after the talk there was a lot started between us and Scribus in regards to managed color-flow, and we realized that together we actually almost at the point of having base things there and integrated. A lot of stuff they had been doing had gotten them close, and lot of the stuff I'd been doing had gotten us close. Then again, Marti confirmed that for basic support, only three functions of the littleCMS API are needed, so we might see that go in *very* soon. Additionally, we were able to use this to help hammer out with Scribus what direction they might want to take on SVG vs. EPS import, and whether things should be done in Inkscape or in Scribus, and to what degree. We probably ended up changing some minds and getting their focus back on enhancing SVG import, since we figured out some basic ways to support spot colors along with full ICC-profile targeted colors in SVG we will end up putting out. And, of course, Marti will be able to help advise us on the proper approach for a lot of the SVG/CSS color-profile details. One of the Inkscape-specific things that came up was someone from Slovenia being interested in animation support. We discussed quite a few things, including some general ideas of what Inkscape should and should not do in regards to UI and feature support for animation that Andy, Bryce, and I had just been tossing around the day before. This also leverages a bit more resources for enhancing the extensions mechanism, so look for new people to possibly show up soon. Speaking of extensions and plugins... there was a lot of general interest in this from many different people, with many different priorities. One of the more interesting exchanges on this was between myself and Craig from scribus. After some Scribus demos it had come up to me that what we were thinking of might be helpful for them also. Craig got really excited about the main idea of exposing a DOM for plugins, and some of the ways that they might go about doing that. Then we moved on to my ideas for abstracting UI for plugins by using XForms. He hadn't been aware of it before (and in fact was very light on XML background in general) but as I drilled in on more and more details he came to feel that it was a very good approach, and cold solve quite a few of the problems they are hitting up against right now, and even more in the future. He also mentioned this might be a concept to push over to the Xara guys (he'd been spending a fair bit of time with them also). One of the last things to go on was a CREATE BOF. It followed our Inkscape BOF, and ended up being very productive. We had lots of people from many projects, and got some good issues hammered out. Watch for more details on the CREATE mailing list, but a lot was about shared assets like palettes, brushes, etc., ways to share them, and how to make that work well (directories, daemons, things like font mangers, etc.) and not lagging. Another aspect was brought up from the drag-n-drop stuff I've been working on lately. Aside from knowing what to share, we also need to come up with how to put those things properly on the clipboard and for drag-n-drop. One point brought up was that it might be good to work details up and then leverage freedesktop.org to actually get MIME types registered. I'll follow up with more, like how Andy's demo went (great), Pippin's impressive stuff, and ReJon's great talk...

1 0

extension attributes documentation
by MenTaLguY 21 Mar '06

21 Mar '06

Hi all, In an effort to get the ball rolling for documenting Inkscape's extension attributes, I've populated a wiki entry with them here: http://wiki.inkscape.org/wiki/index.php/ExtensionAttributes I'd encourage volunteers to have a look and add documentation (just a brief description to start with) for any attributes that interest them. -mental

2 1

Clip path and mask UI patch - committed
by bulia byak 20 Mar '06

20 Mar '06

I have committed Andrius' patch and a couple of fixes of my own. So, clipping and masking are almost usable now. Use and abuse them, and report the results. So far the UI is limited to 4 command in the Object menu. Of course there are lots of issues, this is to be expected; note that while we appreciate your suggestions for how to make the UI better, for now my personal priority is to iron out all the basic behavior and rendering issues, so that at least the UI that we have works flawlessly. Several immediate issues are: - After you moved the clipped/masked object, unclipping/unmasking gives a wrong transform to the clippath/mask. - Mask display is buggy. If you don't see the masked object, try zooming in or out. - Upon unclpping/unmasking, the selection must hold the clipped object and the clippath/mask. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 2

Xara source released
by Joshua A. Andler 19 Mar '06

19 Mar '06

Subject line says it all... http://www.xaraxtreme.org/developers/sourcecode.html Thanks for the heads up John :) -Josh

6 6

Re: [Inkscape-devel] path effects: our plan
by Martin Owens 18 Mar '06

18 Mar '06

What could a perl developer do to help? I can also do graphics design but I dout that will be of help either. On Sat, 18 Mar 2006 19:09:08 -0400 , "bulia byak" <buliabyak@...400...> wrote: >For those interested, below is the implementation plan for the live >path effects that Aaron, Mental and I have developed. It's pretty >simple and powerful, we just need more volunteers to work on it. It's >currently in a branch in SVN. > >STAGE 1 is documented in a jabber chat from 2005-10-10. It is already >implemented in the branch and seems to work fine (last time I checked, >anyway). > >[19:01:50] <bbyak> well, i think the first thing you should do is >familiarize yourself with SPCurve and Bpath classes >[19:02:16] <bbyak> i guess for you they will be obvious, just another >array of lineto/moveto/curvetos >[19:04:00] <bbyak> then, write a simple spcurve->spcurve distortion function >[19:04:09] <bbyak> any kind of distortion, just to check >[19:04:52] <bbyak> make it a member of SPShape >[19:05:26] <ACSpike> so the goal is to distort nartbpath >[19:05:40] <bbyak> yes, as a start >[19:05:52] <ACSpike> by way of spcurve >[19:06:09] <ACSpike> and stick it in sp-shape >[19:06:15] <bbyak> yes >[19:06:16] <bbyak> then: >[19:06:47] <bbyak> declare a bunch of attribs: inkscape:original-d and >as many attrs as needed to express your distortion >[19:06:50] <ACSpike> I don't understand how I will test this function >[19:06:57] <bbyak> i'll explain that now >[19:07:15] <bbyak> attribs are declared in attributes.h/cpp i think >[19:07:33] <bbyak> then learn the way an SPObject reads attrs from the repr >[19:07:36] <bbyak> it's simple: >[19:07:52] <bbyak> for example sp-path.cpp >[19:08:21] <bbyak> sp_path_build calls sp_object_read_attr for all >attributes it knows >[19:08:33] <bbyak> thoese calls end up in sp_path_set >[19:09:01] <bbyak> which is where you do the necessary changes based >on the attribute string passed to you >[19:09:11] <bbyak> similar functions are in all other SPObjects >[19:09:34] <ACSpike> "necessary changes" = distort path >[19:09:40] <bbyak> we'll start by sp-path >[19:09:41] <bbyak> yes >[19:09:44] <bbyak> namely: >[19:10:05] <bbyak> you'll need to add another member, a boolean flag >in SPShape class >[19:10:20] <bbyak> which if set means that this shape is distorted >[19:10:42] <bbyak> and also you'll need one or more members for >storing the distortion params >[19:10:47] <ACSpike> oh, wife calls, brb. >[19:11:16] <bbyak> then in sp_path_build you add another >sp_object_read_attr for the distortion attribs >[19:11:43] <bbyak> and in sp_path_set, a new case for those attrs >[19:12:19] <bbyak> where you just parse and store the value in the >(SPShape *) path, i.e. this path recast to shape >[19:12:35] <bbyak> and set the "distorted" flag >[19:13:02] <bbyak> those new sp_object_read_attr must go before the >sp_object_read_attr for d= >[19:13:30] <bbyak> then you add a sp_object_read_attr for inkscape:original-d >[19:13:41] <bbyak> where you do the same as in case SP_ATTR_D: >[19:13:58] <bbyak> but insert a call to the distortion function >[19:14:12] <bbyak> after sp_svg_read_path(value); >[19:14:32] <bbyak> then you set that distorted curve as usual, >sp_shape_set_curve >[19:14:47] <bbyak> and then one last thing: >[19:15:41] <bbyak> the sp_object_read_attr for d= must go AFTER that >for original-d, and in it, if the distorted flag is set, you simply >skip reading the d and setting the curve >[19:15:46] --- mental has left >[19:16:08] <bbyak> so that the curve is obtained from orioginal-d with >distortion, when they are present >[19:16:47] <bbyak> that's all for stage 1, i think >[19:17:10] <bbyak> it should work if you manually add the attrs to a >path and it will show it distorted >[19:17:19] <bbyak> and will be generally very instructive to play with >[19:17:33] <bbyak> based on which, it will be more clear where to go next > >STAGE 2 is not done yet, I documented it in a message to Aaron: > >Overall, our Stage II goals are: > >1. make the system capable of handling several different effects, >with new ones easy to add > >2. make sure effects are correctly read in SPPath and in all >shapes > >3. make sure objects with effects are correctly transformed > >4. make sure paths with effects are correctly node-edited > >5. make sure shapes with effects are correctly handle-edited > >6. make sure objects with effects are correctly written and >rendered the same in Batik > >Most of these goals are surprisingly easy to achieve :) So don't >be frightened by the length of this email - it's just wordy >explanations. > >After all this works, we can move on to implementing the Path >Effects tool and handle-dragging UI for editing effects on >canvas... that will be Stage III. > >Now, the goals in detail: > >1. Rename inkscape:distorted into inkscape:path-effect. This >attribute would store a string identifier of the effect to apply, >or "none". If there's no such attribute, it's the same as >"none". In addition, register several attributes for distortion >parameters: > >inkscape:path-effect-param1 >inkscape:path-effect-param2 >inkscape:path-effect-param3 > >etc. The interpretation of these will of course depend on the >value of inkscape:path-effect. > >Then, move the reading of these attributes into SPShape, as they >will be used by all its subclasses (not only SPPath but also >shapes) in the same way. (That is, sp_object_read_attr(object, >"inkscape:path-effect") etc must also be in sp_shape_build.) >Store the values in appropriate new members of SPShape. Write a >generic function that takes SPCurve and a SPShape pointers and >distorts the SPCurve according to the values of the members of >SPShape. Store that function in sp-shape.cpp and declare in >sp-shape.h so that it can be used from outside. > >You can even code a couple useful effects at this stage :) > >2. For SPPath, it's all ready: it reads original-d, distorts it >and sets the curve from that. In shapes, it's even simpler. Take >SPStar for an example. In sp-star.cpp, find the line > > sp_shape_set_curve_insync (SP_SHAPE (star), c, TRUE); > >and just insert the call to the distortion function in sp-shape >before that, passing it the curve and SP_SHAPE (star). That is >all! Shapes have no need for original-d because their path is >generated from the shape parameters anyway. > >3. Transforming objects works like this. In "preserve" mode (see >Inkscape Prefs), a transform= attribute is added or edited on all >transformed objects. In the "optimize" mode (which is the >default), various types of objects variously try to embed the >transform, or a component thereof. If this is not possible, again, >transform= attribute is added. For example, for paths, >sp_path_transform can completely embed all of the transform into >its curve (i.e. into d=), by transforming each path point by that >matrix, so it returns identity and transform= is not set. For >rects, sp_rect_set_transform embeds only translation and scaling >components of the matrix; the remainder, if any, is written as >transform=. For stars and ellipses, no embedding is attempted at >all, so the whole transform is always written as transform=. > >Now, for paths, sp_path_transform currently transforms the >(SPShape*)path->curve, i.e. the distorted curve stored in base >SPShape instance. But we also need to transform the original path >by the same matrix too, so that it stays in sync. The easiest way >to do this, which will also have other benefits, is to store the >original path in SPPath as another SPCurve. That is, >(SPShape*)path->curve will be the distorted path, while >(SPPath*)path->original_curve will store the original path. > >You will thus need to add this member in sp-path.h and to add to >store the original SPCurve before distortion in that member in >sp_path_set, case SP_ATTR_ORIGINAL_D. (You may need to figure out >how to copy SPCurves and/or bpaths. Also don't forget to free the >SPCurve when destroying the path in sp_path_release.) Then look at >sp_path_transform: > > /* Transform the path */ > NRBPath dpath, spath; > spath.path = shape->curve->bpath; > nr_path_duplicate_transform(&dpath, &spath, xform); > SPCurve *curve = sp_curve_new_from_bpath(dpath.path); > if (curve) { > sp_shape_set_curve(shape, curve, TRUE); > sp_curve_unref(curve); > } > >And just do the same also for your original SPCurve stored in >SPPath. That is all. > >For shapes, you normally don't need to do anything at all. Those >that don't attempt any embedding and always use transform= >attribute are not affected at all. Those that do embed do it just >by adjusting their internal shape parameters and regenerating the >curve - for example sp_rect_set_transform calls >sp_rect_set_shape(rect). Provided you inserted a distortion call >into *_set_shape, you are all set. > >CAVEAT: rects are the only shape which currently uses <rect>, not ><path>. So you cannot apply shape effects to rects at all, until >this is changed. It's on my TODO for a long time, hope I will get >a round tuit soon. > >4. The Inkscape::NodePath::Path reads the path from SPCurve, but >after modifying it, it writes directly to the d= attribute. This >needs to be changed thus: (a) if the path is distorted, read the >SPCurve from SPPath, not from SPShape (i.e. the original, not the >distorted one), and (b) if the path is distorted, write the edited >path to inkscape:original-d= instead of d= (in >update_repr_internal). Setting inkscape:original-d will trigger >reading it and setting both original and distorted curves, the >latter in turn triggering a redisplay of the distorted path. So I >think this will be enough for nodepath to edit the source path, >with the nodes generally not lying on the visible distorted >path. Adding a helper display of the original path between >nodepath nodes can be left for later. > >5. I think here nothing at all is needed. The knotholder thing >reads and writes from the shape's internal parameters, and thus is >totally unaffected by the visible distorted path. > >6. Look at sp_path_write: it writes the d= attribute from >(SPShape*)path->curve, that is, from the distorted path. So the >"same display in Batik" part is already taken care of. We only >need to write the original-d so it stays in sync. Just repeat this >block: > > if ( shape->curve != NULL ) { > NArtBpath *abp = sp_curve_first_bpath(shape->curve); > if (abp) { > gchar *str = sp_svg_write_path(abp); > sp_repr_set_attr(repr, "d", str); > g_free(str); > } else { > sp_repr_set_attr(repr, "d", ""); > } > } else { > sp_repr_set_attr(repr, "d", NULL); > } > >but for path->original_curve and the inkscape:original-d >attribute, and you are all set. > >For shapes, again, nothing needs to be done. Except for rects, >shapes' _write methods (e.g. sp_star_write) create <path> element >and set its d= from the SPShape curve. This is just what we need. > >That is all - as you see, it's all quite simple, logical and fits >neatly. There will be gotchas of course, but overall the system >looks quite straightforward and robust. I'm really excited by >this. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

path effects: our plan
by bulia byak 18 Mar '06

18 Mar '06

For those interested, below is the implementation plan for the live path effects that Aaron, Mental and I have developed. It's pretty simple and powerful, we just need more volunteers to work on it. It's currently in a branch in SVN. STAGE 1 is documented in a jabber chat from 2005-10-10. It is already implemented in the branch and seems to work fine (last time I checked, anyway). [19:01:50] <bbyak> well, i think the first thing you should do is familiarize yourself with SPCurve and Bpath classes [19:02:16] <bbyak> i guess for you they will be obvious, just another array of lineto/moveto/curvetos [19:04:00] <bbyak> then, write a simple spcurve->spcurve distortion function [19:04:09] <bbyak> any kind of distortion, just to check [19:04:52] <bbyak> make it a member of SPShape [19:05:26] <ACSpike> so the goal is to distort nartbpath [19:05:40] <bbyak> yes, as a start [19:05:52] <ACSpike> by way of spcurve [19:06:09] <ACSpike> and stick it in sp-shape [19:06:15] <bbyak> yes [19:06:16] <bbyak> then: [19:06:47] <bbyak> declare a bunch of attribs: inkscape:original-d and as many attrs as needed to express your distortion [19:06:50] <ACSpike> I don't understand how I will test this function [19:06:57] <bbyak> i'll explain that now [19:07:15] <bbyak> attribs are declared in attributes.h/cpp i think [19:07:33] <bbyak> then learn the way an SPObject reads attrs from the repr [19:07:36] <bbyak> it's simple: [19:07:52] <bbyak> for example sp-path.cpp [19:08:21] <bbyak> sp_path_build calls sp_object_read_attr for all attributes it knows [19:08:33] <bbyak> thoese calls end up in sp_path_set [19:09:01] <bbyak> which is where you do the necessary changes based on the attribute string passed to you [19:09:11] <bbyak> similar functions are in all other SPObjects [19:09:34] <ACSpike> "necessary changes" = distort path [19:09:40] <bbyak> we'll start by sp-path [19:09:41] <bbyak> yes [19:09:44] <bbyak> namely: [19:10:05] <bbyak> you'll need to add another member, a boolean flag in SPShape class [19:10:20] <bbyak> which if set means that this shape is distorted [19:10:42] <bbyak> and also you'll need one or more members for storing the distortion params [19:10:47] <ACSpike> oh, wife calls, brb. [19:11:16] <bbyak> then in sp_path_build you add another sp_object_read_attr for the distortion attribs [19:11:43] <bbyak> and in sp_path_set, a new case for those attrs [19:12:19] <bbyak> where you just parse and store the value in the (SPShape *) path, i.e. this path recast to shape [19:12:35] <bbyak> and set the "distorted" flag [19:13:02] <bbyak> those new sp_object_read_attr must go before the sp_object_read_attr for d= [19:13:30] <bbyak> then you add a sp_object_read_attr for inkscape:original-d [19:13:41] <bbyak> where you do the same as in case SP_ATTR_D: [19:13:58] <bbyak> but insert a call to the distortion function [19:14:12] <bbyak> after sp_svg_read_path(value); [19:14:32] <bbyak> then you set that distorted curve as usual, sp_shape_set_curve [19:14:47] <bbyak> and then one last thing: [19:15:41] <bbyak> the sp_object_read_attr for d= must go AFTER that for original-d, and in it, if the distorted flag is set, you simply skip reading the d and setting the curve [19:15:46] --- mental has left [19:16:08] <bbyak> so that the curve is obtained from orioginal-d with distortion, when they are present [19:16:47] <bbyak> that's all for stage 1, i think [19:17:10] <bbyak> it should work if you manually add the attrs to a path and it will show it distorted [19:17:19] <bbyak> and will be generally very instructive to play with [19:17:33] <bbyak> based on which, it will be more clear where to go next STAGE 2 is not done yet, I documented it in a message to Aaron: Overall, our Stage II goals are: 1. make the system capable of handling several different effects, with new ones easy to add 2. make sure effects are correctly read in SPPath and in all shapes 3. make sure objects with effects are correctly transformed 4. make sure paths with effects are correctly node-edited 5. make sure shapes with effects are correctly handle-edited 6. make sure objects with effects are correctly written and rendered the same in Batik Most of these goals are surprisingly easy to achieve :) So don't be frightened by the length of this email - it's just wordy explanations. After all this works, we can move on to implementing the Path Effects tool and handle-dragging UI for editing effects on canvas... that will be Stage III. Now, the goals in detail: 1. Rename inkscape:distorted into inkscape:path-effect. This attribute would store a string identifier of the effect to apply, or "none". If there's no such attribute, it's the same as "none". In addition, register several attributes for distortion parameters: inkscape:path-effect-param1 inkscape:path-effect-param2 inkscape:path-effect-param3 etc. The interpretation of these will of course depend on the value of inkscape:path-effect. Then, move the reading of these attributes into SPShape, as they will be used by all its subclasses (not only SPPath but also shapes) in the same way. (That is, sp_object_read_attr(object, "inkscape:path-effect") etc must also be in sp_shape_build.) Store the values in appropriate new members of SPShape. Write a generic function that takes SPCurve and a SPShape pointers and distorts the SPCurve according to the values of the members of SPShape. Store that function in sp-shape.cpp and declare in sp-shape.h so that it can be used from outside. You can even code a couple useful effects at this stage :) 2. For SPPath, it's all ready: it reads original-d, distorts it and sets the curve from that. In shapes, it's even simpler. Take SPStar for an example. In sp-star.cpp, find the line sp_shape_set_curve_insync (SP_SHAPE (star), c, TRUE); and just insert the call to the distortion function in sp-shape before that, passing it the curve and SP_SHAPE (star). That is all! Shapes have no need for original-d because their path is generated from the shape parameters anyway. 3. Transforming objects works like this. In "preserve" mode (see Inkscape Prefs), a transform= attribute is added or edited on all transformed objects. In the "optimize" mode (which is the default), various types of objects variously try to embed the transform, or a component thereof. If this is not possible, again, transform= attribute is added. For example, for paths, sp_path_transform can completely embed all of the transform into its curve (i.e. into d=), by transforming each path point by that matrix, so it returns identity and transform= is not set. For rects, sp_rect_set_transform embeds only translation and scaling components of the matrix; the remainder, if any, is written as transform=. For stars and ellipses, no embedding is attempted at all, so the whole transform is always written as transform=. Now, for paths, sp_path_transform currently transforms the (SPShape*)path->curve, i.e. the distorted curve stored in base SPShape instance. But we also need to transform the original path by the same matrix too, so that it stays in sync. The easiest way to do this, which will also have other benefits, is to store the original path in SPPath as another SPCurve. That is, (SPShape*)path->curve will be the distorted path, while (SPPath*)path->original_curve will store the original path. You will thus need to add this member in sp-path.h and to add to store the original SPCurve before distortion in that member in sp_path_set, case SP_ATTR_ORIGINAL_D. (You may need to figure out how to copy SPCurves and/or bpaths. Also don't forget to free the SPCurve when destroying the path in sp_path_release.) Then look at sp_path_transform: /* Transform the path */ NRBPath dpath, spath; spath.path = shape->curve->bpath; nr_path_duplicate_transform(&dpath, &spath, xform); SPCurve *curve = sp_curve_new_from_bpath(dpath.path); if (curve) { sp_shape_set_curve(shape, curve, TRUE); sp_curve_unref(curve); } And just do the same also for your original SPCurve stored in SPPath. That is all. For shapes, you normally don't need to do anything at all. Those that don't attempt any embedding and always use transform= attribute are not affected at all. Those that do embed do it just by adjusting their internal shape parameters and regenerating the curve - for example sp_rect_set_transform calls sp_rect_set_shape(rect). Provided you inserted a distortion call into *_set_shape, you are all set. CAVEAT: rects are the only shape which currently uses <rect>, not <path>. So you cannot apply shape effects to rects at all, until this is changed. It's on my TODO for a long time, hope I will get a round tuit soon. 4. The Inkscape::NodePath::Path reads the path from SPCurve, but after modifying it, it writes directly to the d= attribute. This needs to be changed thus: (a) if the path is distorted, read the SPCurve from SPPath, not from SPShape (i.e. the original, not the distorted one), and (b) if the path is distorted, write the edited path to inkscape:original-d= instead of d= (in update_repr_internal). Setting inkscape:original-d will trigger reading it and setting both original and distorted curves, the latter in turn triggering a redisplay of the distorted path. So I think this will be enough for nodepath to edit the source path, with the nodes generally not lying on the visible distorted path. Adding a helper display of the original path between nodepath nodes can be left for later. 5. I think here nothing at all is needed. The knotholder thing reads and writes from the shape's internal parameters, and thus is totally unaffected by the visible distorted path. 6. Look at sp_path_write: it writes the d= attribute from (SPShape*)path->curve, that is, from the distorted path. So the "same display in Batik" part is already taken care of. We only need to write the original-d so it stays in sync. Just repeat this block: if ( shape->curve != NULL ) { NArtBpath *abp = sp_curve_first_bpath(shape->curve); if (abp) { gchar *str = sp_svg_write_path(abp); sp_repr_set_attr(repr, "d", str); g_free(str); } else { sp_repr_set_attr(repr, "d", ""); } } else { sp_repr_set_attr(repr, "d", NULL); } but for path->original_curve and the inkscape:original-d attribute, and you are all set. For shapes, again, nothing needs to be done. Except for rects, shapes' _write methods (e.g. sp_star_write) create <path> element and set its d= from the SPShape curve. This is just what we need. That is all - as you see, it's all quite simple, logical and fits neatly. There will be gotchas of course, but overall the system looks quite straightforward and robust. I'm really excited by this. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by Martin Owens 18 Mar '06

18 Mar '06

Should you not want to have a permanent clipping option or ability so that the path is altered? Oh and could we please have the ability to clip a group of objects, I want to cut an object at a boundary line perhaps the page boundary I don't want to have to ungroup every object and clip each one, very annoying and causes alot of problems with very complex objects. On Sat, 18 Mar 2006 18:25:15 -0400 , "bulia byak" <buliabyak@...400...> wrote: >On 3/18/06, Andrius Ramanauskas <knutux@...400...> wrote: >> For the first case, I guess the simple approach would be to have something like: >> <defs> >> <clipPath id="clipPath123"> >> <use href="urlclipPathdefs> >> <g clip-path="#clipPath123"> >> ... the clipping object(s) ... >> ... the clipped objects ... >> </g> > >We might try that. But we'll need to code various special cases, such >as deleting the clippath and unclipping its users when the source of >the clone is deleted. Also various clone move compensations need to be >disabled for this case. > >However I have doubts about whether this will be convenient enough. I >think in a lot of cases, when I clip an object I do want the clippath >to disappear and not be in my way. If it stays visible, I will be >tempted to just delete it, which will remove or incapacitate the clip >- not the result I expected! I will therefore have to make it >invisible by removing fill and stroke, which is very inelegant and >brings lots of usability issues of its own. > >Also this approach, as well as Mental's, requires that clipped objects >are always grouped together with their clippers, which adds a layer of >indirection, its own special cases to guard against (what if I just >decide to ungroup it?), and usability issues. > >For these reasons, I feel more predisposed towards the other approach, >where the clipped object is just removed into defs and no grouping or >cloning is needed. It's much cleaner conceptually. Yes, it prevents >direct editing of the clippath unless you temporarily unclip it. But >enabling the node tool to edit the clippath without unclipping is >doable and relatively easy, and in any case this special-casing will >only affect the node tool and nothing else. So, I propose to do this >simple approach first, and then only if it proves inadequate, to look >into more complex solutions with cloning etc. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by bulia byak 18 Mar '06

18 Mar '06

On 3/18/06, Andrius Ramanauskas <knutux@...400...> wrote: > For the first case, I guess the simple approach would be to have something like: > <defs> > <clipPath id="clipPath123"> > <use href="url to the clipping object(s)> > </clipPath> > </defs> > <g clip-path="#clipPath123"> > ... the clipping object(s) ... > ... the clipped objects ... > </g> We might try that. But we'll need to code various special cases, such as deleting the clippath and unclipping its users when the source of the clone is deleted. Also various clone move compensations need to be disabled for this case. However I have doubts about whether this will be convenient enough. I think in a lot of cases, when I clip an object I do want the clippath to disappear and not be in my way. If it stays visible, I will be tempted to just delete it, which will remove or incapacitate the clip - not the result I expected! I will therefore have to make it invisible by removing fill and stroke, which is very inelegant and brings lots of usability issues of its own. Also this approach, as well as Mental's, requires that clipped objects are always grouped together with their clippers, which adds a layer of indirection, its own special cases to guard against (what if I just decide to ungroup it?), and usability issues. For these reasons, I feel more predisposed towards the other approach, where the clipped object is just removed into defs and no grouping or cloning is needed. It's much cleaner conceptually. Yes, it prevents direct editing of the clippath unless you temporarily unclip it. But enabling the node tool to edit the clippath without unclipping is doable and relatively easy, and in any case this special-casing will only affect the node tool and nothing else. So, I propose to do this simple approach first, and then only if it proves inadequate, to look into more complex solutions with cloning etc. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

We need SIOX!!!!
by unknown＠example.com 18 Mar '06

18 Mar '06

The SIOX demo was *very* interesting. http://www.siox.org/ It does fast foreground extraction from images based on color. Last night someone went and grabbed the source and hacked up initial support for this in Blender. We're already behind. :-) It looks like we might be able to gain some interesting benefits hooking that into tracing - perhaps potrace itself, or perhaps something additional. Oh, and it's also already in as a tool in the developer version of The GIMP.

1 0

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by Andrius Ramanauskas 18 Mar '06

18 Mar '06

In my understandign there are two different cases: 1. mask/clippath object is leaved in the document 2. clipping object is moved into defs, but removed from document (no longer visible) For the first case, I guess the simple approach would be to have something like: <defs> <clipPath id="clipPath123"> <use href="url to the clipping object(s)> </clipPath> </defs> <g clip-path="#clipPath123"> ... the clipping object(s) ... ... the clipped objects ... </g> This leaves clippath in defs and allows edditing of a mask directly by editing a clipping object. This can also be implemented without a group and it should still work But for second scenario (object is removed) editing is more complicated, but we can still have this grouping and on entering (dbl-clicking) a group, clipping objects can be copied to a group, so they can be edited, after leaving a group copied object properties goes to a clipPath element and copied object is restored. Or a new manu item "Edit clip path" can be added, which will do basicly the same, but group will not be required, so this can also be used for masks created outside of Inkscape. Andrius On 3/18/06, bulia byak <buliabyak@...400...> wrote: > On 3/17/06, MenTaLguY <mental@...3...> wrote: > > If the clipPath and the clipped objects share a parent group, then you get "compensation" for free. > > Not entirely for free, and in any case no more free than when they are > elsewhere. Here's the scoop: The spec says that any transform= on > clipped object affects the clippath as well, and we implement this. > Therefore, for objects that always get transform= such as groups or > ellipses, you get transforming the clippath truly for free, and this > does not depend on where is the clippath - in defs or in group. It > works the same both ways. However for objects that completely or > partially embed the transformation, we will need to either (a) disable > that and write transform= if there's a clippath or mask, or (b) add > transform= to the clippath/mask corresponding to the embedded portion > of the transform. Both approaches are relatively easy to do. Your > approach (always putting clippend object(s) in group with clippath > there too) is just another way of doing the (a) - you just disable > embedding transforms into the object by virtue of its always being the > group. However for that you have to pay the price of an unavoidable > extra level of <g> and the dangers associated with > resources-not-in-defs which our legacy code is known to mishandle > often. > > > Unlike gradients, I don't see a strong case for re-using clipPaths either (another usual motivation for putting things in <defs>). > > Sure, I don't want them to be shared either. It's not about sharing or > not sharing. > > > Keeping the clipPath with the clipped objects seems to be the simplest approach... > > I don't think so, see above. Besides, if you rely on your clippaths > always inside groups and thus do not implement (a) or (b) above, you > will damage your ability to gracefully handle non-Inkscape SVGs. > > -- > bulia byak > Inkscape. Draw Freely. > http://www.inkscape.org > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

[Fwd: Inkscape und Xara Xtreme]
by Adib Taraben 18 Mar '06

18 Mar '06

Hello, I received an e-mail from the german computer magazin asking what is the progress with the XARA involvement and what is the impact/influence into Inkscape. And also he want to know if this is going into a competition between the two products. He is refering the LIBRE-Meeting. Was there someone? I did not really red all the e-mail's abaout that. So can someone summarize this? Thanks, Adib. -------- Original-Nachricht -------- Betreff: Inkscape und Xara Xtreme Datum: Fri, 17 Mar 2006 13:44:28 +0100 Von: Peter König <pek@...883...> An: Adib Taraben <taraben.a@...50...> Hallo, leider nur aus der Ferne verfolge ich das Libre Graphics Meeting in Lyon. Besonders interessiert mich die Entwicklung in Sachen Open Source Xara Xtreme und Inkscape. Nachdem Xara im vergangenen Jahr angekündigt hatte, den Code seiner Software für Linux und Mac freizugeben, kursierte meines Wissens nach die Vorstellung, dass die Communities von Xara und Inkscape eng zusammenarbeiten würden bzw. es eventuell sogar eine Fusion der Projekte geben würde. Mich würde interessieren, ob sich die Lage inzwischen verändert hat, und wie das Xara-Projekt bei Ihnen in der Inkscape-Community mittlerweile gesehen wird. Denn von Xaras Webseiten entnehme ich, dass die Firma großes vorhat: "Xara Xtreme on Linux will not only bring a leading-edge graphic tool to the platform, but with community assistance, has the potential to become the world's most powerful, easiest-to-use and simply the world's best graphics program." Auf den Veranstaltungsseiten des Libre Graphics Meeting heißt es noch etwas direkter: "Xara's goal is simple: With the help of the open-source developer community they hope to create the fastest, most powerful, easiest to use, general purpose graphics tool for Linux (and Mac)." Und das läuft doch in der Konsequenz auf eine direkte Konkurrenz zu Inkscape heraus, oder irre ich mich da? Über eine Einschätzung oder ein paar Hintergrundinformationen von Ihrer Seite würde ich mich freuen -- sie würden es mir ermöglichen, die Ankündigungen von Xara auf dem Libre Graphics Meeting etwas differenzierter in unserem Newsticker darzustellen. Können Sie mir da - zeitnah - weiterhelfen? Mit Dank und freundlichen Grüßen, Peter König c't - Magazin für Computertechnik http://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH & Co.KG phone: 0511-5352-763 Helstorfer Str. 7 fax: 0511-5352-417 D-30625 Hannover, Germany eMail: pek@...883...

4 4