- Inkscape Devel - Inkscape Mailman

vectorsection
by Alexandre Prokoudine 14 Oct '08

14 Oct '08

FYI: http://groups.google.com/group/vectorsection/browse_thread/thread/6e5d4d820… Eric, are you back? :-) Alexandre

1 0

Appreciation for migration work
by Bob Jamison 13 Oct '08

13 Oct '08

Hi all, I mentioned this on #inkscape, but I thought I should post this on the list, too. For the last several weeks, Johan, Josh, and others have been making huge commits, migrating the vector math code from libnr to 2geom. And for the last few weeks, the grumpier among us (like me :-) have been grouching about build breaks and/or the requirement to perform a complete build after every "svn up." But, hey, that's natural. We like to complain. But nobody should ever forget the fact that we really appreciate the huge amounts of work that they have been doing, the massive commits they have been making, and all of the headaches they have been suffering. These guys deserve our heartfelt thanks for moving ahead and giving the migration the momentum it needs. bob (ishmal)

6 5

Next version(0.47) string freeze
by Lucas Vieites 13 Oct '08

13 Oct '08

Hi, a few days ago someone mentioned how close the string freeze was for the new version (0.47). Is this real? Has a release calendar been set for 0.47? If so, where can I find it? The Roadmap data on the website is generic and has no dates. I'm just being curious and anxious to start translating the new strings in es.po. Thanks in advance. -- Lucas Vieites

6 5

lpe and transforms
by jf barraud 10 Oct '08

10 Oct '08

Hi, Transforms (translate, rotate, etc...) and lpe do not get on well... If you are not familiar to it, consider lpe-bend for instance: Imagine you rotate the input, but not the path parameter (along which the input is bent) the new result is completely different. So transforms need a particular treatment in presence of lpes. Our solution to this problem up to now is to transform the parameters along with the object (or more precisely, to let each lpe decide what todo on transform). This (good!) solution is user friendly, as your lpe parameters nicely move along with your object. However, it implies some limitations (please invalidate if I'm wrong!): I think it prevents from sharing lpes accross different objects, as if one is moved but not the other, which one should be followed by the lpe-parameters? Note that atm, lpe are automatically forked/made unique when you move one object, and I guess that's the reason (?right?). A related (but different) question is about "cloned" path parameters (i.e. references). I might be wrong, but I think path-reference parameters are not transformed atm. (Marginally, one can even think of lpe that depend on the object location, but not relatively to a path or point parameter --- "underlying objects color" for instance?!?--- in which case, transfering the transform to parameters is useless; hmmm! I agree, this is pure abstraction ;-) Although this is not a critical issue ("sharing lpe" jsut does not make sens for a lot of them!!), I think it's a good thing to have, so let's discuss possible strategies! One easy workaround is to add a "lpe-transform" at the end of the lpe-stack whenever the object is transformed (of course, if the last lpe is already a (non shared) transform-lpe, we should just update it instead of adding a new one). This is easy to implement and solves the issue. I think it is a bit cleaner as pes don't have to care about transforms anymore, etc... The (serious) drawback however, common to all solution you can think of, is that if the lpe-parameters do not follow the object anymore, you'll have to look for them all the time and everywhere: if you applied your lpe somewhere, and moved your object a lot, at edition time you'll wonder why the lpe parameter shows up at the other corner of the page, which was the original place, but you completely forgot about. :-( As a conclusion, if we want to keep track of the objects transforms *and* allow lpe to be shared, lpe must be able to strore object specific information at objects level (not in the lpe itself in the defs). Maybe we could add one more attribute to the object, where lpes could register all the data they need (this would be usefull for other purposes anyway). This would make it possible to remember the original position of the object when the lpe was applied: lpe paramters could then be suitably transformed at apply/display/edition time, but stored untransformed. What do you think? jfb.

3 3

Re: [Inkscape-devel] inkscape_version.h is not being updated
by Bob Jamison 09 Oct '08

09 Oct '08

Hi! Thanks for this info. Well, until recently, the SVN revision was not being dynamically fetched at all, so the dependency on inkscape_version.h has remained the same. I have seen this, too, and have added inkscape_version.h to the "touchabout" and "clean" targets. It should have been listed there already, but I guess that since it was never dynamic before, it didn't matter previously. Creating inkscape_version.h -every- time would be overkill and a burden for people wanting to only compile their own files, since that would force aboutbox.cpp to be compiled every time. So... for the typical build/code/build/code cycle, just occasionally do "btool touchabout". "btool clean" will take care of a complete build. -However-, I can see where it might be necessary for <makefile> to make a file every time, regardless if it is up-to-date. So I added an attribute, 'force="true"' to <makefile> to allow this. bob -----Original Message----- >From: Preben Soeberg <prsodk@...400...> >Sent: Oct 9, 2008 1:44 AM >To: inkscape-devel(a)lists.sourceforge.net >Subject: [Inkscape-devel] inkscape_version.h is not being updated > >Hi, > > > >On Windows XP, if inkscape.version.h exists, it is not being updated with >the new revision number, and the old revision number appears in the help >about splash. > >After deleting inkscape_version.h, it is generated with correct revision >number. > >I have seen this behavior since revision 19964. > > > >Preben >

1 0

inkscape_version.h is not being updated
by Preben Soeberg 09 Oct '08

09 Oct '08

Hi, On Windows XP, if inkscape.version.h exists, it is not being updated with the new revision number, and the old revision number appears in the help about splash. After deleting inkscape_version.h, it is generated with correct revision number. I have seen this behavior since revision 19964. Preben

1 0

Re: [Inkscape-devel] Win32 btool problem
by Bob Jamison 08 Oct '08

08 Oct '08

Done. Give it a try, see if it works. Works fine for me on windows and linux. But of course, "works for me" is one of the most hated phrases in CS. :-) bob -----Original Message----- >From: Bob Jamison <rwjj@...127...> >Sent: Oct 7, 2008 1:40 PM >To: J.B.C.Engelen@...1578..., john.cliff@...400..., docsonic@...58..., inkscape-devel(a)lists.sourceforge.net >Subject: Re: [Inkscape-devel] Win32 btool problem > >Hi, all, > >Yes, that is the idea. One thing I need to learn first is the format >of that file. The svn properties are fetched as ${svn.fieldname}, >so I need to know which fields are which. > > >bob > > > >-----Original Message----- >>From: J.B.C.Engelen@...1578... >>Sent: Oct 7, 2008 1:18 PM >>To: john.cliff@...400..., docsonic@...58..., inkscape-devel(a)lists.sourceforge.net >>Subject: Re: [Inkscape-devel] Win32 btool problem >> >>> -----Original Message----- >>> From: john cliff [mailto:john.cliff@...400...] >>> Sent: dinsdag 7 oktober 2008 15:03 >>> To: Docsonic; inkscape-devel >>> Subject: Re: [Inkscape-devel] Win32 btool problem >>> >>> You need to get the command line svn executable. or edit out >>> the bit in build tool that calls it. >>> I think ishmal was going to make it optional... >> >>Even beter: ishmal was thinking about not using the svn executable, but >>the .svn/entries file. That would make it universal. >> >>:) >> Johan >> >>------------------------------------------------------------------------- >>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>Build the coolest Linux based applications with Moblin SDK & win great prizes >>Grand prize is a trip for two to an Open Source event anywhere in the world >>http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>_______________________________________________ >>Inkscape-devel mailing list >>Inkscape-devel(a)lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > >------------------------------------------------------------------------- >This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >Build the coolest Linux based applications with Moblin SDK & win great prizes >Grand prize is a trip for two to an Open Source event anywhere in the world >http://moblin-contest.org/redirect.php?banner_id=100&url=/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Text to Path conversion limitation
by Aurélio A. Heckert 07 Oct '08

07 Oct '08

Hi, Is normal to me convert works on PDF and some times i need to make changes on the text, because i need to convert the text in path, and the text has some color or opacity variations. I'm trying to generate a lot of PDF automatically, with automatically generated SVG. That is cool! But i lost some information. Please, see my explanation in the bug report: https://bugs.launchpad.net/inkscape/+bug/279897 This image show what we lost in a Text to Path conversion: http://launchpadlibrarian.net/18305828/text2path.png I compile the Inkscape every week. I'll be really glad to test this feature if a developer like the idea. Thanks! Aurium -- Aurélio A. Heckert http://colivre.coop.br/Aurium GNU/Linux User #312507 http://counter.li.org - - - - - - - - - - - - - - - - - - - - - - - - - Ilustração Vetorial Livre: http://InkscapeBrasil.org Coop. de Tecnologias Livres: http://Colivre.coop.br - - - - - - - - - - - - - - - - - - - - - - - - - "Eu temo pela minha espécie quando penso que Deus é justo." Thomas Jefferson Antes de imprimir esta mensagem reflita sobre a sua responsabilidade com a preservação do Meio Ambiente.

1 0

r19979 - crash on open of SVG
by Michael Park 07 Oct '08

07 Oct '08

Hi there, I've been doing a more er less daily build of inkscape, and the last few days have been crashing when I try to open an existing SVG file (through the file open dialog). The last stable working version for me was r19967 (Fedora 9 x86_64, KDE4.1.1, using 'updates-testing' repo). Here's the output I get at the console: ------- ** ERROR:(display/nr-filter-units.cpp:44):void NR::FilterUnits::set_resolution(double, double): assertion failed: (x_res > 0) Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. ------- And I hope I did this right, here's the gdb backtrace I got when following the instructions from http://www.inkscape.org/report_bugs.php?lang=en ------- (gdb) bt #0 0x0000003064632215 in raise () from /lib64/libc.so.6 #1 0x0000003064633d83 in abort () from /lib64/libc.so.6 #2 0x00000031a525ced7 in g_assertion_message () from /lib64/libglib-2.0.so.0 #3 0x00000031a525d372 in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 #4 0x0000000000784944 in NR::FilterUnits::set_resolution () #5 0x000000000077036c in NR::Filter::render () #6 0x000000000074670b in nr_arena_item_invoke_render () #7 0x00000000007481ad in nr_arena_group_render () #8 0x000000000074663d in nr_arena_item_invoke_render () #9 0x00000000007481ad in nr_arena_group_render () #10 0x000000000074663d in nr_arena_item_invoke_render () #11 0x00000000007481ad in nr_arena_group_render () #12 0x000000000074663d in nr_arena_item_invoke_render () #13 0x00000000007481ad in nr_arena_group_render () #14 0x000000000074663d in nr_arena_item_invoke_render () #15 0x00000000007481ad in nr_arena_group_render () #16 0x000000000074663d in nr_arena_item_invoke_render () #17 0x0000000000751ddb in sp_canvas_arena_render () #18 0x000000000076b095 in sp_canvas_group_render () #19 0x000000000076b095 in sp_canvas_group_render () #20 0x000000000076d6b1 in sp_canvas_paint_rect_internal () #21 0x000000000076d8f6 in sp_canvas_paint_rect () #22 0x000000000076dd69 in do_update () #23 0x000000000076ddf2 in idle_handler () #24 0x00000031a523742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x00000031a523ac0d in ?? () from /lib64/libglib-2.0.so.0 #26 0x00000031a523b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #27 0x00000031a82e7027 in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0 #28 0x00000000005e54a4 in Inkscape::UI::Dialog::FileOpenDialogImplGtk::show () #29 0x0000000000453a95 in sp_file_open_dialog () #30 0x0000000000789ccb in sp_action_perform () #31 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #32 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #33 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #34 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #35 0x00000031a826b85b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #36 0x00000031a826b90c in gtk_action_activate () from /usr/lib64/libgtk-x11-2.0.so.0 #37 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #38 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #39 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #40 0x00000031a5620f1d in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0 #41 0x00000031a848e0b2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #42 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #43 0x00000031a561f6b1 in ?? () from /lib64/libgobject-2.0.so.0 #44 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #45 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #46 0x00000031a8285e13 in gtk_button_clicked () from /usr/lib64/libgtk-x11-2.0.so.0 #47 0x00000031a828722b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #48 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #49 0x00000031a561efc6 in ?? () from /lib64/libgobject-2.0.so.0 #50 0x00000031a5620b8c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #51 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #52 0x00000031a8285d7c in gtk_button_released () from /usr/lib64/libgtk-x11-2.0.so.0 #53 0x00000031a8286fb2 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #54 0x00000031a8387452 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #55 0x00000031a560b6cd in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #56 0x00000031a561f382 in ?? () from /lib64/libgobject-2.0.so.0 #57 0x00000031a5620a0f in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #58 0x00000031a56210d3 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #59 0x00000031a84f48be in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #60 0x00000031a84f4406 in gtk_widget_event () from /usr/lib64/libgtk-x11-2.0.so.0 #61 0x00000031a83859ee in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0 #62 0x00000031a8384625 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #63 0x00000031a6e57c29 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #64 0x00000031a523742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #65 0x00000031a523ac0d in ?? () from /lib64/libglib-2.0.so.0 #66 0x00000031a523b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #67 0x00000031a8383db0 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #68 0x00000000004498b9 in sp_main_gui () #69 0x0000000000449d1d in main () ------- Please let me know if I did the backtrace wrong, I did see some message fly by about missing debuginfo of some packages. Also, I'll see if I can bisect down to which build this behaviour started happening. Thanks. --Mike

2 2

Problem with running Inkscape on KDE 4.1.2
by ryrych＠...400... 07 Oct '08

07 Oct '08

Hello, I've done a upgrade of my debian recently. I instlled KDE 4.1.2 and now my Inkscape would't run. I got an error: inkscape: error while loading shared libraries: libpoppler.so.2: cannot open shared object file: No such file or directory but I've got libpoppler in /usr/lib/libpoppler.so.3.0.0 The package libpoppler3 is required by KDE 4.1 so I can't remove it and restore the older one. Everything was OK before my upgrade in Sunday. What's the matter? Could you help me? cheers, Wojciech RRH Ryrych :)

1 0