inkscape git mirror?
by MenTaLguY
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
15 years, 3 months
Status of inkboard feature
by Denis Leroy
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
16 years, 8 months
Postscript input extension and skencil
by Denis Leroy
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
16 years, 8 months
RFC: SVG filter transformations
by MenTaLguY
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
16 years, 8 months
Re: [Inkscape-devel] Pattern along path crashes
by Michèle Garoche
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>

16 years, 9 months
Pattern along path crashes
by Michèle Garoche
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.
16 years, 9 months
saving in windows friendly format
by tj
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
16 years, 9 months
our filters may be incompatible with SVG
by bulia byak
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
16 years, 9 months
