- Inkscape Devel - Inkscape Mailman

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