- Inkscape Devel - Inkscape Mailman

SPCanvasItem
by Ralf Stephan 06 Jul '05

06 Jul '05

Hello, I can find no way to make a canvas item a singleton, i.e., ensure that only one of its class is created. Is there a way? Thanks, ralf

3 6

Re: neat design toy
by unknown＠example.com 06 Jul '05

06 Jul '05

Quoting bulia byak <buliabyak@...400...>: > On 7/6/05, MenTaLguY <mental@...3...> wrote: > > This might be nice to have integrated with Inkscape someday, > perhaps as > > another clonetiler sort of thing (each source object being a > different > > terminal symbol type, perhaps). > > > > http://www.ozonehouse.com/ContextFree/ > > Looks like a good candidate for an extension. It just needs to be > patched to generate SVG instead of rasterizing via antigrain > library. > Why don't you post it to the list, maybe Aaron or someone else > will pick it up. Ok. That might be nice to have for now. I think after the 0.42 release, I'd like to try rewriting the clonetiler in terms of a simple CFG engine. All of the plane symmetry groups should be expressable that way. Users wouldn't see anything different, except we could (for example) allow an additional option of specifying a ContextFree-style grammar instead of a symmetry group. -mental

1 0

Re: [Inkscape-devel] 0.42: Call for screenshots!
by Aaron and Sarah Spike 06 Jul '05

06 Jul '05

bulia byak wrote: > will you please create an extensions screenshot for the site? (I think > you were going to do this some time ago). Take > http://www.ekips.org/comp/inkscape/inx/InkexEffects.png as the base, > with the following changes: > > - make it 1280x1024 (if you don't have this resolution, just send me > the SVG and I'll shoot it) > > - add a few path interpolation samples, and maybe some other effects too > > - show one extension dialog, e.g. for interpolate or lindenmayer http://www.ekips.org/comp/inkscape/inx/PythonEffects.png http://www.ekips.org/comp/inkscape/inx/PythonEffects.svg Aaron Spike

1 0

0.42: Call for screenshots!
by bulia byak 06 Jul '05

06 Jul '05

We need more screenshots for 0.42. I recently added one screenshot for the new Align options: http://inkscape.org/screenshots/index.php and we have enough screens for clone tiler and i18n, but for the rest of the features, submissions are solicited. We would appreciate both "demo" (focusing on features) and "work" (showing real work projects) screenshots. Here are some requirements: - 1280x1024 PNG - Visually interesting. It's not to be a design masterpiece but it must not be too ugly, too unbalanced, etc. - Sufficiently informative. We can't have too many screenshots on that page, so we must try to cram as much stuff as possible into each screenshot. Don't waste space. Add objects, captions, explanations. Open dialogs, switch tools, make tooltips appear before shooting. Use objects both large (visible on the thumbnail) and small (visible in full image only). Make each screenshot a story that invites close examination, thinking, and experimentation. The screenshots page is usually the first one that new users go to, so let's work on a 0.42 screenshots collection that makes justice to this great release. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Inkscape in gentoo
by Bryce Harrington 06 Jul '05

06 Jul '05

Good news: Gentoo has just upgraded to Inkscape 0.41 as stable on x86 and four other platforms: http://packages.gentoo.org/search/?sstring=inkscape :-) Bryce ----- Forwarded message from bugzilla-daemon@...599... ----- Date: Tue, 05 Jul 2005 08:36:04 +0000 From: bugzilla-daemon@...599... To: bryce@...260... Subject: [Bug 92995] media-gfx/inkscape-0.41-r1 stable request Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=92995 Secure: https://bugs.gentoo.org/show_bug.cgi?id=92995 zypher@...599... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From zypher@...599... 2005-07-05 01:36 PDT ------- Version 0.41-r1 marked stable. Thanks for your patience, I'll try to keep up a bit better next time ;) Cheers, Marc. -- Configure bugmail: http://bugs.gentoo.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ----- End forwarded message -----

4 4

Inkscape 0.42pre0
by Ted Gould 05 Jul '05

05 Jul '05

Yeah! Yeah! Yeah! Finally got distcheck to pass! https://sourceforge.net/project/showfiles.php?group_id=93438&package_id=991… If the people who can build binary packages would, then we can send an e-mail to the user's list for wider distribution. Whew! Thought that would never get out! --Ted

5 5

RDF id= fix
by MenTaLguY 05 Jul '05

05 Jul '05

Just a quick note that I've just fixed bug 1184252, where we had been adding id= attributes to elements under rdf:RDF in violation of the RDF/XML specification. Now we only add id= attributes to elements in the SVG, Sodipodi, and Inkscape namespaces. Also, I've added code to strip existing id= attributes from under rdf:RDF -- I figure that much is safe to do because it's clearly wrong for them to be there. Even so, I think it would be a good idea if someone went through and resaved all our document templates so they don't include the bogus attributes in their metadata. Volunteers? -mental

3 2

Updated spanish po in the patch tracker
by Lucas Vieites 04 Jul '05

04 Jul '05

Hi, I updated the spanish po in the patch tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1232277&group_id=9… -- Lucas Vieites Fariña <lucas@...212...> Web: <http://www.asixinformatica.com/users/lucas/> Blog: <http://www.asixinformatica.com/blog/>

1 0

Race condition in sp_gradient_invalidate_vector()?
by Ralf Stephan 04 Jul '05

04 Jul '05

Hello, both bugs 1038594 and 1196143 appear to be 'fixed' by not g_free'ing gr->color. This is a text gradient buffer mangled in both bugs (in 1196143 you can see some destruction of the picture when repainting after dialog release). In 1038594, valgrind tells me about attempted reads from the same address which was freed before, and gtk likely reuses the memory, and this fast. This would mean that there is a copy of the color buf somewhere that is not updated but I still am not well into the code. I would propose memory handling of this buffer to be moved into GC, before the release, or using malloc/free if that works. https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1038594&group_… https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1196143&group_… Regards, ralf

5 7

Removing C-Style casts
by Ben Fowler 04 Jul '05

04 Jul '05

In the file libnr/nr-point.h, there are some C-Style casts in the code: /** \brief A function to lower the precision of the point \param places The number of decimal places that should be in the final number. This function accomplishes its goal by doing a 10^places and multipling the X and Y coordinates by that. It then casts that to an integer (to get rid of all decimal points) and then divides by 10^places back again. */ inline void round (int places = 0) { _pt[X] = (Coord)(Inkscape::round((double)_pt[X] * pow(10, places)) / pow(10, places)); _pt[Y] = (Coord)(Inkscape::round((double)_pt[Y] * pow(10, places)) / pow(10, places)); return; } Now casting _pt[] to a double is no-op, and possibly the (Coord) cast is also unnecessary, or could be converted to a function-style one: Coord( ... ) . My problem centres on ensuring that the code matches the comment, which refers to casting to an int. I am fairly sure that the Inkscape::round( ) function actually is a wrapper around std::floor( ) which does everything in IEEE double precision. IMHO, the Coord type should have a round( ) function, which I have had to provide under a different name: namespace NR { /** - * A "real" type with sufficient precision for coordinates. + * A floating point type with sufficient precision for coordinates. * * You may safely assume that double (or even float) provides enough precision for storing * on-canvas points, and hence that double provides enough precision for dot products of * differences of on-canvas points. */ -typedef double Coord; + typedef double Coord; + + /** + \brief A function to lower the precision of a co-ordinate + \param places The number of decimal places that should remain in + this co-ordinate. + + This function accomplishes its goal by multipling the co-ordinate by + (10^places). It then uses the Inkscape round( ) function (currently + implemented with std::floor( )) to remove the surplus precision and + then divides by (10^places) to scale back again. + */ + inline Coord set_precision (Coord c, int places = 0) { +// g_assert( places > 0 ); // Assert on do-nothing calls and negative number of decimal places + double factor = pow(10, places); + return Coord((Inkscape::round(c * factor) / factor));; + } } /* namespace NR */ and then I can re-do the function as: /** \brief A function to lower the precision of the point \param places The number of decimal places that should remain in the co-ordinates of the point. */ inline void round (int places = 0) { // g_assert( places > 0 ); // Assert on do-nothing calls and negative number of decimal places _pt[X] = NR::set_precision(_pt[X], places); _pt[Y] = NR::set_precision(_pt[Y], places); return; } Is this the way to go? Would these changes be acceptable in any way? Should Coord be a class rather than a typedef? Should the round( ) function(s) which are really floor( ) functions be renamed? Should the round functions(s) which are really set_precision( ) (if any) be renamed? Should any of these functions be templates e.g. (untested) template <class T> inline void round( int places=0 ) { // round co-ordinates to places decimal places } How are modifications to working code meant to be tested? I would be happy to submit patches for review, or pursue this in any other way: I am trying to see whether it is viable to remove C-Style casts as per http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeJanitors

1 3

Win32 testers needed!
by Bryce Harrington 03 Jul '05

03 Jul '05

Hi all, We are closing in on the 0.42 release, and getting the last few bugs fixed. There are a _number_ of bugs which appear to be Windows-only. Unfortunately, since the developers are linux-based, it's hard to determine how to fix them and to check that the fixes worked. Thus, if you are a Windows Inkscape user, we really need your help right now, in the run up to the release. Please review the Bug Tracker, and in particular look at the bugs that are ranked at '9'. Install both 0.41 and a version from CVS, and try to recreate each bug on each copy. Then add a comment to the bug report about whether you can or cannot replicate the error. Make sure you're logged into SourceForge, so the developers can contact you with more questions or to verify if a change fixed it. If you do not have a SourceForge account, please include your email address. If you want to help even more, it is extremely valuable to have backtraces. You can learn how to make backtraces on the Report A Bug page on the website. The more you can do to help narrow in on where the bug occurs, the more quickly it can be fixed. Please try to find a couple evenings over the next week to devote to doing some testing; even if you can only test a few bugs, you will help make Inkscape on Windows that much more robust. Thanks, Bryce

1 0

New gtk bundle
by Bob Jamison 03 Jul '05

03 Jul '05

Hi, all, I uploaded another copy of the Win32 libs for the build. This one has xmlparse.dll and libtiff3.dll added, and some unnecessary files removed. It is here: http://inkscape.org/win32/ It is 7-zipped to reduce the size. 24mb is much nicer than 52. I added some lines to the 'dist' target of Makefile.mingw to use these files. Bob

2 2

win32 crash on creating about memory dialog
by Adib Taraben 02 Jul '05

02 Jul '05

Hi, on win32 the current cvs crashes after pressing "about memory" function. I use the new gtk26 libs from Bob. I tried this on linux and there it is ok. I have no glue whats going on as I don't know gtk. I think that has to be resolved before release, thats why I post here. Attached there is the bt: HTH, Adib. --- gdb: kernel event for pid=3976 tid=2572 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x05013750 Program received signal SIGSEGV, Segmentation fault. 0x05013750 in Glib::Object::Object (this=0x8326d98, __vtt_parm=0x8e4830, construct_params=@0x22ec80) at object.cc:214 in object.cc (gdb) 214 object.cc: No such file or directory. bt #0 0x05013750 in Glib::Object::Object (this=0x8326d98, __vtt_parm=0x8e4830, construct_params=@0x22ec80) at object.cc:214 #1 0x05fb5557 in Gtk::Object::Object (this=0x8326d98, __vtt_parm=0x8e482c, construct_params=@0x22ec80) at object.cc:35 #2 0x0073d895 in _fu56___ZTTN3Gtk14TreeViewColumnE () at c:/gtk26/include/gtkmm-2.4/gtkmm/treeviewcolumn.h:848 #3 0x0073df3c in Gtk::TreeView::append_column<Glib::ustring> (this=0x8348fc4, title=@0x22edb0, model_column=@0x8348fa0) at c:/gtk26/include/gtkmm-2.4/gtkmm/treeview.h:1365 #4 0x007730f3 in Inkscape::UI::Dialog::Memory::Private::Private ( this=0x8348f90) at ui/dialog/memory.cpp:93 #5 0x0066ce55 in Inkscape::UI::Dialog::Memory::Memory (this=0x8337b98) at ui/dialog/memory.cpp:206 #6 0x00772d16 in Inkscape::UI::Dialog::Memory::create () at ./ui/dialog/memory.h:23 #7 0x007727a3 in Inkscape::UI::Dialog::(anonymous namespace)::create<Inkscape::UI::Dialog::Memory> () at ui/dialog/dialog-manager.cpp:46 #8 0x00511f91 in Inkscape::UI::Dialog::DialogManager::getDialog ( this=0x72b9dd8, name=1162) at ui/dialog/dialog-manager.cpp:137 #9 0x00511ff0 in Inkscape::UI::Dialog::DialogManager::showDialog ( this=0x72b9dd8, name=1162) at ui/dialog/dialog-manager.cpp:156 #10 0x00511fd6 in Inkscape::UI::Dialog::DialogManager::showDialog ( this=0x72b9dd8, name=0x85a9d2 "Memory") at ui/dialog/dialog-manager.cpp:149 #11 0x004d4076 in Inkscape::HelpVerb::perform (action=0x74cf990, data=0x95, pdata=0x0) at verbs.cpp:1472 #12 0x004e062a in sp_action_perform (action=0x74cf990, data=0x0) at helper/action.cpp:135 #13 0x0043767f in sp_ui_menu_activate (object=0x7526b28, action=0x74cf990) at interface.cpp:284

2 1

Re: [ inkscape-Patches-1000235 ] Save as Flash (.swf)
by Ted Gould 02 Jul '05

02 Jul '05

Raymond Penners wrote: > > definitly lacking on some ways that your plugin is good, but > we'd like to start using the extension approach in the > future, and spalah can do some things your code can't. > Also, we really don't want to add a dependency on ming. I > realize it is a configure option, but the reality is that no > one compiles from source. If we don't make it the default, > no one will ever see the code. It's the sad reality of open > source today. > > Thanks for your contribution, I hope that you will consider > contributing to Spalah, or to Inkscape in other ways. Sorry > again to take so long to get back to you. > > I am wondering, does this mean that Spalah will be distributed > out-of-the box with Inkscape? If not, then IMHO not having a simple > "Save as .swf" feature in Inkscape would be a real shame. Well, we're still trying to figure all that out. On one hand we really want to reduce the size of Inkscape, make it easier to install and faster to load. Which means that we want to make as much external as possible. On the other hand, most people aren't of the mindset to install lots of different packages. On Linux this is pretty easy, most distributions have reasonable package management. On Windows, it is much less so. But it still leaves the issue: how do users know where to go to get these features? We need some way to advertise them also. I realize that wasn't much of an answer to your question, but that is more because we don't quite have one yet. It's quite a thorny issue. --Ted

3 2

LJ Editor's Choice 2005
by unknown＠example.com 02 Jul '05

02 Jul '05

I just flipped to page 82 of the August 2005 issue of Linux Journal. Congratulations to all you devs for the Editor's Choice Award for Graphics Software. Aaron Spike

5 4

object.cpp build failure on Solaris
by Christopher Wiedel 02 Jul '05

02 Jul '05

I've been trying to build Inkscape 0.41 on sparc-sun-solaris2.8, and have run into a bit of a problem. It configures fine, and when I start 'make' it initially goes well, occasionally popping out warnings like: node-context.cpp: In function `void nodepath_event_attr_changed(SPRepr*, const gchar*, const gchar*, const gchar*, bool, void*)': node-context.cpp:313: warning: cast from `GTypeInstance*' to `SPItem*' increases required alignment of target type node-context.cpp:322: warning: cast from `GTypeInstance*' to `SPItem*' increases required alignment of target type However, it blows up when it hits src/object-edit.cpp. Or more accurately, something inside it. It throws out a great many of the same type of warnings as the ones above. This doesn't appear to be the problem, since other files had the same warnings, but were able to compile. It winds up with this: object-edit.cpp: In function `void sp_offset_offset_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:897: warning: cast from `GTypeInstance*' to `SPOffset*' increases required alignment of target type object-edit.cpp: In function `NR::Point sp_offset_offset_get(SPItem*)': object-edit.cpp:909: warning: cast from `GTypeInstance*' to `SPOffset*' increases required alignment of target type make[2]: *** [object-edit.o] Error 1 make[2]: Leaving directory `/usr/foo/inkscape/0.41/inkscape-0.41/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/foo/inkscape/0.41/inkscape-0.41' make: *** [all] Error 2 This is using gcc 3.3.2. It doesn't appear to have any actual error message that I can find. I would appreciate any pointers. Thanks. -- Christopher Wiedel

2 1

Fwd: Re: [Inkscape-devel] Inkboard CVS updates
by David Yip 01 Jul '05

01 Jul '05

On Friday 01 July 2005 01:04 pm, mental@...3... wrote: > I suspect the element and its sodipodi:type attribute might be > getting transmitted separately. > > i.e. the remote client ends up getting a bare <svg:path>, and > immediately creates an SPPath object. The sodipodi:type attribute > which would have instructed it to create an SPEllipse or whatever > might not arrive until it's too late. Actually, it seems like that's exactly what's going on, judging from the way Inkboard processes messages: the new object message arrives, so Inkboard creates a new object. However, only _then_ does it actually parse the type attribute and set it. I'm reworking received_new_object_helper to extract and set the type attribute before it creates the new object. Hopefully, this'll fix the problem. -- David

1 0

Inkboard CVS updates
by David Yip 01 Jul '05

01 Jul '05

I have committed a number of fixes to the Inkboard CVS <http://sourceforge.net/projects/inkboard> that address crashes related to buffer overflows. Instructions for building and running Inkboard can be found in my request for Inkboard testers that was posted to this list. Inkboard should now be much more stable than it previously was, sans conditions like invalid Jabber usernames or passwords. (I haven't gotten around to debugging those yet; I've been chasing down another bug, which is described below.) In a session between two peers Alice and Bob, if Alice sends a star, spiral, or ellipse, it will show up correctly on Bob's canvas, and (almost) any manipulations that Alice makes will be correctly replicated on Bob's canvas. However, if Bob manipulates the star, spiral, or ellipse in any way, the changes will not be correctly replicated on Alice's canvas. Additionally, Bob will not see the object as a star, spiral, or ellipse -- he will only see it as a path. I think these two problems are related, and since I'm not sure where to start with addressing the first problem, I've been focusing on the second, in the hope that it will cure the first :) I don't think this is a case of missing information: if Bob saves the document, exits, and then reopens it, any star, spiral, or ellipse will be correctly recognized as such, and not just a path. I think there's just something that Inkboard is just not triggering correctly. If anyone has any ideas on where to look or what to look for, I'd greatly appreciate them. Another, smaller bug: gradient editing is not replicated properly. Pressing "add" will replicate the changes, but the gradient objects themselves fall out of sync. Finally, just some thoughts about the near-future integration with Inkscape: Ideally, I'd like to begin merging Inkscape with Inkboard only when all of the bugs have been ironed out of the Inkboard code. That's rather unrealistic, though, especially since the act of merging may expose new bugs anyway! :) So it may be a good idea to create a new branch in the Inkscape codebase specifically for integration with Inkboard, and then merge branches when an acceptable level of robustness is achieved. -- David

3 3

object-edit.cpp:842: error: `isfinite' undeclared in namespace `std'
by Jeremy C. Reed 01 Jul '05

01 Jul '05

Building inkscape-0.41 on NetBSD 1.6.2_STABLE with GCC 3.3.3. I receive this error: if c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/pkg/include/freetype2 -I/usr/pkg/include -I/usr/pkg/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -DPOTRACE=\"potrace\" -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/pango-1.0 -I/usr/X11R6/include/freetype2 -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include/sigc++-2.0 -I/usr/pkg/lib/sigc++-2.0/include -I/usr/pkg/include/gtkmm-2.4 -I/usr/pkg/lib/gtkmm-2.4/include -I/usr/pkg/include/glibmm-2.4 -I/usr/pkg/lib/glibmm-2.4/include -I/usr/pkg/include/gdkmm-2.4 -I/usr/pkg/lib/gdkmm-2.4/include -I/usr/pkg/include/pangomm-1.4 -I/usr/pkg/include/atkmm-1.6 -I/usr/pkg/include/gtkspell-2.0 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -s -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -MT object-edit.o -MD -MP -MF ".deps/object-edit.Tpo" -c -o object-edit.o object-edit.cpp; \ then mv -f ".deps/object-edit.Tpo" ".deps/object-edit.Po"; else rm -f ".deps/object-edit.Tpo"; exit 1; fi object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:842: error: `isfinite' undeclared in namespace `std' gmake[2]: *** [object-edit.o] Error 1 Any ideas? (Please carbon-copy me on replies.) Jeremy C. Reed BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/

3 2

current cvs - problems compiling win32
by Adib Taraben 01 Jul '05

01 Jul '05

Hello, I checked out a fresh copy from the cvs. This does not compile with mingw because a used define is commented out in the makefile. See below. I also compiled a win32 installer for the 0.42pre0. This is 18meg, where should I put this? My webspace on geocities is only 10meg. Ciao, Adib. --- cvs diff -u3 -- Makefile.mingw.common (in directory D:\projekte\inkscape\) Index: Makefile.mingw.common =================================================================== RCS file: /cvsroot/inkscape/inkscape/Makefile.mingw.common,v retrieving revision 1.52 diff -u -3 -r1.52 Makefile.mingw.common --- Makefile.mingw.common 29 Jun 2005 07:07:29 -0000 1.52 +++ Makefile.mingw.common 30 Jun 2005 16:31:54 -0000 @@ -111,7 +111,7 @@ MSGFMT = $(GTKDOS)$(S)bin$(S)msgfmt ####### change me!! -DTG := 20050626 +DTG := 20050630 endif ########################################################################## @@ -120,10 +120,10 @@ ###### VERSION NUMBER -VERSION_NR = 0.41+devel +VERSION_NR = 0.42pre0 # VERSION_NR = 0.42+cvs -# VERSION = \"$(VERSION_NR)-${DTG}\" +VERSION = \"$(VERSION_NR)-${DTG}\" ####### the XP_WIN def is necessary for libjs.a CFLAGS = -O3 -Wall -mms-bitfields -DVERSION=$(VERSION) \ ***** CVS exited normally with code 1 *****

5 7

terminology proposal
by Jakub Steiner 01 Jul '05

01 Jul '05

Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative: Scripts ------- Scripts are little programs, written in interpreted language, that supply extended Inkscape functionality. They can work on objects, or even drav new objects on the canvas. Both Blender and GIMP projects eventually came to a conclusion that it makes no sense to separate scripts form the core functionality in terms of interface. A script should be free to register anywhere in the menus, based on its functionality. Grouping them, creating yet another menu structure, just because they are written in a particular language is not helpful to the user. Yes, it is pretty much what you call effects now. Filters ------- Filters are operations on selected objects, on their bitmap renderings even. The result of the filter replaces the original object and cannot be easily changed in future. The resulting image is stored in the file upon save. Effects ------- Effects are similar to filters, yet they are "dynamically" applied on a bitmap copy of the object at the target resolution. Only effect settings are stored in the file on save, and the effect needs to be recalculated (possibly some caching/preview voodoo needs to be applied to speed up preview). cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

11 17

Re: [Inkscape-user] center alignment about guidelines
by MenTaLguY 01 Jul '05

01 Jul '05

Incidentally, do you know what would be required to increase the default snap distance? It's currently quite small. -mental

3 2

guide lines: desktop vs document coordinate system
by Peter Moulder 30 Jun '05

30 Jun '05

Someone has bug #1222819: “guides have different orgin than objects”: horizontal guideline positions are currently stored as distance up from the bottom of the document (i.e. desktop coordinate system), whereas shape positions’ y coordinates are represented as distance from the top of the document. The result is that if you snap a shape’s position to a horizontal guideline and then resize the document (File>Document preferences, Custom page size, then change the page height), then the shape and the guideline will no longer appear to be at the same position. In my local copy I've mostly fixed this so that the guideline's position from the top of the document is preserved (as for shapes) rather than from the bottom. However, this does raise a user interface issue of how to report to the user what the guide line's position is: /* * For dialog boxes and status bar, should we report positions in the * document coordinate system or in the desktop coordinate system? * * The argument for reporting document coordinate system is that this is * the one that we honour when the document is resized, so in some sense * it is the true (or at least robust) position of the guide. OTOH, * resizing a document is rare. * * The argument for reporting desktop coordinate system is that this is * what's used by the rulers and "current position" indication. This is * the coordinate system that we usually report to users, so is less * confusing to users. * * ... * * (Hopefully, future versions of inkscape will get rid of the separate * desktop coordinate system, to remove this problem.) */ Comments? pjrm. -- bbyak: swatches, rich text, gradient on canvas... JonCruz: The answer to the ultimate question of life, the universe, and everything... JonCruz: Inkscape 0.42!!!!!!!

1 0

Fwd: [cairo] redesigning the arguments for svg2png
by unknown＠example.com 30 Jun '05

30 Jun '05

Just FYI in case you had anything to add.. ----- Forwarded message from Jason Dorje Short <jdorje@...859...> ----- Date: Wed, 29 Jun 2005 21:37:27 -0400 From: Jason Dorje Short <jdorje@...859...> Reply-To: Jason Dorje Short <jdorje@...859...> Subject: [cairo] redesigning the arguments for svg2png To: "Cairo Mail List (E-mail)" <cairo@...278...> Current arguments for svg2png: -w $WIDTH -h $HEIGHT -s $SCALE -x, --flipx -y, --flipy input.svg and output.png are taken directly as parameters This is all explained in `man svg2png`. The problem is it's incomplete. ---------- For instance if you give -w and -h svg2png makes an image with the given $WIDTH and $HEIGHT and puts the SVG file inside it with preserved aspect ratio. Thus there is no distortion and there is padding. One thing I need to do is to change the aspect ratio. I want to give a width and height and have the SVG "stretch" to take up this whole area. Thus the xscale and yscale are different. Thus there is distortion and there's no padding. This is what rsvg, sodipodi, and inkscape command-line renderers do. A third thing one would want to do is preserve the aspect ratio but without any padding. Thus the $WIDTH and $HEIGHT provide the max dimensions, just like svg2png does now, but without any padding. Thus there is no distortion and there is no padding. IIRC this is what the librsvg rsvg_pixbuf_from_file_at_max_size function does (which I've found very useful in the past). Yet another thing you might want to do is specify the xscale and yscale independently. I can't recall ever needing to do this, but rsvg allows it. Finally, one might wish to specify things in DPI. If the SVG image is given in real-world dimensions (e.g., inches) giving a DPI to render at will allow you to make the PNG image show up at the right size when rendered at that DPI (to a monitor or a printer). Aspect ratio is preserved; this is just a (possibly) convenient way of setting the --scale. Inkscape provides a -d $DPI parameter allowing this. Note that this will not work with all SVG files. ---------- Of course svg2png should be able to do all of the above tasks. It would also be nice to keep command-line compatibility with rsvg, inkscape, sodipodi. The trick is to do all this without having confusingly many options or giving unexpected default behavior. Thus I suggest: --width=$WIDTH (-w) --height=$HEIGHT (-h) --xscale=$X_SCALE (-x) --yscale=$Y_SCALE (-y) --flipx (-X maybe?) --flipy (-Y maybe?) --scale=$SCALE (-s) --dpi=$DPI (-d) --pad [1] --stretch You may pad or stretch or neither but not both. The default should be to do neither (same as rsvg, inkscape, and sodipodi), this changes the current behavior which is to pad. (--pad and --stretch were suggested by Carl.) Supporting -d will require new functions to libsvg and libsvg-cairo to set the DPI. -x and -y are changed from flipx and flipy to xscale and yscale. This matches the rsvg args (they call it --x-zoom, --y-zoom). In case of conflicting options (--width and --xscale both given) the one higher up in the list is given priority (this is obviously arbitrary and can be tweaked a bit). Care should be taken to give a sensible output no matter what combination of args are given (rsvg is pretty bad at this). ---------- For full compatibility with inkscape and rsvg it would be necessary to add more "long argument" aliases. This would be convenient but would also add clutter to the interface. Inkscape also has some additional parameters that might be useful, either for new features or compatibility. See -a, -f, -e, -i, -j, -t, -b, -y from `man inkscape`. I don't understand all of these but some of them are probably desirable. In a related note xsvg should probably support a similar set of options. Seems there could be a lot of overlap here. -jason _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo ----- End forwarded message -----

3 2

GString or standard C++ library strings?
by David Yip 30 Jun '05

30 Jun '05

To mitigate overflow issues with fixed-size buffers in the Inkboard code for message transmission, I'm going to convert the Inkboard messaging code to use strings. However, I'm not really sure what string implementation would be preferred by the Inkscape team. As a lot of Inkboard and Inkscape code use glib facilities, the GString has that advantage, but since we're using C++... I don't see this explicitly touched on in the Developer's Manual or the InkscapeJanitor wiki pages, so I'm guessing it hasn't been brought up before, but if it's listed somewhere, I apologize for the duplicate message. -- David

5 5