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, 4 weeks
inkscape-1.1: exit during startup, problem loading svgs
by Thomas Klausner
Hi!
I've tried updating the pkgsrc package from 1.0.2 (working fine) to
1.1. It builds and installs fine, but during startup complains about
svg files and exits, without display a window.
(org.inkscape.Inkscape:66): Gtk-WARNING **: 10:54:36.278: Could not load image 'resources/template_about.svg': Couldn’t recognize the image file format for file “/usr/pkg/share/inkscape/ui/resources/template_about.svg”
(and many more like these, then ending with)
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/pkg/share/inkscape/icons/hicolor/scalable/actions/image-missing.svg: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/pkg/share/inkscape/icons/hicolor/scalable/actions/image-missing.svg: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
gdk-pixbuf has SVG support, I tested this with:
gdk-pixbuf-thumbnailer /usr/pkg/share/inkscape/icons/hicolor/scalable/actions/image-missing.svg image-missing.png
which successfully creates a png file.
Now I'm not quite sure where else to look for the root of the problem.
The pkgsrc files for 1.0.2 are here:
https://github.com/NetBSD/pkgsrc/blob/trunk/graphics/inkscape/Makefile
The files for 1.1 are here:
https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=inksc...
Please let me know if you have any ideas what might be missing or wrong. Thank you!
(I've filed https://gitlab.com/inkscape/inbox/-/issues/5111 about this
and Nathan Lee suggested I should ask on the mailing list about this.)
Cheers,
Thomas
1 year, 9 months
Issue with Inkscape 1.1 snap and REALHOME / getent
by Douglas Paul
Hello,
I recently had a machine running Ubuntu auto-update its snap to version
1.1. In this version, there seems to be a new mechanism to determine the
default config path using getent that is not functional on my system.
Some particularities that I have:
1) passwd / groups of users come from a Samba AD using sssd
2) home directories are mounted on NFS
The problem that I see is that the REALHOME variable is not set
correctly, so it tries to look for the configuration in
/.config/inkscape.
This is what I see when launching:
====
$ LANGUAGE=en_CA:en inkscape
/bin/bash: /home/doug/.bashrc: Permission denied
/bin/bash: /home/doug/.bashrc: Permission denied
/bin/bash: /home/doug/.bashrc: Permission denied
Unable to init server: Could not connect: Connection refused
** Message: 08:43:39.229: Cannot create profile directory /.config/inkscape.
** Message: 08:43:39.229: Inkscape will run with default settings, and new settings will not be saved.
** (inkscape:3501254): WARNING **: 08:43:39.395: Could not create directory '/.config/inkscape'
** (inkscape:3501254): WARNING **: 08:43:39.396: Could not create extension error log file '/.config/inkscape/extension-errors.log'
** (inkscape:3501254): WARNING **: 08:43:39.476: Fonts dir '/.config/inkscape/fonts' does not exist and will be ignored.
====
So, the first thing I tried is to add the following in the snap's
apparmor profile:
#include <abstractions/nameservice>
#include <abstractions/bash>
And this got rid of the bashrc access errors (which likely aren't fatal,
anyway), and I could get a proper result with this:
aa-exec -p snap.inkscape.inkscape getent passwd $UID
So, I thought this would work. However, it still doesn't...
With careful use of ctrl-Z and attaching strace (since it seems you
can't strace directly), I was able to see that the /etc/nsswitch.conf
being used by inkscape is coming from inside a chroot or otherwise
remapped by snap, and it does not use the system /etc/nsswitch.conf.
It looks exactly like this issue:
https://forum.snapcraft.io/t/no-sssd-support-in-snaps-nsswitch-conf/10412/12
It seems like the only way around this problem is to use NSCD as a
proxy, which is generally not recommended, it seems, but might be the
only choice I would have. (Using unscd does seem to work, even with 0
cache ttls -- so I think this should be safe)
All this to say -- would it be possible to have a fallback in the
environment to use the old behaviour (was it to use $HOME as REALHOME?)
in case the calls to getent fail? Or, at the least, it should be
documented that using nscd/unscd is required when a different
nsswitch.conf configuration is used.
Thanks,
--
Douglas Paul
1 year, 9 months
Developer Team Budget
by Martin Owens
Dear Developer team,
Thank you to everyone who made the developer meeting today; we talked a
lot about what the budget should look like from the developer team. I
have comprised the ideas here which I will be bringing to the next
board meeting to be held on June 4th 2021 (
https://inkscape.org/cals/event/2/)
Current items to be requested immediately:
* The Developer team requests a General Administrator who can take
care of many of the organisational tasks which we currently struggle
to. This is deemed more important than any funding for specific
features. I'd like to invite everyone to join me for a meeting to flesh
out what this would look like, we'll use previous work as a base and
work from there. Please come to BigBlueButton next Sunday 30th May at
17:00UTC (https://inkscape.org/cals/event/25/) to make sure our
proposal is detailed enough.
* We would like to budget $5k on macOS speed problems; this is to be
spent on analysis first, and then solutions second. The whole developer
team recognises how dire the situation is with René specifically saying
that without a fix we should not release for macOS in the future.
Future budget requests which we do not have a consensus for, or details
are missing:
* CMYK support; Tav would like this, developers feel it's not
important enough. A user study would be useful to know for sure.
* PathFinder; Taking over, or working with the Linux foundation for
their Rust based pathfinder is a great way to bring GPU rendering to
Inkscape. Marc is to contact the linux foundation and Linkmauve about
collaboration or taking over the project.
* ARM Machine for René; If we continue to develop macOS, René will
need one of the newer ARM based macOS machine which would be set up to
do CI builds. Improving the ability to check and build testing builds
for macOS.
Thanks everyone for attending, we had quite a lot of the developer team
there today and a lot of students so I feel good that we got to see a
lot of different opinions. But let me know in this thread if you have
details to add, or can't make the above meeting and want to make sure
something is included.
Best Regards, Martin Owens
Developer Team Hat
1 year, 9 months
call of 'virtualenv' with option 'p=python3' syntactically wrong
by fi＠igh.de
Dear Maintainers,
after pulling revision 5448704355e03a97d2838e1ba30272db335f0dbb
I have built inkscape according to https://inkscape.org/develop/getting-started/
Trying to manage extensions (Extensions -> Manage Extensions) I
receive the following error message:
There has been a problem creating the python environment:
Return Code: 3: b''
b'The path =python3 (from --python==python3) does not exist\n'
args: ['/usr/bin/virtualenv', '-p=python3', '/home/xx/.config/inkscape/extensions']
Indeed the call is syntactically wrong. Instead of
'-p=python3'
the option
'-p python3' ### without equal sign
should be used.
As far as I understand, the problem seems to exist in
inkscape/share/extensions/extension-manager-bootstrap.py:69
call('virtualenv', TARGET_DIR, p='python3')
which then in inkex/command.py:to_args() is evaluated to the wrong
sytnax. According to the (very good) comments in to_args()
:Keyword Arguments:
* *name* (``str``) --
Becomes ``--name="val"``
...
* *n* (``str``) --
Becomes ``-n=val``
...
it should become ``-n val``.
I do not know whether a change would result in problems using other
programs that want -n=val. Which should that be?
Best regards
Torsten
--
------------------------------------------------------------------------
Torsten Finke
fi(a)igh.de
------------------------------------------------------------------------
1 year, 9 months
