- Inkscape Devel - Inkscape Mailman

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

Re: [Inkscape-devel] namedview news
by bulia byak 27 Dec '03

27 Dec '03

>1) The window "flickers" when it's created, because at first it appears >at standard position, then it gets moved and resized immediately. >Wouldn't it be possible to do this before the window is shown? Very difficult, because Inkscape creates the window first and only loads a document into it later. Changing that would require serious changes to the program innards that I'm not very comfortable with. If anyone can do that cleanly, it would be nice of course. >2) I wanted to save the new size of my document but at first it didn't >let me because "no changes needed to be saved". :) I think it would make >sense now if the modified flag would also be set whenever the user >resizes the window or does anything else that can be saved. No, that would be very counterintuitive and annoying ("I did not change anything, why does it say I must save???"). Most people's idea of "changes" does not include zoom-in. I think it's inevitable that the saved state will be that at the last save, not at the last moment that document is onscreen. I think we can live with that, and I don't see how to solve this nicely. _________________________________________________________________ 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

can't compile today
by bulia byak 27 Dec '03

27 Dec '03

OK, I downloaded and installed gtkmm and sigc++. Still no luck: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -I../../src -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libart-2.0 -I/usr/include/libxml2 -g -O2 -I/usr/local/include/gtkmm-2.0 -I/usr/local/lib/gtkmm-2.0/include -I/usr/local/lib/sigc++-1.2/include -I/usr/local/include/sigc++-1.2 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/atk-1.0 -c -o nr-pixblock.o `test -f 'nr-pixblock.cpp' || echo './'`nr-pixblock.cpp nr-pixblock.cpp: In function `void nr_pixblock_setup_fast(NRPixBlock*, int, int, int, int, int, int)': nr-pixblock.cpp:45: error: `rpl_malloc' undeclared (first use this function) nr-pixblock.cpp:45: error: (Each undeclared identifier is reported only once for each function it appears in.) nr-pixblock.cpp: In function `void nr_pixblock_setup(NRPixBlock*, int, int, int, int, int, int)': nr-pixblock.cpp:75: error: `rpl_malloc' undeclared (first use this function) nr-pixblock.cpp: In function `NRPixBlock* nr_pixblock_new(int, int, int, int, int, int)': nr-pixblock.cpp:148: error: `rpl_malloc' undeclared (first use this function) nr-pixblock.cpp: In function `unsigned char* nr_pixelstore_4K_new(int, unsigned char)': nr-pixblock.cpp:181: error: `rpl_malloc' undeclared (first use this function) nr-pixblock.cpp: In function `unsigned char* nr_pixelstore_16K_new(int, unsigned char)': nr-pixblock.cpp:215: error: `rpl_malloc' undeclared (first use this function) nr-pixblock.cpp: In function `unsigned char* nr_pixelstore_64K_new(int, unsigned char)': nr-pixblock.cpp:249: error: `rpl_malloc' undeclared (first use this function) _________________________________________________________________ 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…

4 6

Re: [Inkscape-devel] non-ascii filenames
by bulia byak 27 Dec '03

27 Dec '03

>I'll have to look into the codebase with charset issues in mind (I've >worked with international software for around 15 years now). Thanks, that would be much appreciated! I filed a bug with some more details on what exactly breaks where. >On file versus display encodings, off hand I think you're correct. >However... for the local filenames, things might get tricky. It might be >that things need to work in the local encoding, or... it might be that the >encoding of the filesystem needs to be used. I think at least on Linux, the kernel translates from/to filesystem encoding and presents everything in the locale encoding regardless of filesystem (if properly configured). And on Windows, is there such thing as different filesystems at all? >Hiding these issues for many people is the recent change to UTF-8 for the >local encoding setting (such as with RedHat 8.0). Since the local encoding >is the same as the encoding needed for internal/display calls, programmers >don't notice the potential problems. Also... if users and programmers >aren't actually testing with non-ASCII names (i.e. names with characters >outside of $00-$7f) then they will also not see any problems even if they >exist for their configurations. True, obviously nobody ever tested Sodipodi/Inkscape with non-ascii filenames (even though "Sodipodi" is written in Russian on the site :) _________________________________________________________________ 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 1

Re: [Inkscape-devel] non-ascii filenames
by bulia byak 27 Dec '03

27 Dec '03

>open()/readdir() etc. take as argument a nul-terminated string of bytes, >not some notion of characters. I doubt that. E.g. my Windows partition stores Cyrillic filenames in CP866, but the Linux partition uses KOI8-R (my locale encoding). The Linux kernel is smart enough so it translates Windows filenames into KOI8-R and back when I access the Windows partition. So it's not "just bytes" for the kernel but characters that may need to be reencoded in some situations. >preferences.xml should store filenames >as such. Not as such, but as specified in the XML encoding declaration, which in our serializer is always UTF-8. >If <gui toolkit xyz> does something different, then that toolkit is >broken and should be fixed. I think GTK does a good job of unifying everything into UTF-8 internally, but the file-accessing function are probably outside of its control and therefore use the locale encoding. _________________________________________________________________ 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…

1 0

Re: [Inkscape-devel] Win32 build 1224. Zoom problem
by bulia byak 27 Dec '03

27 Dec '03

>>One problem I think I have uncovered concerns zooming. When the zoom >>factor >>gets above about 7,500% text remains but everything else disappears!!! The >This is probably due to numerical problems in the transform code. Hopefully >I'll track this down as I clean up the matrix code. (Fingers crossed) This happened on linux too, at exactly the same zoom level, before I changed all floats to doubles in libnr. I have no idea why the problem persists on win32 - maybe some build options prevent it from using doubles? _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1