October 2005 - Inkscape Devel

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