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"
11 months, 3 weeks
Re: Old bug tracker / bug migration
by Nathan Lee
Hi Max,
I thought I'd add some input instead of staying silent (Thanks for cc'ing the Bug Wranglers in Patrick!).
As I understand it, now that we know bugs can still be accessible, the main objection is to keep the bug migration game going (and the effort spent to make sure it's done right).
It looks like the workaround with the teams will work smoothly, without adding much of a barrier to the bug migration game.
Just to make sure, would anyone still be able to update existing issues? (e.g. status changed, comments added, receive notifications for these)
If the existing issues aren't modifiable, I would prefer to keep launchpad as is till the bug migration game is over though (perhaps we should consider when it should be closed if we can't migrate them all over.
If existing issues are modifiable, don't have any objections from my end. I do notice that there is a steady trickle of bug reports that are consistently opened; closing the page does seem helpful even while the bug migration is going on since we are wasting time dealing with these reports anyway.
The last objection is the effort spent. Well, thanks for picking up this task again and investigating!
Regards,
Nathan.
2 years
Old bug tracker / bug migration
by Maximilian Gaukler
Hi all,
every once in a while, people still report bugs on the old bug tracker
on launchpad.net. Currently, the bug tracker was left open so that we
can still read old bugs and move them over to GitLab. With some help
from Launchpad.net support
<https://answers.launchpad.net/launchpad/+question/695519> I figured out
that we can disable bug submission there without losing access to the
old bugs:
https://launchpad.net/inkscape/+configure-bugtracker
-> Setting: Bugs are tracked: "somewhere else".
I tried that temporarily for a few seconds, and it seems to work:
Then, the main links "Bugs" and "Report a bug" on Launchpad disappear.
However, one can still search for bugs using the direct link to the
"advanced search":
https://bugs.launchpad.net/~inkscape.bugs/+bugs?advanced=1
Links to old bugs still work, e.g.:
https://bugs.launchpad.net/inkscape/+bug/682585
Maybe in the future we could import the old bugs to a separate GitLab
project, so that one can find all bugs (inbox, real bugs, old launchpad
bugs) using the single URL https://gitlab.com/groups/inkscape/-/issues .
And/or mass-close the largest part of the old bugs, at least those that
are not confirmed/triaged and have not been updated for many years.
Looking forward to hear your thoughts.
Best regards and have a nice weekend
Max
2 years
Charter Discussion Meeting
by doctormo＠gmail.com
Dear Developers and Board,
We're organising to have a video chat in 3 weeks time to discuss
opening Inkscape up to allowing more contributors that just programmers
to vote on board elections.
Please attend if you are a team leader or if you are interested in how
the project should certify contributions from all our different teams.
Calendar entry: https://inkscape.org/cals/event/11/
ical: https://inkscape.org/*board/calendar.ics
Best Regards, Martin Owens
2 years, 1 month
Calling German-speaking Inkscape Community members (and those who don't mind to communicate in English with German Linux users)!
by Maren Hachmann
Hi everyone,
the Inkscape project is going to host a virtual booth/stand at the
Chemnitzer Linuxtage, on March 13 and 14 this year!
We have already gathered a small booth team of 4, possibly 5, but the
CLT (Chemnitzer Linuxtage) are all-day events and we could use your help
answering user questions about how to work with the program, how to
contribute to it and about what is going on in the Inkscape community.
We might even do some short, up to 20min topic-focused sessions, if
someone would like to organize (one of) them.
So, if you're a developer, a forum member, a regular user support
provider in our chat channels, an Inkscape translator, or are
contributing to the project more or less regularly in any other way, and
you have some time available to spend helping the Inkscape project on
that weekend in March, please introduce yourself at the GitLab issue
report where we're discussing the event organization!
We would also be glad to have someone on board from any of the maker
labs or similar communities, who are proficient in helping with maker
topics, or who can demo something interesting in a short session (or
both :) ). Or if you'd like to present the top 10 Inkscape extensions
that people must know about, or do a quick drawing session, or want to
tell people how to compile Inkscape and get started with development or
... whatever you can think of.
******************
Please get in contact with us as soon as possible and find more info at
https://gitlab.com/inkscape/vectors/general/-/issues/192
Let us know how you can help make the booth an interesting place for
visitors to drop by!
******************
We're going to have a meeting with all those interested in about a week,
so it would be good to hear from you before that.
I'm going to announce the meeting time in a separate message.
Hope to see you - and if you are not able to join us at the booth,
consider visiting us there!
Kind Regards
Maren
2 years, 1 month
