- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Re: [Inkscape-user] 0.40pre2
by Tuukka Pasanen 09 Nov '04

09 Nov '04

> However, going forward I think it may be more necessary to split out > separate spec files, especially if packagers take advantage of > distro-specific features/macros, and doubly especially as distro vendors > start providing the spec files. If this is done, though, it would be > helpful to put these into a subdirectory. I.e.: I agree on this.. There should be also LSB compliant version of inkscape for those upcoming tZilionZ LSB compliant distros.. > inkscape/ > packaging/ > debian/ > gentoo/ > fink/ > mandrake/ > inkscape.spec > suse/ > inkscape.spec > windows/ I think this should look like: inkscape/ packaging/ linux/ debian/ mandrake/ suse/ gentoo/ lsb/ windows/ macosx fink So it would be more informative (For stupid people like me:P) Tuukka

1 0

New calligraphic icon
by Andreas Nilsson 09 Nov '04

09 Nov '04

With the recent update on the calligraphic tool I thought it might need a new icon. http://ramnet.se/~nisse/diverse/temp/calligraphicpen.svg - Andreas

4 4

Re: [Inkscape-user] 0.40pre2
by Bryce Harrington 09 Nov '04

09 Nov '04

The main reason there are not spec files for every distribution is that the spec file included has tended to work on most rpm systems with minor changes only, so there hasn't been a strong need to maintain separate spec files. This has been a bit of an advantage in that we were able to combine efforts on maintaining and improving the spec file. However, going forward I think it may be more necessary to split out separate spec files, especially if packagers take advantage of distro-specific features/macros, and doubly especially as distro vendors start providing the spec files. If this is done, though, it would be helpful to put these into a subdirectory. I.e.: inkscape/ packaging/ debian/ gentoo/ fink/ mandrake/ inkscape.spec suse/ inkscape.spec windows/ Bryce On Tue, 9 Nov 2004, Tuukka Pasanen wrote: > Hi, > How one can become a packager and why there isn't spec files for every > distribution available? > > Tuukka > > > > > With more layers functionality, additional bug fixes, calligraphy tool > > improvements and more the 0.40 release is starting to shape up. This > > has prompted the 0.40pre2 release to be created. Please take a look at > > this release and help us find more bugs! If they're not found, they > > can't be fixed. > > > > http://sourceforge.net/project/showfiles.php?group_id=93438&

1 0

performance under win2k
by Gazal, Geraud (GE Healthcare) 09 Nov '04

09 Nov '04

Hi, I don't know if some of you have noticed this, but it looks like the last builds (at least yesterday and today) of Inkscape have become slower under win2k (PII, 1GHz, 512Mo RAM): Examples : * start application, draw a rectangle and click on Fill and Stroke Dialog -> the dialog appears after more than 1sec. * start application, select text tool, type a few chars ("toto") -> the text is only rendered after 15 seconds ! * same problem with import of bitmaps (already notified in the bug tracker) Regards, Matiphas

2 1

[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