- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Create Plug-In for Flow-Chart drawing
by Mirko Marschew 11 Dec '08

11 Dec '08

2 1

10 Dec '08

Hi all, I am having the following problem during compilation of version 20346 (the lastest as of now): extension/internal/cairo-ps-out.cpp: In member function 'virtual void Inkscape::Extension::Internal::CairoPsOutput::save(Inkscape::Extension::Output*, SPDocument*, const gchar*)': extension/internal/cairo-ps-out.cpp:137: error: 'CAIRO_PS_LEVEL_2' was not declared in this scope extension/internal/cairo-ps-out.cpp:141: error: 'CAIRO_PS_LEVEL_3' was not declared in this scope extension/internal/cairo-ps-out.cpp: In member function 'virtual void Inkscape::Extension::Internal::CairoEpsOutput::save(Inkscape::Extension::Output*, SPDocument*, const gchar*)': extension/internal/cairo-ps-out.cpp:201: error: 'CAIRO_PS_LEVEL_2' was not declared in this scope extension/internal/cairo-ps-out.cpp:205: error: 'CAIRO_PS_LEVEL_3' was not declared in this scope make[2]: *** [extension/internal/cairo-ps-out.o] Error 1 make[2]: Leaving directory `/home/rmagno/Downloads/inkscape-20346/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rmagno/Downloads/inkscape-20346' make: *** [all] Error 2 best, Ramiro.

1 0

Parsing a command line to argc/argv
by Krzysztof Kosiński 10 Dec '08

10 Dec '08

I'm getting back to work on the GIO transition. The first thing that must change in order to move to GIO is the parameter parsing (to open files it's best to use Gio::File::create_for_commandline_arg, and for this filenames in filename encoding are needed). However, this will interfere with the shell mode. I don't think this is an useful feature - an embedded scripting language would be a lot better - but probably there's someone who relies on it, so it should be preserved until there's a replacement. I would like to reuse the option parser from the main application, but then I have to parse the command line into argc and argv myself, because that's what g_option_context_parse accepts. Does anyone know whether there's an "officially blessed" way of parsing a command line into argc and argv? Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Parsing-a-command-line-to-argc-argv-tp20874473p208744… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 11

"make check" doesn't run unit tests
by Krzysztof Kosiński 09 Dec '08

09 Dec '08

This wiki page: http://www.inkscape.org/wiki/index.php/TestingInkscape says that "make check" runs the unit tests written in the CxxTest framework on Unix systems, but in fact it doesn't. The only tests which are actually run are the ones using the old homegrown utest framework residing in src/utest. I'm no expert on Inkscape's build process so I'm not sure how to fix this. Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/%22make-check%22-doesn%27t-run-unit-tests-tp20876856p… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 15

Bug in SVN with certain HID devices
by Omar Chanouha 09 Dec '08

09 Dec '08

Hello Everyone, I did an SVN yesterday and after compiling I got this error: ERROR:preferences.cpp:488:Inkscape::XML::Node* Inkscape::Preferences::_getNode(const Glib::ustring&, bool): assertion failed: (pref_key.find('.') == Glib::ustring::npos) After further investigation, I realized that the pref_key my program was crashing on was that of my keyboard/mouse: Liteon Microsoft Wireless Reciever 700 v2*.*0 When I removed the assert from the code the program started properly. I believe the assert is checking to make sure that the first instance of a period is coming at the end of the pref_key, or that one does not exist? Either way, why are you checking for this? Why does it matter? Regards, Omar

2 1

Script to export image
by Alessandro Antonello 07 Dec '08

07 Dec '08

I have to thank all of you guys. You helped me a lot. Mr. Bulia Byak, Jamie Kimberley, John Bintz and others. You are all right. The Inkscape is a great software but not for what I was trying to do. The ideas that Kimberley and Bintz gave to me was perfect. ImageMagick was the right answer to my problem. I did this: - I exported the entire SVG to a single PNG file. That gave me a file with a bit more than 19MB. - I converted the PNG in a MPC file with ImageMagick, after a long and very careful reading of its documentation. This gave me a file almost 4GB long. - Then I made a batch script, much more simpler than the other one, to export all the 29,232 parts that I needed. Amaizing, it took less than 4 hours to export all parts. I loved ImageMagick and all its powerful. I already known it, but never occurs to me that it could do the job. Thank you again, guys. Alessandro Antonello

2 1

Script to export images
by Alessandro Antonello 06 Dec '08

06 Dec '08

Hi, All. I already wrote this question in the inkscape-user list but no one came to me with a good solution. My problem is that I have a SVG image too big. In fact is more than one. They are five SVG files with size of 20880 pixels width by 37800 pixels height. I have to export PNG files of slices that must have 180 pixels width by 150 pixels height. I know that I could do this creating an array of squares in a separate layer and, using the batch export, export every peace. The problem is that I need that every PNG file export must have an specific name. They must have the theis X and Y positon from where they come from in the original image. For example, if one PNG came from a peace at 0:0:180:150 it must be named "0x0.png". The peace that came from 180:150:360:300 must be named "180x150.png". I already made a batch file (I am using Windows XP with Inkscape 0.46) but it is too slow. I left it running almost 16 hours strait and it didn't finished the first file yet. There is someone that can help me with that? Is really important. Thanks a lot. Alessandro Antonello _________________________________________________________________ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack

5 6

Bug in W3C test suite?
by Jasper van de Gronde 05 Dec '08

05 Dec '08

Currently Inkscape renders the W3C Gaussian blur test (filters-gauss-01-b.svg) visibly different from the reference PNG provided by the W3C. However, from what I can tell it might not be Inkscape's problem... (Or is it?) This spreadsheet: http://home.hccnet.nl/th.v.d.gronde/filters-gauss-01-b.ods shows some graphs of data extracted from the reference PNG and Inkscape's output, as well as some artificially created data. The top and bottom graphs correspond to lines extracted at y=220 and y=320, and they show that Inkscape's output matches pretty well to the reference PNG. I've only included the green channel of the reference PNG, but the other channels match as well. The interesting bit is the green channel in the middle graph (corresponding to y=270). Legend: - the continuous green line is Inkscape's output - the dashed green line is the W3C reference PNG - the orange line is the result from alpha compositing the green channels from y=220 and y=320 (corresponding to only red and only yellow). - the brown line is the result of blurring a 45 pixels wide strectch of "red" roughly corresponding to the visible part of the red rectangle (only the green channel, so all 255 except for the "red" part, which is 0) As can be seen Inkscape's output matches almost perfectly with the artificially generated data, and it apparently doesn't matter much whether the filter is applied to each rectangle separately or to the combined image in this case (which is NOT the general case). I've applied for a bugzilla account at the W3C to file a bug, but in the mean time, did I make some mistake in analyzing this or is this really a bug in the W3C test? Also, what on earth could cause such a weird mismatch? And in an interesting twist, Batik gives more or less the same result as the W3C reference PNG. I've had a short look at their blur code, but without spending hours (if not days) to delve deep into their code I really can't tell what causes the difference in behaviour. BTW, the strange fluctuations in the left part of the bottom graph are due to text appearing the reference PNG (which has been removed from Inkscape's tests to make it easier to compare images automatically).

2 2

handling of bugfixes for particular cases
by Thomas Holder 03 Dec '08

03 Dec '08

Hi, I just fixed bug #190424 and #168777. These are about incorrect font size when creating text in a document, that has a viewBox attribute. My patch does not fix the lack of viewBox handling in general, but only for text tool. Actually Inkscape needs a proper generic implementation of viewBox handling I think, but this is probably a larger piece of work. I'd like to know how our policy is for such cases. Go for the easy fix now, and revert it once the proper general fix is done? Or postpone the whole issue until it is properly fixed? Thomas

3 3

Re: [Inkscape-devel] Create Plug-In for Flow-Chart drawing
by Mirko Marschew 02 Dec '08

02 Dec '08

3 2