April 2004 - Inkscape Devel - Inkscape Mailman

IMPORTANT: release tagging
by MenTaLguY 10 Apr '04

10 Apr '04

NOTE: anyone who currently has a checked-out copy of RELEASE_0_38_0, the tags in your working copy are most likely hosed; please check out a fresh copy! Since we need to do a point release, I went to check out the 0.38 release branch, only to discover that there wasn't one -- and RELEASE_0_38_0 was a branch tag itself. That's a problem, because I can't just check out RELEASE_0_38_0, commit the point fixes, and tag RELEASE_0_38_1 -- it would have moved the head of the branch and the next person to check out RELEASE_0_38_0 would have gotten something other than our 0.38(.0) release... In future, PLEASE do this: RELEASE_0_X_BRANCH - a branch for the 0.X.Y releases RELEASE_0_X_Y - a regular tag for the That way, if we need to do a point release, we can just check out RELEASE_0_X_BRANCH, commit the fixes, and tag RELEASE_0_X_Y; no muss, no fuss. As noted at the top of the email I have moved and rebranched the existing 0.38 tag accordingly. RELEASE_0_38_0 is now a regular tag, and RELEASE_0_38_BRANCH is now the branch tag. -mental

4 5

Re: [Inkscape-tracker] [ inkscape-Patches-929745 ] Change action of right-click with the pen tool
by Carl Hetherington 10 Apr '04

10 Apr '04

Hi Bulia, > 1. Aborting current segment is done by Backspace. Finishing > the line with last unfinished segment removed is done by > Return or double-click. Apologies for my ignorance of these shortcuts. > 2. Your patch totally disables right-click menu in this > tool, even when you don't draw anything. I fixed this and > committed the changed patch. Thanks for the fix and the commit! Cheers Carl

1 0

RE: cut tip
by bulia byak 10 Apr '04

10 Apr '04

> > The cutting of the tip is normal by itself, it's controlled > > by the stroke-miterlimit property. > >Could you explain that to me again? I mean, when I chose the first >toggle button for from the "join:" option, I don't want it to be cut at >all. You cannot have it without cut at all, because this will result in the miter length approaching infinity as the angle between the segments approaches zero. You must have a cut somewhere still. That's what stroke-miterlimit is for. See: http://www.w3.org/TR/SVG11/painting.html#StrokeProperties The bad thing is that Inkscape does not seem to honor srtoke-miterlimit currently, although I recall that at one point it did honor it. It's another bug that must be fixed. Well, not quite. I now see that it honors _small_ values. But in a wrong way. I added a comment to that bug. >Theoretically speaking this means if I have three nodes [1]--[2]--[3] >and move node [3] above [1] and then move it closer towards one, the tip >at node [2] should get longer and longer and for distance([1],[3])-->0 : >tip([2])-->infinity. but what acutally seems to happen is tip([2])-->0. Infinity is obviously not an option :) You can set stroke-miterlimit to a large - but finite - value. If you don't set it, the default is 4. _________________________________________________________________ Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 months! http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave…

2 1

RE: [Inkscape-devel] Three notes
by bulia byak 10 Apr '04

10 Apr '04

>he said it's great!), and he told me something interesting: Some dialogs >appear on top of everything else, but some don't. The Fill&Stroke and >the Text&Font dialogs stay on top when clicking the document window, but >the SPRect properties (for instance) does not. I found out there is a >new window in my window manager called "SPRect attributes" (or "SPRect >atributos", which is not correct in Spanish), which might explain the >dis/appearance. The attributes dialogs are really just debug tools, so I did not bother making them behave like normal dialogs. They're likely to be removed, all their controls available from the rect tool secondary toolbar and the XML editor. >Later on, there is this "Append filename extension automatically" (which >is great) (I never understood why some apps wouldn't do it by >themselves), but the thing is that if the filename has already the .svg >extension, it will add another .svg to the name. We specifically tested for this and this does not happen here. If your version is not the latest, this may be caused by non-ascii characters in the name. This is fixed in 0.38, please test again. >The last thing is about international scripts. When trying to write >Arabic I found out it wouldn't show it properly: text was written from >left to right and with no glyphs ligature at all. Yes, text tool does not support right-to-left typesetting yet. Pangoization will help with this, but not cure this immediately. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Three notes
by Daniel Díaz 10 Apr '04

10 Apr '04

Hello there. A friend of mine was checking out Inkscape (hadn't checked since 0.37 -- he said it's great!), and he told me something interesting: Some dialogs appear on top of everything else, but some don't. The Fill&Stroke and the Text&Font dialogs stay on top when clicking the document window, but the SPRect properties (for instance) does not. I found out there is a new window in my window manager called "SPRect attributes" (or "SPRect atributos", which is not correct in Spanish), which might explain the dis/appearance. Later on, there is this "Append filename extension automatically" (which is great) (I never understood why some apps wouldn't do it by themselves), but the thing is that if the filename has already the .svg extension, it will add another .svg to the name. I've looked in some other GNOME applications and they don't seem to behave like this. Screenshot-13 shows this: http://cortijodelrio.net/~ddiaz/directo/inks/Screenshot-13.png (Look also what happens when you have a very long filename; GTK issue, I guess.) The last thing is about international scripts. When trying to write Arabic I found out it wouldn't show it properly: text was written from left to right and with no glyphs ligature at all. The Text&Font (where you type in) shows it alright, but this is later changed. Is this going to be fixed with the Pango-ization? Looking forward to it. http://cortijodelrio.net/~ddiaz/directo/inks/Screenshot-14.png Just reporting. Greetings! Daniel Díaz yosoy@...31...

1 0

RE: inkscape win32 locale ps-output
by bulia byak 10 Apr '04

10 Apr '04

>I don't have problems with the ps-output. Should I anyway change the >codebase to svgostringstream? Strange but true, it seems to be immune. Maybe because it uses fprintfs and not printfs. Let's leave it as is for now. Thanks for your work on the patches. They're very good, I looked them over carefully and did not find any errors. Are you interested in more work on Inkscape codebase? If so we could give you developer access. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

insensitive, xml editor
by David Christian Berg 10 Apr '04

10 Apr '04

I've been bugged by this all day... Anyway, here we go. When turning an object to insensitive via the item properties menu, there's a line added in the xml: sodipodi:insensitive = "true" formally that was sodipodi:insensitive = "1" it seems, since I have a few objects I created with inkscape not long ago, that have that tag. Anyway, setting the value to either "false" or "0" in the xml editor doesn't do anything. Checking sensitive in the item properties dialog again, deletes the whole line. This can of course be done in the xml editor as well, but it's a wierd behaviour, that the value setting doesn't do anything. It also brings me to another point. When you select an attribute and press [del] the whole object is deleted. Rather than that the specific attribute should be deleted, I think. And when selecting a undeletable item, the "delete attribute" should be insensitive. What I also found to be very surprising, is, that I can select items within a insensitive group via ctrl+click, but am not able to select the insensitive item via shift+click or alt+click and then change it back to sensitive via the right-click menu, but as it seems to me have to use the xml editor to select it, and then either directly delete the insensitive attribute or use the item properties dialog to do so. David

3 5

Re: [Inkscape-devel] ps-export
by Peter Linnell 10 Apr '04

10 Apr '04

> > Message: 5 > From: David Christian Berg <david.berg@...240...> > Reply-To: david@...139... > To: inkscape-devel(a)lists.sourceforge.net > Organization: SIP Solutions > Date: Fri, 09 Apr 2004 21:46:02 +0200 > Subject: [Inkscape-devel] ps-export > > Where is the fun about ps-export when neither gradients nor imported > pngs nor transparency attributes are being exported? It is *not* a trivial job to code an exporter with these capabilities. Go ask the Ghostscript team if you have doubts. Furthermore, while some PS3 engines can support transparency, it is in fact PDF 1.4 spec. > Alright, it just that this would be handy for me right now. And speaking > of it, ps2pdf always creates A4 documents, as ist seems. Does anybody > know how to have it export A3 or any customized format? Or does anybody > know another app for it? > I would mention Scribus, but your previously announced distaste for Qt would preclude that. As a professional DTP IT consultant and member of the Scribus team, as well as assisting the Inkscape team, I can assure you nothing GPL'd _except_ Scribus is capable of the features you are looking for. The PDF exporter in Scribus has been optimized over three years of development by the main coder, Franz Schmid. My testing with pro PDF pre-flighting tools shows Scribus PDF quality to match and sometimes exceed many proprietary DTP applications. We on the Scribus team really admire the excellent and rapidly improving SVG capabilties and user friendliness of Inkscape. The Inkscape devels are a good friendly, smart bunch to boot. That it is developed with GTK and Gnome libraries is a *very* minor point. One of our devels runs Gnome as his primary desktop. Inkscape is *very* popular with Scribus users, because it has quickly become IMO the best drawing/SVG tool on Linux. Both teams are sharing ideas and striving to make import/export between both programs work smoothly between the two - sometimes difficult given the complexity of the SVG specs. Oh, by the way Scribus has Gnome code if it makes you feel better. The rendering engine uses libart_lgpl. Peter

1 0

Re: [Inkscape-devel] Calligraphy Pen
by bulia byak 10 Apr '04

10 Apr '04

>So really, I should look at how the free hand tool builds up a path. Which >code is that? The freehand tool itself is in draw-context.cpp (first half only, up to "pencil context") but it calls functions in helper/bezier-utils.cpp to create beziers from points obtained from the mouse. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] Calligraphy Pen
by bulia byak 10 Apr '04

10 Apr '04

>Do you guys want to work on top of the code in dyna-draw-context.cpp that >turns the users motions into a bezier path, or do you have plans for a new >path-to-bezier algorithm? As I explained, that tool creates simple closed paths that have no idea of mid-path or widths array. They are just closed paths with black fill, you can only edit their edge nodes. As such, they're hard to edit after they're drawn and therefore almost useless. What I've been proposing is a more usable approach where you have a midline path and an array of widths, and the final closed path gets calculated from them and updated automatically when you edit the midline or widths. The current dyna-draw code may help in developing this algorithm, but by itself it's a dead end IMHO. It's not worth to develop it further in its current state. One other thing that dyna-draw does is implements some advanced realtime smoothing with "drag", "mass", etc. This applies to the algorithm for transforming your mouse movements into a path (which would become the midline path in the new tool). Some people in our team are already working on making the current freehand tool produce smoother lines, and probably the result of their efforts will be good enough for the new calligraphic tool as well, even without "mass" or "drag" stuff. Maybe, or maybe not. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0