- Inkscape Devel - Inkscape Mailman

filedialog change
by bulia byak 21 Dec '04

21 Dec '04

In file dialogs, I removed the name of the file above the preview: - it's a bit tautologic, as the file is already selected in the list anyway - removing it frees a bit more space for the preview itself - most importantly, long filenames stretch the preview and thus distort the dialog layout, and there's no way to ellipcize the filename label (at least yet, as of GTK 2.6) I like this change, but I realize there may be different opinions, so comments are welcome.

5 9

Re: [cairo] cairo backend for xpdf - first drop (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

More evaluation info about the PDF backend in Cairo ---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 16:40:10 -0500 From: Carl Worth <cworth@...43...> To: Alexander Larsson <alexl@...43...> Cc: cairo <cairo@...278...> Subject: Re: [cairo] cairo backend for xpdf - first drop On Mon, 20 Dec 2004 19:54:12 +0100, Alexander Larsson wrote: > I found an embarrasing bug in it. It kept reading the fonts over and > over again. With that fixed, and with all the performance fixes in Cairo > cvs xpdf-cairo now feels faster than the standard xpdf on my machine. > > I'm attaching the new patch. Alexander, This is fantastic work. I think I may have found a new favorite PDF viewer. The rendering of the glyphs is so much nicer compared to standard xpdf. Though I notice that the improved hinting allows some extra room in which the intra-word spacing could be improved. To my eye, intra-word problems, (such as two adjacent letters colliding) stand out more with the hinting of xdpf-cairo, whereas with xpdf-standard the words are just blurry everywhere. Do you generally still have word structure available in PDF files? Or is every glyph already placed individually? Meanwhile, line art appears to have better snapping with xpdf-standard, (or more likely that's just the lack of antialiasing). I've been meaning to propose a cairo_set_snapping API for some time and I think this application gives us perfect justification and some great test cases for that. Oh, and we still need to add sub-pixel rendering to cairo fonts, (geometry too!), to make things even more legible. Once we get all that done, I think it might even be pleasant to read many documents on a display instead of printing them out. I'm quite happy to see this area improve. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [cairo] New PDF backend snapshot (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 15:41:47 -0500 From: Carl Worth <cworth@...573...> To: Kristian HÃ¸gsberg <krh@...618...> Cc: cairo@...278... Subject: Re: [cairo] New PDF backend snapshot --[[text/plain]] Kristian, Thanks so much for all your hard work on the PDF backend! I'm sorry I've been so slow to review it. I think this is good work, and I want it to land in CVS soon. I have a few comments, (most importantly with respect to the public API). On Wed, 15 Dec 2004 12:52:38 -0500, Kristian HÃ¸gsberg wrote: > I've pondering the cairo_document_t idea a bit and restructured the PDF > backend so that it's split into a cairo_pdf_document_t object and a > cairo_pdf_surface_t object. I believe this makes the code easier to > follow, but I'm no longer sure we need to expose a cairo_document_t in > the user API. If it's easier to have two objects in the backend, that is fine. > public API. 2) It will be a nice way to set metadata and other PDF > specific information for the document. Can't we just do that with cairo_pdf_surface functions? What advantage does the user get from having two different objects? So far, it seems the user just has to do more work before being able to use the PDF backend, (compared to the others). > +void > +cairo_set_target_pdf (cairo_t *cr, > + cairo_pdf_document_t *document); The notion behind the cairo_set_target family of functions is to allow the user to select a backend without having to create any new object. So the cairo_set_target_pdf function should accept the same arguments as cairo_pdf_surface_create. So, I think I would like to see the new public cairo_pdf API match the existing cairo_ps API exactly: cairo_surface_t * cairo_ps_surface_create (FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); void cairo_set_target_pdf (cairo_t *cr, FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); > There are two significant changes outside cairo_pdf_surface.c in this > patch: I've added the set_clip_trapezoids surface method which is > supposed to let cairo pass the absolute clipping path to the backends. (Kristian and I discussed this off-list and he has now proposed a new patch without the set_clip_trapezoids method. See: http://people.redhat.com/krh/cairo-pdf/cairo-pdf-4.patch ) > The other change is the addition of cairo_array_t implemented in > cario_array.c. This is an standard autogrowing array, doubling the > allocation size when it runs out of space. I was using chained lists > before in the PDF backend, but I converted those to arrays. I added the > array as a general data type, since cairo uses the same type of array in > other places and it might make sense to rewrite those places to use this > array type. Eliminating some code duplication seems like a good thing. But I don't like giving up type safety, and worse, I don't want to give up direct access of arrays using C [] notation. This kind of thing is always a tough call since C has no support for what we really want here. Regardless, if the code is to stay, then: > + if (old_size == 0) > + new_size = 1; > + else > + new_size = old_size * 2; > + > + while (new_size < required_size) > + new_size = old_size * 2; should be: new_size = new_size * 2; to eliminate the infinite loop. And these three functions: > +static cairo_status_t > +_cairo_pdf_surface_set_matrix (void *abstract_surface, > + cairo_matrix_t *matrix) > + > +static cairo_status_t > +_cairo_pdf_surface_set_filter (void *abstract_surface, > + cairo_filter_t filter) > + > +static cairo_status_t > +_cairo_pdf_surface_set_repeat (void *abstract_surface, > + int repeat) merit at least a comment stating they are unsupported. This isn't *too* big a deal as I want to eliminate these functions from the surface interface anyway, (they really only belong on patterns). Once the issues above are resolved I'd like to get this into CVS. I haven't actually played with the PDF output yet, but we can have fun playing with that after it lands in the tree. Thanks again. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [Inkscape-user] Textbox
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Cliff wrote: > > On Thu, 16 Dec 2004 13:56:59 +0100, Imre Vida > > <Imre.Vida@...617...> wrote: > > > Do you plan to implement such a feature? > > > > Yes. In fact it already works, though there's no UI for it yet. See > > share/examples/flowsample.svg > > > > Theres no decent, complete UI, but to add the elements needed to put > text into shapes you can select them, right click and do 'add text to > shapes' to add the text itself you currently need to use the xml > editor. better than starting from scratch tho. What sort of UI does this need to have? Is this something that'll be easy to do, or will it need to be planned out? Bryce

2 1

Mozilla/Firefox SVG now has <image> tags
by Bob Jamison 21 Dec '04

21 Dec '04

This is so cool. The code for implementing the <image> tag in Mozilla SVG, which was previously a set of patches, apparently has made it into the mainline. Previously, the Mozilla guys were forced to use the <foreignObject> tag. Here is the SVG file w/images that I always use to test this stuff. Ignore the text alignment; obviously I need to convert it to curves. http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ff_ccp_dump.png Bob

1 0

problem compiling from CVS, python-related
by Ben Crowell 21 Dec '04

21 Dec '04

Can anyone suggest how to fix/work around this problem compiling the latest CVS version? It seems to be related to python extensions. TIA! ======================================================================================= [snip] Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-inkscape_perl_wrap.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Tpo" -c -o extension/script/extension_script_libscript_a-inkscape_perl_wrap.o `t est -f 'extension/script/inkscape_perl_wrap.cpp' || echo './'`extension/script/i nkscape_perl_wrap.cpp; \ then mv -f "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wr ap.Tpo" "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Po"; else rm -f "extension/script/.deps/extension_script_libscript_a-inkscape_pe rl_wrap.Tpo"; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-InkscapePython.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" -c -o extension/script/extension_script_libscript_a-InkscapePython.o `test -f 'exte nsion/script/InkscapePython.cpp' || echo './'`extension/script/InkscapePython.cp p; \ then mv -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.T po" "extension/script/.deps/extension_script_libscript_a-InkscapePython.Po"; els e rm -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" ; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig extension/script/InkscapePython.cpp:13:20: Python.h: No such file or directory extension/script/InkscapePython.cpp: In member function `virtual bool Inkscape::Extension::Script::InkscapePython::interpretScript(Glib::ustring&, Glib::ustring&, Glib::ustring&)': extension/script/InkscapePython.cpp:62: error: `Py_Initialize' undeclared (first use this function) extension/script/InkscapePython.cpp:62: error: (Each undeclared identifier is reported only once for each function it appears in.) extension/script/InkscapePython.cpp:67: error: `PyRun_SimpleString' undeclared (first use this function) make[2]: *** [extension/script/extension_script_libscript_a-InkscapePython.o] Er ror 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2 -

2 1

Re: File Chooser
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Taber wrote: > For some reason I can subscribe to get the Inkscape mail list but my posts get > rejected so am sending this direct.... Can you forward us one of the rejection emails? Maybe we can figure out what's going wrong. > Yes, Gtk filechooser is a total DISASTER as seen by anyone in our office. In > fact it will probably surface more with Firefox as 10 million converts start > trying to download files. It even took me several weeks before I realized > the listbox on left is a bookmark list and it seems like now I just have to > go thru more keystrokes. So you have our vote to modify it to allow > filenames to be typed in. This type of Gtk weirdness really hurts Gtk > adoption. > > btw We now depend on Inkscape for our graphics work and thank all of you for > the great job you are doing on it - it is simply one of the most energetic > and best managed open source projects. How can we convince Fedora folks to > include it ? When Firefox hopefully soon supports SVG, Inkscape will be a > must and hot ticket. > John Cool, good to hear. I don't know how Fedora decides what to include, but perhaps you can send an email to them requesting it? An email to encourage Firefox's SVG efforts would probably be worthwhile too. Bryce

1 0

Multiple page documents in SVG
by Bryce Harrington 20 Dec '04

20 Dec '04

This question came up a couple times this past week. SVG 1.2 (which we don't yet support) provides a method for doing multiple paged documents: http://www.w3.org/TR/SVG12/multipage.html Example: <svg xmlns="http://www.w3.org/2000/svg" version="1.2"> <pageSet>  <page> <circle cx="100" cy="100" r="20" fill="blue"/> </page>  <page> <rect x="100" y="100" width="20" height="20" fill="red"/> </page> </pageSet> </svg> Bryce

4 3

-users -developers test please ignore
by vellum 20 Dec '04

20 Dec '04

1 0

test ignore
by vellum 20 Dec '04

20 Dec '04

1 0

RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

[Please cc: me on replies] Hi, I'm resending this after not hearing any responses to my first email over a period of two weeks... :) I'm using Inkscape 0.40 packaged for Debian unstable. If its an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue/bug, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the "file" utility, to be regular postscript, rather than encapsulated postscript). I've tentatively tracked this down to be the lack of the full first-line of "%!PS-Adobe-3.0 EPSF-3.0" and instead only having "%!PS-Adobe-3.0". Ghostscript utilities, such as eps2eps, produce the full line, while inkscape produces the shorter version. Changing the latter to the former seemed to convince the Linux "file" utility that the file was now EPS. Any ideas on what's the right thing to do? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I"ve given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

3 2

Re: [Inkscape-devel] RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

Hi Bulia, Thanks for the reply... I'm guessing that you shouldn't need skencil to reproduce this bug and do a test EPS import, since I don't have it on my system and EPS imports work (I always assumed that you'd use ghostscript for EPS imports). Anyway, that bug looked familiar but the consensus was that something might be wrong due to an Adobe Illustrator issue. Mine however are EPS outputs produced only using Free Software tools (potrace from gimp-based input scan). If it really helps you, I could probably send you the inputs off-list, but I'd prefer to keep them private unless necessary. For the record, I can make it do this with any sample EPS file I gave it (comparing it to size in ghostview or through import into scribus). Thanks for the help. Let me know if there's anything else I can do. Any ideas about Postscript versus EPS recognition issue I mentioned also? Take care, Daniel > Whenever I place EPS files into a new Inkscape document, they appear > to be smaller (in pixel size or actual size, based upon bounding box) > than they should be. It seems to be this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1027699&group_id=9… If you attach there your comments and the sample EPS and SVG files from potrace it would be very helpful. The bug seems to be easy to fix (apparently the px and pt units are confused somewhere, we had several bugs of this kind) but I can't fix it now because I don't have Skencil installed (afaik we can only import EPS via Skencil).

2 1

Inkscape on LWN
by Bryce Harrington 20 Dec '04

20 Dec '04

Peter pointed out that LWN is featuring Inkscape on its Front page this week. http://lwn.net/ Bryce Vector graphics with Inkscape December 8, 2004 This article was contributed by Joe 'Zonker' Brockmeier. With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right. Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG) specification for its native format, and also exports to PNG, as well as saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and PovRay formats. Inkscape will open or import graphics from Adobe Illustrator and Dia, other programs' SVG documents and a wide array of bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X. We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries. To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface. With an application like Inkscape, using a mouse (or tablet) is almost unavoidable. However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and lowering an object from one layer to another, from the keyboard -- rather than having to grab the mouse to switch between tools or adjust layers. For example, to toggle the current tool from Inkscape's path tool to the select tool, all that's necessary is to hit the space bar or F1. To move an object up one layer, simply hit "Page Up" or "Page Down" to move it lower. Speaking of layers, layer management is one of the major new features in Inkscape with the 0.40 release, according to the release notes. Another new feature in 0.40 is a "text-on-path" feature. This allows the user to conform text to a path -- which is useful for creating interesting logos and other artwork that requires text to wrap text to a shape other than a rectangle. The feature is certainly easy to use. All that's required is to select a path and the text object that is to conform to the path. Rectangles, ellipses and other objects must be converted to a path before the user can wrap text to fit that object. By manipulating that object, the user can change the flow of the text even if the text has been removed from the object or if the object is "invisible" because there is no fill color or stroke color associated with the object. The only thing we couldn't figure out was how to specify a starting point on a path for the text. We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to trace an imported bitmap. By importing a photo or other bitmap, it's possible to create an scalable object that can then be turned into paths or otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The trace bitmap feature works best with line art, but can be used to produce some fun effects with photos or other artwork. Inkscape's performance and stability are excellent. We created a number of documents using Inkscape, exported our documents and some of the Inkscape tutorials to PNG, EPS and PS, and didn't see any glitches. The program never crashed while we were testing, and all of the features that are currently in Inkscape seem to work as advertised. We did noticed that some detail was lost when exporting to EPS from the tutorials, but this may not be an Inkscape limitation. Though Inkscape doesn't have a full user manual at this stage, it does include several useful tutorials for basic and advanced concepts when working with Inkscape, as well as an excellent man page. It also features an "Elements of Design" document, which may be useful for users who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar. For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing. Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format. SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly. Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.

10 38

Extensions stuff
by Ted Gould 19 Dec '04

19 Dec '04

Hey all, First, I'll apologize for my disappearing -- I've been crazy busy, but I hope that it will start to be getting better. I've not read through most of the Inkscape lists, and there seems to be some discussion on extensions, I'm going to try to hit everything I remember in one mega e-mail. -- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future. -- There seemed to be a few "where are extensions going?" type of e-mails. I guess my 'grand goal' is to have them pretty much everywhere, but in the short term I'd like to get functionality similar to GIMP's filters working. This would involve having a menu item which would cause modifications to the document based on some plugable functionality. I hope this can be done with scripts and plugins, and made to 'just work' for every user of Inkscape. This goal may seem overly ambitious, but there is tons of the infrastructure already in place. Some solid documentation has been started on this by Bryce. Find it here: (it also explains the terminology that we've been using) http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/doc/extension_syste… -- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere. -- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out. -- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also? Okay, that is all I can remember right now... tell me more, I should be more responsive now! --Ted PS -- If anyone is looking for "bite-sized" extensions task to do over winter break or something similar, ask, I think that I have a few.

4 5

layer display
by bulia byak 18 Dec '04

18 Dec '04

When you enter a group, the layer selector in the statusbar shows only the ancestors of the group, while regular layers that are siblings of the parent layer disappear. Is there a reason for this? I would much prefer it to always show siblings of each ancestor layer. Without this, to go to the layer above, I have to use the widget twice: once to go up from the group and then again go to the layer above.

2 3

Re: [Inkscape-devel] Re: [Inkscape-user] RPM build errors
by Ted Gould 17 Dec '04

17 Dec '04

On Mon, 2004-12-06 at 16:07 +0000, Jonathan Leighton [Turnip] wrote: > #7 0x0828ab18 in Inkscape::Extension::Dependency::check () > #8 0x082890e8 in Inkscape::Extension::Extension::check () > #9 0x0828c50f in Inkscape::Extension::Input::check () > #10 0x0828b0f9 in Inkscape::Extension::Dependency::check () > #11 0x08289e69 in Inkscape::Extension::DB::foreach () > #12 0x0828b20e in Inkscape::Extension::init () > #13 0x080c53b2 in sp_main_gui () > #14 0x080c55ae in main () Hmm, I can't find anywhere that Inkscape::Extension::Dependency::check calls Inkscape::Extension::Extension::check() (and thus, Inkscape::Extension::Input::check()). Can someone look at src/extension/dependency.cpp just to make sure I'm not insane? Anyone have any other ideas? --Ted

7 14

[Fwd: [cairo] 10000% performance increase for clip surfaces]
by Bob Jamison 17 Dec '04

17 Dec '04

Hi, all. Saw this today on the Cairo list. I don't know if the patch is valid, but it seems to improve performance for me on Cairo, too. Open Source at work. BOb

1 0

script for embedding raster images
by Ben Crowell 17 Dec '04

17 Dec '04

The following patch to sp-image.cpp allows Inkscape to read Adobe Illustrator files that have the "data:;base64" syntax for embedded images. The embedded images are displayed correctly on the screen. However, if you save the file, the resulting svg output still has "data:;base64", which is obviously a Bad Thing. I started looking around in the code for where the output happens, but C++ isn't a language I'm very comfortable with, and I rapidly got lost. I'd be grateful for any insight from anyone who understands the code and the language better. I'd prefer not to commit the patch for the input without making the output standards-compliant. ===================== patch to sp-image.cpp ======================= 902a903,913 > // bcrowell, 2004 dec 13: > // Adobe Illustrator writes output like this: > // data:;base64, > // This is illegal according to the SVG standard, but there seems to be a consensus > // on inkscape-devel that Inkscape should allow input like this anyway. It would > // be nice to do a better syntax check here, but Lauris Kaplinski's old-school C parser > // is already pretty complicated; probably we should be using a C++ regular expression > // library instead. The following line allows input of lame Illustrator SVG: > data_is_image = 1; > // However, the output isn't any more correct than the input. >

5 5

Solaris and SunPro patch
by Robin KAY 16 Dec '04

16 Dec '04

I have made a giant patch against inkscape 0.38.1 which allows it compile under Solaris and with the SunPro compiler. No doubt it won't apply cleanly against the CVS head but I'll look in to that in a few days. Most of the changes are fairly straightforward. A lot of function prototypes had different type signatures to their implementations. Namespace declarations were terminated with semicolons when they shouldn't be. A few source files used GNU extensions. Some numerical constants had ambiguous types. The Solaris maths library doesn't have separate functions for single precision values and fpresetsticky is called fpsetsticky. I created a header file, floatmaths.h, which contains appropriate defines to remedy this. I also replaced <stdint.h> with <inttypes.h>. C99 library support starts with Solaris 10. The only changes of dubious merit I can think of were; changing round to rint as I'm not sure if this will affect the semantics of the code in questions, and importing an implementation of hash_map when you should really switch to GHashTable as the comments suggest. I couldn't see an obvious place to initialize the GHashTables. Note that the floating point optimization level (-fsimple=n) must be 1 or lower as aggressive optimization will break assertions in the code. I will probably create a Inkscape package for blastwave.org (CSW). BTW, on an unrelated note, are there any plans for animation support? -- Wishing you good fortune, --Robin Kay-- (komadori) diff -ur inkscape-0.38.1-orig/src/chunk.h inkscape-0.38.1/src/chunk.h --- inkscape-0.38.1-orig/src/chunk.h 2004-07-02 01:52:04.126170000 +0100 +++ inkscape-0.38.1/src/chunk.h 2004-07-01 04:19:00.151422000 +0100 @@ -0,0 +1,84 @@ +/*! \file deque + * \brief This header provides the definitions and decleration of the chunk class used in hash_map + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +//#include <alloc.h> +#include <iterator> + +// using pair +#include <utility> + +// using operator new +#include <memory> + +// Type legend: +// H: (small) key type, should support effective == +// K: key type +// T: content type + +typedef unsigned int uint; + +template <class H, class K, class T, uint chunk_size> +class chunk { + typedef std::pair<const K, T> pair_t; // <key, value> pair +public: + chunk(): next(0){ + d = reinterpret_cast<pair_t*>(dd); + } + void free_data(size_t end_pos=chunk_size) { + //destroy(d,d+end_pos); + for (size_t i=0; i<end_pos; i++) { + (&d[i])->~pair_t(); + } + }; + + + H h[chunk_size]; // hash values + chunk* next; // next chunk +/// chunk* prev; // previous chunk + // we're using a char[] to get some "raw" memory + char dd[chunk_size * sizeof(pair_t)]; // space for data pairs + pair_t* d; // iterator used to access data pairs + + // the find functions will return a 0-pointer if the element was not found + + // find to use when doing lookups and inserts + pair_t* find_p(H hh, const K& kk, uint last = chunk_size) { + for (uint i = 0; i < last; ++i) { +#ifdef N_USE_HASH + if (kk == (d[i]).first) {return &d[i];} +#else + if (hh == h[i] && kk == (d[i]).first) {return &d[i];} +#endif + } + return 0; + } + + // find to use when deleting elements, we will move the last + // element in the bucket to the place + // hpp is a place to return a pointer to the small hashvalue + + pair_t* find_d(H hh, const K& kk, H** hpp, + uint last = chunk_size) { + for (uint i = 0; i < last; ++i) { +#ifdef N_USE_HASH + if (kk == (d[i]).first) { +#else + if (hh == h[i] && kk == (d[i]).first) { +#endif + *hpp = &h[i]; + return &d[i]; + } + } + return 0; + } + // set a value + // this function is the only one used to set elements directly + void set(H hh, const pair_t& p, uint i) { + h[i] = hh; + // do inplace new + pair_t* pp = &d[i]; + new(pp) pair_t(p); + } +}; diff -ur inkscape-0.38.1-orig/src/desktop-snap.cpp inkscape-0.38.1/src/desktop-snap.cpp --- inkscape-0.38.1-orig/src/desktop-snap.cpp 2004-03-03 23:44:37.000000000 +0000 +++ inkscape-0.38.1/src/desktop-snap.cpp 2004-07-01 03:07:30.120952000 +0100 @@ -71,7 +71,7 @@ NR::Point const req0(req); /* Implement "move from req0 by some multiple of mv" as "dot product with something orthogonal to mv remains unchanged". */ - NR::Point const n2(rot90(mv)); + NR::Point const n2(NR::rot90(mv)); double const d2 = dot(n2, req); if(sp_intersector_line_intersection(n2, d2, n, d, req) == intersects) { return L2(req - req0); Only in inkscape-0.38.1/src: desktop-snap.o diff -ur inkscape-0.38.1-orig/src/desktop.cpp inkscape-0.38.1/src/desktop.cpp --- inkscape-0.38.1-orig/src/desktop.cpp 2004-04-06 06:39:41.000000000 +0100 +++ inkscape-0.38.1/src/desktop.cpp 2004-07-01 03:05:16.156205000 +0100 @@ -823,7 +823,7 @@ gtk_box_pack_start (GTK_BOX (sbar), dtw->sticky_zoom, FALSE, FALSE, 0); // zoom status spinbutton - dtw->zoom_status = gtk_spin_button_new_with_range (log(SP_DESKTOP_ZOOM_MIN)/log(2), log(SP_DESKTOP_ZOOM_MAX)/log(2), 0.1); + dtw->zoom_status = gtk_spin_button_new_with_range (log(SP_DESKTOP_ZOOM_MIN)/log(2.0), log(SP_DESKTOP_ZOOM_MAX)/log(2.0), 0.1); gtk_tooltips_set_tip (tt, dtw->zoom_status, _("Zoom"), NULL); gtk_widget_set_usize (dtw->zoom_status, STATUS_ZOOM_WIDTH, -1); gtk_entry_set_width_chars (GTK_ENTRY (dtw->zoom_status), 6); @@ -1744,20 +1744,20 @@ sp_desktop_widget_update_zoom (SPDesktopWidget *dtw) { g_signal_handlers_block_by_func (G_OBJECT (dtw->zoom_status), (gpointer)G_CALLBACK (sp_dtw_zoom_value_changed), dtw); - gtk_spin_button_set_value (GTK_SPIN_BUTTON (dtw->zoom_status), log(SP_DESKTOP_ZOOM(dtw->desktop)) / log(2)); + gtk_spin_button_set_value (GTK_SPIN_BUTTON (dtw->zoom_status), log(SP_DESKTOP_ZOOM(dtw->desktop)) / log(2.0)); g_signal_handlers_unblock_by_func (G_OBJECT (dtw->zoom_status), (gpointer)G_CALLBACK (sp_dtw_zoom_value_changed), dtw); } gdouble sp_dtw_zoom_value_to_display (gdouble value) { - return floor (pow (2, value) * 100.0 + 0.5); + return floor (pow (2.0, value) * 100.0 + 0.5); } gdouble sp_dtw_zoom_display_to_value (gdouble value) { - return log (value / 100.0) / log (2); + return log (value / 100.0) / log (2.0); } gint diff -ur inkscape-0.38.1-orig/src/dialogs/filedialog.cpp inkscape-0.38.1/src/dialogs/filedialog.cpp --- inkscape-0.38.1-orig/src/dialogs/filedialog.cpp 2004-04-07 07:14:56.000000000 +0100 +++ inkscape-0.38.1/src/dialogs/filedialog.cpp 2004-07-01 02:17:05.166324000 +0100 @@ -348,7 +348,7 @@ -}; //namespace Dialogs -}; //namespace UI -}; //namespace Inkscape +} //namespace Dialogs +} //namespace UI +} //namespace Inkscape diff -ur inkscape-0.38.1-orig/src/dialogs/filedialog.h inkscape-0.38.1/src/dialogs/filedialog.h --- inkscape-0.38.1-orig/src/dialogs/filedialog.h 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/dialogs/filedialog.h 2004-07-01 02:16:48.494087000 +0100 @@ -167,13 +167,9 @@ }; //FileSaveDialog -}; //namespace Dialogs -}; //namespace UI -}; //namespace Inkscape - - - - +} //namespace Dialogs +} //namespace UI +} //namespace Inkscape #endif /* __FILE_DIALOG_H__ */ diff -ur inkscape-0.38.1-orig/src/dir-util.cpp inkscape-0.38.1/src/dir-util.cpp --- inkscape-0.38.1-orig/src/dir-util.cpp 2004-01-26 00:29:37.000000000 +0000 +++ inkscape-0.38.1/src/dir-util.cpp 2004-07-01 19:10:45.924433000 +0100 @@ -6,10 +6,10 @@ #include "dir-util.h" #include <string.h> -const gchar * -sp_relative_path_from_path (const gchar * path, const gchar * base) +const char * +sp_relative_path_from_path (const char * path, const char * base) { - const gchar * p, * b, * r; + const char * p, * b, * r; if (path == NULL) return NULL; if (base == NULL) return path; @@ -31,10 +31,10 @@ return path; } -const gchar * -sp_extension_from_path (const gchar * path) +const char * +sp_extension_from_path (const char * path) { - const gchar * p; + const char * p; if (path == NULL) return NULL; diff -ur inkscape-0.38.1-orig/src/display/nr-arena-shape.cpp inkscape-0.38.1/src/display/nr-arena-shape.cpp --- inkscape-0.38.1-orig/src/display/nr-arena-shape.cpp 2004-04-07 07:14:56.000000000 +0100 +++ inkscape-0.38.1/src/display/nr-arena-shape.cpp 2004-07-01 02:44:01.685201000 +0100 @@ -13,7 +13,8 @@ */ -#include <math.h> +#include "../floatmaths.h" + #include <string.h> #include <glib.h> #include <libnr/nr-rect.h> diff -ur inkscape-0.38.1-orig/src/document.cpp inkscape-0.38.1/src/document.cpp --- inkscape-0.38.1-orig/src/document.cpp 2004-03-14 03:21:29.000000000 +0000 +++ inkscape-0.38.1/src/document.cpp 2004-07-01 19:23:15.250308000 +0100 @@ -839,7 +839,7 @@ } SPItem* -sp_document_item_at_point (SPDocument *document, unsigned int key, NR::Point p, gboolean into_groups) +sp_document_item_at_point (SPDocument *document, unsigned int key, NR::Point const p, gboolean into_groups) { g_return_val_if_fail (document != NULL, NULL); g_return_val_if_fail (SP_IS_DOCUMENT (document), NULL); diff -ur inkscape-0.38.1-orig/src/extension/db.cpp inkscape-0.38.1/src/extension/db.cpp --- inkscape-0.38.1-orig/src/extension/db.cpp 2004-04-04 04:58:41.000000000 +0100 +++ inkscape-0.38.1/src/extension/db.cpp 2004-07-01 02:58:43.204554000 +0100 @@ -247,4 +247,4 @@ return; } -}; }; /* namespace Extension, Inkscape */ +} } /* namespace Extension, Inkscape */ diff -ur inkscape-0.38.1-orig/src/extension/db.h inkscape-0.38.1/src/extension/db.h --- inkscape-0.38.1-orig/src/extension/db.h 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/extension/db.h 2004-07-01 02:16:29.950175000 +0100 @@ -68,7 +68,7 @@ extern DB db; -}; }; /* namespace Extension, Inkscape */ +} } /* namespace Extension, Inkscape */ #endif /* __MODULES_DB_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/extension.cpp inkscape-0.38.1/src/extension/extension.cpp --- inkscape-0.38.1-orig/src/extension/extension.cpp 2004-04-08 06:33:02.000000000 +0100 +++ inkscape-0.38.1/src/extension/extension.cpp 2004-07-01 02:57:42.971575000 +0100 @@ -928,6 +928,6 @@ } -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Extension */ +} /* namespace Inkscape */ diff -ur inkscape-0.38.1-orig/src/extension/extension.h inkscape-0.38.1/src/extension/extension.h --- inkscape-0.38.1-orig/src/extension/extension.h 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/extension.h 2004-07-01 02:12:37.479116000 +0100 @@ -129,6 +129,8 @@ variable. It should really take up a very small space. It's important to note that the name is stored as the key to the hash table. */ + class param_t; + friend class param_t; class param_t { public: gchar * name; /**< The name of this parameter */ @@ -263,8 +265,8 @@ const SPStyle *style); }; -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __INK_EXTENSION_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/implementation/implementation.cpp inkscape-0.38.1/src/extension/implementation/implementation.cpp --- inkscape-0.38.1-orig/src/extension/implementation/implementation.cpp 2004-03-17 06:52:34.000000000 +0000 +++ inkscape-0.38.1/src/extension/implementation/implementation.cpp 2004-07-01 02:46:20.282594000 +0100 @@ -129,9 +129,9 @@ return 0; } -}; /* namespace Implementation */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Implementation */ +} /* namespace Extension */ +} /* namespace Inkscape */ /* Local Variables: diff -ur inkscape-0.38.1-orig/src/extension/implementation/implementation.h inkscape-0.38.1/src/extension/implementation/implementation.h --- inkscape-0.38.1-orig/src/extension/implementation/implementation.h 2004-03-17 06:52:34.000000000 +0000 +++ inkscape-0.38.1/src/extension/implementation/implementation.h 2004-07-01 02:21:30.733764000 +0100 @@ -18,7 +18,7 @@ namespace Extension { namespace Implementation { class Implementation; -};};}; +} } } #include <extension/extension.h> @@ -94,9 +94,9 @@ const SPStyle *style); }; -}; /* namespace Implementation */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Implementation */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __INKSCAPE_EXTENSION_IMPLEMENTATION_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/implementation/script.cpp inkscape-0.38.1/src/extension/implementation/script.cpp --- inkscape-0.38.1-orig/src/extension/implementation/script.cpp 2004-04-08 06:31:58.000000000 +0100 +++ inkscape-0.38.1/src/extension/implementation/script.cpp 2004-07-01 02:52:19.418915000 +0100 @@ -54,7 +54,7 @@ officially in the load function. This allows for less allocation of memory in the unloaded state. */ -Script::Script (void) : Implementation::Implementation() +Script::Script() /*: Implementation::Implementation()*/ { command = NULL; return; @@ -569,9 +569,9 @@ return; } -}; /* Inkscape */ -}; /* module */ -}; /* Implementation */ +} /* Inkscape */ +} /* module */ +} /* Implementation */ /* Local Variables: diff -ur inkscape-0.38.1-orig/src/extension/implementation/script.h inkscape-0.38.1/src/extension/implementation/script.h --- inkscape-0.38.1-orig/src/extension/implementation/script.h 2004-04-02 17:23:15.000000000 +0100 +++ inkscape-0.38.1/src/extension/implementation/script.h 2004-07-01 02:48:59.139245000 +0100 @@ -55,9 +55,9 @@ }; -}; /* Inkscape */ -}; /* Extension */ -}; /* Implementation */ +} /* Inkscape */ +} /* Extension */ +} /* Implementation */ #endif /* __INKSCAPE_EXTENSION_IMPEMENTATION_SCRIPT_H__ */ /* diff -ur inkscape-0.38.1-orig/src/extension/internal/ps-out.cpp inkscape-0.38.1/src/extension/internal/ps-out.cpp --- inkscape-0.38.1-orig/src/extension/internal/ps-out.cpp 2004-04-02 16:24:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps-out.cpp 2004-07-01 02:56:56.473003000 +0100 @@ -63,4 +63,4 @@ return; } -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps-out.h inkscape-0.38.1/src/extension/internal/ps-out.h --- inkscape-0.38.1-orig/src/extension/internal/ps-out.h 2004-04-02 16:24:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps-out.h 2004-07-01 02:56:42.269315000 +0100 @@ -29,7 +29,7 @@ }; -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ #endif /* EXTENSION_INTERNAL_PS_OUT_H */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps.cpp inkscape-0.38.1/src/extension/internal/ps.cpp --- inkscape-0.38.1-orig/src/extension/internal/ps.cpp 2004-04-09 07:16:06.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps.cpp 2004-07-01 02:55:55.706445000 +0100 @@ -845,8 +845,8 @@ } -}; /* namespace Internal */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Internal */ +} /* namespace Extension */ +} /* namespace Inkscape */ /* End of GNU GPL code */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps.h inkscape-0.38.1/src/extension/internal/ps.h --- inkscape-0.38.1-orig/src/extension/internal/ps.h 2004-03-03 04:30:21.000000000 +0000 +++ inkscape-0.38.1/src/extension/internal/ps.h 2004-07-01 02:55:29.807654000 +0100 @@ -70,8 +70,8 @@ static void init (void); }; -}; /* namespace Internal */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Internal */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __EXTENSION_INTERNAL_PS_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/internal/svg.cpp inkscape-0.38.1/src/extension/internal/svg.cpp --- inkscape-0.38.1-orig/src/extension/internal/svg.cpp 2004-04-06 06:39:43.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/svg.cpp 2004-07-01 02:54:13.362159000 +0100 @@ -172,4 +172,4 @@ return; } -};};}; /* namespace inkscape, module, implementation */ +} } } /* namespace inkscape, module, implementation */ diff -ur inkscape-0.38.1-orig/src/extension/internal/svg.h inkscape-0.38.1/src/extension/internal/svg.h --- inkscape-0.38.1-orig/src/extension/internal/svg.h 2004-03-03 04:30:21.000000000 +0000 +++ inkscape-0.38.1/src/extension/internal/svg.h 2004-07-01 02:53:52.417928000 +0100 @@ -33,7 +33,7 @@ }; -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ #endif /* __SVG_H__ */ /* diff -ur inkscape-0.38.1-orig/src/fast_bucket.h inkscape-0.38.1/src/fast_bucket.h --- inkscape-0.38.1-orig/src/fast_bucket.h 2004-07-02 01:52:59.717860000 +0100 +++ inkscape-0.38.1/src/fast_bucket.h 2004-07-01 04:18:05.727462000 +0100 @@ -0,0 +1,191 @@ +/*! \file fast_bucket.h + * \brief This header provides the definitions and decleration of the fast_bucket class used in hash_map + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +// using pair +#include <utility> + +// using operator new +#include <memory> + +#include "chunk.h" + +#define chunk_size 10 + +template <class H, class K, class T> +class fast_bucket { + fast_bucket(const fast_bucket<H, K, T>&); + const fast_bucket<H, K, T>& operator=(const fast_bucket<H, K, T>&); + typedef std::pair<const K, T> pair_t; + typedef chunk<H, K, T, chunk_size> chunk_; + typedef T value_t; + typedef K key_t; +private: +public: + // chunks + chunk_* first; // the first chunk in the single linked list + + // housekeeping for first chunk + // this is located in the fast_bucket class because it is the only + // place it is used and it comes with a price in space + uint end_pos; // is index to the "end iterator" (one past...) + + // find to use when deleting elements, we will move the last + // element in the bucket to the place + // hpp is a place to return a pointer to the small hashvalue + pair_t* find_d(H hh, const K& kk, H** hpp) { + // check the first chunk + pair_t* t; + if (t = first->find_d(hh, kk, hpp, end_pos)) {return t;} + + // check the rest + chunk_* c = first->next; + while (c) { + pair_t* pp; + if ((pp = c->find_d(hh, kk, hpp)) != 0) {return pp;} + c = c->next; + } + return 0; + } + + // move last element to a place according to args + // this is the delete operation, so we need to do it the nice way! + void move_last_element_to(pair_t* pp, H* hp) { + // is the first chunk empty? + if (end_pos == 0) { + // the chunk is empty -- get rid of it + chunk_* trash = first; + first = trash->next; + end_pos = chunk_size; + delete trash; + } + + const uint last_element_pos = --end_pos; + *hp = first->h[last_element_pos]; + //destroy(pp); + pp->~pair_t(); + + // do inplace new + new(pp) pair_t(first->d[last_element_pos]); + //destroy(&(first->d[last_element_pos])); + (&(first->d[last_element_pos]))->~pair_t(); + } + + + // inserting into the first chunk + pair_t* insert_last(H hh, const pair_t& p){ + uint last_element_pos; + // common case first to help pipeline + if (end_pos != chunk_size) { + last_element_pos = end_pos++; + first->set(hh, p, last_element_pos); + } + else { + // no place left, add a chunk + add_chunk(); + last_element_pos = end_pos++; + first->set(hh, p, last_element_pos); + } + return &(first->d[last_element_pos]); + } + + void add_chunk() { + chunk_* second = first; + first = new chunk_; + first->next = second; + end_pos = 0; + } + +public: + fast_bucket() { + first = new chunk_; + end_pos = 0; // end position + } + ~fast_bucket() { + // just destroy data and delete the chunks + chunk_* c = first->next; + while (c) { + chunk_* trash = c; + c = c->next; + trash->free_data(); + delete trash; + } + first->free_data(end_pos); + delete first; + } + + // return size of bucket in valid elements + uint size() { + uint chunks = 0; // n chunks excl. the last + chunk_* c = first->next; + while (c) { + c = c->next; + ++chunks; + } + // the elements in the first chunk is end_pos + return (chunks * chunk_size) + end_pos; + } + pair_t* find(H hh, const K& kk) { + // first chunk + pair_t* pp; + if (pp = first->find_p(hh, kk, end_pos)) {return pp;} + // the rest + chunk_* c = first->next; + while (c) { + pair_t* pp; + if ((pp = c->find_p(hh, kk)) != 0) {return pp;} + c = c->next; + } + return 0; + } + + // insert element in bucket + std::pair<pair_t*, bool> insert(H hh, const pair_t& p) { + // check if the key is here + if (pair_t* pp = find(hh, p.first)) { + // it is -- overwrite + pp->second = p.second; ///!!! is this ok?? + return std::pair<pair_t*, bool>(pp, false); + } + else { + // insert last + return std::pair<pair_t*, bool>(insert_last(hh, p), true); + } + } + + // find or insert element + value_t& find_or_insert(H hh, const key_t& k) { + // check if the key is here + if (pair_t* pp = find(hh, k)) { + return pp->second; + } + pair_t* pp = insert_last(hh, pair_t(k, value_t())); + return pp->second; + } + + + // delete element from bucket + void erase(H hh, const K& k) { + // check if the key is here + H* hp; + pair_t* pp; + if (pp = find_d(hh, k, &hp)) { + // it is -- overwrite with the last element + move_last_element_to(pp, hp); + } + } + + // end_value returns a value& to the last element. + value_t& end_value() { + uint last_element_pos = end_pos - 1; + return first->d[last_element_pos].second; + } + + // end_value returns a pointer to the last pair. + pair_t* end_pair() { + uint last_element_pos = end_pos - 1; + return &(first->d[last_element_pos]); + } +}; diff -ur inkscape-0.38.1-orig/src/floatmaths.h inkscape-0.38.1/src/floatmaths.h --- inkscape-0.38.1-orig/src/floatmaths.h 2004-07-02 01:53:43.021623000 +0100 +++ inkscape-0.38.1/src/floatmaths.h 2004-07-01 14:13:00.159211000 +0100 @@ -0,0 +1,15 @@ +#ifndef FLOATMATHS_H +#define FLOATMATHS_H + +#include <ieeefp.h> +#include <math.h> + +#if defined(__sun) && defined(__SVR4) +#define fabsf fabs +#define ceilf ceil +#define floorf floor +#define isfinite finite +#define fpresetsticky fpsetsticky +#endif + +#endif diff -ur inkscape-0.38.1-orig/src/hash_map.h inkscape-0.38.1/src/hash_map.h --- inkscape-0.38.1-orig/src/hash_map.h 2004-07-02 01:51:58.422066000 +0100 +++ inkscape-0.38.1/src/hash_map.h 2004-07-01 14:04:52.600609000 +0100 @@ -0,0 +1,119 @@ +/*! \file stl_hash_map.h + * \brief This header provides the definitions and declaration of the hash_map. + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +#ifndef __STL_HASH_MAP_H__ +#define __STL_HASH_MAP_H__ + +#include <utility> +#include <vector> +#include "fast_bucket.h" +#include "stl_hash_functions.h" + +namespace cphstl { + +template <class key_t, class value_t, class Hash_t, class Equal> +class hash_map { + + typedef std::pair<const key_t,value_t> pair_t; + typedef std::pair<const key_t,value_t> value_type; + typedef const pair_t* const_iterator; + typedef unsigned long hashvalue_t; + typedef fast_bucket<hashvalue_t,key_t,value_t> fast_bucket_t; +public: + typedef pair_t* iterator; + +#ifndef JTABLE_SIZE +#define JTABLE_SIZE 8192 +#endif + + hash_map(size_t size = JTABLE_SIZE): + jump_table_size_(size), size_(0){ + memset(jump_table,0,sizeof(jump_table)); + } + ~hash_map() { + //destroy(jump_table, jump_table+jump_table_size()); + int len = jump_table_size (); + for (int i=0; i<len; i++) { + if (jump_table[i] != 0) + jump_table[i]->~fast_bucket_t(); + } + } + + iterator end() {return 0;} + + value_t& operator[](const key_t&); + + /* + NOT IMPLEMENTED: + pair_t* insert(const key_t&); + pair<iterator, bool> insert(const value_type& val); + void erase(iterator pos); + const_iterator find(const key_t& key); + */ + + iterator find(const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(jump_table[index]) { + fast_bucket_t* fb = jump_table[index]; + return fb->find(hv, key); + } + return end(); + } + + +// should return size_type?? bjarne 487!!! + void erase(const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(jump_table[index]) { + fast_bucket_t* fb = jump_table[index]; + fb->erase(hv, key); + } + } + + std::pair<iterator, bool> insert(const value_type& val) { + key_t key = val.first; + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(!jump_table[index]) { + fast_bucket_t* fb = new fast_bucket_t(); + jump_table[index] = fb; + fb->insert_last(hv, val); + return std::pair<iterator, bool>(fb->end_pair(), true); + } + fast_bucket_t* fb=jump_table[index]; + return fb->insert(hv, val); + } + + + size_t size() {return size_;} + size_t max_size() {return size_*1000;} +private: + size_t jump_table_size_; + size_t jump_table_size() { return jump_table_size_;} + size_t size_; + fast_bucket_t* jump_table[JTABLE_SIZE]; + Hash_t h; +}; + +template <class key_t, class value_t, class Hash_t, class Equal> +value_t& hash_map<key_t,value_t,Hash_t,Equal>::operator[](const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(!jump_table[index]) { + fast_bucket_t* fb = new fast_bucket_t(); + jump_table[index] = fb; + fb->insert_last(hv,pair_t(key,value_t())); + return fb->end_value(); + } + fast_bucket_t* fb=jump_table[index]; + return fb->find_or_insert(hv, key); +} + +} + +#endif diff -ur inkscape-0.38.1-orig/src/helper/bezier-utils.cpp inkscape-0.38.1/src/helper/bezier-utils.cpp --- inkscape-0.38.1-orig/src/helper/bezier-utils.cpp 2004-04-04 04:58:41.000000000 +0100 +++ inkscape-0.38.1/src/helper/bezier-utils.cpp 2004-07-01 02:21:01.847146000 +0100 @@ -24,9 +24,11 @@ #define SP_HUGE 1e5 #define noBEZIER_DEBUG -#include <math.h> #include <stdlib.h> + #include "bezier-utils.h" +#include "../floatmaths.h" + #include <libnr/nr-point-fns.h> #include <glib.h> diff -ur inkscape-0.38.1-orig/src/helper/canvas-bpath.cpp inkscape-0.38.1/src/helper/canvas-bpath.cpp --- inkscape-0.38.1-orig/src/helper/canvas-bpath.cpp 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/helper/canvas-bpath.cpp 2004-07-01 02:20:36.488376000 +0100 @@ -12,6 +12,8 @@ * */ +#include "../floatmaths.h" + #include <libart_lgpl/art_rect.h> #include <libart_lgpl/art_vpath.h> #include <libart_lgpl/art_bpath.h> diff -ur inkscape-0.38.1-orig/src/helper/sp-ctrlline.cpp inkscape-0.38.1/src/helper/sp-ctrlline.cpp --- inkscape-0.38.1-orig/src/helper/sp-ctrlline.cpp 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/helper/sp-ctrlline.cpp 2004-07-01 02:20:23.830183000 +0100 @@ -17,7 +17,8 @@ * */ -#include <math.h> +#include "../floatmaths.h" + #include "sp-canvas.h" #include "sp-canvas-util.h" #include "sp-ctrlline.h" diff -ur inkscape-0.38.1-orig/src/inkview.cpp inkscape-0.38.1/src/inkview.cpp --- inkscape-0.38.1-orig/src/inkview.cpp 2004-04-01 09:37:47.000000000 +0100 +++ inkscape-0.38.1/src/inkview.cpp 2004-07-01 19:25:54.971029000 +0100 @@ -424,7 +424,7 @@ is_jar(const gchar *filename) { //fixme: mime check or something - char *extension; + const char *extension; if ((extension = strrchr(filename, '.')) != NULL) { if (strcmp(extension, ".jar") == 0 || strcmp(extension, ".sxw") == 0) return true; diff -ur inkscape-0.38.1-orig/src/libnr/nr-point.h inkscape-0.38.1/src/libnr/nr-point.h --- inkscape-0.38.1-orig/src/libnr/nr-point.h 2004-03-01 07:29:05.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-point.h 2004-06-30 23:19:29.483328000 +0100 @@ -7,6 +7,10 @@ #include <libnr/nr-coord.h> #include <libnr/nr-dim2.h> +#ifndef __GNUC__ +#define __attribute__(x) +#endif + struct NRPoint { NR::Coord x, y; }; diff -ur inkscape-0.38.1-orig/src/libnr/nr-rotate.h inkscape-0.38.1/src/libnr/nr-rotate.h --- inkscape-0.38.1-orig/src/libnr/nr-rotate.h 2004-02-26 09:23:57.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-rotate.h 2004-07-01 20:56:22.496040000 +0100 @@ -15,7 +15,7 @@ rotate(); public: - explicit rotate(Coord theta); + explicit rotate(Coord const theta); explicit rotate(Point const &p) : vec(p) {} bool operator==(rotate const &o) const { diff -ur inkscape-0.38.1-orig/src/libnr/nr-svp-uncross.cpp inkscape-0.38.1/src/libnr/nr-svp-uncross.cpp --- inkscape-0.38.1-orig/src/libnr/nr-svp-uncross.cpp 2004-02-09 02:26:08.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-svp-uncross.cpp 2004-06-30 23:25:41.579973000 +0100 @@ -191,7 +191,7 @@ } /* test continuation direction */ NR::Coord order = nr_svl_slice_compare (cs, ns); - if (fabs (order < 0.01)) { + if (order < 0.01) { /* Potentially close, test endpoint */ /* Bitch'o'bitches (Lauris) */ if (cs->vertex->next->y < ns->vertex->next->y) { diff -ur inkscape-0.38.1-orig/src/libnr/nr-svp.cpp inkscape-0.38.1/src/libnr/nr-svp.cpp --- inkscape-0.38.1-orig/src/libnr/nr-svp.cpp 2004-02-26 09:23:57.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-svp.cpp 2004-06-30 23:21:15.844477000 +0100 @@ -15,6 +15,7 @@ #include <assert.h> #include <stdio.h> +#include <ieeefp.h> #include <glib.h> #include "nr-values.h" diff -ur inkscape-0.38.1-orig/src/libnr/nr-types.cpp inkscape-0.38.1/src/libnr/nr-types.cpp --- inkscape-0.38.1-orig/src/libnr/nr-types.cpp 2004-02-20 08:49:50.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-types.cpp 2004-06-30 23:16:52.979743000 +0100 @@ -16,7 +16,7 @@ double len = hypot(_pt[0], _pt[1]); g_return_if_fail(len != 0); g_return_if_fail(!isnan(len)); - static double const inf = 1e400; + static double const inf = pow(10.0, 400.0); if(len != inf) { *this /= len; } else { diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-font.cpp inkscape-0.38.1/src/libnrtype/nr-font.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-font.cpp 2004-02-23 01:49:12.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-font.cpp 2004-07-01 18:48:47.982943000 +0100 @@ -65,7 +65,7 @@ } NRRasterFont * -nr_rasterfont_new (NRFont *font, NR::Matrix transform) +nr_rasterfont_new (NRFont *font, NR::Matrix const transform) { return ((NRTypeFaceClass *) ((NRObject *) font->face)->klass)->rasterfont_new (font, transform); } diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-rasterfont.cpp inkscape-0.38.1/src/libnrtype/nr-rasterfont.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-rasterfont.cpp 2004-03-24 09:36:39.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-rasterfont.cpp 2004-07-01 18:43:09.925595000 +0100 @@ -13,6 +13,8 @@ #include <string.h> +#include "../floatmaths.h" + #include <libnr/nr-macros.h> #include <libnr/nr-point-l.h> #include <libnr/nr-rect.h> @@ -161,7 +163,7 @@ static NRRFGlyphSlot *nr_rasterfont_ensure_glyph_slot (NRRasterFont *rf, unsigned int glyph, unsigned int flags); NRRasterFont * -nr_rasterfont_generic_new (NRFont *font, NR::Matrix transform) +nr_rasterfont_generic_new (NRFont *font, NR::Matrix const transform) { NRRasterFont *rf; diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-type-directory.cpp inkscape-0.38.1/src/libnrtype/nr-type-directory.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-type-directory.cpp 2004-03-15 02:17:28.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-type-directory.cpp 2004-07-01 01:19:59.318131000 +0100 @@ -298,9 +298,7 @@ bool ink_strstr (const char *haystack, const char *pneedle) { -#ifndef WIN32 - return (strcasestr(haystack, pneedle) != NULL); -#else +#if defined(WIN32) || (defined(__sun) && defined(__SVR4)) // windows has no strcasestr implementation, so here is ours... // stolen from nmap char buf[512]; @@ -323,6 +321,8 @@ } else foundto = needle; } return false; +#else + return (strcasestr(haystack, pneedle) != NULL); #endif } diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-type-xft.cpp inkscape-0.38.1/src/libnrtype/nr-type-xft.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-type-xft.cpp 2004-03-02 05:40:35.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-type-xft.cpp 2004-07-01 01:29:06.315821000 +0100 @@ -12,6 +12,7 @@ #include <string.h> #include <stdio.h> +#include <X11/Xlib.h> #include <X11/Xft/Xft.h> #include <glib.h> diff -ur inkscape-0.38.1-orig/src/livarot/AVL.h inkscape-0.38.1/src/livarot/AVL.h --- inkscape-0.38.1-orig/src/livarot/AVL.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AVL.h 2004-06-30 23:27:39.658293000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/AlphaLigne.cpp inkscape-0.38.1/src/livarot/AlphaLigne.cpp --- inkscape-0.38.1-orig/src/livarot/AlphaLigne.cpp 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AlphaLigne.cpp 2004-07-01 02:19:14.112206000 +0100 @@ -9,8 +9,7 @@ #include "AlphaLigne.h" //#include "Buffer.h" - -#include <math.h> +#include "../floatmaths.h" AlphaLigne::AlphaLigne(int iMin,int iMax) { diff -ur inkscape-0.38.1-orig/src/livarot/AlphaLigne.h inkscape-0.38.1/src/livarot/AlphaLigne.h --- inkscape-0.38.1-orig/src/livarot/AlphaLigne.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AlphaLigne.h 2004-07-01 00:40:00.969485000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/BitLigne.cpp inkscape-0.38.1/src/livarot/BitLigne.cpp --- inkscape-0.38.1-orig/src/livarot/BitLigne.cpp 2004-04-01 09:37:50.000000000 +0100 +++ inkscape-0.38.1/src/livarot/BitLigne.cpp 2004-07-01 02:19:28.910299000 +0100 @@ -8,8 +8,7 @@ */ #include "BitLigne.h" - -#include <math.h> +#include "../floatmaths.h" BitLigne::BitLigne(int ist,int ien,float iScale) { diff -ur inkscape-0.38.1-orig/src/livarot/BitLigne.h inkscape-0.38.1/src/livarot/BitLigne.h --- inkscape-0.38.1-orig/src/livarot/BitLigne.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/BitLigne.h 2004-07-01 00:37:30.705467000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> #include "LivarotDefs.h" Only in inkscape-0.38.1/src/livarot: BitLigne.o diff -ur inkscape-0.38.1-orig/src/livarot/DblLinked.h inkscape-0.38.1/src/livarot/DblLinked.h --- inkscape-0.38.1-orig/src/livarot/DblLinked.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/DblLinked.h 2004-06-30 23:27:58.066138000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/Ligne.cpp inkscape-0.38.1/src/livarot/Ligne.cpp --- inkscape-0.38.1-orig/src/livarot/Ligne.cpp 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Ligne.cpp 2004-07-01 02:19:36.479344000 +0100 @@ -10,10 +10,7 @@ #include "Ligne.h" //#include "Buffer.h" #include "BitLigne.h" - -#include <math.h> - - +#include "../floatmaths.h" //int showCopy=0; //#define faster_flatten 1 diff -ur inkscape-0.38.1-orig/src/livarot/Ligne.h inkscape-0.38.1/src/livarot/Ligne.h --- inkscape-0.38.1-orig/src/livarot/Ligne.h 2004-02-29 02:14:00.000000000 +0000 +++ inkscape-0.38.1/src/livarot/Ligne.h 2004-07-01 00:36:52.770590000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> #include "LivarotDefs.h" diff -ur inkscape-0.38.1-orig/src/livarot/LivarotDefs.h inkscape-0.38.1/src/livarot/LivarotDefs.h --- inkscape-0.38.1-orig/src/livarot/LivarotDefs.h 2004-03-06 02:49:27.000000000 +0000 +++ inkscape-0.38.1/src/livarot/LivarotDefs.h 2004-06-30 23:28:15.682110000 +0100 @@ -8,7 +8,7 @@ #ifndef my_defs #define my_defs -#include <stdint.h> +#include <inttypes.h> // error codes (mostly obsolete) enum diff -ur inkscape-0.38.1-orig/src/livarot/MyMath.h inkscape-0.38.1/src/livarot/MyMath.h --- inkscape-0.38.1-orig/src/livarot/MyMath.h 2004-01-15 07:03:32.000000000 +0000 +++ inkscape-0.38.1/src/livarot/MyMath.h 2004-07-01 00:36:27.554185000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/Path.h inkscape-0.38.1/src/livarot/Path.h --- inkscape-0.38.1-orig/src/livarot/Path.h 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Path.h 2004-06-30 23:47:04.328875000 +0100 @@ -389,7 +389,10 @@ } outline_callback_data; - typedef void (outlineCallback) (outline_callback_data * data, double tol, double width); + typedef void (outlineCallback) (outline_callback_data * data, double tol, double width); + + struct outline_callbacks; + friend struct outline_callbacks; typedef struct outline_callbacks { outlineCallback *cubicto; diff -ur inkscape-0.38.1-orig/src/livarot/PathConversion.cpp inkscape-0.38.1/src/livarot/PathConversion.cpp --- inkscape-0.38.1-orig/src/livarot/PathConversion.cpp 2004-03-10 12:16:57.000000000 +0000 +++ inkscape-0.38.1/src/livarot/PathConversion.cpp 2004-07-01 21:51:05.908913000 +0100 @@ -730,7 +730,7 @@ } } -const NR::Point Path::PrevPoint(int i) const +const NR::Point Path::PrevPoint(const int i) const { /* TODO: I suspect this should assert `(unsigned) i < descr_nb'. We can probably change the argument to unsigned. descr_nb should probably be changed to unsigned too. */ @@ -809,7 +809,7 @@ { NR::Point se = iE-iS; NR::Point ca(cos(angle),sin(angle)); - NR::Point cse(dot(se,ca),cross(se,ca)); + NR::Point cse(NR::dot(se,ca),cross(se,ca)); cse[0] /= rx; cse[1] /= ry; double const lensq = dot(cse,cse); diff -ur inkscape-0.38.1-orig/src/livarot/PathOutline.cpp inkscape-0.38.1/src/livarot/PathOutline.cpp --- inkscape-0.38.1-orig/src/livarot/PathOutline.cpp 2004-03-10 01:10:30.000000000 +0000 +++ inkscape-0.38.1/src/livarot/PathOutline.cpp 2004-07-01 02:19:45.761346000 +0100 @@ -8,9 +8,11 @@ #include "Path.h" //#include "MyMath.h" -#include <math.h> +#include "../floatmaths.h" #include <libnr/nr-point-fns.h> +#define MAX(a, b) ((a) > (b) ? (a) : (b)) + /* * the "outliner" * takes a sequence of path commands and produces a set of commands that approximates the offset @@ -955,7 +957,7 @@ double l = csex * csex + csey * csey; if (l >= 4) return; - const double d = sqrt(std::max(1 - l / 4, 0.0)); + const double d = sqrt(MAX(1 - l / 4, 0.0)); double csdx = csey, csdy = -csex; l = sqrt (l); csdx /= l; @@ -1234,7 +1236,7 @@ biss /= lb; const double angCo = dot (biss, enNor); const double l = width / angCo; - miter = std::max(miter, 0.5 * lb); + miter = MAX(miter, 0.5 * lb); if (l > miter) { const double angSi = cross (biss, stNor); const double r = (l - miter) * angCo / angSi; diff -ur inkscape-0.38.1-orig/src/livarot/Shape.h inkscape-0.38.1/src/livarot/Shape.h --- inkscape-0.38.1-orig/src/livarot/Shape.h 2004-04-01 09:37:50.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Shape.h 2004-07-01 22:00:02.834524000 +0100 @@ -12,7 +12,7 @@ #include <math.h> #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> @@ -398,8 +398,8 @@ // the result is NOT a polygon; you need a subsequent call to ConvertToShape to get a real polygon int MakeOffset (Shape * of, double dec, JoinType join, double miter); - bool DistanceLE(NR::Point thePt, double const max_dist); - double Distance(NR::Point thePt); + bool DistanceLE(NR::Point const thePt, double const max_dist); + double Distance(NR::Point const thePt); int PtWinding (const NR::Point px) const ; // plus rapide int Winding (const NR::Point px) const ; diff -ur inkscape-0.38.1-orig/src/livarot/ShapeMisc.cpp inkscape-0.38.1/src/livarot/ShapeMisc.cpp --- inkscape-0.38.1-orig/src/livarot/ShapeMisc.cpp 2004-03-09 09:18:23.000000000 +0000 +++ inkscape-0.38.1/src/livarot/ShapeMisc.cpp 2004-07-01 02:19:55.246551000 +0100 @@ -7,10 +7,11 @@ */ #include "Shape.h" +#include "Path.h" +//#include "MyMath.h" +#include "../floatmaths.h" #include <libnr/nr-point.h> #include <libnr/nr-point-fns.h> -//#include "MyMath.h" -#include "Path.h" #include <glib.h> /* diff -ur inkscape-0.38.1-orig/src/livarot/ShapeUtils.h inkscape-0.38.1/src/livarot/ShapeUtils.h --- inkscape-0.38.1-orig/src/livarot/ShapeUtils.h 2004-02-29 02:14:05.000000000 +0000 +++ inkscape-0.38.1/src/livarot/ShapeUtils.h 2004-06-30 23:47:49.239888000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/main.cpp inkscape-0.38.1/src/main.cpp --- inkscape-0.38.1-orig/src/main.cpp 2004-04-06 06:39:41.000000000 +0100 +++ inkscape-0.38.1/src/main.cpp 2004-07-01 14:13:24.744295000 +0100 @@ -27,6 +27,7 @@ #ifdef HAVE_FPSETMASK #include <ieeefp.h> +#include "floatmaths.h" #endif #include <string.h> #include <locale.h> diff -ur inkscape-0.38.1-orig/src/marker-status.h inkscape-0.38.1/src/marker-status.h --- inkscape-0.38.1-orig/src/marker-status.h 2004-02-26 09:49:05.000000000 +0000 +++ inkscape-0.38.1/src/marker-status.h 2004-07-01 03:12:56.175157000 +0100 @@ -1,6 +1,10 @@ #ifndef SEEN_MARKER_DEBUG_H #define SEEN_MARKER_DEBUG_H +#ifndef __GNUC__ +#define __attribute__(x) +#endif + void marker_status(char const *format, ...) __attribute__((format(__printf__, 1, 2))); #endif /* !SEEN_MARKER_DEBUG_H */ diff -ur inkscape-0.38.1-orig/src/nodepath.cpp inkscape-0.38.1/src/nodepath.cpp --- inkscape-0.38.1-orig/src/nodepath.cpp 2004-04-08 06:00:40.000000000 +0100 +++ inkscape-0.38.1/src/nodepath.cpp 2004-07-01 17:32:09.340350000 +0100 @@ -2361,7 +2361,7 @@ node_scale (n, grow / SP_DESKTOP_ZOOM (n->subpath->nodepath->desktop), which); } -void sp_nodepath_selected_nodes_scale(Path::Path *nodepath, gdouble const grow, int which) +void sp_nodepath_selected_nodes_scale(Path::Path *nodepath, gdouble grow, int which) { if (!nodepath) return; @@ -2375,7 +2375,7 @@ update_repr (nodepath); } -void sp_nodepath_selected_nodes_scale_screen (Path::Path *nodepath, gdouble const grow, int which) +void sp_nodepath_selected_nodes_scale_screen (Path::Path *nodepath, gdouble grow, int which) { if (!nodepath) return; diff -ur inkscape-0.38.1-orig/src/object-edit.cpp inkscape-0.38.1/src/object-edit.cpp --- inkscape-0.38.1-orig/src/object-edit.cpp 2004-03-08 00:19:04.000000000 +0000 +++ inkscape-0.38.1/src/object-edit.cpp 2004-07-01 03:16:42.079755000 +0100 @@ -320,7 +320,7 @@ && ( snaps != 0 ) ) { gdouble arg = 2.0*M_PI*spiral->revo*spiral->t0 + spiral->arg; - spiral->t0 = (round(arg/(M_PI/snaps))*(M_PI/snaps) - spiral->arg)/(2.0*M_PI*spiral->revo); + spiral->t0 = (rint(arg/(M_PI/snaps))*(M_PI/snaps) - spiral->arg)/(2.0*M_PI*spiral->revo); } spiral->t0 = CLAMP (spiral->t0, 0.0, 0.999); @@ -350,7 +350,7 @@ if ( ( state & GDK_CONTROL_MASK ) && snaps ) { - spiral->arg = round (spiral->arg/(M_PI/snaps))*(M_PI/snaps); + spiral->arg = rint (spiral->arg/(M_PI/snaps))*(M_PI/snaps); } sp_object_request_update ((SPObject *) spiral, SP_OBJECT_MODIFIED_FLAG); diff -ur inkscape-0.38.1-orig/src/remove-last.h inkscape-0.38.1/src/remove-last.h --- inkscape-0.38.1-orig/src/remove-last.h 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/remove-last.h 2004-07-01 03:34:45.916484000 +0100 @@ -9,7 +9,7 @@ { using std::vector; - typename vector<T>::reverse_iterator i(find(seq.rbegin(), seq.rend(), elem)); + typename vector<T>::reverse_iterator i(std::find(seq.rbegin(), seq.rend(), elem)); g_assert( i != seq.rend() ); typename vector<T>::iterator ii(&*i); seq.erase(ii); diff -ur inkscape-0.38.1-orig/src/sp-guide.cpp inkscape-0.38.1/src/sp-guide.cpp --- inkscape-0.38.1-orig/src/sp-guide.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/sp-guide.cpp 2004-07-01 16:50:39.372934000 +0100 @@ -264,7 +264,7 @@ * true indicates a "committing" version: in response to button release event after * dragging a guideline, or clicking OK in guide editing dialog. */ -void sp_guide_moveto(SPGuide const &guide, gdouble const position, bool const commit) +void sp_guide_moveto(SPGuide const &guide, double const position, bool const commit) { g_assert(SP_IS_GUIDE(&guide)); diff -ur inkscape-0.38.1-orig/src/sp-item-notify-moveto.cpp inkscape-0.38.1/src/sp-item-notify-moveto.cpp --- inkscape-0.38.1-orig/src/sp-item-notify-moveto.cpp 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-notify-moveto.cpp 2004-07-01 03:37:43.324260000 +0100 @@ -20,7 +20,7 @@ g_return_if_fail(SP_IS_ITEM(&item)); g_return_if_fail( unsigned(snappoint_ix) < 8 ); NR::Point const dir( mv_g.normal ); - double const dir_lensq(dot(dir, dir)); + double const dir_lensq(NR::dot(dir, dir)); g_return_if_fail( dir_lensq != 0 ); NR::Point snappoints[8]; diff -ur inkscape-0.38.1-orig/src/sp-item-notify-moveto.h inkscape-0.38.1/src/sp-item-notify-moveto.h --- inkscape-0.38.1-orig/src/sp-item-notify-moveto.h 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-notify-moveto.h 2004-07-01 16:50:18.068479000 +0100 @@ -4,7 +4,7 @@ #include <forward.h> void sp_item_notify_moveto(SPItem &item, SPGuide const &g, int const snappoint_ix, - double position, bool const commit); + double const position, bool const commit); #endif /* !__SP_ITEM_NOTIFY_MOVETO_H__ */ diff -ur inkscape-0.38.1-orig/src/sp-item-update-cns.cpp inkscape-0.38.1/src/sp-item-update-cns.cpp --- inkscape-0.38.1-orig/src/sp-item-update-cns.cpp 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-update-cns.cpp 2004-07-01 03:38:14.732900000 +0100 @@ -27,7 +27,7 @@ fi != fiEnd; ++fi) { SPGuideConstraint const &cn = *fi; - if ( find(item.constraints.begin(), + if ( std::find(item.constraints.begin(), item.constraints.end(), cn) == item.constraints.end() ) diff -ur inkscape-0.38.1-orig/src/sp-object.cpp inkscape-0.38.1/src/sp-object.cpp --- inkscape-0.38.1-orig/src/sp-object.cpp 2004-03-15 04:02:46.000000000 +0000 +++ inkscape-0.38.1/src/sp-object.cpp 2004-07-01 03:43:19.909472000 +0100 @@ -993,7 +993,7 @@ style = sp_repr_attr (object->repr, "style"); if (style) { - gchar *p; + const gchar *p; gint len; len = strlen (key); for (p = strstr (style, key); p; p = strstr (style, key)) { diff -ur inkscape-0.38.1-orig/src/sp-shape.cpp inkscape-0.38.1/src/sp-shape.cpp --- inkscape-0.38.1-orig/src/sp-shape.cpp 2004-04-08 06:00:43.000000000 +0100 +++ inkscape-0.38.1/src/sp-shape.cpp 2004-07-01 03:46:17.796590000 +0100 @@ -36,6 +36,7 @@ #include "sp-root.h" #include "sp-marker.h" #include "sp-shape.h" +#include "floatmaths.h" #define noSHAPE_VERBOSE diff -ur inkscape-0.38.1-orig/src/sp-spiral.cpp inkscape-0.38.1/src/sp-spiral.cpp --- inkscape-0.38.1-orig/src/sp-spiral.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/sp-spiral.cpp 2004-07-01 03:51:25.843598000 +0100 @@ -444,7 +444,7 @@ g_assert (t >= 0.0); /* Any callers passing -ve t will have a bug for non-integral values of exp. */ - double const rad = spiral->rad * pow(t, spiral->exp); + double const rad = spiral->rad * pow(t, (double)spiral->exp); double const arg = 2.0 * M_PI * spiral->revo * t + spiral->arg; return NR::Point(rad * cos (arg) + spiral->cx, @@ -522,7 +522,7 @@ g_return_if_fail (SP_IS_SPIRAL(spiral)); if (rad) - *rad = spiral->rad * pow(t, spiral->exp); + *rad = spiral->rad * pow(t, (double)spiral->exp); if (arg) *arg = 2.0 * M_PI * spiral->revo * t + spiral->arg; } diff -ur inkscape-0.38.1-orig/src/spiral-context.cpp inkscape-0.38.1/src/spiral-context.cpp --- inkscape-0.38.1-orig/src/spiral-context.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/spiral-context.cpp 2004-07-01 03:35:10.237506000 +0100 @@ -437,7 +437,7 @@ gdouble arg = NR::atan2 (delta) - 2.0*M_PI*spiral->revo; if (state & GDK_CONTROL_MASK) { - arg = round (arg/(M_PI/snaps))*(M_PI/snaps); + arg = rint (arg/(M_PI/snaps))*(M_PI/snaps); } /* Fixme: these parameters should be got from dialog box */ diff -ur inkscape-0.38.1-orig/src/splivarot.cpp inkscape-0.38.1/src/splivarot.cpp --- inkscape-0.38.1-orig/src/splivarot.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/splivarot.cpp 2004-07-01 03:41:48.518466000 +0100 @@ -186,8 +186,8 @@ // extract the livarot Paths from the source objects // also get the winding rule specified in the style int nbOriginaux = g_slist_length (il); - Path *originaux[nbOriginaux]; - FillRule origWind[nbOriginaux]; + Path **originaux = (Path **)alloca(nbOriginaux * sizeof(Path *)); + FillRule *origWind = (FillRule *)alloca(nbOriginaux * sizeof(FillRule)); int curOrig; { curOrig = 0; diff -ur inkscape-0.38.1-orig/src/star-context.cpp inkscape-0.38.1/src/star-context.cpp --- inkscape-0.38.1-orig/src/star-context.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/star-context.cpp 2004-07-01 03:53:01.003400000 +0100 @@ -435,7 +435,7 @@ gdouble r1 = NR::L2 (d); gdouble arg1 = atan2 (d); if (state & GDK_CONTROL_MASK) { - arg1 = round (arg1/(M_PI/snaps))*(M_PI/snaps); + arg1 = rint (arg1/(M_PI/snaps))*(M_PI/snaps); } bool isflat = sc->isflatsided; sp_star_position_set (star, sc->magnitude, p0, r1, r1 * sc->proportion, arg1, arg1 + M_PI / sides, isflat); diff -ur inkscape-0.38.1-orig/src/stl_hash_functions.h inkscape-0.38.1/src/stl_hash_functions.h --- inkscape-0.38.1-orig/src/stl_hash_functions.h 2004-07-02 01:53:30.333724000 +0100 +++ inkscape-0.38.1/src/stl_hash_functions.h 2004-07-01 04:19:40.215269000 +0100 @@ -0,0 +1,123 @@ +/*! \file stl_hash_functions.h + * \brief This header provides the definitions and declaration of hash functions used in hash_map. + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + + +#ifndef __STL_HASH_FUNCTIONS_H__ +#define __STL_HASH_FUNCTIONS_H__ + +#include <string> + +typedef unsigned int uint; +typedef unsigned char byte; + +class hash_jyrki { +public: + hash_jyrki(uint s = 0) { + srand(s); + for (int i = 0; i < 1024; ++i) { + T[i] = (uint)rand(); + } + } + uint operator() (char const* s) { + uint t = 0; + byte* p = (byte*)s; + uint i = 0; + for (; *p != 0; ++i) { + t ^= T[((0x3 & i) << 8) + *p++]; + } + t ^= T[i]; + return t; + } + +private: + uint T[1024]; +}; + +template <class t> +struct hash_stl { + long operator() (const t& s); +}; + +template<> +struct hash_stl<const char*> { + long operator() (const char * s) { + uint t = 0; + while (*s != 0) { + t = 5 * t + *s++; + } + return t; + } +}; + +template<> +struct hash_stl<std::string> { + long operator() (const std::string& ss) { + const char* s=ss.c_str(); + uint t = 0; + while (*s != 0) { + t = 5 * t + *s++; + } + return t; + }; +}; + + + +class hash_crypto { +#define mix(a, b, c) { \ +a -= b; a -= c; a ^= (c >>13); \ +b -= c; b -= a; b ^= (a <<8); \ +c -= a; c -= b; c ^= (b >>13); \ +a -= b; a -= c; a ^= (c >>12); \ +b -= c; b -= a; b ^= (a <<16); \ +c -= a; c -= b; c ^= (b >>5); \ +a -= b; a -= c; a ^= (c >>3); \ +b -= c; b -= a; b ^= (a <<10); \ +c -= a; c -= b; c ^= (b >>15); \ +} + +public: + uint operator() (char const* k); +}; + +uint hash_crypto::operator() (char const* k) { + uint length = 0; + while (*k++) {++length;} + uint len = length; + uint a = 0x9e3779b9; + uint b = 0x9e3779b9; + uint c = 0x8f256195; + + while (len >= 12) { + a += (k[0] + (uint(k[1])<<8) + (uint(k[2])<<16) + (uint(k[3])<<24)); + b += (k[4] + (uint(k[5])<<8) + (uint(k[6])<<16) + (uint(k[7])<<24)); + c += (k[8] + (uint(k[9])<<8) + (uint(k[10])<<16) + (uint(k[11])<<24)); + mix(a, b, c); + k += 12; len -= 12; + } + + c += length; + switch (len) { + case 11: c+=(uint(k[10])<<24); + case 10: c+=(uint(k[9])<<16); + case 9 : c+=(uint(k[8])<<8); + + case 8: b+=(uint(k[7])<<24); + case 7: b+=(uint(k[6])<<16); + case 6: b+=(uint(k[5])<<8); + case 5: b+=k[4]; + + case 4: a+=(uint(k[3])<<24); + case 3: a+=(uint(k[2])<<16); + case 2: a+=(uint(k[1])<<8); + + case 1: a+=k[0]; + } + mix(a, b, c); + return c; +} + +#endif diff -ur inkscape-0.38.1-orig/src/streams-jar.cpp inkscape-0.38.1/src/streams-jar.cpp --- inkscape-0.38.1-orig/src/streams-jar.cpp 2004-03-17 17:28:20.000000000 +0000 +++ inkscape-0.38.1/src/streams-jar.cpp 2004-07-01 03:55:56.402454000 +0100 @@ -30,7 +30,7 @@ #endif //guint32 crc = check_crc(data, flags); - gchar filename[filename_length+1]; + gchar *filename = (gchar *)alloca(filename_length+1); _urihandle->read(filename, filename_length); filename[filename_length] = '\0'; @@ -92,7 +92,7 @@ int ret; if ((ret = do_consume_and_inflate(nbytes)) == EOF && eflen > 0) { - guint8 efbuf[eflen]; + guint8 *efbuf = (guint8 *)alloca(eflen); _urihandle->read(efbuf, eflen); return 1; } @@ -102,7 +102,7 @@ int JarBuffer::consume_uncompressed(int nbytes) { - guint8 data[nbytes]; + guint8 *data = (guint8 *)alloca(nbytes); if (consume(data, nbytes) == EOF) return EOF; diff -ur inkscape-0.38.1-orig/src/streams-zlib.cpp inkscape-0.38.1/src/streams-zlib.cpp --- inkscape-0.38.1-orig/src/streams-zlib.cpp 2004-03-17 17:28:20.000000000 +0000 +++ inkscape-0.38.1/src/streams-zlib.cpp 2004-07-01 03:53:58.994511000 +0100 @@ -105,7 +105,7 @@ int ZlibBuffer::do_consume_and_inflate(int nbytes) { - guint8 buf[nbytes]; + guint8 *buf = (guint8 *)alloca(nbytes); if (consume(buf, nbytes) == EOF) return EOF; diff -ur inkscape-0.38.1-orig/src/svg/ftos.cpp inkscape-0.38.1/src/svg/ftos.cpp --- inkscape-0.38.1-orig/src/svg/ftos.cpp 2004-04-09 07:16:17.000000000 +0100 +++ inkscape-0.38.1/src/svg/ftos.cpp 2004-07-01 01:40:57.875356000 +0100 @@ -275,10 +275,12 @@ int decimal=0; #ifdef HAS_ECVT - char *p = ecvt(val, count, &decimal, &sign); + char *p = ecvt(val, count, &decimal, &sign); #else - char *p; - asprintf(&p, "%.0f", val); + char *p, tmp[256]; + snprintf(tmp, 256, "%.0f", val); + p = (char *)malloc(strlen(tmp) + 1); + strcpy(p, tmp); #endif #ifdef DEBUG diff -ur inkscape-0.38.1-orig/src/svg/round.cpp inkscape-0.38.1/src/svg/round.cpp --- inkscape-0.38.1-orig/src/svg/round.cpp 2004-04-08 04:36:35.000000000 +0100 +++ inkscape-0.38.1/src/svg/round.cpp 2004-07-01 01:33:20.035147000 +0100 @@ -42,6 +42,6 @@ double rround(double x, int k) { if (k==0) return rround(x); - else return rround(x*pow(10,k)) / pow(10,k); + else return rround(x*pow(10.0, k)) / pow(10.0, k); } diff -ur inkscape-0.38.1-orig/src/svg/svg-path.cpp inkscape-0.38.1/src/svg/svg-path.cpp --- inkscape-0.38.1-orig/src/svg/svg-path.cpp 2004-03-18 19:48:25.000000000 +0000 +++ inkscape-0.38.1/src/svg/svg-path.cpp 2004-07-01 01:32:39.876558000 +0100 @@ -520,7 +520,7 @@ { /* end of number */ - val *= sign * pow (10, exp_sign * exp); + val *= sign * pow (10.0, exp_sign * exp); if (ctx->rel) { /* Handle relative coordinates. This switch statement attempts diff -ur inkscape-0.38.1-orig/src/verbs.cpp inkscape-0.38.1/src/verbs.cpp --- inkscape-0.38.1-orig/src/verbs.cpp 2004-04-07 07:14:55.000000000 +0100 +++ inkscape-0.38.1/src/verbs.cpp 2004-07-01 20:02:43.504293000 +0100 @@ -70,19 +70,33 @@ /* FIXME !!! we should probably go ahead and use GHashTables, actually -- more portable */ +#include <functional> + #if defined(__GNUG__) && (__GNUG__ >= 3) # include <ext/hash_map> using __gnu_cxx::hash_map; #else -# include <hash_map.h> +# include "hash_map.h" +using cphstl::hash_map; #endif #if defined(__GNUG__) && (__GNUG__ >= 3) namespace __gnu_cxx { #endif +template <typename T> class my_hash; + +template <> +class my_hash<sp_verb_t> { + typedef sp_verb_t T; +public: + size_t operator()(const T& x) { + return (size_t)g_int_hash((gpointer)&x); + } +}; + template <> -class hash<SPView *> { +class my_hash<SPView *> { typedef SPView *T; public: size_t operator()(const T& x) const { @@ -94,9 +108,9 @@ }; /* namespace __gnu_cxx */ #endif -typedef hash_map<sp_verb_t, SPAction *> ActionTable; -typedef hash_map<SPView *, ActionTable *> VerbTable; -typedef hash_map<sp_verb_t, SPVerbActionFactory *> FactoryTable; +typedef hash_map<sp_verb_t, SPAction *, my_hash<sp_verb_t>, std::equal_to<sp_verb_t> > ActionTable; +typedef hash_map<SPView *, ActionTable *, my_hash<SPView *>, std::equal_to<SPView *> > VerbTable; +typedef hash_map<sp_verb_t, SPVerbActionFactory *, my_hash<sp_verb_t>, std::equal_to<sp_verb_t> > FactoryTable; static VerbTable verb_tables; static FactoryTable factories;

6 6

compile notes
by bulia byak 16 Dec '04

16 Dec '04

Some random notes on compilation: - To compile the latest CVS I had to install libpython-devel and libxslt-devel (on Mandrake 9.2) - The stripped executable size went from approx 3Mb to 4Mb (!) - The warnings I saw: *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against the *** static library /usr/lib/perl5/5.8.1/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a is not portable! *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against the *** static library /usr/lib/python2.3/config/libpython2.3.a is not portable! and /usr/lib/python2.3/config/libpython2.3.a(posixmodule.o)(.text+0x43de): In function `posix_tmpnam': Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp' /usr/lib/python2.3/config/libpython2.3.a(posixmodule.o)(.text+0x4306): In function `posix_tempnam': Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp'

1 0

Re: gtkmm style clean-up, take 2
by Bryce Harrington 16 Dec '04

16 Dec '04

Cool. There was no patch attached, but go ahead and commit directly to the codebase. Your last patch looked fine and from what you describe this one sounds good too. Talk to you tomorrow! Bryce On Thu, 16 Dec 2004, Derek P. Moore wrote: > Hey, > > I did a second-over on the files in the gtkmm codebase, to double check my work > and fix all the switch statements. > > While going through the second time, I also found a few things I missed the > first time. > > The only changes I made where: > > *, &, and type modifiers in their proper place > > made the WIDGET header #defines like the DIALOG header defines > > cleaned-up spacing in places where it made sense > >

1 0

Re: Inkscape .40
by Jon Phillips 16 Dec '04

16 Dec '04

On Fri, 2004-12-10 at 02:56 -0800, Jiaxiang wrote: > Good day, Jon. > > You guys are doing great work on Inkscape. I keep > dipping my toes into it and I'm thinking of taking the > plunge, that is, doing all my SVG-based graphics in > Inkscape and putting all of my little Sodipodi > "evangelism" (video tutorials, word-of-mouth > advertising, donations) to work for Inkscape. We would like this very much. I think that your contributions to Inkscape would be much more widely seen than generating this type of content for sodipodi. > Just curious: What has been the typical opinion of > Inkscape's interface? > > Do most users like it or dislike it? Yes, most people love the new interface. There is only a hand full that don't. > Would you and the other Inkscape developers ever > release a version with a tool box similar to > Sodipodi's to see what the reaction might be? (I > remember reading that the Inkscape interface wasn't > permanent.) > > If the tools collected in one place, with both > collapsible segments and detachable segements (with > special features accessible through the main menus > along the top just like it is now), Inkscape would be > just a delight to use. Well, in the current state you can detach in a similar manner to SODI. We have talked about developing a detachable toolbar approach similar to the gimp in the future using GTKMM. Using this, what you seek might be within closer reach. Jon > > __________________________________ > Do you Yahoo!? > Send holiday email and support a worthy cause. Do good. > http://celebrity.mail.yahoo.com > -- Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

2 1

src/extension/script Makefiles
by Bob Jamison 16 Dec '04

16 Dec '04

Hi, all. Finally got my work email fixed again. Ok.. I finally hooked up the Makefile_insert and makefile.in in src/extension/script to the rest of the automake tree. So Inkscape is now compiling and linking with Perl and Python. Please try updating and building, when it is convenient. We will likely need to tweak it to make sure that the build works on everyone's machine. Now we need to make a dialog to load and execute scripts in either Perl or Python. Would there maybe be a user who is interested in GUIs, who would like to draw a mockup of what such a dialog might look like? (that's a lot of subjunctives in one sentence ;-) Bob

5 8

Winlibre and Upping our point release numbers
by jon 15 Dec '04

15 Dec '04

Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users? http://www.winlibre.com/en/Versions.php Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now) I am making the official push that our 1.0 of Inkscape is full 1.2 SVG compliance. By this, I mean we can accept and render a SVG 1.2 file. I think that developing the editing around this is important, but it is more important that we handle SVG 1.2. Maybe though someone can argue for Inkscape 1.0 being able to both render and edit an SVG 1.2 file. However, our system works currently, so why change it, right? I do think though that we need to get a supa-advanced version of Inkscape out the gate as Microsoft is going to drop their WVG (their SVG makeover) soon, and then we know what that means... I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?

12 30

inkscape static build
by herve couvelard 15 Dec '04

15 Dec '04

Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2. we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !) So what we can do is 1) to go back to previous state (gtk2-2.2). but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?) thanks

6 11

[patch] compile errors in nodepath.cpp
by Derek P. Moore 15 Dec '04

15 Dec '04

Howdy, I grabbed Inkscape 0.40 last night. I've been enjoyin' Inkscape for a little bit now, tryin' to hack a few things into the code (selectable ruler metrics, etc.). I figured it was time to port what modifications I'd been working on to the 0.40 tree. I'm using GCC (g++/libstdc++) 3.4.3 and Fedora Rawhide (post Core 3). In nodepath.cpp, I was getting the following compile errors: nodepath.cpp: In function `void node_ctrl_grabbed(SPKnot*, guint, void*)': nodepath.cpp:2220: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) nodepath.cpp:2222: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) make[2]: *** [nodepath.o] Error 1 In examining the code, the problem was with a few anonymous objects when calculating the origin of the grabbed control. The offensive code is: // remember the origin of the control if (n->p.knot == knot) { n->p.origin = Radial(n->p.pos - n->pos); } else if (n->n.knot == knot) { n->n.origin = Radial(n->n.pos - n->pos); } else { g_assert_not_reached(); } n->p.origin is of type Radial; and n->p.pos, n->n.pos, and n->pos are of type NR::Point. The creation of the anonymous Radial object with the subtraction of Points as the constructor argument seems to be working... The problem seems to be with the assignment of the resulting anonymous Radial object to n->{p,n}.origin. Translating the current code to pseudo-constructor-syntax (which is more along the lines of what the compiler actually compiles) results in: Radial origin(Radial(Point pos1 - Point pos2)) But since the Radial class has Radial::Radial(NR::Point const &), the following should suffice: Radial origin(Point pos1 - Point pos2) ... thus dropping the superfluous anonymous Radial. There are two solutions: A) create a pass-by-value Radial constructor, so we can properly pass the anonymous Radial, or B) drop the superfluous anonymous Radial in favor of the assignment being translated into the Radial::Radial(NR::Point const &) constructor. Attached is a patch that drops the anonymous Radial object in favor of C++ assignment/constructor magic. Now Inkscape 0.40 compiles and functions without complaint on my system.

2 1

Shortcut key translation
by Lucas Vieites 14 Dec '04

14 Dec '04

Hi, I was contacted the other day by J. Ramón Palacios, who translated the basic tutorial to spanish (I'll sent it in as soon as I do a quick revision). He asked me a question I had no answer for: in the inkscape menus the names of theshortcut keys are not translated. On the attached screenshot you'll see the spanish 'Object' menu (red underlining is mine). The shortcut keys are named 'PgUp', 'PgDn', etc. when they should be named 'Repág', 'Avpág', etc. Are these strings supposed to be in the .po file? If not, where are they supposed to be translated? Thanks for your time, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 2

Re: [Inkscape-devel] Shortcut key translation
by Kees Cook 14 Dec '04

14 Dec '04

On Tue, Dec 14, 2004 at 04:49:04PM +0100, Lucas Vieites wrote: > > This seems to be common to all Gtk applications, but I can't believe > > it's intended. If I run other tools (like gnumeric), I get the same > > results. > > > That's strange, because I don't. Before posting the origianl message I > checked Gnumeric and Evolution, and both show the correct key names, > that's why I asked. > Any other comments, anyone? Hm. Then I wonder if it's the locale of the Gnome instance itself? I use the "C" locale for my system by default, so when I start X, everything is in English. If I force inkscape (or gnumeric, etc) into another locale ("LC_ALL=fr_FR inkscape"), I get the localized menu names, but not shortcuts. Weird. I wonder if inkscape is missing some kind of localization initialization call? I know there is the main one at the start. Don't know. I guess file a bug so we can track this. -- Kees Cook @outflux.net

2 1

API for extensions?
by Ben Crowell 14 Dec '04

14 Dec '04

Bulia tells me there will soon be an extensions menu. I'm interested in writing some extensions in Perl. My motivation is to scratch my own itch, but some of the stuff I write might be of interest to other users as well. So far I've just been writing Perl scripts to manipulate SVG files, and running them from the command line. Is there an API for extensions yet? The simplest thing would probably be to do it through a shell, and provide a way to hook the command-line options and arguments up to a dialog box in the GUI. There would need to be provisions for internationalization, and for error reporting (including errors resulting from not having the right Perl modules installed). However, since Inkscape runs on Windows, running it in a shell might not work. Is the Extensions menu envisioned as a Unix-only feature? It seems like it would be quite complicated to implement such a thing on a cross-platform basis. It's easy to write the scripts to be platform-independent, but, e.g., most Windows users aren't going to have Active State Perl installed, and even if you embedded a Perl interpreter in Inkscape, that would only work for Perl, and there would still be the issue of libraries. Even if you told Windows users they were required to install Perl and a certain set of libraries, it would also be complex to try to write the glue between Inkscape and Perl in a platform-independent way. And my experience from writing a cross-platform Perl app is that it's a lot of work in terms of testing and code maintenance, much more than writing a Unix-only app.

3 2

[pjc@...609...: Re: [Inkscape-devel] OpenCD]
by Kees Cook 14 Dec '04

14 Dec '04

----- Forwarded message from Pierre-Jean Coudert <pjc@...609...> ----- Hello, I am Pierre-Jean Coudert from the WinLibre project ( http://www.winlibre.com/en/ ). WinLibre is a free software distribution for Windows aimed at popularizing free/open source software. We are including Inkscape since the WinLibre 0.2 release. (actually Inkscape 0.39 ) I want first to thank you for your great and impressive work. We have actually a problem with the 0.40 version. When we install it over the 0.39, it's impossible to open a file with the menu or the icon command (Inkscape crashes). Any idea for correcting this ? We would like to include the 0.40 version in the next WinLibre release. TIA Best regards, Pierre-Jean Coudert, WinLibre. ----- End forwarded message ----- -- Kees Cook @outflux.net

1 0

script for embedding raster images
by Ben Crowell 13 Dec '04

13 Dec '04

>> and I'm going to need to write >> various scripts anyway for my own use (e.g., I'm going to need >> something to gamma-correct svg files). Is there an API for >> extensions? >Hmmm... >Sounds perhaps like you might need to do more than just base gamma-correction. >There are many issues on color in general that need to be addressed. What >exactly are your needs for gamma-correction, and have you skimmed any of the >wiki pages on color? Ah, thanks for pointing me to the wiki -- lots of cool information there! I have a set of textbooks that was originally done on a Mac in PageMaker and Illustrator, and which I'm now in the process of converting to LaTeX and Inkscape on Linux. I'm actually producing the printed books in black and white, so CMYK issues aren't important to me. But as I move the books from Mac to Linux, I've been switching to the appropriate PC gamma correction. This makes them look right to me on the screen, and to users on Windows. (I give the PDFs away for free on my web site, and also sell them in print. Having them look good to professors who might adopt them is important.) Up until now, I'd just been gamma-correcting the EPS output from Illustrator using a kludgy Perl script. Now that I'm actually getting set up to *edit* the files on Linux using Inkscape, I'm planning to write software to gamma-correct the svg source files themselves.

1 0

Re: [Inkscape-user] Re: script for embedding raster images
by bulia byak 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote: > Up spake Ben Crowell: > > I don't know if AI's output is standards-compliant in this situation > > or not. If omitting the type is legal according to the SVG standard, > > then maybe Inkscape should allow it on input. > > Inkscape should probably allow it regardless, since being compatible > with AI is nearly as important as being compatible with the spec. > We don't have the clout to force AI to fix its mistakes, yet :-) I have to agree with that, though upon reading the RFC it's clear that the missing mimetype is interpreted as text/plain by default. So I think Inkscape is correct in its ignoring such images because technically, they're not images but texts. I'm not sure how to "fix" this because we probably use some library call to retrieve images from URIs.

1 0

script for embedding raster images
by Ben Crowell 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote: > Up spake Ben Crowell: > > I don't know if AI's output is standards-compliant in this situation > > or not. If omitting the type is legal according to the SVG standard, > > then maybe Inkscape should allow it on input. > > Inkscape should probably allow it regardless, since being compatible > with AI is nearly as important as being compatible with the spec. > We don't have the clout to force AI to fix its mistakes, yet :-) Yep. If Inkscape allows the user to read noncompliant AI SVG output, and change it into standards-compliant Inkscape SVG, then that's a win for standards. If Inkscape won't let the user do that, then the user has no way of switching to a standards-compliant format. It's not like the situation with browsers, where bug-for-bug compatibility arguably just encourages web sites to use nonstandard HTML. Visiting a broken site with my standards-compliant browser doesn't fix the broken site :-) >I have to agree with that, though upon reading the RFC it's clear that >the missing mimetype is interpreted as text/plain by default. So I >think Inkscape is correct in its ignoring such images because >technically, they're not images but texts. I'm not sure how to "fix" >this because we probably use some library call to retrieve images from >URIs. Should just be a question of reading the first four bytes of the file to find out the magic number, and then closing it and calling the appropriate library for that type of file. Does anyone know where in the source code I should look? This is something I'm motivated to try to fix, since I have 660 AI SVG files I'm trying to get working with Inkscape, and many of them have this problem.

1 0

Re: [Inkscape-user] Re: script for embedding raster images
by bulia byak 13 Dec '04

13 Dec '04

> I've fixed the script to write it the way Inkscape wants it: > http://www.lightandmatter.com/embed_raster_in_svg Excellent, thanks! I tested it and it works when I run it on a file in the current dir, but when I tried to give it a file in a subdir tt/, I got this error: $ ./embed_raster_in_svg.pl tt/a.svg embedded raster file New_document_1-path1061-4294967076.png, image/png error renaming file tt/a.svg to tt/a.svg.bak, No such file or directory at ./embed_raster_in_svg.pl line 114. > I don't know if AI's output is standards-compliant in this situation > or not. Consult http://www.faqs.org/rfcs/rfc2397.html to find out who is compliant and who's not > >P.S. If you plan to keep contributing to Inkscape I can give you > >developer access > That would be nice, thanks! Given my weak C++ skills and lack of > familiarity with Inkscape's codebase, I probably wouldn't dare > to committ changes to the C++ code on my own, except maybe after > getting comments on them. But if the plan is to have an Extensions > menu that can call various Perl scripts, then it might be nice for > me to be able to contribute directly to that. My Perl skills are > a lot better than my C++ skills, and I'm going to need to write > various scripts anyway for my own use (e.g., I'm going to need > something to gamma-correct svg files). Good, I added bcrowell to the project > Is there an API for > extensions? I know we're moving towards it, Ted Gould will probably be able to give you more specific info. If you can help him to work on the extensions system for the next version, this would be fantastic. Also we have the ill2svg perl script that is used for importing illustrator files. I believe there were some issues with it that needed fixing (look up the bug tracker and list archives). In any case, since you're working with AI files and know Perl, you seem to be the ideal person to systematically test this script and write at least some documentation for it (what AI versions and what features are supported and what not, how to best prepare your files for import, etc). It might also make sense to incorporate the embed/outbed images functionality into it as an option.

1 0

Problems with EPS export and printing of markers
by Per Bjornsson 13 Dec '04

13 Dec '04

Hi, I'm seeing some problems with markers in Inkscape 0.40 and current CVS: They simply don't print or get exported in exported EPS files. (They are also all black instead of the line color, but that's known to be an unimplemented feature: http://sourceforge.net/tracker/index.php?func=detail&aid=995815&group_id=93… .) I couldn't find anything about them not getting printed or exported though so I figured that I'd check if it's just my build. Also, when building Inkscape with gnome-print support ('./configure --with-gnome-print') I don't get any print dialog at all, the print job is just dumped immediately on the default printer. Is this supposed to happen or should I actually be getting the regular gnome- print dialog? I noticed that the statically linked RPMs on the SF download site are built without gnome-print support, is that because gnome-print support is actually broken? My platform is Fedora Core 3, with GNOME 2.8 (for libgnomeprint), GTK 2.4 and my compiler is GCC 3.4. If this is specific to my setup I'll be ahppy to try to dig into what's going on; if it's universal maybe I can try to hack a solution, although although C++ might not be my most fuelnt language so I can't make any promises as to how far I'll get... Cheers, Per

1 0

compile problem, ar: libnr/have_mmx.o: No such file or directory
by Ben Crowell 12 Dec '04

12 Dec '04

I'm trying to compile the latest CVS version on my Debian box, and am getting the error message shown at the end of this mail. I have previously compiled 0.40 on this machine successfully. Can anyone suggest how to fix this problem? This is on Debian-testing, pretty standard setup except that I had to install automake 1.9 from source, since Debian only has 1.4 in unstable. TIA! ============== tail end of compiler output ============== gcc -g -O2 -c libnr/have_mmx.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.S rm -f libnr/libnr.a ar cru libnr/libnr.a libnr/nr-blit.o libnr/nr-compose-transform.o libnr/nr-compose.o libnr/nr-gradient.o libnr/nr-matrix-div.o libnr/nr-matrix-fns.o libnr/nr-matrix-rotate-ops.o libnr/nr-matrix-scale-ops.o libnr/nr-matrix-translate-ops.o libnr/nr-matrix.o libnr/nr-object.o libnr/nr-path.o libnr/nr-pixblock-line.o libnr/nr-pixblock-pattern.o libnr/nr-pixblock-pixel.o libnr/nr-pixblock.o libnr/nr-point-fns.o libnr/nr-rect-l.o libnr/nr-rect.o libnr/nr-rotate-fns.o libnr/nr-rotate-matrix-ops.o libnr/nr-scale-matrix-ops.o libnr/nr-scale-translate-ops.o libnr/nr-svp-render.o libnr/nr-svp.o libnr/nr-translate-matrix-ops.o libnr/nr-translate-scale-ops.o libnr/nr-translate-rotate-ops.o libnr/nr-types.o libnr/nr-values.o libnr/have_mmx.o libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.o libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.o ar: libnr/have_mmx.o: No such file or directory make[2]: *** [libnr/libnr.a] Error 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2

2 1

Mention in this months Linux Format
by John Cliff 12 Dec '04

12 Dec '04

Hi guys, First up, sorry about the empty mail, stupid ie on my parents computer :) Just thought I'd let you all know that we're mentioned very briefly in the news section of the xmas edition of linux format, just a they've released a new version with improved text features etc blurb, with the GO! screenshot above it. Didnt buy the mag as i dont use linux and didnt want to spend $10 on a magazine for 1 paragraph. Cheers John __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

2 1

Mention in this months Linux Format
by John Cliff 11 Dec '04

11 Dec '04

Hi guys, __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Mention in this months Linux Format
by John Cliff 11 Dec '04

11 Dec '04

Hi guys, __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Article to introduce Inkscape 0.40
by Bryce Harrington 11 Dec '04

11 Dec '04

I've started sketching out a PR piece about Inkscape 0.40, with the intent of writing up something lengthy that both discusses the new capabilities of the project and encourages people to chip in help at improving things. http://inkscape.org/cgi-bin/wiki.pl?ArticleIntroducingInkscape0_40 I've identified a few areas that definitely need more fleshing out; help on those areas would be quite valuable. Also, example images are needed to show off the capabilities; I'm sure I could rough something together but am betting that folks who actually have artistic talent could do a much better job than I. :-) So help would be much appreciated there as well. I haven't thought about where to publish it; Footsteps perhaps. This is also a rough "off the cuff" writing, so needs some editing and wordsmithing, as it's probably too wordy at this point. I haven't even spell checked it, so there's probably seplling and that grammer problem too. Bryce

4 6

OpenCD
by Kees Cook 11 Dec '04

11 Dec '04

These folks are creating a Windows-only OSS CD: http://theopencd.sunsite.dk/ They've had some discussions about possibly including Inkscape, and I'm worried about some of their impressions. I'm not sure how to address their concerns. "Too much flux" and "Development has slowed" wtf!? I wish they had contacted us, we could have made the v2.0 cut... http://theopencd.sunsite.dk/forum/viewtopic.php?t=540&highlight=inkscape http://theopencd.sunsite.dk/forum/viewtopic.php?t=717&highlight=inkscape -- Kees Cook @outflux.net

2 1

Static build portability warning
by Mike Hearn 11 Dec '04

11 Dec '04

Good day gentlemen, Statically linking libgc is a good idea, because not many people have this library and it's small enough that doing so isn't a big deal. Unfortunately due to the general brokenness of glibc, this will fail on some systems with the following error: inkscape: relocation error: inkscape: symbol __libc_stack_end, version GLIBC_2.1 not defined in file ld-linux.so.2 with link time reference This is because at some point, __libc_stack_end was changed from being public to private. It seems there's been some to-and-fro on this issue: on a Debian unstable system I have access (glibc 2.3.2) to __libc_stack_end is exported but marked as private, eg you can still build against it and it'll work but may break at any moment. On my inkscape nightly build system (glibc 2.3.4) and on my Fedora Core 3 system it's public (@@GLIBC_2.1). It appears that this symbol was originally public, made private then it was discovered that it was required for some of the non-exec stack work and made public again. The net result is that anything attempting to use this symbol is going to be screwed by the symbol versioning mechanism. Boehm GC attempts to weak link against this symbol, but due to the dubious design of weak linkage on GNU systems it fails because glibc does not export this symbol as weak. I will apply a patch to the autopackage copy of libgc soon to make it always fall back to parsing /proc, ask for an explanation of this mess from the glibc developers (I will probably be ignored) and post the patch to upstream libgc to use dlsym to retrieve this symbol, which should bypass symbol versioning. If anybody sees this message then, now you know what it means (kinda). thanks -mike

3 4

Re: [Inkscape-user] Grid and adjustment
by Felix Rabe 10 Dec '04

10 Dec '04

Hi, Batista, Facundo wrote: > Now, with "#" the only thing that goes on and off is the grid, but not > the "adjustment" (it adjusts to nothing, because the grid is not drew, > but it still adjusts). This is very annoying to me, because to be able > to work freely and back, and need to go the config, change the settings, > and then again to go back. I also strongly dislike this behavior of the recent Inkscape versions. (I can only apologize not to have mentioned it before here or in Bugzilla - I hoped it would resolve "automagically" sooner or later... very old very bad user attitude of mine (; ) My "workaround" is to keep a "Document Preferences (Shift+Ctrl+D)" window open most of the time - but just when I need it to switch the grid and the snapping (that's probably meant by "adjustment") on and off "together", it's not there... :o/ Maybe the solution might be to make a couple of checkboxes to define '#' / '|' key behavior, for example: -------------------------------------------- | Pressing the <#> key toggles: | [ ] Grid visibility // equiv. to "Show grid" | [ ] Snapping bounding boxes to grid // equiv. to "Snap bboxes 2 grid" | [ ] Snapping points to grid // equiv. to "Snap points 2 grid" -------------------------------------------- They are actually equivalent to those already in the Doc.Pref. window. OR, it could be solved like this: -------------------------------------------- | [ ] Show grid [ ] Toggled by pressing <#>? | [ ] Snap bounding boxes to grid [ ] Toggled by pressing <#>? | [ ] Snap points to grid [ ] Toggled by pressing <#>? -------------------------------------------- Hope to have provided some useful ideas, Felix PS: Thanks bulia for the fast bug fixing :)

1 0

[Bug 73619] Inkscape crashes with GLib problem when trying to print (fwd)
by Bryce Harrington 10 Dec '04

10 Dec '04

---------- Forwarded message ---------- Date: Fri, 10 Dec 2004 01:53:44 +0000 From: bugzilla-daemon@...599... To: bryce@...260... Subject: [Bug 73619] Inkscape crashes with GLib problem when trying to print http://bugs.gentoo.org/show_bug.cgi?id=73619 ------- Additional Comments From xanderhsia@...210... 2004-12-09 17:53 PST ------- OK. I following the instructions on running gdb and got a backtrace. Note that I do not have USE="debug" flag turned on. If this report doesn't have the right info , I can recompile and rerun gdb. Bear with me, this is first time I have run gdb, so I'm not really sure what I am looking for. ender@...600... ~/home $ gdb inkscape GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /usr/bin/inkscape (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread -1220237632 (LWP 31494)] (inkscape:31494): GLib-CRITICAL **: file gthreadpool.c: line 284 (g_thread_pool_new): assertion `g_thread_supported ()' failed GLib-ERROR **: The thread system is not yet initialized. aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1220237632 (LWP 31494)] 0xffffe410 in ?? () ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

2 1

Inkscape-Deps (Problem in Gentoo)
by Carsten Niehaus 09 Dec '04

09 Dec '04

Hi As some of you might know Inkscape is outdated in Gentoo. Version 0.37 is marked as stable, 0.38, 0.39 and 0.40 are marked unstable (~ARCH) [1]. The reasons are that Inkscape is "known" to crash an startup for some people (see e.g. [2]). I am using 0.39 since it it released with the ebuild Gentoo provides as "unstable" and had _no_ problems at all. For Inkscape 0.40 there is the problems of new deps, esp. libboehm and gtmmm. See [3] for it. Furthermore there have been a lot reports about GLIB-crashes I never could reproduce. See [4] for a glib-crash in 0.40. I hope that some of you could add comments to these 4 bugreports to help the gentoo-ebuild-writer. Gentoo is probably the only distro without a uptodate Inkscape and that is a shame. If you don't want to do it yourself write me a mail and I will add the comments. Thanks in advance, Carsten [1] http://packages.gentoo.org/search/?sstring=inkscape [2] http://bugs.gentoo.org/show_bug.cgi?id=73743 [3] http://bugs.gentoo.org/show_bug.cgi?id=71017 [4] http://bugs.gentoo.org/show_bug.cgi?id=73619 -- The rule on staying alive as a forecaster is to give 'em a number or give 'em a date, but never give 'em both at once. -- Jane Bryant Quinn

5 8

Inkscape 0.40 - error importing AI files
by unknown＠example.com 09 Dec '04

09 Dec '04

When I am importing .AI files this error message appears: ** (inkscape:9542): CRITICAL **: file document.cpp: line 511 (void sp_document_set_uri(SPDocument*, const gchar*)): assertion `document != NULL' failed Pleas help, how can I solve it? I have thousand .AI files which I could open in 0.39. Is downgrade only one solution? (OS: Gentoo unstable, same expirience with self compiled inkscape 0.40cvs and 0.40 stable in Slackware current) Thanks Martin Grohman

2 1

libXSLT dependency
by Bob Jamison 08 Dec '04

08 Dec '04

I have been asking around if anyone would mind adding libxslt as a dependency for this cycle. So far, I have had no complaints. This would allow not only us but also the average user to write input and output filters. Bryce mentioned that the requirement should not be bleeding edge. So I found this pkg-config file, libxslt.pc, on RH7.3, which seems good enough, so requiring libxslt >=1.0 should be sufficient. Could someone add this dep to configure.ac, if it is OK with everyone? ========= SNIP ============== prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libxslt Version: 1.0.15 Description: XSLT library version 2. Requires: Libs: -L${libdir} -lxslt -L/usr/lib -lxml2 -lz -lm -lm Cflags: -I${includedir}

3 5

Firefox 1.0 Linux on Gentoo has SVG plugin installed by default!!!!!!!!
by Jon Phillips 08 Dec '04

08 Dec '04

Hello all, I just opened an svg file by accident in Firefox 1.0 just to find that it displayed properly in my browser!!! Upon closer inspection I thought that I had setup svg to display in inkview, but no, I looked in the MozillaFirefox plugin folder and found these: -rw-r--r-- 1 root root 5632 Nov 18 04:20 libmozsvgdec.a -rwxr-xr-x 1 root root 1368 Nov 18 04:20 libmozsvgdec.la -rwxr-xr-x 1 root root 8536 Nov 18 04:20 libmozsvgdec.so Thus, could you all check to see if the Mozilla SVG is provided with your Firefox 1.0 install? I am ecstatic with joy if this is installed by default on all Firefox 1.0 browsers, because that means we now have penetration into the world with SVG. I have just ruled out that I built my Gentoo install of Firefox with SVG, as it is not an option. Thus, the gentoo ebuild builds the SVG plugin by default. Hmmm...if you all could report if you have the SVG plugin on your install, it would be great to know to promote via our website. In the end, we have to consider that our app's usefulness will scale dramatically if SVG is adopted by more user's. As of now we are using more as a meta-format not much unlike Illustrator using AI as a default format for creating illustrations. With viewing of SVG files on the web, so much more will be possible. Jon -- Jon Phillips (NEW) USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

4 8

RE: [Inkscape-devel] SVG Linking
by NAGY Endre 08 Dec '04

08 Dec '04

Jon Thanks for responding and apologies for the delay in getting back My initial enquiry concerning linking related to a requirement to be able to edit attributes in the users namespace. See Feature Request No 1070754 and the mail in Inkscape-Devel on the subject "what do you _really_ want". I assumed that "SVG linking" might be able to help because Ch 17 of the SVG spec mentioned that I could use an URI specified by an Xlink to access a program. In retrospect I think I was grasping at a rather short straw. I can only guess at how I thought I was going to open an application in a browser to edit attribute values and then get those values back into the SVG content. As Peter Moulder points out in in his responses to my feature request, what I really need is a user friendly version of the XML editor that I can constrain to a specific set of attributes. My best hope here appears to be to make use of the plugin architecture. Peter suggested that I speak to Ted about this. I need this feature in Inkscape proper rather than a viewer because its all part of my editing process. If you think I'm still confused please feel free to respond Regards Endre -----Original Message----- From: Jon Phillips [mailto:jon@...235...] Sent: Wednesday, 1 December 2004 5:32 AM To: bulia byak Cc: NAGY Endre; inkscape Subject: Re: [Inkscape-devel] SVG Linking On Mon, 2004-11-22 at 19:25 -0500, bulia byak wrote: > > When invoking the example in InternetExplorer, the affect of clicking on the > > ellipse is to bring up W3's web page. > > I have not found a way of achieving this in inkscape. > > What, Inkscape did not show you the web page?! :) > > Seriously, it would be nice to run a browser by clicking a link. In > theory. In practice, Inkscape is not so much of a "user agent" as it > is an SVG creating application. In particular, following link on click > will badly get in the way of editing. Clicking something in Inkscape > has lots of editing functions. So, while we can create links, I think > we can be excused for not following them. > > This of course applies to inkscape proper. For inkview, following > links by calling a browser is a must. I think we already have an RFE > on that; search in the tracker and add your comments. Yes, I have been working on this behind the scenes. There are a few RFE's about linking. We (inkscape developers) have discussed having a preview mode like in Macromedia Flash whereby any animations/scripting/linking can be tested. Yes, Inkview should be a runtime/player of SVG content. And, yes, linking should work the way you are describing. My understanding of the spec though would allow you to in Inkview click on a link and if it is local and an SVG, then it is opened in Inkview. If it is a URL, to the SVG file, then that is viewed as well. If the file is not SVG, then it would be dealt with as described in the spec. Ideally, html would be opened in one's default browser, and other media would be shuttled to where it needs to go. I'm trying to get this feature into the next release. I think inkview is a good app in its own right as a simple viewer. I'm trying to decide if I should make these features into an inkbrowse app that is similar to inkview, but for browsing the web and local svg files. What this looks like needs to be debated. Initially I would like a UI like a web browser but for SVG content only. Do you all agree with me that this should be a separate application or should it be rolled into inkview? I could make it so that Inkview accepts URLs and could have a browsing interface and a simple menu system that can be hidden. It would be good to allow Inkscape to open SVG files that are qualified URLs (and I remember that Inkscape used to be able to do this), and then enable this functionality in inkview to add web-based svg files to a presentation, and eventually, this will allow for SVG-based animations in inkview as a presentation. Thoughts? > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > -- Jon Phillips (NEW) USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu) IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

1 0

visible, printable and wxSVG
by Edouard TISSERANT 08 Dec '04

08 Dec '04

WxSVG (wxsvg.sf.net) is a young GPL project that as still never released files, since it as not reach beta stage. First commit should occur in January 2005. WxSVG let you "draw" GUI with Inkscape. Have a look to screenshots at http://sourceforge.net/project/screenshots.php?group_id=124832 It consist of a thin layer of python classes that derive from wxPython controls classes. It use SVG elements to layout controls such as buttons or panels and map them with some pieces of bitmap cut-out from one or two (on & off) bitmaps exported from Inkscape. SVG elements that are used to layout controls are <rect> and <g>. We were used to use the non-printable feature of Inkscape to let us draw layout rect's over the visible GUI design, and the export the GUI image without control rect's. We have upgraded to yesterday's CVS snapshot. No more non-printable feature... And invisible elements are exported in bitmaps. So we cannot work anymore in the same way... The only way I found is to set global transparency for the "Control" group to 0.0 when exporting bitmap, ant to 1.0 when working on. Non-printable object was a very nice feature. WxSVG is really need it. Is there any other solution ? Except guide-lines is there anything that Inkscape can show but not export ? Edouard.

4 6

[Fwd: Re: Cross-compiling GlibMM statically to Win32 with MinGW]
by Bob Jamison 08 Dec '04

08 Dec '04

See how cool it can be when Open Source projects help each other? ^^ Bob

1 0

E nderuara Kompani!
by unknown＠example.com 08 Dec '04

08 Dec '04

E nderuara Kompani! ITS Germany e cila operon prej vitesh ne fushen e telekomunikacionit dhe internetit, tashme deshiron te zgjeroje aktivitetin e saj edhe ne teritorin e Kosoves . Stafi yne i perbere nga inxhiniere, teknike, designer, analiste tregu, etj. Kane pergatitur www.kosova-informacion.de Ne kete portal mund te nxirren njoftime per shitblerje, qeradhenie e qeramarrje te pasurive te patundshme, automjeteve, pajisjeve, apo te sherbimeve te ndryshme si telekomunikacioni, hoteleri-turizmi, apo udhetimet, etj. Cdo njoftim mund te shoqerohet me 1-6 fotografi te objektit. Cmimi per njoftim varion ne varesi te kategorise se objektit, kohezgjatjes online te njoftimit dhe numrit te fotografive (cmim i cili do te vendoset bashke me ju). ITS Germany eshte duke kerkuar Perfaqesuesin / Distributorin e saj per Kosove i cili do te marre Eskluzivitetin e plote te www.kosova-informacion.de per te gjithe territorin e Kosoves. Marrja e Eskluzivitetit nenkupton fillimin dhe zhvillimin e gjithe aktivitetit komercial te ketij portali vetem nga nje Perfaqesues / Distributor pra vetem nga ju. Nderkohe ITS Germany merr persiper mirembajtjen dhe suportin teknik te portalit, si dhe mbeshtetjen e saj nepermjet konsulences se nevojshme ne cdo moment. Per cdo informacion apo interes tuajin, ju lutem te na kontaktoni nepermjet postes sone elektronike , ne ju mirepresim. Na lejoni tju urojme mireseardhjen ne kompanine tone, kompania me e madhe e telekomunikacionit dhe internetit ne Gjermani! Me respekt, A. Berzani Directorin Development office@...595...

1 0

E nderuara Kompani!
by unknown＠example.com 08 Dec '04

08 Dec '04

E nderuara Kompani! ITS Germany e cila operon prej vitesh ne fushen e telekomunikacionit dhe internetit, tashme deshiron te zgjeroje aktivitetin e saj edhe ne teritorin e Kosoves . Stafi yne i perbere nga inxhiniere, teknike, designer, analiste tregu, etj. Kane pergatitur www.kosova-informacion.de Ne kete portal mund te nxirren njoftime per shitblerje, qeradhenie e qeramarrje te pasurive te patundshme, automjeteve, pajisjeve, apo te sherbimeve te ndryshme si telekomunikacioni, hoteleri-turizmi, apo udhetimet, etj. Cdo njoftim mund te shoqerohet me 1-6 fotografi te objektit. Cmimi per njoftim varion ne varesi te kategorise se objektit, kohezgjatjes online te njoftimit dhe numrit te fotografive (cmim i cili do te vendoset bashke me ju). ITS Germany eshte duke kerkuar Perfaqesuesin / Distributorin e saj per Kosove i cili do te marre Eskluzivitetin e plote te www.kosova-informacion.de per te gjithe territorin e Kosoves. Marrja e Eskluzivitetit nenkupton fillimin dhe zhvillimin e gjithe aktivitetit komercial te ketij portali vetem nga nje Perfaqesues / Distributor pra vetem nga ju. Nderkohe ITS Germany merr persiper mirembajtjen dhe suportin teknik te portalit, si dhe mbeshtetjen e saj nepermjet konsulences se nevojshme ne cdo moment. Per cdo informacion apo interes tuajin, ju lutem te na kontaktoni nepermjet postes sone elektronike , ne ju mirepresim. Na lejoni tju urojme mireseardhjen ne kompanine tone, kompania me e madhe e telekomunikacionit dhe internetit ne Gjermani! Me respekt, A. Berzani Directorin Development office@...595...

1 0

Updating gtk.zip for this release
by Bob Jamison 08 Dec '04

08 Dec '04

Now that we are at the beginning of a cycle again, it is time again to start updating the gtk24.zip file with new stuff. I made a first try at a new bundle here: http://troi.hous.es3.titan.com/~rjamison/inkscape , ...at the bottom of the page. It is very large, but only because we will need to discover from development and usage what is needed from the Perl and Python libraries. It will of course get smaller with time. And I changed the name, since it is not just Gtk stuff anymore. Bob

1 0

Inkscape 0.40 - error importing AI files
by Martin Grohman 08 Dec '04

08 Dec '04

When I am importing .AI files this error message appears: ** (inkscape:9542): CRITICAL **: file document.cpp: line 511 (void sp_document_set_uri(SPDocument*, const gchar*)): assertion `document != NULL' failed Pleas help, how can I solve it? I have thousand .AI files which I could open in 0.39. Is downgrade only one solution? (OS: Gentoo unstable, same expirience with self compiled inkscape 0.40cvs and 0.40 stable in Slackware current) Thanks Martin Grohman

1 0

Suggestion: Dim-able layers.
by Jakob Ilves 08 Dec '04

08 Dec '04

Hello! I had a very brief test of inkscape 0.40 and of course had a shot at using the layers feature and I liked it, especially that one could easily temporarely hide layers. One feature I would really appreciate is an additional option for a layer, in addition to locking and hiding: dimming (or whatever to call it). That is, one can set a layer to have a opacity lower than 1 to make it semi-transparent by using some convenient GUI widget. I know, one can do that today by entering the XML-editor (we all love it, don't we?) and once there, select the group the layer consists of and add "opacity: 0.5" (or whatever) to the group's style property. So it's already available but you know, a GUI isn't bad either. Thanks for a great tool! It is getting better and better! Best regards /IlvJa PS. I know, "Dim-able layers" might sound a bit corny but I could not make up any other term. (not a native English speaker, living in Sweden).

2 1

NEW: Tile clones
by bulia byak 08 Dec '04

08 Dec '04

Before getting deep into the boring stuff planned for 0.41, I decided to do some eye candy... http://inkscape.org/screenshots/gallery/inkscape-0.41-CVS-linux-tiles1.png http://inkscape.org/screenshots/gallery/inkscape-0.41-CVS-linux-tiles2.png * The new powerful "Tile clones" dialog implements all 17 plane symmetry groups, allowing you to easily create all sorts of symmetric patterns, Escher-like tesselations, ornaments, etc. Since the pattern is made out of clones, you can freely edit the original tile and the entire pattern is updated live. This feature puts Inkscape into competition with software such as the free Arabeske or commercial SymmetryWorks. ** Apart from selecting the symmetry (and uniquely to Inkscape), you can also set the shift, scale, rotation, and opacity of the clones in the pattern, per row and/or per column. Any of these parameters can also be randomized to any degree. This produces "object fields" that can be arbitrarily distorted, skewed, slanted, "faded out," or "magnetized" like iron particles in a magnetic field. ** To create a clone pattern, simply select something, set the number of rows and columns, and click Create. You can then change some parameters in the dialog and click Create again; this will remove any existing tiled clones of the selected object and recreate the pattern anew. Or, you can just remove the old pattern by clicking Remove. To protect a pattern from deletion by this dialog, group it or move it to another layer. ** Initially, a pattern is created based on the bounding box of the selected object. For symmetries that involve rotation to an angle other than 180 degrees, the rotation point is usually in the middle of the right-hand side of the bbox. After the pattern is created, resizing the original tile does not move the clones away, so you can make the tiles overlap. Also, when the pattern is created, the current bbox of the original tile is remembered; later, if the "Use saved tile bbox" checkbox is on, the same bbox will be used when you click Create again, which means you can vary the pattern parameters without losing the overlapping of the tiles. ** It's best to use a group as the original object for tiling, because you can then enter this group (right-click, "Enter group") and draw inside it. Any changes or new objects added to the group will show in the pattern immediately.

5 7

pivot in scale mode
by PTT 07 Dec '04

07 Dec '04

I noticed from 0.39 on the pivotpoint (the cross that on which an object rotates, i think it's called pivot) is hidden in scale mode, so only visible in rotate mode. I find it quite usefull in scale mode too, (ie. while overlaying images you move the point to a place you want to keep, then scale so the whole image is as you wish). What is the reason it hides? And can it perhaps be turned into an option? PTT

4 4

inkscape memory leaks
by MenTaLguY 07 Dec '04

07 Dec '04

Hi, I was directed to recent traffic on the freebsd lists... I suspect the memory leaks you're experiencing aren't freebsd-specific, nor are they necessarily the result of bugs in libgc proper -- one of the recurring issues we've been having has been large leaks due to the way we bridged the refcounted and garbage-collected portions of the codebase. In a nutshell, some garbage-collected objects also have refcounts that can be used to pin them so they can be referenced by non-gc-aware objects. Since these objects are still traced by the collector, and are generally organized in the form of trees with parent pointers, a single leaked refcount will pin the entire tree of objects. [ It was one of those designs that seemed like a good idea at the time... ] In a profound irony, pretty much all of the leaks of gc-managed memory we've discovered so far have been due to refcount leaks in conventional code. :/ I thought we had found and fixed them all, but they can be pernicious and hard to nail down; I am noticing that we are still a little leaky on other platforms as well. There may be issues with libgc on freebsd as well, but I would look at refcount leaks if you've not already done so. Anyway, it sounds like you've been spending a good deal of time with debugging this; would you like to further compare notes in case we're duplicating effort? -mental

2 1

Difficulty with sizing imported EPS files...
by Daniel 07 Dec '04

07 Dec '04

[Please cc: me on replies] Hi, I'm using Inkscape 0.40 packaged for Debian unstable. If it's an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the 'file' utility, to be regular postscript, rather than encapsulated postscript). Any ideas? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I've given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

1 0

Fwd: [Inkscape-devel] Graphics-by banner
by Ana Saiz García 06 Dec '04

06 Dec '04

Hi again I'm sorry to bother you again, but I've realised that I hadn't convert the text to curves, in order to avoid problems with the fonts. Now I've corrected this problem, so maybe you can put the new svg in your page (the png hasn't changed). The link is: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg Sorry for the inconveniences and thank you again Ana -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

2 1

Re: [Inkscape-user] RPM build errors
by Bryce Harrington 06 Dec '04

06 Dec '04

On Sat, 4 Dec 2004, Jonathan Leighton [Turnip] wrote: > Okay. I took them all out, and tried to run inkscape, but nothing > happened. As in zero, zilch, nada. The cursor just sat there on the line > beneath the "inkscape" command. So I quit that, and put all the > extensions back in. I then took them out one by one, and when I took out > the one called "gimpgrad.inx", it again wouldn't do anything when I ran > the "inkscape" command. So I believe we have a culprit, although I'm not > entirely sure what I should do now. Hmm interesting, that wouldn't have been the one I'd have guessed. So to recap, you're getting a failure during Extension initialization where it complains about an improperly freed pointer, presumably a string, that appears related to the gimpgrad.inx extension. Ted can you help give some guidance on this? > Just out of interest, do you think this problem is specific to me, or > would it happen to anyone using the RPM I built? Because if it would > happen to anyone then I guess it's more serious. Aha, this is why you shanghai a couple friends into testing it. ;-) Go ahead and see if you can find someone to test it, and see if they get the same problem. That'll be good to know. Let's move this over to the inkscape-devel@ list, it's gotten a bit too nuts and bolts for the user list. Bryce

3 3

OT: Path to NURB
by Aaron Spike 06 Dec '04

06 Dec '04

First off congratulations and thank you for the 0.40 release. I'm telling everyone how much I love Inkscape. I was wondering if anyone could offer some advice or insight. I'm writing a little PHP script to convert a subset of SVG PathData (only M, C, L and z directives) drawn with Inkscape into DXF SPLINEs (NURBs) for use in QCad. I can do it successfully following the practical instructions at the bottom of this article about NURBs <http://www.mactech.com/articles/develop/issue_25/schneider.html>. To do this I write a separate SPLINE for each segment of a Path. I would prefer to write a single SPLINE for each continuous portion of a Path, but I can't get it right. So far I have just been guessing and guessing wrong. Any direction would be appreciated. Aaron Spike

3 4

Making rpm for Suse 9.2
by Jogchum Reitsma 05 Dec '04

05 Dec '04

Hi, On my Suse 9.2 box, I downloaded inkscape-0.40-1.src.rpm from sourceforge, solved a few dependancies and issued rpmbuild --rebuild inkscape-0.40-1.src.rpm to create a rpm-binary (not as root, but as normal user). It compiles OK, but bails out with the following message lines: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/inkscape-0.40-root error: Installed (but unpackaged) file(s) found: /usr/lib/inkscape/plugins/libgimpgrad.a /usr/lib/inkscape/plugins/libgimpgrad.la /usr/lib/inkscape/plugins/libgimpgrad.so.0.0.0 The mentioned files do exist in /var/tmp/inkscape-0.40-root, and the names are stated in a file /tmp/rpmN24154 Also there exists a file /tmp/rpmF24155 with the same creation date and time, but empty. Anyone an idea what might be happening? Thanks, Jogchum

3 6

concerning layer selection - OpenOffice method works very well (fwd)
by Bryce Harrington 05 Dec '04

05 Dec '04

---------- Forwarded message ---------- Date: Wed, 1 Dec 2004 22:35:51 -0500 From: Phoenix <phoenixreads@...584...> To: bryce@...260... Subject: concerning layer selection - OpenOffice method works very well OpenOffice has a very effective system background graphics I have group 1 above background graphics. I have group 2 above group 1 if I double click on group 1 everything else grays out and now I have group 1 "ungrouped" and highlighted. I am now editing group 1 in context (that is behind group 2, above background). if I click the background, I return to the "edit document" stage. To move from group 1 editing to group 2 editing... I double click to get to the "edit document" stage, then double click to edit group 2. To make things more interesting the concept of layering applies so I can double click groups within groups and edit accordingly. Double-clicking outside the group moves one up in the order. Using version 0.37 for reference. As for Inkscape double-click item to change modes that should become double-click handlers. If I want to experiment, I have to move back and forth to object to change. Double-clicking handlers is more intuitive since that is what I want to change. I don't know enough about internals of Inkscape but a request that Inkscape develop into a vector drawing engine so programs like mind-mapping and Visio-like program are basically a GUI redesign and of course standardize on SVG. Excellent program, Phoenix

2 1

0.40 Build on Mac
by Gazal, Geraud (GE Healthcare) 04 Dec '04

04 Dec '04

Seen today on Linuxfr.org about Inkscape on apple MacOSX Hope it can help some of you (see translation below) Regards, Matiphas --- Bon, donc effectivement, inkscape 0.40 a des dependances assez contraignantes. Une mise a jour complete de tout ce qui est environnement de developpement de Apple (via l'ADC http://connect.apple.com/ est necessaire, et apres ca marche tout seul. Le bug de l'affichage des menus derriere les fenetres reste la. Dommage ----> Yes inkscape has some hard to solve dependancies. A complete update of development enverinment from apple (see ADC : http://connect.apple.com/ ) is required and then it works ok without any problem (Pity, the display bug (menus behind windows is still there)

2 1

Query: I/O cleanup, reorganization?
by Bob Jamison 03 Dec '04

03 Dec '04

Hi all, I am back from holidays today, and have been catching up on my email. I was wondering: would a good task for this cycle be a reorganization of our set of scattered, disparate I/O classes into a nice, clean heirarchy of its own, such as /src/io and the namespace Inkscape::IO? We have been talking about moving from filenames to URIs for months now, and changing slowly from FILE * to iostreams. Maybe now at the beginning of a release cycle would be a good time to bite the bullet. This would not be a roadmap thing, but a nice clean top-to-bottom refactoring that would finally take care of our recurring migraines with files and paths and localization. Consider it to be a big bugfix. If we could upgrade from char * ---to--->FILE * to a much cleaner URI ---to--->istream and URI ---to--->ostream ...with built-in support for localization, it would make things a LOT easier. I have been looking around the net a lot, and there already exists a wonderful 'gzstreams' lib for supporting .svgz without pipes. I experimented with it by recoding my copy of repr-io.cpp to use iostreams instead of FILE *, and it worked wonderfully. There is also a pair of iostream implementations I found, that provide printf() and scanf() style formatting, to alleviate the pain of conversion somewhat. This would be a lot like Java's "java.io.*" heirarchy, putting streams, files, URI/URL's and paths into one place. Any thoughts, opinions? This is just something I have been thinking about recently. Bob

5 15

Article: Introducing Inkscape 0.40
by Bryce Harrington 02 Dec '04

02 Dec '04

The article about Inkscape is now live on OS News: http://osnews.com/story.php?news_id=9049 Also, we got picked up on LWN: http://lwn.net/Articles/113513/ And Footnotes: http://gnomedesktop.org/node/2062 Bryce

3 2

please read webdevnews article before publication today
by Peter Moulder 02 Dec '04

02 Dec '04

An article about inksape 0.40 is to appear on http://webdevnews.com/ at 16:00 in Central US time (which I think means 22:00 UTC). Can pleple please check it and communicate any corrections etc. to SteamedPenguin, who will drop by on IRC some time before then? It isn't yet available to be read as I type this, but should appear at http://webdevnews.com/2004/12/02/open-source-svg-editor-inkscape-reaches-04… before being linked to from the front page. (Incidentally, it's possible that I wrongly guessed what sp meant by "tomorrow", in which case publication would be about 35hrs from this e-mail instead of about 11 hrs.) pjrm.

1 0

Re: C-based garbage collection for Inkscape
by Bryce Harrington 02 Dec '04

02 Dec '04

Thanks Keith, passing along to the crew... Bryce On Tue, 30 Nov 2004, Keith Packard wrote: > > I've been using a garbage collector in C for about twenty years which is > different from the Boehm system. > > advantages: > > 1) Completely portable -- no machine dependent code at all > 2) Integrates with malloc/free using code > 3) Precise pointer knowledge - the set of referenced objects is known, > not discovered. > > disadvantages: > > 1) Requires stylized function call/return macros both where the > allocator is used as well as in at least one place above all > allocation calls in the call graph. > > It's part of the nickle language implementation (http://nickle.org) and > has been used in several other projects to good effect. > > -keith > > >

3 4

Inkscape status 2004-12-01
by Bryce Harrington 02 Dec '04

02 Dec '04

Inkscape 0.40 has turned out to be a good solid release. We're already seeing a surge in downloads, and the response to our notices and article on OS News has been quite positive. There have been a few complaints about the bleeding-edge-ness of the deps; this wasn't a surprise, we knew this would be a tough release for folks to get installed. We should keep this in mind and be a bit more conservative for the next release or two. With 0.40 out the door I see both a collective sigh of relief at being done and ready for a break, plus an energy to start working on new stuff for 0.41. For the next month or so we're going to keep things low key, enjoy the holidays, and work on whatever seems most intriguing. Below I've listed out the stats for the past two months for direct comparison. (I swear, some day I'll graph this data so we can visualize it easier...) Note the big jump in Freshmeat subscribers; these all came the day we announced the new release. Our mailing list memberships are also growing nicely. I think the article in early Nov brought in a sizeable number of people. I suspect that for us to continue building our lists we need to seek out new communities and have articles published in new publications. For instance, we seem to get good coverage in foreign trade magazines; it'd be good to get published in some U.S. computer magazines too. Statistics Oct 15 Nov 1 Nov 15 Dec 1 ========== ====== ===== ====== ===== Lifetime Rank on SourceForge: 687 684 636 636 (95.2%) (95.2%) (95.6%) (95.6%) Max Week's Rank on SourceForge: 124 62 14 16 (99.3%) (99%) (100%) (99.9%) Total SF Page Views 1,339,114 1,487,659 1,758,321 1,921,981 Total SF Downloads 63,869 69,078 80,152 89,345 Total Freshmeat URL Hits 11,465 11,849 12,162 13,351 Total Freshmeat Subscriptions 124 125 126 141 Lines of Code in src/: 303,783 306,602 307,747 309,285 Code lines 216,027 217,198 217,982 218,803 Comment line 52,421 53,262 53,491 53,798 Blank 41,872 42,699 42,829 43,249 Lines of Docs in doc/: 16,841 16,841 16,974 17,901 Lines of content in website: 7,840 8,121 8,382 8,732 Size of the Inkscape wiki: 22,459 18,977 19,735 21,379 Bugs open/total: 135/653 104/683 102/733 119/774 Features open/total: 263/406 279/426 291/448 307/467 Patches open/total: 7/126 7/130 7/137 5/143 CVS Commits (as per inkscape-cvs) 7,860 8,279 8,613 8,878 Inkscape-devel membership: 109 108 117 120 Inkscape-announce membership: 98 113 124 137 Inkscape-user membership: 138 144 157 162 Num Translations: 33 33 33 33 Ave Translation Ratio: 35.0% 38.5 38.4 42.2 * - Statistics unavailable Bryce

1 0

Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)
by Bryce Harrington 02 Dec '04

02 Dec '04

---------- Forwarded message ---------- Date: Tue, 30 Nov 2004 19:01:37 -0500 From: Jonadab the Unsightly One <jonadab@...581...> To: clipart@...330... Subject: Re: [Clipart] Announcing Inkscape 0.40 Release Bryce Harrington <bryce@...260...> writes: > user's may encounter more trouble getting Inkscape installed on some > platforms than in previous releases. To help those who run into > this issue, we're also providing 'Static Binary' packages that > include these new libraries inside the package, and thus, the static > releases are very large. Very large? 8 Megs hasn't been a large size for an application download in *years*. There are *plugins* nearly twice that large. (For example, I've got a copy of j2re-1_4_2_05-linux-i586.rpm sitting around in my downloads directory weighing in at 14MB, and nobody apologised for that being large.) Honestly, I wish more applications would realease statically linked binaries like this. <rant intensity="50%"> However, I still have to chase down a dependency: gtk2. I have gtk2, of course, but apparently it's not the latest and greatest version. So I downloaded that, but now I need other stuff... error: Failed dependencies: libglib2.0 >= 2.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk libpango1.0 >= 1.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk libgtk+-x11-2.0_0 = 2.4.9-9mdk is needed by libgtk+2.0_0-2.4.9-9mdk I need to do this anyway, since there's a new Gimp coming out that I'll want, but this underscores the single largest problem IMO in open-source today: excessive use of dynamic linking makes upgrades painful beyond the bounds of all reason. I can understand the desire to link inkscape dynamically against GTK, because *lots* of stuff links against GTK, and it makes sense to install one copy (of each major version). But I do NOT understand why GTK is linked dynamically against libglib and pango. Virtually nothing else besides GTK uses those libraries, so there's no good reason for the dynamic linking: root@...582... ~/download :) # rpm -q --whatrequires libpango1.0 libgtk+2.0_0-2.2.4-2mdk root@...582... ~/download :) # rpm -q --whatrequires libglib2.0 libgtk+2.0_0-2.2.4-2mdk libgtop2.0_0-2.0.5-1mdk root@...582... ~/download :) # rpm -q --whatrequires libgtk+-x11-2.0_0 gtk+2.0-2.2.4-2mdk libgtk+2.0_0-devel-2.2.4-2mdk root@...582... ~/download :) # Not only is GTK quite pointlessly dynamically linked against libglib and pango, but it *itself* is subdivided into two packages, for absolutely no good reason. This is why I only have time to upgrade stuff at home, and at work I'm still using Gnome 1.4 -- at work, I can't justify the time to chase down a hillion jillion dependencies. I shouldn't have to do it at home either. Nobody should. Hard drive sizes being what they are, it no longer makes sense to save a couple of measley megabytes by inflicting superfluous pain on the user. Inkscape is an application I use with some frequency: as such, it's welcome to a few megabytes of drive space. </rant> One can only imagine the trouble I'd have put myself through if I'd downloaded the non-statically-linked version of Inkscape. <<shudder>> The take-home message is this: Static linking is GOOD, and the world needs more of it. -- $;=sub{$/};(a);=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/ _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

4 5

Scene interpretation mentioned on Slashdot
by Bob Jamison 01 Dec '04

01 Dec '04

There is an article on Slashdot that mentions a "new photographic technique" with some concepts strikingly similar to how the Tracer works: http://science.slashdot.org/article.pl?sid=04/12/01/0238222&tid=152&tid=126… this is the quoted article: http://www.photo.net/learn/technology/mflash/merl-non-photo.html Notice the mention of a "canny edge detector." ;-) One thing that someone showed me, is how tracing the same image multiple times with different algorithms and/or parameters, and recombining the results, can often produce a fairly good rendition of the original. Here is a trivial example of the raytracer doing it with merely 3 different levels of brighness threshold: http://troi.hous.es3.titan.com/~rjamison/inkscape/files/clemens-traced.png So, hey, we are ahead of the curve on this one! ^^ Bob

2 2

Re: Announcing Inkscape 0.40 Release . www.inkscape.org (fwd)
by Bryce Harrington 01 Dec '04

01 Dec '04

---------- Forwarded message ---------- Date: Wed, 1 Dec 2004 18:00:49 +0100 From: Dave Neary <bolsh@...85...> To: Bryce Harrington <bryce@...1...> Subject: Re: Announcing Inkscape 0.40 Release . www.inkscape.org Hi Bryce, Congratulations on the release! Yet another huge step forward. Cheers, Dave. Quoting Bryce Harrington <bryce@...1...>: > Inkscape 0.40 > ============= > > Draw Freely. > > http://www.inkscape.org/ > > The Inkscape community is proud to announce release 0.40 of Inkscape, "A > Cross-Platform Open Source Vector Graphics (SVG) Drawing Tool." This > release includes three highly requested new capabilities: Layers, > Text-on-Path, and Bitmap tracing. In addition, several minor features > have made the cut along with a number of usability enhancements, three > new tutorials, and hundreds of bug fixes; this is by far the most > feature-packed release to date! > > The implementation of layers provides another means for organization of > compositions. Layers can be locked to not allow changes and their > visibility may be toggled on and off. This is great for sketching over a > bitmap image by using it as a template. However, one might skip this > technique altogether by using the new "Bitmap Tracing" which uses > Potrace to convert pixels/bitmaps into vector graphics. Normally this > function is not found in illustration programs, but now it is front and > center right on the canvas within Inkscape. > > Since our last release four months ago, we have added several new > dependencies such as the Boehm garbage collector and the stable Gtk 2.4 > libraries. Hence, installing Inkscape on some platforms might raise more > issues than as with previous releases, and we ask you to please post to > the bugtracker (http://inkscape.org/report_bugs.php) any issues > discovered. To help those who run into undocumented problems we're also > providing 'Static Binary' packages that include these new libraries. > > We celebrate this release from our community and hope to encourage > others to join our project by the simple act of contributing graphics, > tutorials, code, and translations. Inkscape recently became a one-year > old project. We are looking forward to another dynamic year of > development as we move Inkscape further from C to C++, approach SVG Tiny > compliance, and eventually full SVG 1.2 validation. Thank you for using > Inkscape. Draw Freely. > > Download your packages (Linux, Windows, Mac OSX): > > http://sourceforge.net/project/showfiles.php?group_id=93438 > > For many more details, see the Release Notes for 0.40: > > http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes040 > > Community submitted screenshots: > > http://www.inkscape.org/screenshots/ > > > _______________________________________________ > gnome-announce-list mailing list > gnome-announce-list@...45... > http://mail.gnome.org/mailman/listinfo/gnome-announce-list > -- Dave Neary Lyon, France bolsh@...85...

1 0

Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)
by Bryce Harrington 01 Dec '04

01 Dec '04

---------- Forwarded message ---------- Date: Wed, 01 Dec 2004 08:48:44 -0500 From: Carl Worth <cworth@...573...> To: Jonadab the Unsightly One <jonadab@...581...> Cc: clipart@...330... Subject: Re: [Clipart] Announcing Inkscape 0.40 Release On Tue, 30 Nov 2004 19:01:37 -0500, "Jonadab the Unsightly One" wrote: > I'll want, but this underscores the single largest problem IMO in > open-source today: excessive use of dynamic linking makes upgrades > painful beyond the bounds of all reason. The problem of a single application upgrade requiring many libraries to also be upgraded has been solved in any number distributions with good package managers. If you're not yet using one, I would recommend you try one out. > The take-home message is this: Static linking is GOOD, and the world > needs more of it. No. Static linking leads to bug propagation. This is especially bad when there are security bugs in well-used libraries, (for example the zlib bug from some time ago). Widespread use of static linking makes it much harder to get security fixes out since it requires updating many applications. With dynamic linking, only the affected library need be updated. -Carl _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

1 0

Inkscape slides in spanish
by Lucas Vieites 01 Dec '04

01 Dec '04

Hi, A few months ago there was a presentation of Inkscape at the University of A Coruña. Now the slides used at that presentation have been made available. The slides are made in inkscape in order to provide a useable space on the right to do some demos as you speak. Find them at: http://www.gauss-fic.udc.es/Members/moebius/tutoriales/inkscape/inkscape-sl… And «kudos to the author»: Adrián Perez de Castro If an english translation is needed I'll be glad to provide one. Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 4

Re: [Inkscape-user] Inkscape Release 0.40 Now Available
by bulia byak 30 Nov '04

30 Nov '04

> > As soon as it's up, I'll post an announcement on deviantart (as a > > majority of users on their site are Win32 based)... I just uploaded the exe installer made by Sim. Please download and test: https://sourceforge.net/project/showfiles.php?group_id=93438

2 1

Wiki again
by Arpad Biro 30 Nov '04

30 Nov '04

Hi, Yet another spammer wants to be banned from the Wiki. See the recent changes for details (if you're strong enough for this kind of stuff). Arpad Biro __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

10 22

Announcing Inkscape 0.40 Release
by Bryce Harrington 30 Nov '04

30 Nov '04

= Inkscape 0.40 = 'Draw Freely' http://www.inkscape.org/ The Inkscape community is proud to announce the release 0.40 of Inkscape, "A Cross-platform Open Source Vector Graphics (SVG) Drawing Tool." This release includes three majorly requested new capabilities: Layers, Text-on-Path, and Bitmap tracing. In addition, there are many minor features, a number of usability enhancements, three new tutorials, and hundreds of bug fixes. This is by far the most feature-packed release the project has had. This is all due to the strong developers that have contributed countless hours on Inkscape 0.40. Following our last release four months ago, we have focused intensively on development, adding several new dependencies such as the Boehm garbage collector and the stable Gtk 2.4 libraries. Because of this, user's may encounter more trouble getting Inkscape installed on some platforms than in previous releases. To help those who run into this issue, we're also providing 'Static Binary' packages that include these new libraries inside the package, and thus, the static releases are very large. Download your packages: http://sourceforge.net/project/showfiles.php?group_id=93438 For many more details, see the Release Notes for 0.40: http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes040 Community submitted screenshots: http://www.inkscape.org/screenshots/

3 2

XMLifying of tutorials
by bulia byak 30 Nov '04

30 Nov '04

As you know, currently tutorials are written directly in SVG. This, among other things, prevents proper automated i18n - if a section changes, a translator will have to manually figure out what changed, manually find the matching text in his translation, and manually change it. Also, producing the tutorials in formats other than SVG is also pretty much manual work. In other words, it looks nice but is a nightmare to maintain. Our attempts to change that ran into difficulties: a script or stylesheet which might generate an SVG tutorial would have to combine text (from some source file, e.g. Docbook) with illustrations (from separate SVG files). To do so, it would need to know the dimensions of the pieces of texts and the illustrations, because everything in SVG is absolutely-positioned. And that was the problem. Now I got an idea: Why not use Inkscape itself for this? Here's how it might work: 1 Add a couple new command line switches to Inkscape that would force it to load the document, find the object with the specified id, and report on the command line the width or height of that object's bbox, then quit. 2 Write an XSLT stylesheet that, for each piece of text, would write a temporary SVG file with it (in flowtext, same as the finished tutorials would use), run Inkscape with these command line switches to figure out its dimensions, and then use these numbers to position it in the final SVG files it produces. Same thing is done with illustrations, except that no temporary files are needed - they are stored separately (and referenced from the master XML source) anyway. If this sounds like a mess, it's not. I've done XSLT running external processes before. It works, and it is even portable (though portability may depend on the processor you use). It will be rather slow but in our case it does not matter much, I guess. So, unless someone invents something still better, I can do 1 above (it will be useful for other things, too), and someone will need to do 2 (with my help if needed). Perhaps 2 can also be done in another language, but I vote for XSLT - it's a very nice and powerful language for XML processing, definitely worth learning.

3 4

Spiral bug
by Gazal, Geraud (GE Healthcare) 29 Nov '04

29 Nov '04

Hi, playing with the 29nov04 build on win2k, I got a very bad bug with spiral Here is the way to reproduce it : Start inkscape Draw a spiral, then set its divergence to 0.00 Select the spiral, and switch to node or spiral tool Try to modify the spiral with the mouse (inner or outer handle) -> crash with an error pop up : **Error**: file sp-spiral.cpp line 446 (NR::sp_spiral_get_xy(const SPSpiral*, gdouble)): assertion failed: (t>=0.0) aborting... I don't think it has been reported yet. By the way, I'm wondering about the toolbar: being in node tool, when selecting a shape (spiral, ellipse, rectangle, star), it displays node commands, that are not applicable to shapes. would it be possible to have it switch to the appropriate toolbar ? (example : selecting a rectangle -> rectangle tools, then selecting a path -> node tools, ...) Shall I submit a RFE for this ? Regards, Matiphas

7 7

End of freeze - back to regular development
by Bryce Harrington 29 Nov '04

29 Nov '04

With 0.40 tagged and branched, it's safe to go back into the water. Regular development can resume now. Thanks to everyone who worked at putting out this release, it is going smoothly, and we don't expect any issues. Presently the focus is on packaging, distributing, and PR. Going forward, the plan is to take a good long break for the month of December. If you're worn out from Inkscape development, please disappear and rejoin us when your batteries are recharged! If you're itching to do some coding, scratch away. I'm going to be working on the Gtkmmification stuff, and would welcome anyone wishing to join in on this; the code is in the experimental CVS module currently, and it'll be integrated into the main codebase in the coming weeks. (Note: Since we added several dependencies in the 0.40 release, it would probably be wise to hold off a bit on adding new ones until we see how these do. If you need to add a new dependency, please get a concensus with the other developers before doing so.) Bryce

1 0

Static builds (again)
by Kees Cook 29 Nov '04

29 Nov '04

Okay. We can take two approaches to the static linux compile: 1- requiring gtk 2.4 already be installed 2- requiring pango 1.0 already be installed Pango does not appear to allow itself to operate as a statically compiled library. As a result, it's use of glib creates dynamic lib deps. I'm going to try to solve that, but it will still require pango dynamic libs. I was shooting for only requiring pango, but this is getting harder and harder. My test-case is a redhat 9 box, and it really doesn't like me: /tmp/inkscape.strip: relocation error: /tmp/inkscape.strip: undefined symbol: g_type_class_add_private So, I'm going to continue working on pango, but I think we can make an operational "static" build that requires gtk 2.4, since that's the bulk of the static lib work I've been trying to make work. Getting gtkmm hasn't been very hard. libgc has some tricks up it's sleeve, but I think I solved those. I'm building an RPM now that basically requires gtk 2.4, but is actually my latest attempt at approach #2. I need someone with an RPM-based distro with gtk 2.4 to test it. All I have is gtk 2.0 on rh9. -- Kees Cook @outflux.net

2 1

Inkscape Release 0.40 Now Available
by Bryce Harrington 29 Nov '04

29 Nov '04

The official 0.40 tarball is now posted, and is available for download here: http://sourceforge.net/project/showfiles.php?group_id=93438 The Release Notes describing the changes are available here: http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes At this time we are requesting all packagers to create and post packages for the release. Formal announcements for the release will be delayed until Monday evening in order to give a little time for packages to be created and tested. We are also encouraging everyone to assist with the PR push to get word out about this release. If you're interested in writing an article on a topic related to Inkscape, this would be an excellent time to do so. Bryce

3 2

SVG version?
by MenTaLguY 29 Nov '04

29 Nov '04

While I'm thinking about it, what SVG version should we indicate in our output? If we are including SVG 1.2 features like the flow text stuff, don't we almost have to bump the version number to 1.2? -mental

6 17

Hard Freeze
by Bryce Harrington 28 Nov '04

28 Nov '04

We've held off on going into hard freeze for a few days, due to several troublesome bugs. However, I'd like to propose that we move ahead with the hard freeze. It's impossible to release a bug-free product. It's understandable and commendable that we hold such a high set of standards for bug-free-ness, but the fact is, we'll have more releases in the future, and we'll _always_ have "one more thing to do..." If for some people, 0.40 won't run, they can stick with 0.39, or wait for 0.41. We've done a large amount of research into the bugs that exist; we can provide a good, detailed 'known issue' list. Heck, maybe this'll give some others inspiration and a headstart on figuring those problems out in the coming weeks. 0.40 has been one of the most energy-intensive releases that Inkscape's done so far. We've integrated a number of new dependencies, added scores of new features, and fixed hundreds of bugs. I would bet folks are getting worn out! With Christmas coming up, we ought to get the release behind us, so folks can enjoy the time off without worrying about Inkscape issues. This is a great release and I think the community's going to really enjoy it. As far as the remaining bugs go, here are some thoughts. The infamous Windows open file and freeze error is the worst remaining bug, however the current working hypothesis is that it's an issue with libgc. It is entirely conceivable that the fix would go against libgc, not inkscape, so may be entirely orthogonal to our release. However, if indeed it is an inkscape problem, it is an intermittent bug, and doesn't occur on every Windows user's box. As well, the use case for it is on file open, rather than save or during work, so the chance of data loss is small. I think we could simply document the problem and ensure users are aware of it, and provide workarounds/solutions later as we find them. The 'windows gets stuck in loop' error is a similarly annoying problem, and does involve data loss. However, it sounds like it is even less reproduceable than the previous one. The other level 9 bugs do not sound very serious to me. Most appear to be issues for a particular user running on a specific configuration (e.g., with Japanese language encodings, or installing with the autopackage snapshot, or when compiled with a particular version of gcc, etc.) All of these need fixing, but I don't think they're critical enough to warrant delaying the release. I suggest we write the hypotheses for each level-9 bug, list them as 'known issues' in the release notes, and move forward with the hard freeze today. Bulia, Mental, Kees, Peter, Jon Cruz, Ishmal, Simarilius, and Ted, how do you feel about moving forward with the release at this time? Bryce

2 2

Updated Norwegian Nynorsk translation of Inkscape
by Karl Ove Hufthammer 28 Nov '04

28 Nov '04

Here's an updated Norwegian Nynorsk translation of Inkscape. Please commit it to CVS. Hope I'm not to late for 0.40! :) -- Regards, Karl Ove Hufthammer

2 1

Fwd: [Inkscape-devel] Graphics-by banner
by Ana Saiz García 28 Nov '04

28 Nov '04

I'm very proud to see it in your homepage :o) Only a remark, my first surname isn't García, but Saiz (you know, I'm spanish, so I have two surnames :o)) I'm glad you liked it, thanks for all Ana On Sun, 28 Nov 2004 12:57:03 +0100, Ana Saiz García <anasaiz@...400...> wrote: > thanks to you :o) > > On Sat, 27 Nov 2004 22:59:53 -0800 (PST), Bryce Harrington > > > <bryce@...260...> wrote: > > Thanks Ana, I've added it to our homepage, and stuck them in our images > > directory. :-) > > > > Bryce > > > > > > > > On Sun, 28 Nov 2004, [ISO-8859-1] Ana Saiz García wrote: > > > > > Hi all > > > > > > I've been searching for the typical "graphics-by" banner to put it in > > > a web and let all people know I've used Inkscape to make some of the > > > graphics on the web, but i didn't manage to find anything. I don't > > > know whether there is already something like that, but I've done one > > > on my own and I wanted to share it with you in case somebody else want > > > to use it. > > > > > > I don't know if I can send attachments to this list, so I give you two > > > links from where you can download it. > > > > > > Here is the svg: > > > > > > http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg > > > > > > And here is the png, with a more appropiate size for a banner: > > > > > > http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.png > > > > > > Hope you like it :o) > > > > > > Ana > > > > > > > -- > "El más baldío de todos los días > es aquél en que no hemos reído" > (de Chamfort) > > http://www.cosasdedos.net > http://ana.cosasdedos.net > -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

1 0

Graphics-by banner
by Ana Saiz García 28 Nov '04

28 Nov '04

Hi all I've been searching for the typical "graphics-by" banner to put it in a web and let all people know I've used Inkscape to make some of the graphics on the web, but i didn't manage to find anything. I don't know whether there is already something like that, but I've done one on my own and I wanted to share it with you in case somebody else want to use it. I don't know if I can send attachments to this list, so I give you two links from where you can download it. Here is the svg: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg And here is the png, with a more appropiate size for a banner: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.png Hope you like it :o) Ana -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

2 1

Final release candidate for Inkscape 0.40
by Bryce Harrington 28 Nov '04

28 Nov '04

Hi All, Tonight we are entering the 'Hard Freeze', the very last phase before the final tagging and branching of 0.40, which is planned for tomorrow evening. Ted has created the final release candidate, 0.40pre5, which is now available from the website. Testing is essentially complete, however we're encouraging people to give the release a quick review. We're looking for silly mistakes like forgetting to update the version number, packaging problems, and major show-stopper bugs. But also add anything else you find to the bug tracker, and we can sort those issues out during the next development cycle. During this Hard Freeze phase, we're going to let the dust settle a bit, do a once-over, and then proceed with packaging and delivering the release. As with all prior releases, once it's cut we need to switch into marketing mode, in order to get the word out. This is where Inkscape users can make a big contribution. We want to get word out on all the major blogs, articles into relevant online magazines, and word of mouth to friends and family. Stay tuned. :-) Bryce

1 0

problems with sf cvs
by Adib Taraben 27 Nov '04

27 Nov '04

Hi, I am having following problems since yesterday: cvs -d :pserver:anonymous@...54...:/cvsroot/inkscape login Logging in to :pserver:anonymous@...54...:2401:/cvsroot/inkscape cvs [login aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused) ***** CVS exited normally with code 1 ***** I cannot connect to the cvs . Any hints, MANY THANKS; Adib.

3 3

Hard Freeze 11/26 ?
by Bryce Harrington 27 Nov '04

27 Nov '04

Hi all, Is anything remaining to be done, or are we ok to move into hard freeze tomorrow? If so, perhaps we can target having 0.40 tagged and branched by Friday evening? Bryce

8 16

new about screen modification
by Andy Fitzsimon 27 Nov '04

27 Nov '04

I'm not sure if this is better than the current about screen in CVS but i'll let Bulia decide.

1 0

test - ignore
by Kees Cook 26 Nov '04

26 Nov '04

Sorry, please ignore. Sourceforge has been acting up for me... -- Kees Cook @outflux.net

1 0

[Fwd: SourceForge.net Sitewide Update: Nov 23, 2004]
by Jon Phillips 26 Nov '04

26 Nov '04

We made Number 21 for the month on sourceforge!!! > 21. Inkscape > https://sourceforge.net/projects/inkscape > A Linux and Windows vector graphics editor (SVG format) featuring > transparency, gradients, node editing, pattern fills, PNG export, and > more. Aiming for capabilities similar to Illustrator, CorelDraw, Visio, > etc. Jon -- Jon Phillips (NEW) USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

Updated spanish po
by Lucas Vieites 26 Nov '04

26 Nov '04

Justo to have the max of strings translated before hard freeze, here's an update to the spanish po ;-) Cheers -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

2 1

Re: [Inkscape-devel] w32: Gtk24.zip with new xml.dll
by Jasper van de Gronde 26 Nov '04

26 Nov '04

Ted Gould wrote: > Well, that wouldn't be a bad thing, but the reason that svgz was done > this way in the first place was to test the scripting stuff. It seems > to have done that, and proven there is a problem on Win32. I'd like to > fix the problems with the scripting stuff on Win32 also... I think that > is also a 0.41 issue though. I'd say the following note from MSDN explains it all: --------------- Note The _popen function returns an invalid file handle, if used in a Windows program, that will cause the program to hang indefinitely. _popen works properly in a Console application. To create a Windows application that redirects input and output, read the section "Creating a Child Process with Redirected Input and Output" in the Win32 SDK. --------------- If you're interested in some code that does work with Win32 I'd be happy to provide it (I have some code lying around that would only need minimal changes).

1 0

Inkscape does not save to A:\ drive
by vellum 26 Nov '04

26 Nov '04

Inkscape build 041124 win32 2000 does not save to A:\. (31/2 " floppy). The dialog has PCINTERNET2 as the drive name. When you try and save to that drive you get an error message saying 'Could not mount PCINTERNET2 (A:\): This file system does not support mounting'. vellum kaver@...68...

1 0

RE: What do you _really_ want? [was RE: [Inkscape-devel] SVG Linking]
by NAGY Endre 26 Nov '04

26 Nov '04

Alan >and want to be able to add arbitrary name value pairs to >objects rather than using any namespaces in particularly? No. I have an XML Schema that conforms to "Topic 5 : Features" of the OPenGIS Abstract Specification. That is, it contains elements that are "geographic" (for which Inkscape provides a very convenient means of maintenance) as well as other domain-specific attributes that are associated with these geographies. These are ussually simple string types. When I proposed the capability of providing a form of name-value-pair maintenance capability I was envisaging a simple means of maintaining these attributes (in the hope of the availability of an imminent solution). If such capability were thought to be appropriate then of course the mechnism by which this would be achieved would be up to the Inkscape community. I have no intent in providing users with the ability to define arbitrary name-value pairs. >Why do I get the sneaking suspicion that you are using Inkscape for >diagramming >Inkscape is a vector graphics editor >Dia is for Diagrams http://gnome.org/projects/dia/ Rather than being concerned with identifying the (presumably mutually exclusive) domain of descriptive terms, I would prefer to deal with the more practical issue of which tool is most suited to my applications development problem. A brief examination of the capabilities of DIA indicated that it follows an "Object-Connector" paradigm. This does not suit my purpose of manipulating geographic entities. These are arranged and transformed spatially in a multitude of ways according to the desires of a user. I've been able to demonstrate the rich capabilities of Inkscape in achieving these spatial operations. I've not seen anything in DIA that comes close. The question is "will Inkscape support the maintenance of domain-specific attributes associted with geometries(while admitting that such capabilities may be rudimentary), or will shapes only ever be shapes" Regards Endre -----Original Message----- From: Alan Horkan [mailto:horkana@...44...] Sent: Wednesday, 24 November 2004 3:43 AM To: NAGY Endre Cc: Inkscape is a vector graphics editor Subject: What do you _really_ want? [was RE: [Inkscape-devel] SVG Linking] On Tue, 23 Nov 2004, NAGY Endre wrote: > Date: Tue, 23 Nov 2004 14:40:05 +1100 > From: NAGY Endre <Endre_NAGY@...561...> > To: bulia byak <buliabyak@...400...> > Cc: inkscape-devel(a)lists.sourceforge.net > Subject: RE: [Inkscape-devel] SVG Linking > > Bulia > > Thanks for responding > > I take your point about distinguishing "editing" from "viewing". I was > ignorant of the existance of inkview. > > To quote my original mail > >My purposes are not the rendering of HTML but rather the invocation of > >a program. Does inkscape support this and how. > My original post was grasping at a solution for my posted Feature > Request "1070754 - Maintaining Attributes in Users Namespace". In > essence, the request was for some capability that allowed for the > maintenance of the attributes of a shape that are defined in the > namespace of the user (e.g if a line represented a road then I would > like to define the name of that road). Why do I get the sneaking suspicion that you are using Inkscape for diagramming and want to be able to add arbitrary name value pairs to objects rather than using any namespaces in particularly? HTML was very clever in simple the way it did meta data tags, basically it provided a single tag and two attributes and from there users could create as many of their own name (Author) value (authorname) pairs as they would like by specifying new values for content and name everytime. <meta content="Author" name="authorname"> <meta content="desc" name="description"> (Dia users have been asking for the ability to tag objects with all kinds of information for ever and that has only confirmed my belief in the need for a meta data system that would be simple and extensible at the user level rather than requiring an extended predefined schema). You can see OpenOffice.org offers a similar ability to have an unending set of name value pairs http://books.evc-cit.info/ch02.php#meta-xml-section this screenshot shows it reasonably well the numbered labels are the names and the text entries are the corresponding values, and the popup shows they are arbitrary pairs. http://books.evc-cit.info/figures/ooo.ess.0203.png Let me use this opportunity to say that I hope parts of the Oasis standardized namespaces could be reused by Inkscape rather than creating more things in the inkscape: namespace. I hope to do more reading soon and recommend what custom tags and markup that it migth make sense to drop in favour of an open and standardised namespace shared by a variety of other applications. > From the perspective of the users of the application that I'm > developing, this activity is part of the process of "svg creation" not > of "svg use" (by which I mean, analogously, "editing" not "viewing"). Even if my guessing is way off a better less evasive description of what you are actually trying to do, the specific end result you are trying to achieve will better enable the developers to help you than specific example problems. If you are really lucky it might even allow them to indirectly help you by doing things they were planning on doing anyway at some point. > Any thoughts ? > > Endre Sincerely Alan Horkan Free SVG Clip Art http://OpenClipArt.org Dia is for Diagrams http://gnome.org/projects/dia/ Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

3 3

layer selector upate problem solve d
by MenTaLguY 26 Nov '04

26 Nov '04

Okay, finally nailed it down. It seems that sigc++ doesn't deal with reference parameters totally graciously; it was creating a copy of an SPObject & argument somewhere internally, causing equivalency tests further in to fail. Actually this would have been caught a long time ago if SPObject had been given a private copy constructor (or at least not left with an implicit public one). Rule of thumb with C++: if it's not a value class [a class in which binary copies of objects are interchangable], give it a private copy constructor like so: class Foo { public: Foo(); ... private: Foo(Foo const &); // no copy }; You needn't actually define the copy constructor once you've declared it, as in this case it shouldn't be used. If you don't do this, C++ will add a copy constructor for you that just does a binary copy, and all kinds of happy bugs like the one I just fixed can sneap up on youl. In rare cases where you do need to give such classes real copy constructorsm, make sure that they're either explicit, or not public. -mental

4 4