- Inkscape Devel - Inkscape Mailman

0.36 release candidate tagged in CVS
by Bryce Harrington 11 Dec '03

11 Dec '03

The one priority-9 bug that was identified in testing was fixed by Bulia, thus closing the last task required for the Inkscape 0.36 release. It builds with both gcc and g++. Folks are itching to get into dev mode for 0.37. We're ready to cut the release. RELEASE_0_36_0 is now tagged in CVS. Unless we discover any major issues during packaging, this should be considered the official release source. If there are issues that require fixing for this release, we can create a branch from this tag point to work on them, and allow the main branch to return to development. This tagged version can be checked out via the command: cvs co -r RELEASE_0_36_0 -d inkscape_0_36_0 inkscape Ted, can you finalize and post the official tarball at your earliest convenience? Nathan and Mael, once this tarball is available, please proceed with creating the Debian and Windows binary packages, and I'll do the same for RPM. Once all of these packages have been created, then we will put out an announce to Freshmeat, et al. Hopefully we can achieve this within a day or two. Meanwhile, everyone should consider CVS HEAD to be unfrozen and available for open development once again. Thanks, Bryce

3 4

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