December 2003 - Inkscape Devel

last changes pleease
by bulia byak 11 Dec '03

11 Dec '03

Hoping it's not too late, could you guys please take the latest CVS for the release? Just a couple last-minute cosmetic changes: h and v shortcuts for flipping, and the Edit menu is split into Edit and Object. This is important for making a good first impression, as the old Edit menu was way too big. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

1 0

RE: [Inkscape-devel] 0.36 release candidate tagged in CVS
by bulia byak 10 Dec '03

10 Dec '03

> > What about doc/keybindings.txt? Whoever is preparing the release, pray > > remove this old crap and replace it with a copy of KeyboardShortcuts >from > > wiki! > > (ideally this needs to be automated) > >Ah, true... > >Ted, I've marked this as a task for you. Bulia, can you cut a copy of >your doc from wiki and put it into CVS HEAD? Ted can pick it up from >there when he's ready. Done, doc/keybindings.txt removed, doc/keyboard-shortcuts.txt added (manually created for now). _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

1 0

Website problems
by Jon A.Cruz 10 Dec '03

10 Dec '03

I've noticed some problems on the website in regards to it's markup. The most visible problems showed up under Mozilla 1.0.2. I then went to validate the pages (at http://validator.w3.org) and found that there are actual problems. Whoever can make changes should probably go through and use validators and do some cleanup. In hand with those pointing out problems, the 3.2 and 4.0 HTML references at http://www.htmlhelp.com are *very* useful, since among other things they are machine generated from the DTDs and include listing what tags/elements can contain others, and which can be contained. A *must* use for anyone doing web work. :-) Anyway, on to some specific problems: * The validator doesn't like the keywords meta tag for some reason. * Anchor tags can't contain H1 tags. Just swap and put the A's inside the H1's and all will be happy-happy * ALT attributes missing on images. It's polite to have them. :-D * List nestling broken. This is probably the main cause of the problems I was seeing. * Literal "<defs>" in the text, instead of "<defs>" On the list nestling, the problem is with UL's contained in other UL's. The validator complains because a UL can't contain another UL. However, it's legal to include a UL inside of a LI. So at the moment the last list entry is closed before opening a new UL. That closing </LI> tag should be moved to *after* the enclosed UL. Then all should be happy-happy. :-) (I've gone ahead and sent this out to the list since these are subtle things that are easy to trip over and not be aware of, however once understood they're easy problems to avoid. Plus the two links up there are very useful)

2 1

RE: [Inkscape-devel] 0.36 release candidate tagged in CVS
by Bryce Harrington 10 Dec '03

10 Dec '03

On Wed, 10 Dec 2003, bulia byak wrote: > What about doc/keybindings.txt? Whoever is preparing the release, pray > remove this old crap and replace it with a copy of KeyboardShortcuts from > wiki! > (ideally this needs to be automated) Ah, true... Ted, I've marked this as a task for you. Bulia, can you cut a copy of your doc from wiki and put it into CVS HEAD? Ted can pick it up from there when he's ready. Bryce

1 0

Re: [Inkscape-devel] new booleans patch
by bulia byak 10 Dec '03

10 Dec '03

The updated patch from the author and my hookup patch (which puts the new commands into the menu and as shortcuts - ugly, just for testing) are here: http://sourceforge.net/tracker/index.php?func=detail&aid=857377&group_id=93… Bryce, can you give Fred developer access to the CVS so he could create a branch for testing the new functions? (Or maybe I can now do this too as an admin, but I don't know how :) _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx

2 2

Re: libgsf + Inkscape
by Jody Goldberg 10 Dec '03

10 Dec '03

On Tue, Dec 09, 2003 at 09:49:19PM -0800, Bryce Harrington wrote: > On Tue, 9 Dec 2003, Dom Lachowicz wrote: > > > > I just committed a bunch of documentation. We're a bunch closer to 100% API > > documentation now. Nice work. > Very cool. May want to think about a webpage too... at the least, a > list of features. Yah. I know. I tend to be better at writing code than web pages. Probably when gsf 2.x comes out or someone steps forward. > Possibly libgsf and neon would obviate any need for gnome-vfs but I > haven't really looked in enough depth to say for sure. I haven't > confirmed that gnome-vfs actually supports WebDAV, and if it does, > how good the support is. > > WebDAV is composed of a number of different methods, some basic (GET, > PUT, HEAD), others more advanced (MOVE, MKCOL, PROPFIND, etc.) So when > a lib or app says it supports WebDAV you have to check 'how much'. Neon > supports a wide range of them, according to its feature list. > > http://www.webdav.org/neon/ Interesting I'll have to have a look. As mentioned our plans had been to use libcurl for network related activity. However, I have not checked on its webdav status any more than gnome-vfs. > Have a look at Neon and let me know what you think. Would it be > feasible to use it in conjunction with libgsf? I'll have a look. > The direction we're heading is to make wrapperization of the app easier, > whether that be with Python bindings (via SWIG?), Bonobo, or even a kind > of SVG Canvas. Being able to plug inkscape into other things opens lots > of very interesting uses of it. That would be very interesting. Abi and Gnumric had previously discussed supporting embedding by just rendering an svg image. Something like this would be nice.

2 1

Re: [Inkscape-devel] new booleans patch
by bulia byak 10 Dec '03

10 Dec '03

Are you subscribed to the inkscape-devel list? Let's move our discussion there, because many people will be interested in your code. >the code is "borrowed" from the >sp_path_selected_combine(), and there's a check on the >number of elements in the selection (looks like it, at >least). It only checks that there are at least two objects selected: if (g_slist_length (il) < 2) return; So we need to fix it for the case when there are more than two. If you can make intersect and union functions accept any number of objects in one go, that would be the best. And for difference functions, we need to check that there are exactly two objects selected, and complain if not (for now you can just print a g_warning and do nothing). > > Inset and offset, although very very useful, are > > unfortunately more buggy. > > When you do them repeatedly, the number of nodes > > grows very fast, and soon > >oops... yes the number will grow fast (exponentially). >isn't there already a function to cleanup a path in >sodipodi? None that I know of. i recall seing somewhere discussion on how >to simplify a path... besides it's just a lame >approximation of the offset, there's probably wiser >algorithms (that i do not konw about) You can discuss this on the list with people who have much better knowledge of algorithms than I, such as Nathan Hurst. >well, the soutline/offset/inset algorithm is quite >stupid: build an offset path, and treat it like a >polygon. the "difficulty" lies in building the offset >path. the code is still rough, and doesn't like null >segments in the path, path with multiple subpath, >closed paths, etc... i have to admit it hasn't been >tested thoroughly; just outlining a path twice as you >suggested brought up a number of serious problems i'll >have to investigate. on top of that, the result of the >offset is transformed in a svg path description (so if >d="", it means the algorithm completely failed), and >the precision used to store the coordinates in the d >attribute seems insufficient. We plan to increase it from 6 digits to at least 8. Do you think 8 will be enough for you? >technically, coordinates >are rounded to a 1/32 grid by the code in livarot; >dumping the path with less precision in the xml tree >can cause ugly things. the cusps you mentioned are >usually small segments making sharp turns because >coordinates were rounded. using a round or bevel join >"removes" them (btw, how do you set the miter limit in >inkscape?) I don't think setting meter limit is implemented. Anyone? I think now the best course of action is this. I'll ask Bryce to give you access to the CVS so you could create a branch for testing and development of the new commands. You will store the entire Inkscape tree there, so that people would be able to checkout and test it without patching. To hook up your commands to the menu and as shortcuts, I did a simplistic patch, which I will now upload to the Inkscape tracker along with your updated patch; you can use my patch as a starting point. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Re: [Inkscape-devel] new booleans patch
by bulia byak 10 Dec '03

10 Dec '03

After some testing I can say that the four basic operations (union, intersect, diff, symdiff (which is similar to combine, except that it adds nodes where sides intersect)) are very stable. I could not force them to do something wrong or misbehave. The only problem is that when more than one object is selected, these commands only operate on the first two objects while others simply disappear. But I think it will be easy to fix. The quality of these operations seems to be good: no extra points, no curve distortion. Inset and offset, although very very useful, are unfortunately more buggy. When you do them repeatedly, the number of nodes grows very fast, and soon some very strange artifacts appear (such as dense "clusters" of nodes that really distort the shape). Also, when you do inset or offset to a path with many nodes, it becomes extremely slow, and Inkscape may hang for minutes. Sometimes, a path simply disappears (the object is there, but its d="" attribute is empty). The outline stroke function works acceptable. Sometimes the strokes are distorted (usually near ends or sharp cusps) but the number of nodes in the resulting shape is not too big, and for simple strokes it gives good results. >Actually, having looked at the patch, I think we really need to leave >this 'til the next release. Three reasons: First, it's in C++ and we >had decided to hold off on changes that commit us to C++ until 0.37. What is the value of preserving plain C compilability? Will people complain if we require C++ for 0.36? I, for one, do not care what is the compiler, so long as the program works :) >Second, it's a good bit of code, and deserves to be tested. The best way to test is to release! We're not doing 1.0, after all. It's just a 0. release. >Third, we >will need to do some additional development (buttons, etc.) to integrate >it. I could certainly live without buttons - menu commands and shortcuts are quite enough for the time being. Besides, we could borrow buttons from the other patch, and I think I remember seeing the icons somewhere in the sodipodi innards already. So my opinion is this: let's include the four boolean operations and outline path for this release, and then help the author debug the inset/offset operations for the next release. _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx

2 1

Re: [Inkscape-devel] non-ASCII chars
by bulia byak 10 Dec '03

10 Dec '03

>So... it's often good to do 'sanitizing' of input. In this case, where it's >direct user input, speed should not even be a problem. OK, what about: u = g_utf8_get_char (utf8); if (u == (gunichar) -1) { g_warning ("Bad UTF-8 character"); return pos; } if (!g_unichar_isprint (u)) { g_warning ("Non-printable character"); return pos; } is this enough sanitizing? :) _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Status of priority-6 bugs for 0.36 release
by Bryce Harrington 10 Dec '03

10 Dec '03

All of the priority 9 bugs and all of the bugs listed on the roadmap for required the 0.36 release have been resolved and closed. (It's been pretty amazing how much intensity was placed into bug fixing this last week; 20 bugs closed!) The remaining priority-6 bugs are listed and commented on below. My thought was that the priority-6 bugs "would be nice to close" but were not required. We've closed a number of them, and I think the remainder can be left for a future release. If anyone feels differently on any of these, speak up now. Bryce [ 851467 ] Export selection bounds too small There is a patch for this that John Stracke is developing for Sodipodi. If we wait a tad longer it might become more matured. See Sodipodi Bug#758775 for the patch. [ 841633 ] Icons problem for win32 I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the next release. [ 850936 ] .32 crashes when setting printer destination It no longer crashes but it does emit an ERROR message. This should receive high priority in the next release but may be acceptable for 0.36. [ 853804 ] SVG COMPLIANCE: Paths shown will fill when fill:none The issue is that "file: none;" and "fill:none;" behave differently for the given case. This is important for importing SVG but perhaps one we can leave 'til next release as it doesn't impact general use. [ 852619 ] XML editor crash There are a couple XML editor related bugs, but they appear unrelated. This particular bug is uncovered after a sequence of steps that may not be encountered by most users in general usage. [ 50549 ] spiral crash This is an easy bug to reproduce, however the spiral shape does not seem like one that would normally get heavy use. [ 847886 ] transformation inaccuracies The change from float to double addressed part of the bug, the remainder appears to be a legitimate issue but may not be noticeable to regular users. [ 851937 ] Postscript file output does not respect document size More of a feature request than a bug, I think. [ 851131 ] Print preview does nothing I'm not sure if print preview is implemented, as it's never worked for me. I've commented out the menu item. If this *does* work for anyone, let me know so we can leave it in but mark it a 'known issue', and get it fixed. Otherwise we should list high on the feature request list. [ 853858 ] errors when copying objects between docs Bulia estimates this will require too much effort to fix for 0.36. It's listed as a known issue on the release notes page. [ 850971 ] Crash while deleting too much using the XML editor This bug is in regards to deleting the sodipodi namedview element via the XML editor. I looked into the code to see if there was an easy way to trap it but to do it right it looks like it would take some research. Since it's an unusual error I don't think a quick fix would be appropriate, and some time should be taken during the next release cycle to find a good solution. [ 851779 ] Style property "currentColor" not used properly This is another compliance issue for importing SVG files. Specifically, from gnuplot.

4 4