- Inkscape Devel - Inkscape Mailman

all keys work regardless of mouse position
by bulia byak 02 Jan '04

02 Jan '04

OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes. I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas). Please test the program thoroughly. This change may well have broken something I did not notice. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

fixing NR precision issues
by MenTaLguY 02 Jan '04

02 Jan '04

Okay, really more generally what we need to do is replace e.g. NRRectL and NRRectS with a single type ... maybe NRIRect. That was the general effect of changing NRShort and NRLong to the same width anyway, since the structures don't differ at all except in the precision they use. -mental

2 3

[Fwd: Re: purpose of s/double/Coord/ change in nr-types.h]
by MenTaLguY 01 Jan '04

01 Jan '04

-----Forwarded Message----- From: MenTaLguY <mental@...3...> To: Peter Moulder <Peter.Moulder@...38...> Cc: Nathan Hurst <njh@...5...>, Inkscape ML <inkscape-devel@...142...ge.net> Subject: Re: purpose of s/double/Coord/ change in nr-types.h Date: Thu, 01 Jan 2004 15:47:01 -0500 On Thu, 2004-01-01 at 04:55, Peter Moulder wrote: > I believe that in revision 1.13 of src/libnr/nr-types.h you introduced a > `typedef double Coord' (CVS comment "removed *S variants of NR structs"). > > Can you please document where Coord is to be used, or the purpose of > this change? > > Knowing the purpose of the type, or how the typedef may change in > future, helps programmers to decide when to use Coord and when to use > double. The purpose of NR::Coord and NR::ICoord are to provide "real" and integer types used for storing coordinates in the rendering subsystem (and consequently having sufficient precision for that purpose). (I'll add doxygen comments accordingly) The motivating factor here was eliminating the entire class of bugs caused by switching between various precisions so much, particularly in the case of integer arithmetic. If Coord and ICoord are used consistently for math involving coordinates (and have sufficient precision), we'll have many fewer headaches with precision issues. I erred on the side of using Coord everywhere at first because I think it's less work to revert the few instances where it's not appropriate rather than the other way around. Probably non-libnr code should have little reason to use them (operator*(double, NR::Point) should probably remain with the double, though maybe it should have an NR::Coord variant too). I will let Nathan be the ultimate judge of where it's appropriate and where it's not, since the NR:: stuff is his purview at this point. -mental

1 0

Inkscape Status 2003-12-31
by Bryce Harrington 01 Jan '04

01 Jan '04

Project Status Wednesday, December 31, 2003 The past couple weeks have seen work in a variety of areas. Ctrl-click selection within groups, including multiple and nested groups has been implemented. The new inset/outset capability is receiving a lot of testing attention. The Win32 build of Inkscape has also been a focus of development efforts over the past couple weeks, and it's expected that 0.37 will see much improvement in this area. A few issues have arisen and been resolved. The issue of handling comments in SVG documents was brought up by a Sodipodi user; comments are not always preserved when editing in Sodipodi or Inkscape. Fortunately, some good ideas have been voiced for addressing this. A second and much more critical issue has been raised regarding Gtkmm. As planned since early in the project, we began incorporating Gtkmm into Inkscape following the 0.36 release. Quickly it became evident that this introduced severe dependency issues. Gtkmm 2.x is not available commonly on most Linux distros. On Windows it adds to the DLL download weight. Most distressingly, it isn't yet ported to OSX. Due to these reasons we've decided the best course of action is to postpone use of Gtkmm until the library is more widely available. Statistics Nov 02 Nov 15 Nov 29 Dec 15 Dec 31 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 6103 4391 3676 2452 2444 (56.2%) (68.5%) (73.6%) (82.4%) (82.5%) Max Week's Rank on SourceForge: 6023 62 37 27 22 (56.8%) (99.6%) (99.8%) (99.8%) (99.9%) Total SF Page Views 200 * 50,000 86,000 107,600 Total SF Downloads 0 * 1700 3640 4,751 Total Freshmeat URL Hits 0 746 1121 2237 2567 Total Freshmeat Subscriptions 0 16 19 28 30 Lines of Code in src/: 115,754 115,901 116,970 132,134 165,664 Code lines 100,549 132,458 Comment line 11,591 12,234 Blank 20,559 21.540 Lines of Docs in doc/: 1,135 1,135 2,100 2,225 2,615 Lines of content in website: 74 1,173 1,624 2,090 2,261 Size of the Inkscape wiki: 0 3,700 5,737 7,385 11,062 Hours since last ChangeLog mod: 90 6 2 21 0.8 Bugs open/total: 0/0 9/15 40/51 67/111 66/130 Features open/total: 0/0 18/18 23/24 40/45 103/115 Patches open/total: 0/0 1/ 6 5/20 6/25 4/32 CVS Commits (as per inkscape-cvs): 148 481 963 * 1580 Inkscape-devel membership: 4 49 61 64 65 Inkscape-announce membership: 0 9 14 16 20 * - Statistics unavailable

1 0

Re: [Sodipodi-list] 
by Jonathan Phillips 01 Jan '04

01 Jan '04

Maybe a warning dialog or a status bar update would be positive to notify the user if a comment is orphaned in someway. I know though this would require some intelligent coding. jon On Wed, 2003-12-31 at 15:17, MenTaLguY wrote: > I guess one thing to think about is how to deal with Sodipodi's > "advertising" comments if comment preservation were added. > > Obviously we wouldn't want to add an advertisment comment to the > document if one already existed, or they'd start piling up every time > one was saved. > > -mental -- Jonathan Phillips <jon@...15...>

2 1

Re: [Inkscape-devel] Nuke the fake config?
by bulia byak 01 Jan '04

01 Jan '04

>I didn't think about the gen-nrconfig change very closely when it was >first made, but in retrospect, since NRShort is a general-purpose type >with a precision implied by its name, changing its precision is probably >a bug in itself. > >The correct fix is to replace uses of NRShort that require more >precision with a type that provides it -- e.g. NRLong, or better gint32. Why "better"? What if one day, we need 64 bit precision - do a global search and replace again? The NR* stuff was there exactly for this: a layer of abstraction that allows to change the actual precision quickly - and it was not "a bug" because the typedefs are there for exactly this purpose (and they were not "general purpose" becaue the NR prefix limited their scope pretty narrowly to the NR subsystem). Frankly I don't understand why it was necessary to kill it and replace with hard-coded 32-bit types (I can understand getting rid of nr-config.c, but not this). Anyway, it's not my domain, so please fix it one way or the other, so long as it's fixed :) _________________________________________________________________ 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…

3 4

SPOffset UI
by bulia byak 31 Dec '03

31 Dec '03

Now there are two pairs of inset/outset commands: one creates the SPOffset object and the other simply offsets a path, leaving it as a path. Which pair is linked to the menu commands can currently be changed by commenting/uncommenting within sp_selected_path_offset() and sp_selected_path_inset() in splivarot.cpp. I propose the following UI: - "Inset path" and "Outset path" commands act depending on the type of the selected object(s). For SPOffset objects, they increment/decrement radius by options.insetdistance (to be added to the preferences, no more relying on stroke width please!). For all other objects, they do one-time offset leaving objects as paths (or converting them to paths if necessary) also by options.insetdistance. If there are several objects selected, each one is treated according to its type. - The third command, "Dynamic inset/outset", creates an SPOffset with zero radius. It also flashes to the statusbar, "Use node editor to inset/outset the path interactively." If there are no objections, Fred, could you please implement these three commands and I will put them into the menu and in shortcuts. See this page on how to create/access a preferences value: http://www.inkscape.org/cgi-bin/wiki.pl?HandlingPreferences More issues: - The splotches bug is fixed, but now interactive offsetting has become much slower. With a text string, I need to wait at least a second after dragging the control before it regenerates the path. Is this inevitable, or can it be optimized somehow? - The quality of offset in SPOffset object is very good, however the sp_selected_path_do_offset() function creates ugly artefacts (e.g. try it on a text string) even when applied _only once_. Why the difference? - Please use statusbar API to report errors, instead of g_warning: http://www.inkscape.org/cgi-bin/wiki.pl?StatusBar Whenever a command cannot perform its action, it must provide a reason for it in the statusbar. Also please don't forget to enclose all text strings shown to the user into _("...") so they can be translated. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Re: [Inkscape-devel] Nuke the fake config?
by bulia byak 31 Dec '03

31 Dec '03

>For those who were not on Jabber last night: > >Done. I replaced the following definitions >with GLib types: >NRLong gint32 >NRULong guint32 >NRShort gint16 >NRUShort guint16 You broke zooming with that change, because previously I patched gen-nrconfig so that shorts are not shorts but actually ints. Now shapes disappear at about 69x zoom. See this patch: http://sourceforge.net/tracker/index.php?func=detail&aid=854506&group_id=93… Please restore the ints precision as per this patch, so that zooming works again! _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

RE: [Inkscape-devel] RE: offset width modifying
by bulia byak 31 Dec '03

31 Dec '03

I've tried the new offset object - really impressive! For those who haven't tried it yet, you can now interactively adjust the inset/outset value by dragging a control point (similar to e.g. rounding a rect) and it will be redrawn in real time. You can also vary the radius attribute of the object in XML editor to achieve the same result. The quality and precision of the outline is very good (at least compared to the previous attempts to do multiple in/outsets). A few comments: - The new attributes that you add must be in the inkscape: namespace, not sodipodi:. - The inset/outset commads still require that a path has a stroke. Please change them so that they decrement/increment the radius attribute, by say 1 pt with each command, regardless of stroke (converting a path into offset if necesary). Ideally we'll need to have two pairs of commands, say one incrementing radius by 1 pt and the other (with alt) by the distance corresponding to 1 visible pixel at the current zoom (similar to alt-arrows). - The statusline description of the object can be more useful if instead of simply "Offset" it would say e.g. "Path inset by 1.5pt" or "Path outset by 3pt". - Even though the path quality is now very good, I still noticed occasional "splotches" that would be nice to fix. I'm now uploading one example to the bug tracker so you can see what I'm talking about. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

3 2

gtkmm2 rollback
by MenTaLguY 31 Dec '03

31 Dec '03

Well, I've made an executive decision... The packaging situation with gtkmm2 is really pretty dire at this point on several platforms (even RedHat), so I'm going to roll back our gtkmm2 dependency for now. I hadn't expected it would trail Gtk2 packaging by THIS MUCH, but it seems to be... Hopefully the situation will resolve itself in the next month or two, and we can go back to using it. -mental

2 1

Re: [Inkscape-devel] Re: dnd [was: Re: export patches]
by bulia byak 31 Dec '03

31 Dec '03

>Okay, had to change > >rnewdoc = sp_repr_read_mem (svgdata, data->length, NULL); > >to > >rnewdoc = sp_repr_read_mem (svgdata, data->length, SP_SVG_NS_URI); > >now it should behave exactly like the import function. Updated patch >attached and posted to the tracker. Works for me ;) Thanks! Indeed it works well now. I think you can commit it. Of course it'll need more testing when/if Gimp supports svg dnd too. And by the way, why can't I drag an svg document from my KDE desktop into Inkscape? Is this version of dnd Gnome-only? _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

5 8

Nuke the fake config?
by Jon A. Cruz 31 Dec '03

31 Dec '03

Can we get rid of gen_nr_config.c and nr_config.h? We 'should' just be using standard config approaches and config.h. This is even in gen_nr_config.c /** * A little utility function to generate header info. * * Yes, it would be possible to do this using more "native" autoconf * features, but I personally find this approach to be cleaner. * * The output of this program is generally written to art_config.h, * which is installed in libart's include dir. **/ To me, that translates as "I don't understand the standard ways, so I'll subset and re-invent a wheel myself". Given that we're trying to keep cross-platform including Win32 and OS X support, it probably is time to kill it. Are there any issues I'm missing? Or anything from those building on Win32 that would complicate things?

3 2

can't compile
by bulia byak 31 Dec '03

31 Dec '03

There's a mismatch in declarations: desktop-snap.h has the last argument of _free_snap as const, but *.cpp has it without const. Please fix one way or the other. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

6 12

SPOffset
by MenTaLguY 30 Dec '03

30 Dec '03

I've been playing with SPOffset today -- great stuff! It has some awesome potential as an artistic tool. That said, there are a few issues that bug me: 1. something's going a bit wonky with the associated NRArenaItem -- an assertion keeps triggering about the object's bounding box. Unfortunately, until I figure out what NRArenaItem::state actually means, I'm not sure of the best way to fix this. 2. I think perhaps Inset/Outset should modify the original path, rather than making a duplicate. Its behavior of duplicating the path and leaving them both selected surprised and frustrated me. 3. I'm not sure the use of xlink:href is really SVG-compliant in this case ... also, the behavior of following the original path was also a little surprising and frustrating, once I managed to get the original path selected without selecting the outset. -mental

3 3

node edit now listens!
by bulia byak 30 Dec '03

30 Dec '03

I finally added repr listener to the node editor, which means it now updates its nodes when an object is modified outside of its control (by undo, in XML editor, in another view etc.) This fixes 857997, 852973, 865627, and re-fixes 848355 properly (previous hack in document_undo is removed). "Works for me" but I'd appreciate if it is tested really thoroughly, as the code is still somewhat flakey. E.g. instead of the closed bug I'm now submitting two other bugs related to the new code which I still need to fix. Any insights are appreciated. Some issues: - When to regenerate the nodepath? Not always when a repr is changed, because the majority of such changes are from the node editor itself. One approach: compare the actual repr with a "fake" repr temporarily created from the current nodepath; if different, recreate nodepath. Another approach: When updating repr from within node editor, set up the local_change flag. The listener checks this flag and if it's set, does not recreate nodepath (but zeroes the flag). Right now my code uses both these approaches, the first for the nodepath and the other for knot_holder (the structure used to edit ellipses, spirals etc). Does anyone have an opinion on which approach is more preferable? - Preserving selection is a hack: before regenerating nodepath, I save the list of the numbers of selected nodes, and then re-select them in the new nodepath. This does not always work (see bug 867525). Can anyone propose a better idea? - Objects within groups: they can be transformed via their group, without their repr being changed at all (see bug 867521). What to do with them? _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

RE: [Inkscape-devel] Nudge control
by bulia byak 29 Dec '03

29 Dec '03

>Ok. I know it's the silly season but can someone tell me where the nudge >control distance setting for the arrow keys is located? I want to control >the distance setting as the current default one is too high. There must a >control surely but I cannot find it. It's not in the UI yet. Maybe in the next version. For now you can change it in your ~/.inkscape/preferences.xml, by setting e.g. <group id="nudgedistance" value="10"/> (the value is in points). >While I'm on nudge I notice that operation of nudge seems a bit erratic on >occasion. Sometimes an object does not nudge with the arrows until it has >been moved manually with the mouse. When it happens none of the arrows >work. >I'll try and document more precisely when it occurs. Most likely the arrows don't work when the mouse is not over the canvas. It's documented here: http://inkscape.org/cgi-bin/wiki.pl?EventContextGrab If the misbehavior you experience is different, please file a detailed bug report. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] Ungroup All Command
by bulia byak 29 Dec '03

29 Dec '03

>On Tue, 30 Dec 2003, vellum wrote: > > In the real world of drawing pictures I often group objects and then put > > groups within groups etc sometimes many times over. Commonly I have many > > composite groups floating around. Now, if I need to modify something >buried > > in a composite group it can be a real pain getting back down to it. It >would > > be very useful to have an "Ungroup All" command to complement "Group" >and > > "Ungroup". No, "Ungroup all" is not necessary, Ungroup must simply ungroup _all_ selected groups (now it only works if one group is selected). This way you'll be able to ungroup any nested group(s) down to atoms by pressing ctrl-u sequentially. It's in my todo list already. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

Gtkmm
by Daniel Borgmann 29 Dec '03

29 Dec '03

Hello, I have just changed the save confirmation dialog to use Gtkmm. For this to work, I also had to change gtk_init (&argc, (char ***) &argv); to Gtk::Main kit = Gtk::Main(&argc, (char ***) &argv); in main.cpp, otherwise it would crash with lots of "quark" errors. I don't really understand the reasons to be honest, but it seems somewhat logical and it works well. My question is, should I commit this or should the Gtkmm stuff rather happen in a branch? Daniel

4 4

Re: [Inkscape-devel] selection news
by bulia byak 28 Dec '03

28 Dec '03

>On the other hand, you're getting experienced with this code now. Do >you have ideas for how best to make these selected items draggable >directly? Actually it turned out to be quite easy. Please test now. Still, I'd like to hear your opinion on whether it's acceptable to keep extending the item_at_point machinery in select-context as opposed to canvas code. Are we perpetrating ugly hacks, or is this the right way that should have been followed from the start? _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 2

RE: [Inkscape-devel] RE: offset width modifying
by bulia byak 28 Dec '03

28 Dec '03

> > commit it; otherwise >done Thanks! I will test it. >a note on knot editing of objects: when doing >modifications directly in the xml tree, the knots are >apparently not refreshed (see the spiral and the >sodipodi:t0 attibute for an example). Yes, this is because node context has no listeners for repr changes, it's a cause of several bugs and is described here: http://www.inkscape.org/cgi-bin/wiki.pl?SelectionModifiedSignal It's in my near-term plans to fix this. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

RE: offset width modifying
by bulia byak 28 Dec '03

28 Dec '03

>looking in the inkscape code, seems to me that this >requires the creation of a SPShape derivative, like >the SPSpiral is, and the storing of the path whose >offset is considered as a attribute. i already coded a >working solution with a SPOffset object, and a >sodipodi:original attribute (the width is stored as a >sodipodi:radius), but i dunno what clearance i need to >do such additions: is it OK to add attribute types and >objects classes at will? is there a guide explaining >what behavior is expected for these? Please clarify: As I understand it, you plan to change the current inset/outset menu commands and shortcuts so that: - when applied to an arbitrary shape, they convert it to SPOffset and set some initial offset attribute value, - when applied to an SPOffset, they simply modify its offset attribute and regenerate the visible shape from the same original shape? Is this your plan? If so I think it could work, and would provide a nice solution to the problem of "shape degradation" when in/outset commands are applied multiple times. One problem that I see (but may be you already took care of that): our SVG must always remain renderable, and it must render the same in any other SVG renderers. This means the d="" attribute of the SPOffset object must store the _already offset_ path, not the original path. For storing the original path, you'll need a separate attribute in the inkscape: namespace. Other questions: It would be very nice to be able to edit the _original_ path with the node editor without losing the SPOffset status of the object, i.e. have the visible offset contour to be updated automatically when I edit the nodes of the original contour. Is this possible or if not, do you think it's easy to implement? Also, it would be very nice to be able to convert any other SPShape derivative to an SPOffset without losing its original status. For example, being able to edit a rect (e.g. rounding its corners) and see the outset contour updated at once. And it would be extremely useful to be able to apply SPOffset to text objects without converting them to path first. Is this possible with your current model? Well, even if not (i.e. if node-editing of an SPOffset loses its offset status and original shape, and if SPOffset can only be created from a path), I think it's still useful, so let's try it out. Whether to commit it depends on how disruptive it is; if you didn't change much outside of your domain and don't expect other things to break, go ahead and commit it; otherwise please create a branch for your code (see Wiki for instructions) so we could test it. P.S. Please cc: your replies to the list so that everyone else can participate in the discussion. Also, please add yourself to the AUTHORS file if you didn't already, and please document your changes in the ChangeLog. _________________________________________________________________ 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

Re: [Inkscape-devel] selection news
by bulia byak 28 Dec '03

28 Dec '03

>On Sat, 2003-12-27 at 02:31, bulia byak wrote: > > Ctrl-click now selects within groups, ctrl-shift-click adds to selection > > disregarding grouping. Multiple and nested groups work. Special care was > > taken to preven double grouping when both a group and one of its >descendants > > are selected. Please test. > >Good work! > >One thing -- as it is currently, you can select things within a group, >but not e.g. move them around when they are selected -- probably >contrary to user expectations. I thought about that but didn't implement it yet, partially because I myself almost never use dragging to move objects, but only arrow keys (they work within group). This will involve another instance of ignoring the item passed with the event and using the selected-within-group items instead in item_handler. Looks like with this approach, the canvas code which does its own item picking will be eventually left unemployed. I don't know if it's good or bad from the architectural viewpoint, but at least my own way of fiddling with items is much easier to implement for me than any changes to the canvas code, so I tend to choose the easy route. >I guess this means the next phase of my layers work just became more >important -- making groups that have selected children (descendants) >automatically 'transparent' (in the SPArenaGroup sense). Oh yes, if you can do this, then mousedragging selected-within items will be enabled automatically. Perhaps that's a better approach. >On the other hand, you're getting experienced with this code now. Do >you have ideas for how best to make these selected items draggable >directly? I think the code I originally had in mind to do >selection-dependant "event transparency" could get nasty to implement. As outlined above, I think I can basically re-implement most if not all of selector's functionality using my own item_at_point functions and their variants, disregarding the item argument of the event. This is one approach; the other is your changes to canvas code to make partially-selected groups auto-transparent. As to which one is easier, I don't know; I can try to do the first one but I have very little idea of how difficult is the second for you (it's likely to be very difficult _for me_). _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

[Fwd: Re: [Sodipodi-list] gradient-bug]
by MenTaLguY 28 Dec '03

28 Dec '03

Could someone pick up this fix from Sodipodi if they have a chance? -----Forwarded Message----- From: Lauris Kaplinski <lauris@...39...> To: david@...139... Cc: sodipodi-list(a)lists.sourceforge.net Subject: Re: [Sodipodi-list] gradient-bug Date: Sat, 27 Dec 2003 18:43:13 +0200 Hello! You were right, sorry :-( What happened was, that sodipodi did not set gradientUnits="userSpaceOnUse" attribute to proper gradent while saving file. So if reading it back, gradient got interpreted as "objectBoundignBox", causing spread coordiantes to go way out of object (I hope this was all problem - at least fixing it makes sodipodi to read its own gradients back peoperly). Quick fix is to add gradientunits... attribute by hand to xml file (or use xml editor). I also fixed this in CVS - it may take some time to propagate, if you are using anoncvs still... Thank you for reporting it! Best wishes, Lauris Kaplinski David Christian Berg kirjutas L, 27.12.2003 kell 15:24: > Thanx Lauris, > > Blame the librsvg... at least concerning object bounding box gradients. > But when it comes to UserSpaceOnUse, Sodipodi (0.34-pre) definetely > screws up, sorry to say that. It can't even handle it's own gradients, > since when you reopen a file with a simple gradient, it is positioned > absolutely wrong, and UserSpaceOnUse is back to ObjectBoundingBox (maybe > the error? I can't find anything specifying if it's USOU or OBB in the > xml code). > Perhaps it's just because I'm using the 0.34-pre (which compiles, runs, > does about what it should -see above-, but crashes quite often ;-) ) > Since I'm not familiar with programming, I'll keep on bugging you with > assumable bugs, and feature requests, sorry for that. > > Take care > > David > > > > On Sat, 2003-12-27 at 11:38, Lauris Kaplinski wrote: > > Hello! > > > > I am quite confident sodipodi does gradientTransform properly > > (although I may be wrong). Here is UI feature-request, yes, > > to make handling spread direction more intuitive. > > Can you check, how does batik render it - of all SVG viewers > > batik is most close to 'the right one'. > > > > Best wishes, > > Lauris Kaplinski > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Sodipodi-list mailing list > Sodipodi-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sodipodi-list

1 0

selection news
by bulia byak 28 Dec '03

28 Dec '03

Ctrl-click now selects within groups, ctrl-shift-click adds to selection disregarding grouping. Multiple and nested groups work. Special care was taken to preven double grouping when both a group and one of its descendants are selected. Please test. I also plan to implement cltr-alt-click to "select under", i.e. multiple cltr-alt-clicks will cycle selection through the stack of objects at the current point, starting from the topmost one and going towards the bottom (also disregarding grouping). I would like to do the same for alt-click _preserving_ grouping, but unfortunately alt-clicks are usually stolen by a window manager. _________________________________________________________________ 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…

2 1

non-ascii filenames
by bulia byak 28 Dec '03

28 Dec '03

Currently Inkscape fails in numerous ways when you try to name your file with non-ascii characters. For one thing, it records that filename into preferences.xml using the locale encoding, which is invalid UTF-8, which causes parser to reject the file upon the next load and the preferences are simply lost. Can anyone give any advice on how to deal with this problem? I know about g_locale_to/from_utf8() but the question is, where is the best place to put these functions. It looks like all standard file-related functions (gtk_file_selection_get_filename, file opening and saving, etc) require the filename in locale encoding, but all display functions (setting window title, display in XML editor, recent files menu) require UTF-8. And of course, serialized XML must get UTF-8 too. Looks like there are quite a lot of places where I'll need to translate between the encodings, and I'm afraid it will become pretty messy. I'm not going to experiment with this but if anyone has any inshights on this problem I would appreciate any help. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

4 5