The Freehand tool seems much smoother in recent incarnations. vellum
On Sat, Nov 20, 2004 at 08:45:36AM +1100, vellum wrote:
The Freehand tool seems much smoother in recent incarnations.
Thanks for the info. How recent is recent? In particular, before or after 2004-11-22 05:15:51 UTC, when I committed a partial regression in the sophistication of the fitter that happens to improve things for our current pencil tool.
My understanding is that current CVS is better than 0.39, but overall worse than sodipodi 0.34. My current intent is to leave freehand tool as it is for 0.40 (except for trying to address a rare assertion failure), and do more experimentation after 0.40 is released.
pjrm.
Thanks for the info. How recent is recent? In particular, before or after 2004-11-22 05:15:51 UTC, when I committed a partial regression in the sophistication of the fitter that happens to improve things for our current pencil tool.
I doubt he's using as recent a build.
My understanding is that current CVS is better than 0.39,
Yes.
but overall worse than sodipodi 0.34.
No. As I have demonstrated, it's better for some uses but worse for others. It's just different, let's not try to compare them in terms of better/worse.
My current intent is to leave freehand tool as it is for 0.40 (except for trying to address a rare assertion failure), and do more experimentation after 0.40 is released.
Sounds like a good plan.
Hi Peter, Due to machine troubles I have not been able to get to the list for about a week.
regarding Freehand drawing you said:
Thanks for the info. How recent is recent? In particular, before or after 2004-11-22 05:15:51 UTC, when I committed a partial regression in the sophistication of the fitter that happens to improve things for our current pencil tool.
It was before 22/11, possibly around build 041118. However, I have just brought down build 0411221024 and have compared it with SP0.34. Firstly, Inkscape Fd is smoother now than it has been but it still falls far short of 0.34, at least on my system. I did a small comparison side-by-side comparison drawing a shape first on Inkscape and then on Sodi Podi. Then another shape etc. and noted nodes.
Shape Nodes (Inkscape) Nodes (SodiPodi) triangle 18 8 figure S 19 8 circle 23 6 square 19 8 random1 32 10 5 link chain 42 16
Not strictly scientific but there is some consistency there. I think some people have said they think SP is sluggish. Yes it is slower but certainly not sluggish (again on my machine). However, SP has a very nice feel to it and as a user I like it. In everything else I reckon Inkscape is streets ahead but in smoothness........
Again this may be a personal thing but when I am drawing maps I nearly always find it simpler to start from a simpler outline and add nodes where necessary for fine tuning. Removing nodes nearly always means having to do more fiddling with the ones that are left. The Inkscape method certainly seems to create more nodes than SP. Yes I know I can 'simplify' but I don't necessarily want to do that.
Anyway as Bulia said:
but overall worse than sodipodi 0.34.
No. As I have demonstrated, it's better for some uses but worse for others.
If worse equals less smooth then Yes. It is.
It's just different, let's not try to compare them in terms of better/worse.
I agree not better/worse but maybe let's not forget there is very real difference there which may have a significant impact on people coming to Inkscape for the first time.
Peter said:
My current intent is to leave freehand tool as it is for 0.40 (except for trying to address a rare assertion failure), and do more experimentation after 0.40 is released.
Sounds great to me and I look forward to the results.
vellum
It's just different, let's not try to compare them in terms of better/worse.
I agree not better/worse but maybe let's not forget there is very real difference there which may have a significant impact on people coming to Inkscape for the first time.
Let's not start these arguments again, OK? :) See http://inkscape.org/cgi-bin/wiki.pl?FreehandComparison where I posted my example in which Inkscape reproduces my handwriting pretty close to paper pen, while Sodipodi turns it into a horrible mess. For me, this is more than decisive, and I honestly don't understand how Sodipodi's tool can be used other than as a toy. Let's just accept that everyone has a different manner of drawing and different requirements.
All of the tutorials can be found at: http://scislac.com/inkscape/ Still haven't got my cvsNT issue resolved, so I can't commit yet. Bulia, sorry for not getting them to you last night.
They are not done in flowtext for this version as the ability to edit the text easily still isn't in there (nothing wrong with the XML editor, but the text tools still can't modify it). Changes are as follows: tutorials are now layered, keystrokes are bolded, more consistency to directions regarding menu items, couple typos corrected, updated Tips & Tricks (from the wiki), and the tracing tutorial should be good to go for now as well.
Unfortunately the calligraphy one just isn't all that good yet, so we may want to temporarily edit it down or potentially omit it from this release (as I started writing it from a more "all encompassing" position, but didn't have the time to add all that I'm intending). You'll see what I'm talking about when you read it. Perhaps editing out a little of the stuff that would lead into more (that doesn't exist yet) would be ideal. That way we can still educate people on the controls of the tool at the very least.
The history part is ok (not great yet), but it mentions different styles which I didn't address yet with examples or tips. The glaring omission however is the lack of filled in examples. I've tried in a few 30 min blocks to see what I can do, but my examples are not consistent enough at this point to include. I think a monkey with a stick could probably do better than I'm achieving. =) Bulia or Brisgeek would produce much better examples than I can without a doubt.
For .41 I will convert all tutorials to flowtext, and if it's possible to use svgz files, I will save them like that as well (reduction on file size seems appealing, but flowtext alone will probably cut size way down too, so we'll see). I also intent to try and see about writing raw XML files (for source) and doing conversions from them to SVG or other formats, as experimenting in the name of flexibility can't hurt.
Feel free to shoot me any comments or thoughts.
-Josh
On Tue, Nov 23, 2004 at 08:39:50AM -0700, Joshua A. Andler wrote:
All of the tutorials can be found at: http://scislac.com/inkscape/
I've pulled them down into CVS now.
Feel free to shoot me any comments or thoughts.
First, they look great!
Since Inkscape doesn't resize within screen boundries, can you reduce the default tutorial size back to 800x600, as in the originals? That's a reasonable size for folks on smaller screens:
- inkscape:cx="127.56063" - inkscape:cy="5467.4815" - inkscape:window-width="780" - inkscape:window-height="580" - inkscape:window-x="0" - inkscape:window-y="0" + inkscape:cx="128.89392" + inkscape:cy="5380.9403" + inkscape:window-width="1280" + inkscape:window-height="934" + inkscape:window-x="-4" + inkscape:window-y="-4"
I've updated the ones in CVS to be resized.
On Tue, Nov 23, 2004 at 08:39:50AM -0700, Joshua A. Andler wrote:
All of the tutorials can be found at: http://scislac.com/inkscape/
I've pulled them down into CVS now.
Awesome, and thanks.
Feel free to shoot me any comments or thoughts.
First, they look great!
Since Inkscape doesn't resize within screen boundries, can you reduce the default tutorial size back to 800x600, as in the originals?
That's
a reasonable size for folks on smaller screens:
Doh! I didn't even think of the resolution issue, I'll note it for next time. Is Inkscape not resizing w/in screen boundaries a GTK thing? Just wondering because in Gimp, Inkscape & Gaim (the GTK apps I use in Windows) on my dual monitor setup it ALWAYS opens windows in an inconvenient place. Essentially, sending a file between the dual monitor and a single monitor setup is always a hassle on first open.
inkscape:cx="127.56063"
inkscape:cy="5467.4815"
inkscape:window-width="780"
inkscape:window-height="580"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:cx="128.89392"
inkscape:cy="5380.9403"
inkscape:window-width="1280"
inkscape:window-height="934"
inkscape:window-x="-4"
inkscape:window-y="-4"
I've updated the ones in CVS to be resized.
Thanks!
-Josh
On Tue, Nov 23, 2004 at 09:34:29AM -0700, Joshua A. Andler wrote:
Doh! I didn't even think of the resolution issue, I'll note it for next time. Is Inkscape not resizing w/in screen boundaries a GTK thing? Just wondering because in Gimp, Inkscape & Gaim (the GTK apps I use in Windows) on my dual monitor setup it ALWAYS opens windows in an inconvenient place. Essentially, sending a file between the dual monitor and a single monitor setup is always a hassle on first open.
It's a bug/rfe right now. I honestly haven't played with it at all.
Since inkscape restores window position from the file settings, I think it may be different than gimp, etc, since those placements are usually left up to the window manager.
--- "Joshua A. Andler" <joshua@...533...> wrote:
All of the tutorials can be found at: http://scislac.com/inkscape/ Still haven't got my cvsNT issue resolved, so I can't commit yet.
If your using CVS on windows you might want to try tortoise from http://www.tortoisecvs.org/ integrates CVS into explorer, and works a treat.
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
All of the tutorials can be found at: http://scislac.com/inkscape/ Still haven't got my cvsNT issue resolved, so I can't commit yet.
If your using CVS on windows you might want to try tortoise from http://www.tortoisecvs.org/ integrates CVS into explorer, and works a treat.
Beautiful... works like a charm. Thanks.
Joshua, I'm working on the calligraphy one and I noticed that you did the bold key names as separate text oobjects. This is a really bad way to do it, please revert this change if you can. Sorry I did not discuss this before, I just did not expect that you will do this. The correct way to do this is of course by creating child <tspan>s in the main text object and assigning style to them. That's what I meant when I told you we don't yet have UI for this. In a future version it will be as easy as selecting a fragment with mouse drag or shift+arrows and pressing a button for bold or italic. The entire text will be editable as a whole. This is possible to do now via XML editor or by manual editing of SVG, and when you mentioned you're still doing it I assumed this was what you were doing. The way you did it (in Calligraphy tutorial at least) is bad because the text is not editable and the alignment is easy to break. Please change that. Here's how you do it properly:
<text><tspan sodipodi:role="line">This is some text with <tspan style="font-weight:bold">bold</tspan> fragment in it.</tspan></text>
K... I will correct them all here this afternoon. Sorry about that, it was the fastest way to achieve the bolding not knowing about being able to do child tspans (which I should have just asked about, and will make sure to in the future).
Would you prefer that I do the child tspans on the existing tutorials, or should I just spend a little more time and flowtext it all (and do the bold in that)?
Actually I suppose the better question is... If it is done with the tspans in the tutorials current form, will the text still be editable via the Text UI? If so it makes sense to me to do that instead of flowtext (at this point), so people can edit the text w/o the XML editor... I assume if it does work w/ text UI, they would lose the "extra" formatting when applying changes though, correct?
Let me know your thoughts so I can get cranking...
-Josh
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Tuesday, November 23, 2004 1:03 PM To: Joshua A. Andler Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Tutorials for .40
Joshua, I'm working on the calligraphy one and I noticed that you did the bold key names as separate text oobjects. This is a really bad way to do it, please revert this change if you can. Sorry I did not discuss this before, I just did not expect that you will do this. The correct way to do this is of course by creating child <tspan>s in the main text object and assigning style to them. That's what I meant when I told you we don't yet have UI for this. In a future version it will be as easy as selecting a fragment with mouse drag or shift+arrows and pressing a button for bold or italic. The entire text will be editable as a whole. This is possible to do now via XML editor or by manual editing of SVG, and when you mentioned you're still doing it I assumed this was what you were doing. The way you did it (in Calligraphy tutorial at least) is bad because the text is not editable and the alignment is easy to break. Please change that. Here's how you do it properly:
<text><tspan sodipodi:role="line">This is some text with <tspan style="font-weight:bold">bold</tspan> fragment in it.</tspan></text>
Would you prefer that I do the child tspans on the existing tutorials, or should I just spend a little more time and flowtext it all (and do the bold in that)?
tspans won't be lost, we will have a command "flow text into shape" which will make flowtext out of regular text, preserving all formatting tspans in it (but removing line tspans of course).
Actually I suppose the better question is... If it is done with the tspans in the tutorials current form, will the text still be editable via the Text UI?
Yes. It's editable as usual, and the formatting is not lost in editing. You can try it.
If so it makes sense to me to do that instead of flowtext (at this point), so people can edit the text w/o the XML editor...
Sure, flowtext can wait, formatting tspans are orthogonal to that and won't be wasted even when we move to flowtext.
And please don't touch calligraphy tutorial, I'm editing it right now and I will convert it myself. Do all the others.
I read the last message too... got it! Will have them fixed shortly.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Tuesday, November 23, 2004 1:40 PM To: Joshua A. Andler Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Tutorials for .40
And please don't touch calligraphy tutorial, I'm editing it right now and I will convert it myself. Do all the others.
On Tue, 23 Nov 2004, Joshua A. Andler wrote:
Date: Tue, 23 Nov 2004 08:39:50 -0700 From: Joshua A. Andler <joshua@...533...> To: 'bulia byak' <buliabyak@...400...> Cc: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Tutorials for .40
All of the tutorials can be found at: http://scislac.com/inkscape/ Still haven't got my cvsNT issue resolved, so I can't commit yet. Bulia, sorry for not getting them to you last night.
For .41 I will convert all tutorials to flowtext, and if it's possible to use svgz files, I will save them like that as well (reduction on file
I would expect the package formats to include compression, are you sure using svgz is a good idea, does it make that much difference? In the belief that 'anything that can go wrong will' i tend to keep small individual files uncompressed so I can always edit them with any crappy text editor (no messing with zcat or aything clever like that) and only ever compress groups of files or backup and what not.
The point "what difference" does it make applies to both compressing and not compressing, I just want to note that I'd prefer if you didn't but it is an almost inconsequential detail.
size seems appealing, but flowtext alone will probably cut size way down too, so we'll see).
Would it be practical to try and seperate out the style information for the various SVGs into one external stylesheet or is that too awkward at present?
I also intent to try and see about writing raw XML files (for source) and doing conversions from them to SVG or other formats, as experimenting in the name of flexibility can't hurt.
When you say raw XML do you mean like Docbook or something else specific? Docbook is the XML format that most projects use for their documentation and there are already ways to generate many other formats from docbook.
Feel free to shoot me any comments or thoughts.
My suggestions should not be taken as shooting at anything, just adding ideas to the stew. :)
- Alan
participants (7)
-
Alan Horkan
-
bulia byak
-
John Cliff
-
Joshua A. Andler
-
Kees Cook
-
Peter Moulder
-
vellum