Regarding the serialization of Spiro control points
by Fred Brennan
Greetings,
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.[1] Things are virtually unchanged since then, I checked `git
blame`.
Spiro has five point types, not including beginning and ending points. They
are:
* 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"
attribute.
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[2] 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
that.
Cordial regards,
Fredrick Brennan (@ctrlcctrlv)
[1]: https://narkive.com/63FADpG3.4
[2]: https://levien.com/garden/ppedit/README, section "Plate files"
1 year
bit of an update on svg animation
by NASA Jeff
- hi everyone
- I've been looking at animation support and evaluating the competition.
also I found a javascript implementation of the web animations api which
may be the animation engine to support as it's getting native support in
browsers. that doesn't limit us by not allowing support for snap or GSAP on
top of this. web animations API works with css and svg and
provides interfaces to animation, keyframes and timelines.
-
- https://github.com/web-animations/web-animations-js
<https://github.com/web-animations/web-animations-js>
github.com
*web-animations/web-animations-js*
<https://github.com/web-animations/web-animations-js>
JavaScript implementation of the Web Animations API -
web-animations/web-animations-js
- SVGator, a commercial svg animator supports javascript (using it's
custom engine) or css
-
I still wouldn't suggest supporting any old javascript, but a cut down
version of javascript where complex functions get replaced with stubs that
return some default value and the code can be evaluated to get the
animation (limited by what javascript functionality is implemented) and
property settings for the animation can be traced. I would do this roughly
by using the built in parser in the javascript engine to calculate
animation settings to be presented in the UI. the commercial svg animation
tool SVGator supports javascript and css. it doesn't allow the javascript
to be modified in the application, I haven't tried importing and svg file
with modified javascript. it may also be a good idea to support snap or
GSAP ontop of this, on the other hand, they may become obsolete as web
animation s API gets full support and people start writing functions for it
such as the morph one found here
https://coherent-labs.com/Documentation/cpp-gameface/d1/dea/shape_morphin...
-
- for instance, simple loops may be supported, but more complex(that use
the result of a function call to determine the loop[ conditions) ones may
be too complex to support rationally
- Doing this loses nothing as the animation will still run in a browser,
but Inkscape may only support animations with complex functionality
partitioning
- Accurate animation playback can still be supported by executing the
javascipt but I would limit imports to trusted javascript and not any old
javascript for reasons of side effects and security.
there are already shims that implement SMIL in javascript, and assuming
they allow you to position the timeline and query keyframes and object
attributes they should allow for a relatively straight forward SMIL
implementation
so long as javascript is supported.
this proposal sees inkscape supporting SMIL, CSS and javascript. the Web
Animations API implementation should allow for the support of CSS without
any javascript but can still be used for the actual process of animating
and setting the timeline position.
at the moment I'm still working on importing text from pdf files in
scribus. I have most of the functionality already implemented for this out
just requires a bit of polish. to do that I'm going to refactor the code to
use a simple framework that should make the code a lot cleaner, be faster
and support all the features for the Polish needed to have a decent
implementation.
2 years, 9 months
Suggestions documentation regarding "Getting Started with Inkscape Development"
by wiesi＠posteo.net
Hello,
I recently filed a pull request and was pointed out to
* increase the timeout in "Settings => CI/CD => General Pipelines =>
Timeout" to 3h
* Check the "Allow commits from members who can merge to the target
branch" in the pull request settings.
I suggest to add a section in "Getting Started with Inkscape
Development" on the homepage describing the correct settings and maybe
also how to create a fork on gitlab (or just link the gitlab
documentation).
Cheers,
Thomas
2 years, 9 months
Inkscape Hackfest 2020
by Martin Owens
Dear Inkscape developers and users,
I've been thinking about how best we can host a hackfest for 2020 given
all the restrictions. After talking with multiple people, I've decided
that the best format for an online hackfest is to have one spread out
over the summer.
So may I present to everyone the Summer of Hackfest:
https://gitlab.com/inkscape/vectors/general/-/issues/161
This gitlab issue is just for organising people's preferences, and
thoughts. Once I have times confirmed, I'm going to write everything in
the regular hackfest wiki page for everyone.
So. The idea here is to take advantage of the online nature of this
year's hackfest activity and allow people more breathing room between
sessions. Each week I'll be hosting a video chat which you will be free
to join and just hang out in and where hopefully some of the important
topics will happen once per week. No grueling commitment, no big block
of time, just a predictable schedule of lovely inkscape topics which
will be publisised to get more people involved than ever before.
Please join me on GitLab to proposed topics and set your preferred
times. I'm looking for one topic per week, so that's six topics.
And thanks for your participation.
Best Regards, Martin Owens
2 years, 9 months
chrome's support for modifying web animations api in it's developers console.
by NASA Jeff
Chrome seems to do a reasonable job of capturing and modifying web
animations API in JavaScript. Its not so hot, however, when it comes to
elements that have animations that are programmatically generated, it
doesn't even group them all together and identify the source of
programmatic generation, which in many cases is just a simple trace of the
code. I dare say it could do better than just passively listening out for
animation events and actually infer many of the from the source documents.
2 years, 9 months
[GSoC Paths] Status update
by Moazin Khatri
Hi everyone,
I would like to provide a status update on the Path Library Improvement
project. Since this is my first report to the list (the last one wasn't
public), I'd like to discuss everything done so far. This report is huge
and quite technical, so if you want a short version, it is this:
"I have successfully written a relatively short piece of code that creates
simplification results totally identical to the livarot version. The
algorithm is the same as livarot and is nearly as fast. I'm about to start
cleaning it, documenting it and integrating it with simplify, lpe-simplify
and pencil tool. This will be done within the next two days."
Now the detailed version:
According to the original schedule, I was supposed to work on the Path
Simplification feature and that is what I have been doing. I started with
writing some boilerplate code that will allow me to trigger my own Path
Simplification code in Inkscape. This is so that I can compare its results
with livarot based simplification quickly.
I started exploring the simplification algorithm of lightvarot and wrote
some path flattening (the process of approximating a path by line segments)
myself. I integrated these in Inkscape and the algorithm produced pretty
satisfying results but it was too slow. In a "Release" build, the
performance might be okay for a "Path > Simplify" but would do pretty bad
in live path effects. For what it's worth, I also created an animation
explaining this algorithm. You can find it here:
https://moazin.github.io/simplification-algos.html
Disappointed by its performance, I replaced the main part of the algorithm
with its equivalent from livarot (that's explained in the link attached
under the title "Livarot / Simplifying the curve". The performance improved
but there were significant differences between the results. I had a choice
here, I could either just rewrite a cleaner version of livarot's code or
understand what's causing the differences and fix those. I chose to do the
latter.
I started following the procedure "draw paths -> trigger both algorithms ->
debug both simultaneously -> understand and fix the differences -> repeat".
Going down this route, I understood almost all the parts of livarot and was
even able to discover/fix bugs in both livarot and lightvarot. Here are the
reasons behind the differences:
1. The codes for flattening the paths were different so obviously there
were differences in the results. I simply implemented livarot's algorithm
for splitting cubic beziers to solve this problem.
2. There is an iteration of Newton-Raphson method. (I'll probably add what
this iteration is and what it does in the link attached above soon, it's
mostly math stuff). I suspect that the code for this iteration in
lightvarot is mathematically incorrect, so I fixed it. I will do the
derivation again to be sure if it's really a bug though. Anyways, I fixed
it by replacing the constants from my derivation (which are identical to
the livarot version).
3. There is a special portion in livarot code which fixes what livarot
calls the "splotch" problem. When the number of points you're fitting are
few, you can sometimes get a fit which fits the points correctly but
overall doesn't fit the polyline properly. There is some special code that
calculates error differently to take into account this situation and
thereby avoid bad fits. My code was missing this code, so I wrote it.
4. There is a slight optimization in livarot that reuses some calculations
and I suspect it compromises on the accuracy of the fits. I need to
investigate more to be sure. I fixed it in livarot by simply using the
non-optimized version. (There are two `AttemptSimplify`)
5. There were some silly bugs in livarot's non-optimized `AttemptSimplify`.
A minus was replaced by a plus and a weight factor was commented. Fixed
both of those on the livarot side.
After doing all of these changes, both versions are producing totally
identical results. The computation time is also mostly identical. There is
a very minor difference in the flattening part which I'm working on.
The code can be found at:
https://gitlab.com/moazin/inkscape/-/tree/integrating-livarot-low-redesign My
code lives in `src/path/PathSimplifier(.h/.cpp)` and
`src/path/PathFlattener(.h/.cpp)`. The temporary verb "Path > MyOperation"
triggers code in `src/path/path-myoperation(.h/.cpp)`.
The commit history is pretty much garbage since I have been experimenting a
lot. Over the weekend I'll be cleaning this code, documenting it properly
and integrating it in lpe-simplify and the pencil tool. I'll add the final
resulting code "cleanly" on a fresh branch.
An interesting part of this project is the "design" of whatever code I
write. But I think it's too early for me to start thinking about it because
as I move towards Boolean Operations, a lot of new things will be
discovered and whatever "design" I decide on would change. So, IMHO, this
can be discussed later once I am done with Boolean Operations.
Please feel free to ask any questions that you may have or provide feedback.
Thank you,
Moazin
2 years, 9 months
C++ & Gtk dependencies
by Alex Valavanis
Hi All,
I just wanted to follow up a couple of recent discussions on our build
dependencies.
1. There was some talk of moving to C++17. Tav - I think you were going
ahead with a dependency bump in master? Are we still doing this, or did we
find any issues?
2. Are we OK to bump to Gtk+ 3.24? AFAIK this is the final Gtk+ 3 version
so would be a good stable target for Inkscape 1.1. The only issue would be
RHEL/CentOS/Debian LTS are stuck on an older version. My feeling about
this kind of thing is that we keep Inkscape 1.0.* as our LTS and push ahead
with a dependency bump in master.
Best wishes,
Alex
2 years, 9 months
Getting error status/messages for Inkscape actions (when called via activate_action)
by wiesi＠posteo.net
Hello everyone,
is there a possibility to get some error status and/or error messages
when executing actions via, e.g., activate_action()? I had a look at the
glibmm documentation but couldn't find anything regarding this topic.
I've just included executing Inkscape actions from the internal Python
interpreter feature I'm porting to the current master branch
(https://gitlab.com/wiesi/inkscape/-/tree/python-internal-1) and it
would be nice (maybe even mandatory) for the Python user to get some
feedback whether an action was successful and a meaningful error
message if not.
Can anyone point me in the right direction? Does glibmm have some
infrastructure for this task that I'm just unable to find or does it
really require some extended surgery?
Thanks,
Thomas
2 years, 9 months
