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"
12 months
back in the USSR
by NASA Jeff
or rather the UK,
I left my flat keys in turkey and can't get into my flat and my mum and
grandfather were moving house when I got back and we've only just had the
internet hooked up. it's running at a measly 1.5mb so I'm going to have to
wait until I get a new keyfob from the landlord and can get back into my
flat before I can continue with more serious work.
They take a week or so to get a new keyfob for some reason so I'll ask them
if they have a code for an emergency box on the door so I can get in sooner
and don't have so much hassle if I lose my keyfob again. They will probably
tell me to bugger off so I expect to see you all again in a week or so's
time when I have fiber and we can catch up properly.
My mum is almost moved now so hopefully i'll have some time to relax and
get on with some reading, Turkey was busy all the time and I got quite a
lot done over there and even learnt a little turkish.
I had a chance to look at acrobat when I was over there and appart from the
kind of clicking and locking you get in cad packages it didn't really seem
anything special, it was quick however.
2 years, 5 months
Custom Styles
by Early Ehlinger
Hello Inkscape Devs,
I've put together this pull request:
https://gitlab.com/inkscape/inkscape/-/merge_requests/2405
I've run into a bit of a snag on the unit test front because make check
doesn't show as a valid target, even though I've run download-gtest.sh and
re-run cmake.
cmake complains that:
-- Could NOT find GTest (missing: GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY)
CMake Warning at CMakeLists.txt:187 (message):
No gtest found! Disabling testing...
I'm going to keep hacking at this, but would love any advice and/or to
discuss the PR in the meantime.
--
Early Ehlinger
2 years, 5 months
i missed the team meting again :-(
by NASA Jeff
apologies for missing the team meeting. I had to order a take out, I got
food poisoning. Almost recovered but my bottom can't stop blowing trumps.
2 years, 5 months
Dependency : boost-filesystem
by Marc Jeanmougin
Hi all,
Since we switched to C++17, there has been an attempt to use
std::filesystem to simplify some of our file handling code.
However, some compilers we still want to support for now (like gcc8 or
some macos clang versions) do not have it in by default or need a
special flag.
Hence we decided at the last dev meeting (reminder, next dev meeting is
saturday, and we have a board meeting tomorrow (friday)) to use
boost-filesystem, which has exactly the same API, in the meantime (so
that when we switch, it will "just" be a matter of removing the dep, a
few lines in CMakeLists and change the #include).
On some systems boost includes everything (and we already use some of
boost) so you'll be fine, and on ubuntu-like systems you might need to
apt install libboost-filesystem-dev
If you have questions for a particular system, feel free to voice them,
and if you are willing to use std::filesystem and want to maintain a
patch to avoid adding a dep in the meantime, you'll basically want to
locally revert 6880148747deb6d7ec4e73068b9e196bb11a0f0c
Good evening,
--
Marc
2 years, 5 months
