- Inkscape Devel - Inkscape Mailman

RE: [Inkscape-devel] shift+click to select broken
by MenTaLguY 20 Dec '03

20 Dec '03

On Fri, 2003-12-19 at 21:42, bulia byak wrote: > >There's a really simple way of doing this. Every desktop has an integer > >'key' associated with it, that you can use to match against > >SPItemView::key. > > Does not work: if child is an SPItem then child->display->arenaitem->key > exists but is always 0. Or am I doing something wrong? No, use child->display->key ... or, actually, since as I said child->display is the head of a linked list: SPItemView *iv; NRArenaItem *arenaitem; arenaitem = NULL; for ( iv = child->display ; iv ; iv = iv->next ) { if ( iv->key == dkey ) { arenaitem = iv->arenaitem; break; } } .. then use arenaitem as appropriate. (dkey being the dkey you got from the SPDesktop, of course) -mental

1 1

RE: [Inkscape-devel] shift+click to select broken
by MenTaLguY 20 Dec '03

20 Dec '03

On Fri, 2003-12-19 at 22:19, bulia byak wrote: > >So, to keep this programmer-friendly, I think basically what you need is > >an sp_desktop_item_at_point() that figures out what NRArena to use, and > >calls sp_document_item_at_point(). > > > >To get the NRArena for a desktop, you can use ((SPCanvasArena > >*)SP_DT_ACETATE (desktop))->arena. > > doesn't work too. Printing > > (NRArena *) (((SPCanvasArena *) SP_DT_ACETATE (desktop))->arena) > > and > > child->display->arenaitem->arena > > gives: > > arenas 0x315, 0x8453b38 Actually... I think it's SPDesktop::drawing, not SPDesktop::acetate; sorry... But use the dkey method anyhow -- that's the "correct" way. -mental

1 0

RE: [Inkscape-devel] shift+click to select broken
by bulia byak 20 Dec '03

20 Dec '03

>On Fri, 2003-12-19 at 04:25, bulia byak wrote: > > Fixed, please test. I had to make use of >sp_document_partial_items_in_box() > > for this, which was in the code but never used, and fixed a bug in it so >it > > could actually work. > >Hrm, I still can't get shift+click (versus shift+drag) to work. :/ That was a bad solution anyway. It just used bounding box, so objects with holes etc. were treated as opaque rectangles. Now a much better solution is checked in. I had to dig into the arena code (something I was trying to avoid) but I think I succeeded. Please test now. Here's what I did: in document.cpp, a new function sp_document_item_at_point() was added, to complement items_in_box and partial_items_in_box. It calls nr_arena_item_invoke_pick() on all items to find those that are pickable at the given point, and returns the topmost of them. Now select-context.cpp simply uses sp_document_item_at_point() in its root_handler when shift-clicked and does selection toggle. This means we can do without the item that was passed on from the arena code - if we have mouse coordinates, we can always find out the item under mouse. This was necessary in this case because I do shift-rubberband in root_handler, and I must process shift-click in it too, and root_handler does not get an item as an argument. The same approach can be used for ctrl-clicking to select within group. Mental, if you think this approach is acceptable, I'll go on and try to implement ctrl-click. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

shortcut regressions
by MenTaLguY 20 Dec '03

20 Dec '03

Okay, I've fixed the most glaring shortcut key regressions. Still to fix: * shortcut hints should update when shortcut binding is changed * SPButton tooltips should show shortcut hint -mental

1 0

RE: [Inkscape-devel] Minor CVS request for Win32
by bulia byak 19 Dec '03

19 Dec '03

>It would be nice, however, if a kindly committer would add the >extra codepage source files needed for the build to src/libnrtype. >These are not touched at all by the Linux/Unix build, so they will >not break anything. However, (IMHO) they really should be >in the source tree. There are only about 12 .c files: > >http://prdownloads.sourceforge.net/sodipodi/sodipodi-codepages-1.0.zip?down… > >BUT, with the change to C++, they need to be changed, too. Here are the >same files, but tweaked for C++: > >http://troi.lincom-asg.com/~rjamison/files/nrtype-codepages.zip I can put them up on CVS, if nobody's yet done that. Where exactly do they belong - src/libnrtype? What else needs to be added if we want the CVS to be compilable on win? Thanks, it would be really nice to have an up-to-date win build. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

article from osnews.com
by Jonathan Phillips 19 Dec '03

19 Dec '03

"If you're looking for vector graphics software, you'll also come up empty handed. I do 99% of my layout work in Illustrator or Freehand and there is nothing even close on Linux. SodiPodi and a couple others may be contenders later on down the road, but right now they are far from being serious competitors to either Illustrator or Freehand." Read this article on differences between win, lin, osX and the big advantages of big apps. http://www.marcusvorwaller.com/weblog/archives/000011.html Jon -- Jonathan Phillips <jon@...15...>

1 0

keyboard shortcuts broken
by MenTaLguY 19 Dec '03

19 Dec '03

Please note that keyboard shortcuts are currently broken in CVS HEAD -- the keyboard shortcut code needs reworking. (SPActions are no longer global, so SPActions no longer work for holding global keybindings...) Anyway, I'll see about reworking this tonight. -mental

1 0

color selector arrows
by MenTaLguY 19 Dec '03

19 Dec '03

Hrm, I like the new double arrows, but having one white, one black is a little distracting. Often, dragging from one end of the slider to the other, the top one starts to disappear, and I have to switch to focusing on the (now barely visible) bottom one instead. I liked the "karaoke" arrows (black with a white outline) much better -- could we try double karaoke arrows? -mental

1 0

Re: First sodipodi+scribus doc experience
by P Linnell 19 Dec '03

19 Dec '03

Note the orginal message did not get to the Scribus list. Posting is subscriber only. Please see my comments in-line. > Message: 13 > From: Jonathan Phillips <jon@...15...> > To: inkscape <inkscape-devel(a)lists.sourceforge.net> > Date: Fri, 19 Dec 2003 09:05:36 -0800 > Subject: [Inkscape-devel] [Fwd: [Sodipodi-list] First sodipodi+scribus doc experience] > > -----Forwarded Message----- > From: Tarax <tarax.mdk@...118...> > To: sodipodi-list(a)lists.sourceforge.net, scribus <scribus@...119...> > Subject: [Sodipodi-list] First sodipodi+scribus doc experience > Date: Fri, 19 Dec 2003 15:00:25 +0100 > > Hi yall, > > First let me tell you that it is a REAL GREAT PLEASURE to use these two > wonderfull softs together :-))) Using sodipodi (0.33) for a little while now, > yesterday I created my first document with Scribus (1.1.4cvs, build id > 29.11.03) importing svg drawings. Actually this was a business card to be > laid down on paper by a professional printing company. At the end of the day > I felt quite well with scribus and the PDF (with transparency) was validated > by the "printer"... JOY ! ;-) > > Nevertheless, I encountered few issues... > First, importing in scribus from a sodipodi svg: > - path width and shape stroke is abnormaly fat, but reducing it to 0 then > resetting the proper thickness works well > - line breaks in text elements disapear in scribus and bitstream vera sans > bold italic becomes bitstream vera sans roman Could be different naming convention of fonts. Note, I find it much safer and consistent to export "plain" SVG from Inkscape or Sodiopodi. We have tested a significant part of the W3C SVG 1.1 test suite for import and rarely have problems - excepting unsupported features i.e. animation, scripting. > - it would be great to be able to open/create a new scribus document straight > from an svg one, thus setting automaticaly the document size (and in future > evolutions with svg print support, multi pages documents...:-) > size and proportion doesn't seem to be very stable (50x64mm object -> 71x84mm) > You should be able to open Scribus and then select Flie > Import > SVG Image and have it create a doc. I checked the current cvs and this does work as designed. Because the way measurements can be changed in Scribus, you still are probably safer creating a page and then importing SVG. If the importer, finds issues with the SVG file, it simply will do nothing. > "Cleaning" up the doc then exporting it back in svg with scribus and opening > this last file in sodipodi: > - the path which hadrounded ends has now square ends. Resetting the proper > choice is ok. Will look at this... > - 91x61mm doc with 2mm margins => 72.8x48.8mm svg doc in sodipodi > - texts are exported in one text element but, in it, a tspan is created for > each character, which is not very handy to work with then :-S > > Finally, it would be great if guides could be kept from one soft to the other > and back. > > These are few things I have noticed... I'll certainly be more accurate in my > comments as I'll experiment further... > > Anyway, many thanks again > > Tarax > > PS: little OT, I have fonts available in sodipodi which aren't in scribus, > could someone give me few advices about that problem ? Which distro and which fonts? This has largely been fixed in Scribus 1.1.1 with a new font discovery mechanism. At the moment, for getting really high quality PDF from SVG, SVG > Scribus > PDF can't be beat. Franz has put a ton of work into making the PDF exporter really robust and correct to the PDF specs. I test Scribus PDF's almost daily using professional PDF pre-flight tools, as well as a new Fiery RIP. Generally, I find if it RIPS, most printers should have no problems with Scribus PDF's. Right now, there is really nothing in open source which can generate the kind of 'press-ready" PDF like Scribus. Ghostscript 8.1+ has many improvements in pdfwrite, but its still in progress. Mind you the SVG importer is quite new code, but it is quite functional and usable. There are also detailed notes on http://scribus.net in the documentation. When you have issues, please drop in on #scribus at freenode.net or post to the mailing list. All the devel team monitor these closely. Cheers, Peter

1 0

[Fwd: [Sodipodi-list] First sodipodi+scribus doc experience]
by Jonathan Phillips 19 Dec '03

19 Dec '03

-----Forwarded Message----- From: Tarax <tarax.mdk@...118...> To: sodipodi-list(a)lists.sourceforge.net, scribus <scribus@...119...> Subject: [Sodipodi-list] First sodipodi+scribus doc experience Date: Fri, 19 Dec 2003 15:00:25 +0100 Hi yall, First let me tell you that it is a REAL GREAT PLEASURE to use these two wonderfull softs together :-))) Using sodipodi (0.33) for a little while now, yesterday I created my first document with Scribus (1.1.4cvs, build id 29.11.03) importing svg drawings. Actually this was a business card to be laid down on paper by a professional printing company. At the end of the day I felt quite well with scribus and the PDF (with transparency) was validated by the "printer"... JOY ! ;-) Nevertheless, I encountered few issues... First, importing in scribus from a sodipodi svg: - path width and shape stroke is abnormaly fat, but reducing it to 0 then resetting the proper thickness works well - line breaks in text elements disapear in scribus and bitstream vera sans bold italic becomes bitstream vera sans roman - it would be great to be able to open/create a new scribus document straight from an svg one, thus setting automaticaly the document size (and in future evolutions with svg print support, multi pages documents...:-) size and proportion doesn't seem to be very stable (50x64mm object -> 71x84mm) "Cleaning" up the doc then exporting it back in svg with scribus and opening this last file in sodipodi: - the path which hadrounded ends has now square ends. Resetting the proper choice is ok. - 91x61mm doc with 2mm margins => 72.8x48.8mm svg doc in sodipodi - texts are exported in one text element but, in it, a tspan is created for each character, which is not very handy to work with then :-S Finally, it would be great if guides could be kept from one soft to the other and back. These are few things I have noticed... I'll certainly be more accurate in my comments as I'll experiment further... Anyway, many thanks again Tarax PS: little OT, I have fonts available in sodipodi which aren't in scribus, could someone give me few advices about that problem ? -- Jonathan Phillips <jon@...15...>

2 1