December 2006 - Inkscape Devel

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

inkscape git mirror?
by MenTaLguY 18 Jun '08

18 Jun '08

I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this. -mental

6 11

Status of inkboard feature
by Denis Leroy 23 Jan '07

23 Jan '07

What is the status of the inkboard feature ? Is it considered stable ? More importantly, is it considered safe (from a security standpoint) ? We had requests in Fedora to have the feature enabled and so am doing some testing on my side. It was originally turned off because it was pretty unstable and would often crash in the loudmouth library, but that was a while ago... thx! -denis

8 10

Postscript input extension and skencil
by Denis Leroy 11 Jan '07

11 Jan '07

Hi, The current PostScript input extensions are dependent on the skconvert utility (it uses pstoedit -f sk to produce sketch format), itself part of Skencil, a "competing" (? :-) ) vector drawing project. As the Fedora inkscape maintainer, this dependency is somewhat problematic. From a distribution/packaging perspective, it is difficult to justify a hard dependency between inkscape and skencil as skencil is itself another desktop application and also fairly large. It is also somewhat non-intuitive and confusing to the end-user (and as a side-note, skencil might be dropped eventually because it's still based on gtk1). Now, I would still like to have PostScript import work out of the box as that's a feature that was requested by several users. So my questions: why the skconvert dependency ? Are there any alternatives ? pstoedit has many output formats (such as plot-svg using GNU libplot), is it possible to use a different one to achieve the same result ? -denis

7 17

RFC: SVG filter transformations
by MenTaLguY 07 Jan '07

07 Jan '07

Well, it looks like Inkscape's behavior is non-compliant at the moment, but only under certain combinations of transformations (generally, rotation + non-uniform scaling). bulia and I have been discussing this, and since reworking filters will take a while, we think we have two options for this release: 1. leave the behavior as it is 2. disable filter rendering when the output would be non-compliant #1 has the advantage that the bug would be less noticeable (fewer user complaints until the next release when it's fixed), and it has the disadvantage that the bug would be less noticeable (people getting bitten when the rendering behavior changes in the next release). #2 has the advantage that it actively discourages people from using filters in situations where Inkscape can't currently render them properly. It has the disadvantage that it might actively discourage them from using filters. Which one should we go with? Other suggestions? -mental

5 15

Inkscape 0.45 About Screen Contest
by Joshua A. Andler 02 Jan '07

02 Jan '07

The contest begins today and the deadline is December 31st. As with the past few contests we've had, it is being done on DeviantART. You can find out more about it at: http://inkscapers.deviantart.com/journal/11071733/ Good Luck! -Josh

6 10

Re: [Inkscape-devel] Pattern along path crashes
by Michèle Garoche 31 Dec '06

31 Dec '06

Le 30 déc. 2006 à 09:54, Bryce Harrington a écrit : > On Sat, Dec 30, 2006 at 09:37:29AM +0100, Mich?le Garoche wrote: >> Sorry if this is not the right mailing list to ask, just thought that >> there is more chance to touch Mac OS X users here. >> >> I've tried the new pattern along path extension from svn on Mac OS >> X 10.4. >> >> It crashes reproducibly. >> >> Did anyone else try it on Mac successfully? Or is the crash >> confirmed? >> >> Note: I've just copied the extension directory onto the old one from >> 0.44 installation via fink, it worked for all other extensions, >> but it >> could make a difference for this one. > > Please doublecheck that there is a bug in our bug tracker about this. > Attach any example files where the issue occurs, along with steps to > reproduce it. I did not find any bug in the tracker, so I've created one: <http://sourceforge.net/tracker/index.php? func=detail&aid=1625230&group_id=93438&atid=604306> The examples are taken from the extension author's web site (url in the tracker). But it is the same for any group of images. Cheers, Michèle <http://micmacfr.homeunix.org>

1 0

Pattern along path crashes
by Michèle Garoche 30 Dec '06

30 Dec '06

Sorry if this is not the right mailing list to ask, just thought that there is more chance to touch Mac OS X users here. I've tried the new pattern along path extension from svn on Mac OS X 10.4. It crashes reproducibly. Did anyone else try it on Mac successfully? Or is the crash confirmed? Note: I've just copied the extension directory onto the old one from 0.44 installation via fink, it worked for all other extensions, but it could make a difference for this one.

2 1

saving in windows friendly format
by tj 30 Dec '06

30 Dec '06

How can I save an inkscape svg file into a format that Windows can use? I tried saving it as an .eps, but Windows Paint Shop Pro barfed on it. Is there a linux native way to create a jpeg, bitmap, etc? tj

2 1

our filters may be incompatible with SVG
by bulia byak 29 Dec '06

29 Dec '06

I would like to discuss a potentially very serious compatibility issue with our filters implementation. The question is, If an object has a transform, do the filters apply to it _before_ or _after_ transfomation? To illustrate this, do the following: - draw a circle - blur it - squeeze it vertically (note the blur is also squeezed, i.e. x-blur is greater than y-blur) - rotate the object At this stage in Inkscape, the blur remains horizontal, so it is no longer parallel to the object itself, so the appearance of the object changes very visibly after the rotation. If however you now save your file and view it in Batik, you will see that it rotates the blur too, so the object looks exactly the same as before rotation. Note that Inkscape differs from Batik only after you add rotation. For non-uniform scaling, Inkscape emulates Batik's behavior by scaling the x and y deviations of the blur filter when applied to a scaled object. However, such emulation is not possible for rotation or shear, hence the discrepancy. Now, I could not find a definitive indication in SVG 1.1 standard as to which of the two behaviors is correct. (I may have missed it, of course.) Some arguments can be found in favor of both behaviors: Batik: - It is more visually consistent because rotation/shear does not alter the appearance of a filtered object in a confusing way - So far, we always considered Batik an authoritative renderer (though it may be in error too, of course) Inkscape: - The idea of transforming an already filtered object (i.e., in essence, a bitmap!) goes absolutely against our architecture, in which rasterization and filtering are always the last step after all things that can be done in vector (such as transforms) are done. If we try to fix this to match Batik, we will need to implement a separate bitmap transformer (!) which will have to be run for filtered objects _only_ (otherwise we'll end up with pixelated renditions of any scaled-up object). This will be a total mess from the programmer's viewpoint if you ask me. - Our behavior preserves the same appearance of a path regardless of whether its transform is embedded or given in a transform= attribute (but this is currently only true for rotations, not for non-uniform scales). This is a principle which we're kinda trying to uphold, although it's not always possible. I _think_ that even if our behavior is an error, it's not a reason enough to stop 0.45, because this only affects squeezed _and_ rotated objects. However it's still very serious because it's a visible rendering discrepancy. So I would like to discuss this issue and the approach we should eventually pursue. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4