November 2004 - Inkscape Devel

[Q_AT_ping_dot_be: Bug#279991: inkscape: FTBFS: error: reinterpret_cast from `void*' to `int' loses precision]
by Wolfram Quester 09 Nov '04

09 Nov '04

Hi, I just received this bug report about (not) building inkscape in Debian's BTS. With best regards, Wolfi ----- Forwarded message from Kurt Roeckx <Q_AT_ping_dot_be ----- X-Original-To: wolfi@...33... X-Original-To: wolfi@...111... Subject: Bug#279991: inkscape: FTBFS: error: reinterpret_cast from `void*' to `int' loses precision Reply-To: Kurt Roeckx <Q_AT_ping_dot_be, 279991@...499... Resent-From: Kurt Roeckx <Q_AT_ping_dot_be Original-Sender: Q@...560... Resent-To: debian-bugs-dist@...501... Resent-Cc: Wolfram Quester <wolfi@...111...> Resent-Date: Sat, 06 Nov 2004 15:03:01 UTC Resent-Message-ID: <handler.279991.B.109975247611270@...499...> X-Debian-PR-Message: report 279991 X-Debian-PR-Package: inkscape X-Debian-PR-Keywords: Date: Sat, 6 Nov 2004 15:47:55 +0100 From: Kurt Roeckx <Q_AT_ping_dot_be To: submit@...499... Resent-Sender: Debian BTS <debbugs@...499...> X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de Package: inkscape Version: 0.39+0.40pre1-1 Severity: serious The package is failing to build on all 64 bit arches (alpha, ia64, amd64) with the following error: In file included from selection.h:25, from arc-context.cpp:30: gc-finalized.h: In static member function `static Inkscape::GC::Finalized* Inkscape::GC::Finalized::_unoffset(void*, void*)': gc-finalized.h:66: error: reinterpret_cast from `void*' to `int' loses precision arc-context.cpp: In function `void shape_event_attr_changed(SPRepr*, const gchar*, const gchar*, const gchar*, bool, void*)': arc-context.cpp:148: warning: unused parameter `SPRepr*repr' arc-context.cpp:148: warning: unused parameter `const gchar*name' arc-context.cpp:148: warning: unused parameter `const gchar*old_value' arc-context.cpp:148: warning: unused parameter `const gchar*new_value' arc-context.cpp:148: warning: unused parameter `bool is_interactive' make[3]: *** [arc-context.o] Error 1 Casting a void * to an int is probably a very bad thing to do. A void * is 64 bit on those arches while an int is 32 bit. Kurt ----- End forwarded message -----

2 4

Some suggestions for the export dialog
by Andreas Nilsson 09 Nov '04

09 Nov '04

Hello there! Im new to this list, but have been a user of inkscape since the beginning of the project. I use it on a regular basis, mostly for drawing icons and I therefore use the export function a lot. What I really miss for the export dialog is the ability to see what the final .png will look like, and that is expecally important when the output file must be very small. I usually end up checking the icon out in gThumb and then go back to Inkscape, tweaking the icon a bit and then export it again, and again, and again... Another thing that bothers me a bit is that is a bit hard to see what kind of export area that is choosed, and I think that maybe a bunch of radiobuttons is easier to see. I did a quick mockup on what it all could look like here: http://ramnet.se/~nisse/diverse/temp/inkscape_export_mockup.png I understand that everyone is busy with the release of 0.40, but perhaps this could be nice further down the road. - Andreas

3 2

layer functions - naming confusion
by Adib Taraben 08 Nov '04

08 Nov '04

Hi, I am a little bit confused when I want to use the layer functions. Once objects and layers are moved vertically in the Z-order "up-" and "downwards". But then I can move objects to "next" and "previous" layer. :-O Is next the lower or higher layer ? For me it makes more sense to call this functions also "move to lower" or "higher layer". This is my opinion. Thanks, Adib.

2 1

does "remove kerning" works ?
by Adib Taraben 08 Nov '04

08 Nov '04

Hi, testing the translation I found this nice feature for myself. But it does not work with my family name "Taraben" and the default font"Bitstream Vera Sans". Inkscape->Text->Remove Kerns Is this a feature or a bug? HTH, Adib.

4 5

UI annoyance with current CVS
by Arpad Biro 08 Nov '04

08 Nov '04

Hi, "Inkscape 0.40cvs (Nov 7 2004)": 1. launch Inkscape 2. activate the calligraphy tool 3. click on the canvas 4. click on a menu item or an icon At this point, Inkscape denies access to those interface items. Let me know if you cannot reproduce it. Arpad Biro __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

3 5

Glue : SVG Support ? Inkscape Sypport ?
by NAGY Endre 07 Nov '04

07 Nov '04

Greetings I sent the message, asking about Inkscapes capabilities regarding gluing, that is attached to the bottom of this mail, to the Inkscape-User mailing list. Bulia responded >Peter Moulder works on this and has some code checked in (though >there's no GUI yet). If you can help push this ahead it would be >great. Perhaps inkscape-devel is a better place for discussing this. Peter (or anybody else with knowledge), can you advise on how to implement "glue" Regards Endre Nagy ---------------------------------------------------- Greetings My goal is to implement in Inkscape the equivalent behaviour of "glue" as found in Visio. In Visio this is exhibited by creating two "lines" and then dragging the end point of one line to coincide with the end point of the other. The behaviour of these "lines" are defined such that when a "coincidence" event occurs the end points are "glued", ie a transformation of one of the lines (e.g a translation) causes the end point of the other line to continue to coincide with the position of the other end point (i.e the end of one line "follows" the position of the other). It would be nice if, within Inkscape, I could specify such behaviour, but its absence would not be fatal because I have other means of specifying the content of the SVG that would be input to Inkscape. Firstly, are there any elements within the SVG specification that would naturally allow this behaviour to be defined?. Unfortunately I am not in a position to specify the glued coordinate as one that is part in a single polyline. I am constrained by a requirement that this behaviour be exhibited between two distinct geometric elements. I initially had in mind providing an identifier for one of the points in one polyline. I could then define a point in the other polyline as a reference to this identifier. But I dont think SVG's element and attribute structure allows this. Secondly, if the SVG specification supported such a semantic, would Inkscape reflect this in its behaviour. That is, if (to take one possible solution) one point were defined as a reference to the other, would Inkscape know to update all points that were defined by reference. Thanks in advance for any assistance Endre Nagy 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

cmyk fill
by David Christian Berg 07 Nov '04

07 Nov '04

Hmm, I didn't even know it existed, but look at this. Some might now, it's there. Anyways, it's causing trouble, cause I can't change the color of the objects this being in place. sodipodi:fill-cmyk="(0.80000001 0.44999999 0.0000000 0.25000000)" David

2 1

win32 svgz not open problem
by Adib Taraben 07 Nov '04

07 Nov '04

Hi, is it eventually possible that the libxml-dll in the gtk libraries provided are not compiled with the -D HAVE_ZLIB_H ? And so that there is no support for compressed files ? Just thinking ( I did not found any string "zlib" in the libxml.dll but in freetype.dll) . Adib.

2 1

Ruby Cairo bindings
by MenTaLguY 07 Nov '04

07 Nov '04

Just for fun tonight I wrote a Ruby binding for Cairo, so I can learn my way around it more. If anyone's morbidly curious, it's in CVS under mental/cairo-testbed in the experimental module. More details: The Ruby extension is in the cairo/ subdirectory; the cairo-testbed directory proper will contain some scripts and things that use it (right now it just contains a simple demo script, demo-0.rb, that generates a PNG). To build the extension, just run: ruby extconf.rb make The binding is moderately complete at this point; the only two areas I've not really covered yet are fonts and patterns, and I need to expose more surface types (currently only in-memory and PNG output surfaces are exposed). In terms of the major classes at this point: * Cairo - a cairo graphics context * Cairo::Surface - a cairo drawing surface * Cairo::Transform - AKA Cairo::Matrix, a matrix representing an affine transformation In general the way things work are that you create a cairo context, set a target surface for it to draw on, and draw away, calling show_page when you're done. require 'cairo' File.open("foo.png", "wb") {|port| ctx = Cairo.new ctx.target_surface = \ Cairo::Surface.new_png(port, Cairo::FORMAT_ARGB32, 200, 200) # fill in the background ctx.new_path ctx.rectangle(0, 0, 200, 200) ctx.set_rgb_color(1.0, 1.0, 1.0) # white ctx.fill # draw a big X ctx.new_path ctx.move_to(20, 20) ctx.line_to(180, 180) ctx.move_to(20, 180) ctx.line_to(180, 20) ctx.set_rgb_color(0.0, 0.0, 0.0) # black ctx.line_width = 5 ctx.line_cap = Cairo::LINE_CAP_ROUND ctx.stroke ctx.show_page # write the PNG } -mental

1 0

Re: [Inkscape-user] Feedback 0.40pre1
by MenTaLguY 07 Nov '04

07 Nov '04

On Sat, 2004-11-06 at 20:01, bulia byak wrote: > > - Like 0.39, very large paths (4000 nodes) are very slow, especially during > > zoom and when I go into node-edit-mode (inkscape spends a lot of time drawing > > stuff that's off-screen). > > Yes it's a problem. We need to do more optimization in one of the > future versions. I have some specific ideas for algorithms to reduce the repainting burden. I'll try to document them sometime soon. Strictly speaking, when performing individual node edits it should only be necessary to redraw maybe four path segments at most. -mental

1 0