- Inkscape Devel - Inkscape Mailman

win98 support?
by lode leroy 18 Oct '05

18 Oct '05

Does anyone know if installing "Microsoft Layer for Unicode on Windows 95, 98, and Me Systems" on a win98 pc makes it possible to use cairo and thus inkscape / gimp / ...? http://www.microsoft.com/downloads/details.aspx?FamilyID=73ba7bd7-ed06-4f0d…

4 4

Articifical Limits (was Re: Sanity checking files on open)
by Ben Fowler 17 Oct '05

17 Oct '05

On 10/16/05, jiho <jo.irisson@...400...> wrote: > On 15 oct. 05, at 20:23, Ben Fowler wrote: > > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> On 15 oct. 05, at 18:34, Ben Fowler wrote: > >>> On 10/15/05, bulia byak <buliabyak@...400...> wrote: > >>>> On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote: > > > Having said that, perhaps Inkscape compiled in debug mode should > > have some of these artifical limits, (just as we have assertion > > statements). It will help identify to developers just where the > > shoe pinches, but users do not need to handle this. > > If they could, why not? Once you pointed me to the problem the fix > was really easy. Having that build into inkscape would have avoided > you all my long emails ;-) Not really, the root cause of this e-mail conversation (maybe lengthy, but not unnecessary) is the fact that Inkscape did not gracefully handle a specific error condition. This wasn't deliberate. It was just that the precise combination of circumstances that brings it about had not occurred to any of the developers who had worked on that part of the code. Bringing this up up was very necessary. This kind of bug report is one of the most important raw materials needed for the production of good software. Now, release versions should not have 'articifical limits' or training wheels. Th assumption is that if the Application is in an unexpected state with a developer, it is because he or she got something wrong, and we want the earliest indication of when this is happening. If the application is in an unexpected state with a user, then the user is probably 'in the right' and merely doing something that hadn't been tested or anticipated. In the present case, if a scale factor exceeds 1 million, we are going to guess that on a developer's machine there is something wrong the code, but on a user's machine that he or she is simply working with large objects. Ben

5 5

[joxeankoret_at_yahoo_dot_es: Bug#330894: inkscape: Arbitrary code execution when opening a malicious file]
by Wolfram Quester 17 Oct '05

17 Oct '05

Hi allotogether, I just received a message at debian's BTS [1] which reports a possible security flaw in inkscape. It is surely a DOS since here on my PowerBook inkscape simply crashes saying wolfi@...453...:/tmp $ inkscape poc.svg Emergency save activated! Segmentation fault (core dumped) I attach the backtrace, which shows that inkscape is rather irritated: Core was generated by `aaaaaaaaaaaaaaaaa'. BTW, vim's syntax highlighter has certain toubles when editing this file, too. Thanks, Wolfi [1] http://bugs.debian.org/330894 ----- Forwarded message from Joxean Koret <joxeankoret_at_yahoo_dot_es> ----- Subject: Bug#330894: inkscape: Arbitrary code execution when opening a malicious file Reply-To: Joxean Koret <joxeankoret_at_yahoo_dot_es>, 330894@...499... Resent-From: Joxean Koret <joxeankoret_at_yahoo_dot_es> Resent-To: debian-bugs-dist@...501... Resent-Cc: Wolfram Quester <wolfi@...111...> Resent-Date: Fri, 30 Sep 2005 10:48:06 UTC Resent-Message-ID: <handler.330894.B.11280765119494@...499...> X-Debian-PR-Message: report 330894 X-Debian-PR-Package: inkscape X-Debian-PR-Keywords: From: Joxean Koret <joxeankoret_at_yahoo_dot_es> To: submit@...499... Date: Fri, 30 Sep 2005 12:51:04 +0200 Resent-Sender: Debian BTS <debbugs@...499...> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at honk.physik.uni-konstanz.de X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at honk.physik.uni-konstanz.de Subject: inkscape: Arbitrary code execution opening a file Package: inkscape Version: 0.41-4.99.sarge0 Severity: grave Justification: user security hole Inkscape is vulnerable to, almost, one buffer overflow that may allow arbitrary code execution. I contacted the Inkscape team but, at the moment, there is no patch for the issue. Attached goes a Proof Of Concept. NOTE: I think the problem may not be exploitable because you need to write a shellcode using only valid XML characters. Regards, Joxean Koret -- System Information: [...snip...] ----- End forwarded message -----

5 7

Re: [Inkscape-devel] Static RPM isn't Very Static
by DJA 17 Oct '05

17 Oct '05

Jean-Francois Lemaire wrote: > On Friday 14 October 2005 20:00, you wrote: > >>Jean-Francois Lemaire wrote: >> >>>I've just uploaded inkscape-0.42.2-0.static.i686.rpm to >>>SourceForge. Would you please check it out and report back? > > >>That fixed that problem, but...umm...here's a new one: >> >>[dallen@...1044... miscellaneous]$ inkscape >>inkscape: error while loading shared libraries: >>libpangocairo-1.0.so.0: cannot open shared object file: No such file >>or directory > > > libpangocairo is not statically linked on purpose. It's not unreasonable to expect the user to install some support libraries or tweak the run-time environment. However, if there are libraries required by the package, then it shouldn't be called a static package. > Aren't you able to install it on your system? Isn't it part of your distribution? I will look for that library. No, Cairo[1] is not part of the Fedora Core distribution, and this is a full ("Install everything") install. Neither is Inkscape, BTW. > We can't link statically every library needed by Inkscape. Fair enough. But then you shouldn't call that package static. > We have to make reasonable choices. Now, maybe libpangocairo should be added. Your choice. Just let the users know what is required to install the package or binary. If there are library or environment requirements for the Inkscape package, then those requirements should be listed on the download (or some conspicuous) page on the Web site, preferably with links pointing to wherever contemporary versions of those files/packages can be found. [1] I'm assuming 'Cairo' is the library name - I'm not familiar with it. No doubt you will have many users new to your app who are not up to speed on all the latest graphics libraries and support packages. All the more reason to spell out exactly what one needs to experience your app. -- Best Regards, ~DJA.

5 9

Re: Sanity checking files on open
by Ben Fowler 17 Oct '05

17 Oct '05

On 10/16/05, jiho <jo.irisson@...400...> wrote: > On 15 oct. 05, at 20:23, Ben Fowler wrote: > > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> On 15 oct. 05, at 18:34, Ben Fowler wrote: > >>> On 10/15/05, bulia byak <buliabyak@...400...> wrote: > >>>> On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote: > >> > OK with this: > If the file cannot be read if not corrected (=definition of error > for me) the fix should be automatic. > . if the file can be read (as it was for mine: the syntax was OK) but > contains some unusual values, the correction should not be made > automatically. but, in addition of issuing a warning, I think it > would be great if a fix was proposed. then the user can choose to > accept it (in most cases, yes) or to reject it (in this case user > probably know what he is doing and will reject it if necessary). > In addition to that... This is RFE [ 1119025 ] repair broken xml on load http://sourceforge.net/tracker/index.php?func=detail&aid=1119025&group_id=9… You might want to: * Add a comment there * Put it onto the roadmap * Add a wiki page to record progress Note that this may not be 'interesting' to an open source developer, and you may find that progress is sporadic, but if a start is made so that there is a place to add code for handling new sorts of errors, I expect that eventually this will get done. Ben

1 0

Re: Sanity checking files on open
by Ben Fowler 17 Oct '05

17 Oct '05

On 10/16/05, jiho <jo.irisson@...400...> wrote: > On 15 oct. 05, at 20:23, Ben Fowler wrote: > > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> On 15 oct. 05, at 18:34, Ben Fowler wrote: > >>> On 10/15/05, bulia byak <buliabyak@...400...> wrote: > >>>> On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote: > > - that some criteria are chosen in the sanity check and some fixes > are proposed when these criteria are met. As I mentioned before, I am > thinking about scaling objects that have insane bbox or that are > really big/small in comparison with the rest of the drawing. Or even > scaling the whole drawing if it is huge (as it was the case > previously with somebody who couldn't zoom out far enough to see the > whole drawing if I remember well) or tiny (as it is the case with the > other file I have). And having the possibility to accept or reject > any change individually make this feature not too intrusive. Once > again I don't know if all this even means something. Just correct me > if this is stupid. If it is necessary to 'fix up' objects individually, then you might want to select them one at a time and check the appearance and/or the properties. Ben

1 0

Fix Error handling first (wasRe: Sanity checking files on open)
by Ben Fowler 17 Oct '05

17 Oct '05

On 10/16/05, jiho <jo.irisson@...400...> wrote: > On 15 oct. 05, at 20:23, Ben Fowler wrote: > > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> On 15 oct. 05, at 18:34, Ben Fowler wrote: > >>> On 10/15/05, bulia byak <buliabyak@...400...> wrote: > >>>> On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote: > > [ snip ] > > To help this I can provide plenty of buggy files to play with ;-) > Scilab and other math plotting software apparently produce eps files > that pstoedit/inkscape do not like at all. Yes, we should have a corpus of files that cause problems for Inkscape (and/or sister programs whether valid or invalid. You might want to take this to the testers list Ben

1 0

Sanity checking files on open (was Re: [Inkscape-devel] zooming bug)
by Ben Fowler 17 Oct '05

17 Oct '05

On 10/15/05, jiho <jo.irisson@...400...> wrote: I am assuming that you meant to post to the list. > On 15 oct. 05, at 18:34, Ben Fowler wrote: > > On 10/15/05, bulia byak <buliabyak@...400...> wrote: > >> On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote: > > Assuming that in general we cannot expect Inkscape to determine > > whether or not a bounding box is insane, I was thinking that we > > might exclude some items from the bbox estimation to make the > > behaviour less surprising. > > I think some could be determined at least. For example, if only one > object is insane this could be found: if all transform look like > 1,0,1,0,0,1 and one is 10e15,0, 10e15... it is very probably wrong. > This could be detected and corrected at openning time and if the user > wants to see the unmodified file anyway he could just cancel the > correction. This would allow users with specific needs to edit their > files anyway. Could I make sure that we are distinguishing at leaast two cases here? The first is when a file is in error, and the fix is forced. If possible, we should always do this. (I suspect that where this is not possible, we open in the XML editor, if even this is not possible, we show a helpful diagnostic - but this is not the current topic). The second is when the file is not in error, but contains some suspicious values, and we want to warn. This happens in Freehand when a bitmap cannot be found or a requested font is missing. Now I think that it is often a mistake for an application to put up a modal dialog and demand that the user pay attention. In some cases. the time to warn is just before saving, or to require that the file is saved under a new name, to ensure that the user does not lose data. If the application feels that a file has 'warnings' (non fatal errors or failure of sanity checking) there should be an annunciator in a margin that one can click on to see details. Additionally or alternatively there should be a menu item: Verify File that would check the file with great rigour. Think of it as Norton's Disk Doctor for SVG. (We have a menu item: Vacuum Defs that is cognate to 'Speed Disk'). The problem with performing rigorous sanity checking at every start-up (file read), particularly by default is that we cannot as developers really know how long this will take, but we can be pretty sure that 9999 times out of 10 000 it is not necessary: It is a little user hostile. O.K. We can do some statistical analysis of a) The diagonals, b) The x position and c) the y position of every bounding box, and by looking at twice the standard deviation determine if the out-liers were lying out too far. The trouble with this approach is that it is the 'fool proof' approach, just making as a system proof against a fool only works until a better one comes along, this appraoch will be defeated in the field by the great variety of insane files. Whether we like it or not, people are going to have to be opening SVG files with text editor (or the built-in XML editor) to fix problems with insane files for some time to come. It is madness to pretend otherwise. Having said that, perhaps Inkscape compiled in debug mode should have some of these artifical limits, (just as we have assertion statements). It will help identify to developers just where the shoe pinches, but users do not need to handle this. Ben

2 2

Inkscape Project Stats - Oct '05
by Bryce Harrington 17 Oct '05

17 Oct '05

Statistics Jun 1 Aug 1 Oct 1 Oct 15 ========== ====== ====== ====== ====== Max Week's Rank on SourceForge: 38 3 26 26 Total SF Page Views 1,935,964 4,452,437 4,948,483 5,329,542 Total SF Downloads 254,647 378,712 501,162 534,047 Total Freshmeat URL Hits 19,149 21,261 23,148 23,454 Total Freshmeat Subscriptions 183 208 229 233 Lines of Code in src/: 374,180 389,945 544,117 544,031 Code lines 260,236 270,423 373,797 373,738 Comment line 67,136 70,478 108,884 108,883 Blank 53,443 55,698 73,412 73,386 Lines of Docs in doc/: 27,790 28,090 27,176 27,176 Lines of content in website: 42,490 44,483 48,689 48,928 Size of the Inkscape wiki: 26,729 34,890 34,847 34,847 Bugs open/total: 215/1223 215/1445 260/1643 267/1684 Features open/total: 453/ 728 440/816 453/ 934 468/ 955 Patches open/total: 11/ 230 8/325 10/ 346 14/ 357 CVS Commits (as per inkscape-cvs) 12,040 12,915 14,201 14,372 Inkscape-devel membership: 179 200 213 217 Inkscape-announce membership: 202 236 284 299 Inkscape-user membership: 248 276 310 314 Inkscape-tester membership: 31 30 Num Translations: 33 33 34 35 Ave Translation Ratio: 47.8 54.6 51.5 51.5

1 0

Open Clip Art Library Release 0.18 Announcement :: www.openclipart.org
by Jon Phillips 17 Oct '05

17 Oct '05

October 16, 2005 - Release 0.18 of Open Clip Art Library (http://www.openclipart.org), containing over 6900 SVG files created by over 500 artists, is now available for download and use. For the month of September, the Open Clip Art Library sought imagery related to pets including images of different breeds appropriate for use by animal shelters. For the upcoming 0.19 release, due November 1, 2005, the theme is Halloween. This is any artist's chance to submit to the Open Clip Art Library images of ghosts and goblins, bats, witches, and pumpkins. The community would also welcome printable templates for creating holiday decorations usable in Inkscape, OpenOffice?, Scribus, and, or other graphics applications. Some of the highlights from this release: * New top level categories 'science', 'electronics' * New subsections 'religion', 'astronomy', 'network', and more * Flags collection has been fleshed out / improved a bit more * Bunch of new signs/symbols * Lots of new vehicles, office, sports, music, and toys clipart A lot of the previously 'unsorted' art is now sorted and moved into other categories, and several duplicates removed. While much more work is required before the collection is perfect, this release refines the collection for easier access. Please download it directly from: http://openclipart.org/downloads/0.18/openclipart-0.18-full.tar.bz2 http://openclipart.org/downloads/0.18/openclipart-0.18-full.tar.gz http://openclipart.org/downloads/0.18/openclipart-0.18-full.zip http://openclipart.org/downloads/0.18/openclipart-0.18-win32.exe Or, find one of the other packages at: http://openclipart.org/downloads/0.18/ The Open Clip Art Library (http://www.openclipart.org/) aims to create an archive of user contributed clip art that may be freely used. All graphics submitted to the project are placed into the Public Domain according to the Creative Commons Public Domain Declaration.

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> From: bulia byak [mailto:buliabyak@...400...] > Sent: 15 October 2005 18:04 > On top of that, in my humble opinion, this is also the most awkward > thing in Xara from UI viewpoint. The Xara strength has always been to > edit everything on the canvas. So opening a separate window for bitmap > feels extremely clumsy. Totally agree and that's the way we're going. You can already use some picture editor tools on the vector object directly such as our Enhance dialog (brightness, sharpen, blur etc). Indeed many picture plug-ins now work on canvas in Xara (on vector or bitmap objects alike). Work to do still but I completely agree, editing and painting operations should be able to be done directly on canvas just like all other tools. We're sort of about 2/3rds the way there now. Our architecture is such that they can be used stand-alone in the picture editor, OR directly on canvas in Xara, so you get the best of both worlds. i.e. the plugs-in designed to work in a pure bitmap editor, just work on canvas for free in Xara. Charles

3 2

Re: What should 'zoom to content do? (was Re: [Inkscape-devel] zooming bug)
by jiho 16 Oct '05

16 Oct '05

On 15 oct. 05, at 21:01, Ben Fowler wrote: > I am assuming that you meant to post to the list. yes sorry about that. inkscape's list should really have a "reply to" address set up if this is possible. > On 10/15/05, jiho <jo.irisson@...400...> wrote: > >> If this is a good solution for a newly opened/finished file (which >> should not have things outside the page in order to print correctly), >> I think this might be annoying when editing the file. For example, I >> very often put some objects outside the page while I edit the rest. I >> might zoom into the page on a small selection and then zooming out to >> content, including what is outside the page is a very efficient way >> of finding back all my objects. otherwise it is often a pain to look >> for it outside, or to zoom out manually, find them, move them, zoom >> back in... >> > > Terminology: Outside the page | Off the page | On the pasteboard > > If you have a small selection already made, 'Zoom to content' (I would > call it 'Fit All') is not the same as 'Fit selection'. I would suggest > that 'Zoom to content' always sets the zoom to fit all objects. I am > sorry if I implied otherwise. Ok I think I misunderstood you. Just to be clear what you propose is in fact: - zoom to page: zooms to the page ;-) - zoom to content: zooms to fit ALL visible objects - zoom to selection: zooms to the selection unless selection is larger than the page, in this case zoom to the page. is that it? in this case: "why not", but my opinion is that if there are real issues in the file, they should provoke some strange behavior in order to be corrected. > Also, I suspect that what you are looking for is a zoom between the > 'User state' (showing a small part of your drawing, possibly > defined by > a selection of one or a small number of objects) and the 'Standard > state' (showing all). I think that the key to this is to have an easy > way of switching between these states. In this case I think you might have misunderstood me. I'm sorry if I was not clear by english is not my main language. There are two things: - what I though you suggested before. I though you suggested that zoom to content should not zoom out of the page. to which I replied that IMHO current behavior (zooming to all, even off the page) was useful to quickly visualize all objects during the editing process. - the problem with the file with the insane bbox. this problem was revealed by the complete zoom out. in this case the zoom issue was in fact just _revealing_ some other problem: the fact that apparently Make bitmap copy produced an object with a wrong bbox. so in this case the problem does not come from the zoom but from "Make a bitmap copy". So in fact I am quite happy with current behavior of the zoom tool ;-) > I don't think that we can guarantee perfect or even satisfactory > results > when working with insane files, but I do think that the Interface > should > not be surprising. > > What is the least surprising behaviour here? > > I am proposing that when you make a selection, including 'Select > All' and > then 'Fit Selection' you should see the boundary selection handles > just > inside your workarea. > > I am suggesting that the meat of your report was that when you > expected > the zoom to be 66% and many objects visible, you observed the zoom to > be 1% and the objects to be the canvas equivalent as screwed up into > a tiny ball. > > It is your bug, not mine and you are free to correct me. concerning the reaction facing this bug, please see my answer to the other thread. thank you for taking care of this issue as you did from the beginning. 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/

2 1

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 16 Oct '05

16 Oct '05

> From: Ted Gould [mailto:ted@...11...] > Sent: 15 October 2005 00:36 ... > A couple of things here: > > - Do you expect to release the Live Effect plugins as open source also? > I thought so, but you listed it here as the additional features in a > boxed version. We can and will make the Xara owned ones Open Source. But we bundle many (17 at the last count) provided by third party companies that specialise in providing Photoshop plugins, such as Alien Skin. Very cool effects but we have no ownership or control over them. > - It sounds like your initial plan is not to sell a Linux boxed version, > is that correct? There is no short term plan to sell a boxed Linux version. Down the road (one we get to a 1.0 stage) if we can add enough added value, this might be possible. e.g. if we can persuade the likes of Alien Skin to create Linux compatible plug-ins that we could bundle in a premium boxed version, and if enough people want things like commercial support, CD, manuals, whatever, then it's a possibility. > - Have you looked at the embedded Linux market? One device that I'm > anticipating is the Nokia 770, which will run Linux. My understanding > is that the graphics application there is... well... Xara could probably > help :) An uber-fast rendering engine would definitely be of interest > to embedded developers. I think this could be an exciting potential > market for Xara, and companies like Nokia would probably pay for the > porting to their device. I love the device, and would love to put something like Xara on it. But this is exactly what I'd hope would be one of the benefits of going open-source. We couldn't justify spending time on this (unless Nokia pay us) but if there are enough enthusiasts willing to put the work in then they can take our code and create it for themselves, and everyone else. It would be very cool to do. > I totally agree on the Pantone point, but that leads me to say, why not > just leave the whole thing as LGPL Not an option because it could then be used by our commercial competitors, especially on Windows, against us. Would be hugely damaging. So I'm with Stallman on the copyleft aspect of GPL. We make our stuff free and can be used by anyone else as long as they make their stuff free as well. > and not worry about the BSD stuff. > Then you can link to other libraries as need be, and sell that as your > boxed version. Then users can contribute under their copyright, and > licensed under a single license. This would protect you from the case > where a significant contribution could be integrated by Adobe without > any contribution to the community. Ah do you mean why can't we take contributions in LGPL? If I understand LGPL correctly that only allows for linking via a defined library API. So it doesn't work for contributions to the code itself. That would still prevent us (or anyone) creating versions containing other non-open licensed code. Charles

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel- > admin(a)lists.sourceforge.net] On Behalf Of Ted Gould > Sent: 16 October 2005 05:46 .. > ... but I think the single biggest > thing Inkscape could do to help integration is notice changes in bitmap > files. So, I link in a JPEG, and if I change that file in any other > application Inkscape notices and updates instantaneously. I think this > should be possible with further GNOME-VFS integration. Then, the > command is to just to open GIMP on the file. Yes, great. Something really simple like that. I'd support that (in Xara or Inkscape). But we'd like to go further (and part of the reason we do it the way we do with a private API) so that we pass raw (or PNG) bitmaps to and fro, to avoid the JPEG lossy cycle. We also keep the photo edit list associated with the bitmap, so you can edit it in future and alter (or undo) the previous edits you did to the bitmap. That requires a bitmap editor to remember the lists of edits, and keep a master around. But for a basic simple, still very useful feature, just watching for file changes would seem to do the trick.

1 0

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

> Perhaps it would be a good idea to come to the Libre Graphics Meeting > 2006 in Lyon, to define your position in the OpenSource Community. > http://wiki.gimp.org/gimp/LibreGraphicsMeeting > > Tobias All ready to put in my diary, only to discover I've already booked a vacation at that time, which is a real pain. I'll see if we can send some other representative. We should be there I agree. Charles

1 0

Proposed changes to Keyboard shortcuts
by Alan Horkan 16 Oct '05

16 Oct '05

=== Patch first === The Patch https://sourceforge.net/tracker/download.php?group_id=93438&atid=604308&fil… The Patch assigns F1 to Help, Keys and moves some other keys around mapping them to ones used by Xara. The tracker request https://sourceforge.net/tracker/index.php?func=detail&aid=1326159&group_id=… === Ask questions later === (And these are just for starters) Inkscape has keybindings for almost everything which makes it very hard to change anything without having consequences, it is worse than a Rubiks cube. I tried to make changes as non invasive as possible but it was difficult. I may not use Inkscape every day but it is precisely for that reason I find it so important to try and get inkscape to use Keybindings which resemble those used by other applications. F1 for Help was one of the first and most important keybindings I learnt (and hitting Esc like a madman anytime something went wrong was probably the second). It is not just about F1 but it seems like a place to start. Beginners and new users face a much steeper learning curve if Inkscape uses different conventions from other applications. I realise an changes will be uncomfortable for existing users but no one ever claimed Inkscape was ready for stable 1.0 and not going to change things around. Experienced users should know inkscape will be subject to changes and they are exactly the people best able to adapt to changes and if we are lucky they might even like the changes because they make inkscape a little more like Xara. The long term solution is of course to have fully switchable keyboard profiles. That doesn't change the need for good defaults and I hope by trying out these ideas (even if they need to be reverted before the next release) it will encourage people who do not like it to come up with better suggestions rather than blocking changes. Using F1 for help is a convention used by Windows, Mac OS X, Gnome, KDE. The changes make Inkscape more like Xara [1] in particular. Precedent is significant but if we at least try out the change we can get a better idea of the impact. If people really hate the change and it has to be reverted it will at least help show the need for different keyboard shortcut profiles sooner rather than later. There are many more things which could be said about this but please lets try it and come up with ways to do it better rather than not doing it at all. (bulia mentioned his displeasure at the choice of Zoom key which I expect could be addressed parallel to this by providing other Zoom functionality but I think that may need seperate discussion.) Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ [1] Keyboard Shortcuts for Xara http://www.xaraxone.com/html/tip_of_the_week_4.html http://www.xaraxone.com/assets/images/tip_30.gif (I have a text reference of the Xara shortcuts too somwhere, if anyone has a reference for Corel I'd appreciate it too.)

6 17

Bitmap manipulation
by Charles Moir 16 Oct '05

16 Oct '05

On Tue, Oct 11, 2005 at 08:22:39PM -0300, bulia byak wrote: > > Another focus of Xara is on bitmap manipulation. They have a built-in > > Picture Editor, something like a primitive Photoshop. I think it's > > safe to bet Inkscape will never have such a thing - why do it if we > > can just call Gimp instead. > Well, depends what you mean by "have such a thing": calling gimp code > would count as having such a thing; though currently we don't do that > at all to my knowledge, and we certainly don't currently make it easy > to edit embedded bitmaps, or have gimp layers implemented as separate > <image/>s, or allow other vector objects to be visible when editing a > bitmap. > > pjrm. This point reminds of another area we could cooperate. We do have an integrated bitmap / photo editor, because in principle I don't believe you can or should separate the two worlds. Real users want to mix photos and vector artwork, and so it's simply more convenient to be able to do this directly from within your vector editor. (And Microsoft Expression will be majoring on this point - integrated bitmap and vector editing, indeed the only significant change MS have made to Expression they bought, is adding a fully integrated bitmap editor) So in Xara X we added an API to call an external photo editor, so that you could double click a photo, (or a bitmap fill) edit your picture, close the window and the edited result is passed back. The theory was that we could use any external editor and were not going to make it specifically the Xara Picture Editor. So in principle this is exactly like you guys calling out to GIMP. But our Xara <-> Picture Editor API sucks, partly because it's very COM based and partly because it's become very specific to our implementation of the photo editor. Worse, our Picture Editor component is going to be an absolute dog to port to Linux because unlike Xara X, it was never designed to be the slightest bit platform portable. GDI+ code everywhere, transparent fading, rounded dialogs, the lot. This remains a major potential stumbling block for the port down the road (it will be the last component we do). So we should also be changing our API to be more general purpose. So the user can configure their favourite photo editor to be called when they want to edit a photo. So, if this is a feature that you guys are thinking of adding to Inkscape, lets have a common API to call external photo editors. Then we can be compatible - we can both use and call Photo editors in a compatible way. What's more this provides an added incentive for the various photo editors out there to support this API and so greatly increase the interop and choice for all users. I might be talking b**ls here, because for all I know Linux already has an open, common API to pass photos to and from the various picture editors. But it seems another area where we could both possibly develop a feature in parallel, but both benefit equally from it. Or is this rubbish?

4 3

RE: [Inkscape-devel] Bitmap manipulation
by Charles Moir 15 Oct '05

15 Oct '05

> > I might be talking b**ls here, because for all I know Linux already has > > an open, common API to pass photos to and from the various picture > > editors.... > > I don't know of anything *specifically* for that. > > However, there is an API that might be relevant here, with added benefits. > It's a network protocol, primarily for 3D graphics collaboration, called > "Verse": > > http://www.blender.org/modules/verse/ > > Performance could be an issue for large bitmaps, since it's a network > protocol, but perhaps an optimised version could be used locally. This is interesting and possibly suitable. Might be more suitable as an API to interface to 3D apps (which is another area altogether - Illustrator and Corel have had good 3D capabilities for a while). Charles

2 1

Writing News
by unknown＠example.com 15 Oct '05

15 Oct '05

Could someone in the know update the wiki with the current new writing procedure? http://wiki.inkscape.org/cgi-bin/wiki.pl?WritingNews Aaron Spike

2 1

zooming bug
by jiho 15 Oct '05

15 Oct '05

Hi list, this file http://jo.irisson.free.fr/dropbox/schema_bilan.svg was completely made in inkscape with version 42-2-2 on mac os X. Then it was edited with latest CVS on linux and after that: - zooming to fit content in window zooms out to 1% - selecting all and zooming to selection produces the same result both on stable or latest cvs inkscape on os x or linux. (NB: the same problem was also remarked in other files, converted from eps to svg with pstoedit such as this one: http://jo.irisson.free.fr/dropbox/sampling.svg it might be that the eps was corrupted in the first place or that pstoedit job wasn't perfect because there are other problems with this file: any new path/tex created is huge, no dashes can be applied to some imported path or to any new path created etc. But I mentioned it in case the zooming problem is the same. Nevertheless, the point is that previous file (schema_bilan.svg) was entirely made in inkscape so there is no incriminating pstoedit or the software which produced the eps in previous case.) in addition, the first file (schema_bilan.svg) does not display properly on os x (stable or cvs) anymore: all shapes are there (selectable), their fill and stroke attributes are still correct but they are not displayed. I know that the zoom has been changed a bit lately. might it be related to this? I submitted a bug to the tracker: [ 1326574 ] maximum zoom out when zooming to fit in window I hope this will be easy to fix. I am naturally ready to test anything you'll need. 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/

3 8

zooming bug
by jiho 15 Oct '05

15 Oct '05

sorry I replied only to bulia. Begin forwarded message: > The real problem is the insane bbox. I think this may happen to >> other elements too, for any number of reasons. So perhaps the best >> way >> to address this is to ignore anything which is larger than, say, a >> million px in any dimension. For example scaling by keyboard already >> has the 1 million upper limit. However I'm reluctant to do that, as >> you never know what weird files people would want to edit. This >> arbitrary limit may bite us sometime. >> >> > > what about scaling down or up the objects with "insane" bbox after > issuing a warning/question when the file is opened? if it is a > isolated case in the file (as the one attached in the bug I > submitted) it will suppress the problem and focus the attention of > the user on this (and if he knows about the xml editor he could > delete the incriminated object). if the whole file has insane > transform matrices (like the one to which I provided a link in the > bug report) it will make its modification in inkscape easier. > currently, in the second file, when I add anything it is insanely > scaled (like strokes with 720 px of width) I think because all > objects have transform matrices like this one: > transform="matrix > (2.007003e-3,0.000000,0.000000,-2.007003e-3,-6.079619e-2,1.461081) > > I don't know if anything of this is meaningful but my impression > was that, dealing with vector images, scaling won't be a problem. 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

gtkmmification update
by unknown＠example.com 15 Oct '05

15 Oct '05

I'm asking purely as a user who, possibly incorectly, thinks that the changes made in gtkmmification will make future progress of Inkscape quicker and easier... I could't help but notice the hubub centered around rwst's recent refactoring. But I confess I don't understand much of what is going on or what significance it has. What is the current status of the gtkmmification? Is there a list of gtkmmification goals notated with those that have been completed? What does it mean that there is a canvas in --new-gui? What does it mean that we need to use Actions? Clue Seeking, Aaron Spike

2 1

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> > > > Also the guys are under intense pressure to ship a brand new commercial > > Windows release right now and so have very limited time. Indeed right > > now we have very limited number of developers purely on the open-source > > version. > > Can you tell us a little about the backgrounds/interests of the folks > working on the open source version? I'm looking forward to chatting > with them in the future. :-) Well the guys you may come across are Phil and Gerry both been with Xara since well before our Windows exploits back to Acorn RISC days. Phil was even involved in some Atari ST products we did in historic times. But they've worked on just about everything including Artworks the ARM based (pure assembly language) predecessor to Xara X and Impression our Quark-like DTP package. Both have huge experience across the board. Phil probably has more ownership of the technical architecture than any. Gerry has very broad experience of whole computer and Windows gamut. However neither have that much experience (perhaps none) of Linux as far as I'm aware). Neil our CTO has Unix experience going back - more project manager, but a very good understanding of architectural and OOP things. Er, who else. Luke might post from time to time - he's the main guy working on the Linux port right now (and has more Linux experience than any of us). Others you may come across but probably wont be posting here much. Oh and although I'm CEO I used to program (mostly assembly language, authored the products that the company was built on 25 year ago, e.g. Wordwise a word processor that was very popular in the 80s in the UK) and so understand, in some detail, all the concepts of what we're doing. So we are a very techy orientated organisation. (Maybe that's why we're not bigger than we are because I should be more marketing oriented). Having come from a background where every byte mattered and processors were pathetic, that's perhaps where and why we get this speed / space efficiency thing from. It also means, that as CEO, I don't get or accept any technical BS from my people about what is and is not possible. If they come to me and say "can't be done" I'm always pushing back to ask why, there must be other angles we can take, and usually we find a way. I am also a fanatic about detail, trying to find better more slick ways to do UI and cutting anything that is not necessary. I'm an total believer in the KISS principle, Occam's razor and such approaches. And although over the decades there is not a class of software we've not been involved in, from games to databases, spreadsheets, interpreters and compilers, even hardware design, I'd say that we've been involved in publishing software more than anything - be it word processors, Postscript interpreters (this is where our rendering engine started life 15 years ago), DTP packages and graphics software of all types. So a pretty broad background.

7 6

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> From: MenTaLguY [mailto:mental@...3...] > Sent: 14 October 2005 21:49 > > So why doesn't someone do a sort of Ultra-draw wrapper super-API library > > thing that we can both use. i.e. it provide one super-set rendering API > > that itself calls down to XaraDraw, Cairo, Quartz depending on user or > > program preferences. And then we'd both use this ultra-draw and both > > gain the desired benefits. Quartz, Cairo and XaraDraw are similar enough > > to make this not too huge a job I would guess. > > I would be reluctant to introduce yet another new API. I've been > peripherally involved in the Cairo effort, and have learned that good > API design is VERY hard in this area. Well yes, you're right the last thing anyone needs I more APIs, but on the other hand Cairo has a pretty limited feature set (but on the positive side, seems super-clean, very simple and that's worth a great deal.) > However, I suspect XaraDraw doesn't owe its speed so much to the > specific rasterization backend as to a "retained-mode" layer which can > do caching and optimization of drawing calls? Almost a great deal of the speed of Xara X1 and predecessors is the rasterizer backend (but the main object tree is designed around calling this efficiently). In Xtreme we added a bitmap caching layer which can make substantial further speed-up for groups, layers, shadows, feathered stuff, blends, etc, which otherwise an be relatively slow to render. > Cairo pretty much only does rasterization; it provides no retained-mode > layer of its own. There seems a very close correspondence between it and XaraDraw, and Quartz (and GDI+ even). These all are all non-retained rastersization engines. > My own feeling is that it would be most beneficial to take Xara's > retained-mode layer, target it to Cairo, and then write a new Cairo > backend using XaraDraw's lower-level layers (in the long-term, we would > also want to investigate merging what we could of the "XaraDraw" Cairo > backend into Cairo's normal software backend, assuming you folks were > comfortable with relicensing those bits accordingly). Yes I think there's a lot of sense in that approach. Trouble is we might not have a clear, retained-mode layer as you put it. You can see once the source code is provided. The 'viewer' that forms the core of the download we now have is probably close to this. > In case Cairo's generic API proved insufficiently rich for everything > required by Xara, note that Cairo does allow for backend-specific API > extensions. We could simply employ those in the short-term, and it is > likely that many could be incorporated into the generic API over time. Ah, OK, that is useful. Cairo certainly is not rich enough and appears to implement a relatively small percentage of the capabilities of the XaraDraw engine, and is rather less capable than the Quartz PDF engine even. But if it's an extendable API that may be the best way to go. There might be licensing issues, would need to be looked at. > Both Inkscape and Xara could then use Xara's retained-mode layer, and > both could use Cairo underneath while still taking advantage of Xara's > optimized rasterization routines. In the long run all Cairo-based > applications (e.g. all GTK and wxGTK applications) would potentially > benefit, and Xara could benefit from future third-party improvements to > Cairo directly. > > That approach would let us stick with two already well-refined APIs, and > take advantage of the principle that a rising tide lifts all boats. Yep, a lot of merit to that approach. Charles

1 0

RE: [Inkscape-devel] RE:Xara Announcement
by Charles Moir 15 Oct '05

15 Oct '05

> -----Original Message----- > From: bulia byak [mailto:buliabyak@...400...] > Sent: 14 October 2005 21:32 ... > Working on shared libs is a good thing. However, for me personally the > most important thing is the UI. I added a lot of small and > not-so-small UI tweaks to Inkscape, and even though a few years ago I > was a diehard Xara fan, now I perceive Xara as somewhat clumsy > compared to Inkscape. It feels a bit awkward when I use it, I miss > lots of small conveniences of Inkscape. I would love to have an offline conversation with you about what you dislike or find awkward - I feel the same when using Inkscape, in certain areas more than others. But UI is an area I take a great deal of interest in. Of course a huge amount is that you like what you know and know what you like. I know diehard Illustrator users who defend what, to most others, appears a tortuously convoluted way of doing things. They've been through the pain learning it all once and 'sure as hell aint going to learn something else'. > Also Xara misses a few > critical features of Inkscape, most importantly clones. Yep, I agree. Been on the wish list for about 10 years. Always had higher priorities. A great example of a feature that I'd imagine little if any Inkscape code would be relevant or help us. So if we want the feature we'd have to do it from scratch. > It's up to you, but I'm not sure resisting to improvements, even > temporarily, is the best tactic. Everyone can try the complete Xara on > Windows right now, and everyone can get a good idea of what's in most > urgent need for improvement, based on that. Well you're possibly right, and we're never going to turn down improvements if they're dead safe and can be done with delaying things. But the dangers are that a) we de-stabilize the product b) we get distracted implementing new features and thus delay a 1.0 release. I think having a very clear target that is easy to describe and understand is worth a great deal. We've been burned so many times by making a 'relative small change' that turns into a huge job. For example Live Effects, was originally estimated at about 3 months works, no great architectural changes required. 14 months later we had it done to our satisfaction. Charles

1 0