I write from the FontForge project. Of particular interest to me is the Spiro
spline feature, which was originated around ten years ago by Raph Levien.
One thing I'd like to add, (which would benefit both our projects,) is the
ability of FontForge to understand the Inkscape Spiro serialization format.
However, there are several things about the format which to me as an outsider
appear to be defects serious enough that I have no idea how to even *import*
these splines correctly, much less export our Spiro splines to this format. I
would very much like to support the _de facto_ standard Inkscape has
originated of supporting Spiro in SVG, but I am lost.
George Williams, FontForge's original author, noticed this defect over eleven
years ago. Things are virtually unchanged since then, I checked `git
Spiro has five point types, not including beginning and ending points. They
* G4 curve (o)
* G2 curve (c)
* Corner (v)
* Left Constraint ([)
* Right Constraint (])
The ASCII single letters are the normal method of Spiro serialization, as
championed by Raph Levien and by us in FontForge.
Inkscape seems to create what I will call a "pseudo-SVG path". So, it is not
really an SVG path, but rather is an SVG path which undergoes transformation
into the typical Spiro format. Inkscape stores this in the "original-d"
So, given a Bezier spline with control points defined as (x, y, c1, c2),
Inkscape interprets a control point with only (x, y) to be a corner, meanwhile
a control point with all four is a G4 curve, and (x, y, c1, NULL) is a left
constraint while (x, y, NULL, c2) is a right constraint.
I can probably overcome this, although George Williams was right to be
skeptical of this format. There is no way I can see to define a G2 curve in
this strange "original-d" format.
Thus, this email. I write to ask a few things. I suppose first of all, what
are the chances that we can convince you guys to store Spiro splines in
plate format, or another widely accepted Spiro serialization format?
Second, if we cannot convince you to do that, how do I export FontForge spiros
which contain G2 control points to Inkscape's original-d format? It's not
possible, yes? So should I just silently fail and save them as G4? The curves
will not be the same if I do that. Should I disallow export to SVG w/Spiro if
glyph contains G2 control point? That seems a steep cost that will just
confuse my users, so perhaps I should abandon the whole thing if it comes to
Fredrick Brennan (@ctrlcctrlv)
: https://levien.com/garden/ppedit/README, section "Plate files"
Firstly awesome awesome software. I used to use AI but as soon as I saw
Inkscape, switched to this despite some change in familiarity. I will
always switch from proprietary to libre tool wherever possible.
I request you to add a feature where the SVGs would directly export as HTML
or HTML+CSS code. Since there are plenty of web designers out there, this
would be a very useful resource.
Are launchpad builds supposed to work or is everything built with gitlab ci
---------- Forwarded message ---------
Från: Launchpad Buildd System <noreply(a)launchpad.net>
Date: ons 27 maj 2020 kl 02:46
Subject: [Build #19361546] amd64 build of inkscape-trunk
1:0.92.0+devel+202005270041+9cc0e3c~ubuntu20.04.1 in ubuntu focal RELEASE [~
To: Christoffer Holmstedt <christoffer.holmstedt(a)gmail.com>
* Source Package: inkscape-trunk
* Version: 1:0.92.0+devel+202005270041+9cc0e3c~ubuntu20.04.1
* Architecture: amd64
* Archive: ~inkscape.dev/ubuntu/trunk
* Component: main
* State: Failed to build
* Duration: 2 minutes
* Build Log:
* Builder: https://launchpad.net/builders/lcy01-amd64-015
* Source: not available
If you want further information about this situation, feel free to
contact us by asking a question on Launchpad
amd64 build of inkscape-trunk
1:0.92.0+devel+202005270041+9cc0e3c~ubuntu20.04.1 in ubuntu focal RELEASE
You are receiving this email because your team Inkscape Developers is
the owner of this archive.
In my use of Inkscape, I use the "export png image" feature from the vector
drawing to a specific size. However, I systematically use the generation
multiple times because I work with standardized sizes. I use it on my
website to pick the smallest appropriate image.
I am thinking of evolving the export feature to have predefined sizes and
being capable of generating all the images at once. For instance, by
selecting a generation profile and a destination folder.
Do you guys think that this feature may be useful for the software?
ps: I haven't yet developed on this software and I'd be happy to have a
little bit of coaching for the beginning.
sans virus. www.avast.com
For a personal project I'm trying to add the advanced png export options as
commandline args. I've got most of it working, but am now getting blocked
by a weird issue when trying to use 0 (zero) as an input value for an
If the value is zero, the argument doesn't get added to the options
VariantDict (I check this in inkscape-application.cpp around line 1500). If
i use any other int value it does get passed along.
The reason this is causing me problems is, I add options like the the
antialiasing settings and those are based on zero-indexed enums, but don't
use 0 as a default. This means I can't just set default value to zero in
the InkFileExportCmd struct (as happens for margin ).
Hopefully this makes sense to someone here. My background isn't cpp so I'm
probably missing something simple (although I did briefly go over the glib
source code as well lol). If I can get something working I'll contribute of
Thanks for any help.
find some discussion about what's required to implement animation in
it all boiled down to either writing a bespoke animation engine or
writing an SVG DOM
it turned out that the SVG DOM is a lot smaller and easier to implement
industry-standard API for third parties to use. One benefit of going the
written. this would take inkscape to the level of a flash replacement.
---------- Forwarded message ---------
From: NASA Jeff <tallboy258(a)gmail.com>
Date: Thu, 21 May 2020 at 16:06
Subject: Re: more svg animation updates.
To: inkscape-devel <inkscape-devel(a)lists.sourceforge.net>
SMIL 3.0 Animation
not requiring a bulky,. 3rd part engine and simplicity of parsing. The
downside are that you have to implement an animation engine, they are
already available for js and SMIL complete and tested of you take the
also be used for CSS another downside when compared to js is that SMIL
isn't as feature-rich. it's also going to be fun reflecting changes of
object details on the canvas with each animation in it own little thread
and sometimes having keyframes sometimes not.
There's little difference in all the work to hook up the GUI between js
and SMIL, they support the same features and activities in general.
looking at the two roadmaps the traid off is the difficulty
would revert back to it's old self, with animation disabled, and just be an
inkscape and the play feature still available to play the animations, the
animation information meaning inkscape would still be better than nothing
for js animation it just would have full GUI integration.
On Thu, 21 May 2020 at 15:10, NASA Jeff <tallboy258(a)gmail.com> wrote:
> as the basis for a road map for the SIML path, which I'll send shortly
> reading thought it it wasn't the flour phase plan I put together prev just
> some basic ideas and a breakdown
> my current proposal to implement SVG animation is as follows (i expect
> this list isn't exhaustive but I feel I have the majority of the critical
> components listed)
> as I went through the list of possible ways of implementing animation
> before SIDL isn't possible due to lack of support from Microsoft and plans
> to drop support by google.(there is now a shim to do this so it's no longer
> an issue)
> css seems a bit limiting, especially for those hardcore flash
> fanboy animators that have been begging for animation to be implemented.
> alternative of only allowing editing through the GUI and making the
> features can be turned off selectively preventing any attempts at
> an SVG editor for the files in question
> there is a hypothetical risk of viruses being spread by svg files that
> the exposure of the hosts API and potentially which lists for what to allow
> been created. I expect that the API shim can be generated via a script
> keeping the task accurate and timely. I've not reviewed Inkscape's codebase
> to see if this is a possibility.
> it makes sense at this time to slightly extend the feature set so as to
> cost-effectiveness. security fort macros and svg would require than the
> positioning and animation information from it, the user interface also
> needs to be extended sot hat values can be read and written
> via the GUI and updating/replacing the existing script
> the canvas enabling them to be animated
> a simple code editor also needs to be implemented, but
> *I wouldn't go beyond the basics otherwise people may be tempted
> to write apps in inkscsape.the final phase is a a timeline navigator with
> support for keyframes and layers needs to be createdthe ability to go to
> any frame, step through and preview play SVG files and their animation
> needs to be added.animation parameters need to be, get, set and updated for
> the keyframesfake smile could then be used to implement SIML on top of the
> and integrated into the GUI
> *finally with all in place and tested a CSS implementation can be
> engines already exist and are well tested so complex parsers and
> interpreters don't have to be created, * fake smile exists and is well
> the number of implementations down and limiting bugs etc... it should
> also be a lot faster than a standalone SIML implementation. There are
> also libraries available and tested that implement SVG animation via
> On Sat, 16 May 2020 at 03:01, NASA Jeff <tallboy258(a)gmail.com> wrote:
>> I didn't manage to catch up wiith anyone on irc yet, and i only
>> managed to catch up with the scribes team tonight as my irc client was
>> buggy. short of a programming task I';ve been working on my psychology
>> hopefully, any day soon, I will begin implementing the PDF import
>> routines in Inkscape internal with Scribus, this is my first mini project
>> to do and after growing through the code it doesn't appear it should take
>> too long unless there's major issues implementing multipage/full document
>> after this, I'm free to spend the majority of the considerable amount of
>> free time i have on Inkscape..
>> sorry I repeat the same thing a couple of times in a couple of places
>> because I added a couple of paragraphs that added background that the
>> reader may not be familiar with or remembered.
>> I've been thinking some more about the best way to implement SVG
>> animation and I would also include +UI as in makes sense to implement some
>> interactive features that would allow the SVG files to be used too create
>> user interfaces for games and apps, though actually creating games and apps
>> insider Inkscape is out of scope so a full flash feature set won't be
>> available without third-party apps.
>> my current proposal to implement SVG animation is as follows (i expect
>> this list isn't exhaustive but I feel I have the majority of the critical
>> components listed)
>> as I went through the list of possible ways of implementing animation
>> before SIDL isn't possible due to lack of support from Microsoft and plans
>> to drop support by google.
>> css seems a bit limiting, especially for those hardcore flash
>> fanboy animators that have been begging for animation to be implemented.
>> readonly and the feature set reduced should be no more difficult to pull
>> the element numbers from than CSS would as both would need custom parsers
>> as they are not xml.
>> been created. it makes sense at this time to slightly extend the feature
>> including cost-effectiveness.
>> to interact. My current plan goes along the lines of hickaking inkscapes
>> undo/redo features and extending and generalizing them so that when a macro
>> is set to be recorded a call to add something onto the undo stack writes
>> the equivalent of a redo to the macro file buffer.
>> efficiently support anyway
>> trigers on updates would have to be extended so as to write values to
>> keyframes anyway, it is fairly trivial to write out a line in a macro file
>> at the same time.
>> a macro engine allows for relatively easy testing that hooks are in
>> it also makes it possible to test that animation features are working
>> correctly even if the UI hasn't been fully implemented.
>> it's not a major job so why not most of the functionality would be needed
>> for animation anyway and it allows for the implementation and testing to be
>> done in two phases.
>> it makes testing and debugging much easier and will probably save more
>> time and headaches than it cost to create.
>> a simple code editor also needs to be implemented, but
>> *I wouldn't go beyond the basics otherwise people may be tempted
>> to write apps in inkscsape.at the same time as doing this I intended to
>> write a guide to implementing macro engines in computer software with undo
>> starter kit. it makes sense to do this so that others are encouraged to add
>> this kind of functionality to applications once they realize that it's
>> relatively straight forward and not as complicated as one may think.undo
>> animation not for macros, calls to append to the undo buffer should now
>> additionally update the values at keyframesInkscapes user interface needs
>> to be extended to add any animation-related data, this should update undo
>> which will then populate the relative animation setting in the animation
>> script.a timeline navigator with support for keyframes and layers needs to
>> be createdthe ability to go to any frame, step through and preview play SVG
>> viewable but read-only. I would allow it to be extended using scripts with
>> a predefined interface, these scripts should be editable but only allow for
>> extendable and customizable and to implement features that inkscape doesn't
>> implement for whatever reason.a parser needs to be created to scrape the
>> gui where they can then be edited and updated.*
Spidermonkey doesn't seem too hard to integrate, creating a shim for a
a library that provides an API for Inkscape hopefully shouldn't be too
tricky and possible with a few precompiler directives in the code and a
Spidermonkey looks a little short on documentation especially when it
comes to C/JaverScript interoperability.
V8 maybe seems a little trickier to embed, only a little not a great deal
but has good, clear documentation. it is however C++ base, so it how well
that mixes with Inkscape's choice of c
do it's going to take some searching for documentation and examples of
will embed the nicest based on hope Inkscape's SPI is implemented and also
look at debugging support and any other featurtes
Can we drop this old dialog now? It has effectively been deprecated for
the last couple of releases and I don't think it has any functionality that
hasn't been replaced by GradientToolbar.
I'm currently migrating the PaintSelector and friends to C++ so I'd prefer
to kill the old dialog at this stage rather than maintain it!
I've merged quite a few updates today, including the use of c++17 as per
the previous discussion (thanks Linkmauve), and the change of 2geom
inclusion to a submodule (Thanks Sergei Izmailov).
So you're likely to get a CMake error on your next compile, which should
be solved with a "git submodule init; git submodule update;"