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, 5 months
- 2
- 1
Inkscape PLC Meeting (moved to Nov 12, 2021)
by Ted Gould
Howdy folks,
I am late getting out this notice and folks in the chat mentioned it'd be easier for everyone if we shifted the normal meeting back a week. So we're planning on having it Nov 12, 2021 and high noon Texas time. I think this gets is out of the confusing week where everyone is on different daylight savings time as well.
Timezone tool: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211112T10&p1=202
Wiki page: https://wiki.inkscape.org/wiki/Leadership_Committee_Status_Updates
I'll note that we have a few votes outstanding and if all board members could look and make sure you voted that would be helpful. I hope to do an audit on those tonight or tomorrow and it's a lot easier if all the votes are in! Otherwise you'll be shamed at the meeting 😉
Ted
1 year, 9 months
- 1
- 1
Emoji handling - a mixed problem of system font management and application behavior - what is the part of inkscape
by Stefan Lechner
Hello folks, I have a very special and obscure situation. I am using
inkscape version 1.1.1 on Arch Linux with Gnome Desktop 41.1, but the
problem is present since several years on different systems, but I
didn't notice it for a long time. Some months ago the situation changed…
It is related to Emojis. I am using svg-files with astrological symbols
as text, the fonts I am using are covering this unicode symbols and I do
not want to have them replaced with symbols from an other font. But
exactly this is happening since some years (in nearly every application
and in a very special way in inkscape).
I think it all comes from the definition which symbols are emojis and
which not. There is a hand full of symbols which are in use as emojis
and as normal "letters" in text - in my case asterisks. Since 2016 the
system-wide emoji support is interpreting this symbols as emojis and
substituting them with an emoji-font even if the signs are available in
the font in use. A behavior I dislike at all, but maybe it is wanted by
others for chat applications and similar.
From 2016 to 2020 my system lack a special bitmap-emoji-font and I
didn't notice the on going substitutin in the background. I use the
Libertinus Sans (former Linux Biolinum) font and the emoji-substitutin
has been replacing the asterisks signs of this font with the Dejavu Sans
font - it seems Dejavu Sans is in use as an Emoji-fallback font, because
of the huge unicode coverage.
Since 2020 a bitmap-emoji-font is present on my system as dependency of
gnome-characters. So everything changed. Now I have ugly colorful
graphics instead of normal text-signs in many applications including
Firefox, Eye Of Gnome,…
… and inkscape? Even worse! Inkscape can not handle the signs from the
bitmap-emoji-font and is substituting once again the asterisks with
normal letters from the alphabet.
My workaround at the moment: uninstalling gnome-characters and the
emoji-font to again fallback on Dejavu font. But this is not satisfying,
I want back the signs from my Libertinus font. I have not found any
solution yet.
I think this is a misbehavior of the emoji-implementation. But what is
the problem? A missing functionality on application side or a bug of the
emoji-substitution on system side?
In other words: is it part of the application to accept or refuse the
emoji-substitution or is the undemanded emoji-substitution of the
font-system a bug itself?
No matter what - I think, as long as inkscape is not able to use the
emoji-fonts, it should refuse all emoji-substitution functionality
completely (if possible?!). It causes problems in every case.
What do you think, am I right?
Stefan
1 year, 10 months
- 1
- 0
- ← Newer
- 1
- Older →