- Inkscape Devel - Inkscape Mailman

SVG in the press
by Taraben, Adib 20 Sep '05

20 Sep '05

http://www.linuxdevices.com/news/NS2394080884.html

4 3

Usage Notes
by Michael Wheeler 19 Sep '05

19 Sep '05

Hi all, When I have opportunities, I like to try out Inkscape for some of my freelance work and take notes. My freelance work is mostly doing artwork for those t-shirts you see in kiosks at the mall. Think "Coolest Grandpa in the World". A lot of tracing and finishing of scanned drawings. Anyway, I realized that I had a lot of notes from over several months and I thought I'd finally gather them together and send them to the list. I love the MMB panning and zooming, especially now that I can MMB pan even while I am in the middle of drawing a path with the pen tool. Is there any reason that Shift+MMB+drag couldn't serve the same function as LMB+drag with the zoom tool (zooming in on the area you've just dragged a box around)? I think it would really complete the middle mouse button as a document navigation tool. Shift+MMB+drag currently just pans the document, the same as regular MMB dragging. Dialogs pop-up to the front whenever I hover for more than a second over a toolbar button or menu. They appear to pop up simultaneously with the tooltips. This is under Win2k, It works correctly in Ubuntu. Is there any way that the HSL color picker could be fixed so that changing the value of one component would not affect the values of the other components? For instance, setting S to 0 often snaps H to 0 also. Other, less drastic value changes occasionally occur too. It is frustrating to pick out the exact hue I want, only to have it change when I start tinkering with the saturation or lightness. Align nodes is nice, but it would be more useful if there was an option to align to the center or average of the selected nodes. I love the node editing tool, especially now that i can drag curve segments and double click to add nodes! I use Illustrator at work and at home for freelance jobs and I must say that the path editing UI is one area where I find Inkscape to be head and shoulders above AI. The only problem is the speed. Forgive me for mentioning it (since I know everyone is aware of the slow rendering), but more than any other drawback this is the one that can turn using Inkscape from a pleasure into a headache. I've brought this up before, and people mentioned profiling, but it is a little bit over my head. I don't know if it is still worth doing, but some instructions are available at http://wiki.inkscape.org/cgi-bin/wiki.pl?Profiling for those who would like to try (maybe this page should be linked to the TestingInkscape page?). Anyway, I hope these notes are helpful. -Mike

4 5

Connector avoidance fix for ellipses and translated objects
by Michael Wybrow 18 Sep '05

18 Sep '05

Hello, I have posted a fix for the previously discussed problems with connector avoidance for circles, ellipses and arcs as well as translated objects. I am curently in the UK with a very bad internet connection and very limited computer access so I can't easily read mail or get on Jabber to tell where we are in the release. For this reason I have put the patch in the tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=1294687&group_id=… If the release hasn't already happened can someone please apply the patch before it does! Also, please check it compiles fine because while I fixed the problem on my laptop, I had to copy the changes by hand to get them anywhwere near the internet, and coulndn't connect to any of the machines at Monash where I would actually have been able to compile the change. I'll try to check replies to this message in the list in the next day or so. I'm back in Australia in a week so \i'll talk to you all then. Thanks, Michael

2 1

Is pressure sensitivity supported in X11 running under OS X?
by Jonathan Chetwynd 18 Sep '05

18 Sep '05

Is pressure sensitivity supported in X11 running under OS X? if it is, what configuration instructions are there? if not, what is the issue, and why hasn't it been fixed in the past three or four years? regards Jonathan Chetwynd please take care when replying not to copy across lists. Howtos for linux X11 regarding pressure sensitivity: http://linuxwacom.sourceforge.net/index.php/howto/inputdev http://ubuntuforums.org/archive/index.php/t-25151.html Wacom or other tablets use pressure sensitivity and applications such as GIMP and Inkscape use this facility, when available. Adobe Illustrator is a commercial application frequently used with wacom tablets and OS X. http://lists.apple.com/archives/X11-users OS X X11 mailing list archive

2 2

Inkscape stats 9/15/05
by Ben Fowler 18 Sep '05

18 Sep '05

I would respectfully disagree with both of the substantive points in this thread(!): On 9/16/05, Nicu Buculei <nicu@...398...> wrote: > Bryce Harrington wrote: > > > > [ snip ] > > > Where the project needs help right now is in closing bugs. > > We have our bug tracker quite well under control, but there > > are 258 open bugs, and it would be wonderful if we could cut > > that down significantly before the 0.43 release. If you can > > code, please check out if you can help close one or two, ... I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42! Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release. Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle. I suspect that I am missing something ... Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over. Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle). > Other projects keep from time to time some events called "bug > party", when people clean the bug/feature tracker, collaborating > over IRC and closing as much as possible as DUPLICATE, WON'T > FIX, INVALID, RESOLVED or prioritizing. It may have the benefit > of attracting new contributors and giving non-developers a way > to contribute. > > What do you think about the opportunity/usefulness of such a > bug party? > > At 258 bugs and 448 RFEs the number may be small enough and > the action not needed. I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones. I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time. I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important. Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ... That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ... Ben

10 22

Is pressure sensitivity supported in X11 running under OS X?
by Jonathan Chetwynd 17 Sep '05

17 Sep '05

Is pressure sensitivity supported in X11 running under OS X? if it is, what configuration instructions are there? if not, what is the issue, and why hasn't it been fixed in the past three or four years? regards Jonathan Chetwynd please take care when replying not to copy across lists. Howtos for linux X11 regarding pressure sensitivity: http://linuxwacom.sourceforge.net/index.php/howto/inputdev http://ubuntuforums.org/archive/index.php/t-25151.html Wacom or other tablets use pressure sensitivity and applications such as GIMP and Inkscape use this facility, when available. Adobe Illustrator is a commercial application frequently used with wacom tablets and OS X. http://lists.apple.com/archives/X11-users OS X X11 mailing list archive

1 0

Bounding Boxes
by Stephen Schrenk 17 Sep '05

17 Sep '05

Hi, I believe there is a problem with the way bounding boxes are calculated. At the moment the calculation assumes that lines have a >Round< join and cap style if the stroke is visible. This means, for example, that the bounding box of a 30-60-90 degree triangle does not preserve the proportions of the triangle and that a triangle with a Miter join style extends past the bounding box. It also means that a non-horizontal or vertical line with a Square cap extends outside the bounding box and that a line with a Butt cap doesn't reach the bounding box. I can't see any advantage to this particular definition. A better choice for defining the bounding box would be to use the entire visible area covered by an object. Advantage: More intuitive and probably what most people would expect. Disadvantage: More CPU intensive? May not be what is wanted for lines with markers - could ignore. There may be occasions where a different definition could be advantageous such as defining a bounding box assuming a Miter join style or using only the nodes (both preserve the proportions of regular objects). Perhaps these could be added as per object options. Tav

5 13

Re: [Inkscape-devel] Mac OS X developpement build
by Kees Cook 17 Sep '05

17 Sep '05

Hey, I just noticed your email didn't get sent to the list.... sorry I didn't respond; I didn't see it. :) We'll give you group access on sourceforge, and you can just upload it there (not through CVS or the file release section, but to the website area). If you've got CVS changes for packaging, put it in the patch tracker first, then we can move on to CVS. On Thu, Sep 15, 2005 at 05:41:41PM +0200, jiho wrote: > >We can make another directory up on sourceforge, alongside the win32 > >snapshots. > > I'll need CVS acces for that, which I don't have at the moment. my > sourceforge user account name is "irisson". > Where should I put the file exactly? I'm browsing inkscape CVS > without finding the win32 snapshot... > Then I guess that this must be linked from the download page. I would > be able to modify the download-en.inc file but I am no good in > german. How should I modify it: download the website, modify and > commit by CVS? -- Kees Cook @outflux.net

3 3

Re: [Inkscape-devel] Inkscape stats 9/15/05
by Nicu Buculei 16 Sep '05

16 Sep '05

Ben Fowler wrote: > I would respectfully disagree with both of the substantive points in this > thread(!): But you forgot to reply to the list ;) > On 9/16/05, Nicu Buculei <nicu@...398...> wrote: > >>Bryce Harrington wrote: >> >>>[ snip ] >> >> > Where the project needs help right now is in closing bugs. >> > We have our bug tracker quite well under control, but there >> > are 258 open bugs, and it would be wonderful if we could cut >> > that down significantly before the 0.43 release. If you can >> > code, please check out if you can help close one or two, ... > > > I am sitting on three patches, waiting for a thaw so that I can commit > without endangering other's activities. There was never much of a thaw > after 0.42! > > Ideally, the tree should be open just after a release for new work > including patches for minor bugs, also for developers' prized features, > as there will be a period for stabilisation before the next release. > > Just before a release, the emphasis should be on testing, packaging > and to a lesser extent on 'blocking bugs'. Cutting down the number > of open bugs by commiting is highly likely to expose other bugs or > problems with the code that require stabilisation and should be done > (IMHO) early in the release cycle. > > I suspect that I am missing something ... > > Personally, I would suggest that some manageable number > bugs (somewhere between 10 an 50 given the number of developers) > are marked as must fix before 0.43 and patches for other bugs (the > 'minor bugs' I mentioned above) are held over. > > Ideally this should be based on the importance to the end-user > rather than priority or ease of fixing. (High priority and easy to fix bugs > should most certainly be fast tracked, but again, at the beginning > or in the middle of a release cycle). > > >>Other projects keep from time to time some events called "bug >>party", when people clean the bug/feature tracker, collaborating >>over IRC and closing as much as possible as DUPLICATE, WON'T >>FIX, INVALID, RESOLVED or prioritizing. It may have the benefit >>of attracting new contributors and giving non-developers a way >>to contribute. >> >>What do you think about the opportunity/usefulness of such a >>bug party? >> >>At 258 bugs and 448 RFEs the number may be small enough and >>the action not needed. > > > I wholeheartedly agree with these data and your suggestions, until > the last line, where there is the implication that 250 open bugs is > a small number. Really, we should be aiming at zero bugs, and > should have 10 or fewer open ones. I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little. > I would urge every effort to getting non-coders interested in triaging > bugs and assigning priorities at all times. It is especially helpful to > have end-users prioritising bugs, as bugs which do not impact > the user community can be left to a future when there is more > time. > > I also note that many of the open bugs refer to the Windows > operating system, and unless those they are easily reproducible > they may never get seen by a developer unless the user > community can get behind them and insist that (some of) such > bugs are indeed important. Well, it may also be the case some of those bugs can't be reproduced at all or referring to old versions of Inkscape and can be simply closed. > Finally, if we are going to have hundreds of open bugs, we should > consider an even/odd policy, and do 'bug fixes only' for even > numbered releases ... > > That may not desirable if we have a large number of RFEs and/or > features which developers are interested in. Certainly in the > proprietary world, there are products which have benefitted > from a period of stability in which six months of the developers > time was spent on stabilisation, performance and bug fixing > rather than new features. Ideally we need to know whether the > user community would vote for quality and bug fixes or new > features ... > > Ben > -- nicu

5 7

Using Inkscape.
by Gavin Band 16 Sep '05

16 Sep '05

Hi, First let me thank the developers for the fantastic Inkscape. I have a couple of questions about its usage. (It's a wish-list, really. I am using Inkscape 0.42.2). First, when using Inkscape on a large file such as this one: http://www.liv.ac.uk/~gband/shift_class_classification.svg it's impossible to zoom out so one can see the whole picture at once. Secondly, it would seem to me that one should "export" to file types which are not rich enough to recover the whole file, and "save" to other file types. But in Inkscape one has to "save as" (for example) Postscript. Then, if you want to keep a master copy for later editing you has to save as .svg as well, forcing you to keep choosing between the two filenames. This also seems inconsistent with the command-line switches where there is a --export-ps switch. Can't "Export bitmap" be turned into "Export", offering a choice of bitmaps, and remembering the chosen filename? Thanks, gav.

12 35