March 2007 - Inkscape Devel - Inkscape Mailman

removing effects
by bulia byak 01 Apr '07

01 Apr '07

I plan to remove these two extension effects, please speak up if you disagree: svg_dropshadow: writtern in Perl for which we have no support infrastructure on Windows; is really primitive, more a proof of concept than a useful effect. I suggest that if anyone wants to have such an effect, it's easier to rewrite it in Python using inkex, with gaussian blur and clones (but better wait until we have more SVG filters supported, which will allow us to have black shadows regardless of the color of the object). Export groups as PNGs: seems to be redundant with the recent improvements in Export ("Batch export all selected objects") that do the same but in a more integrated and controllable fashion. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

svg->raster lib under php
by unknown＠example.com 31 Mar '07

31 Mar '07

Hello Inkscape developers! Great work :) I love svg & inkscape, and I'm currently playing with dynamically altering svgs (created with inkscape) under php. Now i am facing the problem of converting these svgs to raster graphics (png, jpg) using only php and gd on a web server. I googled but did not find any approach in this direction. There is a gd extension for creating svgs from gd commands, but not the other way round. Anyone know a possibility of doing this? If there really is no such library yet, I am ready to take a stab at it myself. Do you think porting some inkscape code to php (of course preserving the GNU license) is a manageabel and promising approach? I'd be grateful for any comments, links or reccomendations. Regards, Tobias P.S.: I have three reasons for wanting to convert from svg to raster before serving: Old browsers not supporting svg, dumb users not being able to handle them, and protecting original fully-scalable artwork.

6 7

Re: [Inkscape-devel] SoC 3D box tool - website updated
by Maximilian Albert 31 Mar '07

31 Mar '07

Thorsten Wilms schrieb: > But there should be planes/grids at least, too. Certainly. But that's candy for later when the core tool tool is thoroughly implemented, although it should of course be considered during the design phase. > If adding a box creates new VPs, you either need the ability > to 'snap' VPs together, or an additional way to create boxes using > exitsing VPs. Yep. That's the overall plan. > BTW, have a look at http://www.khulsey.com/demo_howto_car.html > I have to wonder if using a 3d app wouldn't be more efficient, but this > at least impressive and maybe inspiring :) Thanks for the link! This really looks like it can give suggestions. I'll study it in detail later. Max

5 9

Python extensions: making a package a dependency
by Justin Barca 31 Mar '07

31 Mar '07

So, for a while now I've been working on some abstractions in Python to help simplify and organize the generation of SVG vector graphics. Originally, I did this out of my own interest and need, but now I'm more interested in making this code a resource for educational and artistic purposes. I have recently made the code available on sourceforge under the title pLAySVG here : http://sourceforge.net/projects/play-svg/. Recently I created a handful of Inkscape extensions using this library and included them in the pLAySVG code base. These toys include extensions to - generate a hexagonal lattice - similarly, generate a "Flower of Life" lattice - generate a triangular grid - plot a Star Polygon (as described here: http://mathworld.wolfram.com/StarPolygon.html) - render an image of a fully connected graph, vertices arranged in a circle I would like to include them in the next version of Inkscape, but they depend on the playsvg package that I have created for my libraries. Currently the library installs itself using the typical distutils setup.py. So, I am wondering: should I include these extensions into the Inkscape code base ? If so, how can I add a dependency for a package and not a file ? Should the package be installed by the third party using distutils, or should it be included in inkscape/extensions/ ? Lastly, I'd like to get a feel for whether these playsvg libraries seem useful to any of you extension developers. I have a sense that the 2geom libraries have a lot more functionality and robustness to them, but I find them inaccessible, difficult to understand at the moment. I wonder if there is some way they can work together. Cheers, Justin

1 0

Re: [Inkscape-devel] How debug you under windows?
by Gail Banaszkiewicz 31 Mar '07

31 Mar '07

> Are there any way for debug inkscape under WinXP with > a IDE integrated debugger (e.g. DevC++, Code::Blocks, > Eclipse/CDT or MS Visual C++)? How debug you under > windows? Today I was working on getting set up for my SoC bug fixes, and I wanted to figure out the same thing. So far, Eclipse/CDT is looking promising. I can get it to build within in Eclipse, as well as run/debug. There is an error when the program starts in debug, but I continued and it seemed to start ok. Will be testing now whether debugging actually works. Using Eclipse requires a bit of massaging which I can hopefully help you figure out once I have it all working. Gail

4 12

Re: [Inkscape-devel] [Inkscape-user] Transparency using PSTricks
by Jasper van de Gronde 30 Mar '07

30 Mar '07

Adi Eyal wrote: > The PSTricks output is a tex file - and I know that PSTricks can do > transparency - at least they have some demos on their site with > transparency. Intrigued by this I had a look and indeed, it does support it. But it only works if you then convert the file to a PDF file (and apparently only through some special way too, but I haven't tried it myself, so I don't know whether that's necessary). Apparently the pstricks-add package is what does the trick, so if anyone wants to have a look at implementing some support for this, have a look: ftp://tug.ctan.org/pub/tex-archive/graphics/pstricks/contrib/pstricks-add/p…

2 1

3D box tool
by Dave & Ann Marie Barry 30 Mar '07

30 Mar '07

Hi All, I've spoken with Máirín Duffy about helping out with the 3D box tool listed in the google summer of code project list. I'm a full time engineer, and I'm sure I could handle the vector math work and support functions. However, I'm not a GUI/application programmer. What do you think? Dave Barry

2 1

Inkscape go-slow issues redux
by Donn 29 Mar '07

29 Mar '07

Inkscape Issues Date : Started this on 28 March 2007 Version : 0.45.1 self-compiled on Kubuntu Dapper (32 bit version) Machine : Brand new AMD 64x2, Gigabyte m/b, 1 gig DDR2 RAM, lots of drive space (old IDE drives), PCI-Express nvidia card of no particular specs. (My old machine literally went boom!) I reported this slowing-down on my last machine (an old AMD 1 ghz) on the inkscape-users list. I was very surprised to see the same thing on my new machine. I apt-get installed the build requirements (as per the Inkscape wiki) and compiled 0.45.1 to see if that would boost performance, it *was* much quicker but the slow-down still happens. Inkscape starts nice and fast. For example panning is very quick, even with a complex drawing. After a time, perhaps 20/30 minutes, the panning becomes choppy and then unusable. I find it quicker to zoom out and zoom-in to a new area than to pan across to it. After a time the GTK dialogs start to draw very slowly. I have noticed this on: 1. The fill/stroke dialog (particular culprit) 2. The Doc properties 3. The Global prefs 4. Export sub-dialogs like the 'confirm file replace' dialogue. 5. Now and then on the Font dialog After they begin to 'go slow' they quickly stop working at all. I often get blank forms (see attached -- assuming it does not get stripped.) BTW - This is the only GTK app that does this. Pan, Gimp, Tomboy, FontyPython, Firefox all work fine, if slowly. When I feel Inkscape slowing, I save and restart it. Inkscape can take up to 30 seconds to close. The entire machine is non-responsive during that time. Music playing usually stutters and while the mouse will move around, nothing can be clicked or dragged. Is there something I can do to help diagnose this? Can I compile with other flags (I am clueless about gcc/g++) in order to produce debug info or something? Or perhaps there is a trick to track memory useage to a logfile that I can post? Could this issue be a problem with the quality of the supporting libraries as released on Kubuntu Dapper? I have always thought GTK apps were easily half the speed of QT apps on Kubuntu Dapper (and before that Fedora Core 1 and 3). Please let me know what I can do to help, I am not well so I often fall off the net, but I thought I needed to let you know about my experiences. Donn.

7 34

Re: [Inkscape-devel] SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Thorsten Wilms schrieb: > You can't have a box without VPs and VPs are useless if there is no > box. Hmm, to me a perspective is essentially _defined_ by the position/arrangement of its VPs. It seems to me that we have different understandings of the term. What do you mean by perspective then? How would you add and modify perspectives without using VPs? Also, given my point of view I don't agree that VPs without a box are useless. Rather, they define a perspective, which you can use to draw boxes whose edges (or rather their prolongations) meet in the respective VPs, i.e. essentially to draw boxes _in the given perspective_, from a visual POV. Note that I use the term 'perspective' in a slightly broader sense than usual here, for it also covers arrangements like the one you entitled as 'impossible' (the second picture in the 'core' section on the website). Again, it's nothing else than a configuration of VPs. > Additionaly the VPs of a perspective share a horizon. Well, they certainly do. But I can't see why a horizon makes working with boxes cumbersome, especially since it's supposed to be only a kind of add-on to make things more convenient, but it's certainly not required for drawing boxes (and can probably be toggled to be off by default). I still think I'm misreading you here because I don't know your precise definition of a perspective. > Regarding adding a box by dragging, I'm a bit concerned about the > need for 3 drags in a row. It's only two, actually. ;) One drag for the "front" face, and one drag to add depth. > Simply adding a box with default size > would work around this (where the 'default' size should actually > take the zoom level into account). Hmm, but you don't need perspectives as separate modifiable objects to achieve that. Just add a button or a menu item or whatever to create such a box in the given configuration of VPs. > If any number of boxes can be tied to a 3-VP/horizon system, > I think this clearly establishes that there are separate entities. > The user can't form the right expectations if you try to cover this > up. True. We are definitely not going to cover it up. But I think it should remain to be seen how much _functionality_ for working with perspectives alone (without a box) we need to provide. Can't tell at the moment, tough. > Well, where I said 2 VPs, I actually meant 2 'finite' and one 'infinite', > as I have a hard time thinking of a point if I see parallel lines ;) Granted. I normally don't realize how much my studies of mathematics influence my thinking about these things. ;) > 'have to be' is maybe a bit hard, but say you have 3 boxes, all on the > same plane. 2 have parallel edges, the 3rd is rotated. The 2 share all > 3 VPs, but the 3rd only has the nadir in common with them. > For additional boxes, you could choose between 2 groups of VPs (or > create additional VPs). Ah, now I see what you mean. But which are the two groups? If I'm reading you correctly then you are suggesting to have one group of VPs for the two boxes with parallel edges, and a separate group for the third box, each of which you can choose for drawing new boxes. Is that right? But this is precisely the concept that I have in mind when talking about 'perspectives'. In my wording, a perspective is precisely such a group of three VPs (maybe some of them at infinity) which can be used to draw new boxes whose edges point in the directions of the VPs. So you could simply select one of the three boxes and define its 'perspective' as the default for the new box. Is this what you have in mind? Or did I get it completely wrong? Max

1 0

SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Hi all, for my official SoC application I have considerably updated the website describing my thoughts on the 3D box tool. It now includes some ideas for advanced features and future work (outside the scope of SoC itself). It is far from being complete, but anyone who is interested is warmly invited to have a look and make comments, praise it or goof on it. Here is the URL once again: http://www.rzuser.uni-heidelberg.de/~malbert/ In any case, I really hope that my application may be successful. Contributing to your great work would be a huge pleasure and honour for me. Thanks and cheers, Max

2 1