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, 8 months
[Re: cloudscale.ch's sponsoring for Inkscape]
by Bryce Harrington
----- Forwarded message from "cloudscale.ch Support" <support(a)cloudscale.ch> -----
Date: Mon, 7 Dec 2020 14:02:56 +0100
From: "cloudscale.ch Support" <support(a)cloudscale.ch>
To: Bryce Harrington <bryce(a)bryceharrington.org>
Subject: Re: cloudscale.ch's sponsoring for Inkscape
Dear Bryce
Thanks for your message.
We are working hard for the exact feature you are asking about: Soon (tm), our cloud control panel will allow to create "organizations", which in turn can own "projects" consisting of one or more servers/resources. Multiple people/accounts can be part of such an organization and also invite others across organizations to collaborate on their projects. It will also be possible to hand over entire projects from one organization to another.
However, we expect to release a first version of this long-awaited feature within the first half of 2021 only.
In the meantime, we can offer to change your account's main email address (i.e. your username) to something more general such as "devops(a)inkscape.org", if that helps. For day-to-day use, you would need to share API keys and/or GUI credentials, though (which is a nasty way, admittedly, but obsolete within a few months' time). While "transferring" an entire account to another email address is possible already, transferring resources between accounts is not yet.
Having outlined the currently possible workarounds, I am glad that this big rework of our control panel will exactly fit your (and many others') use case. We are almost there...
If we can do anything else for you, please let us know.
Best regards from Zurich - Switzerland,
Markus
--
Markus Furrer
cloudscale.ch AG
Venusstrasse 29
CH-8050 Zürich
Fon: +41 44 55 222 55
Fax: +41 44 55 222 56
Web: https://www.cloudscale.ch
> On 5 Dec 2020, at 10:30, Bryce Harrington <bryce(a)bryceharrington.org> wrote:
>
> Hi Markus,
>
> Thanks again for all the support you've provided, the project has really
> benefitted from cloudscale's support!
>
> Could I ask, what is the procedure for turning over responsibility for
> the account to another person? Should I have them create a new account
> and then I let you know so you can switch everything over to them?
>
> Alternatively, is there an established way for more than one person to
> share access to the dashboard + hosts?
>
> (With my severely limited time availability I find I am a
> single-point-of-failure. So we need a way to either turn it over to
> someone else, or a way to share the duty with them.)
>
> Thanks,
> Bryce
>
> On Mon, Apr 27, 2020 at 07:56:00PM +0200, Markus Furrer wrote:
>> Dear Bryce
>>
>> Thanks for such a quick response!
>>
>> And many thanks for the interesting insights into your environment! As your server naming indicated some sort of "scaling out", I was not sure to suggest our larger flavors and our new "Plus" offerings featuring dedicated CPU cores [1]. Seeing the list of different services, however, there probably are reasons to separate things on multiple, smaller servers.
>>
>> While we trust that our users keep a backup outside of our infrastructure (as mentioned in our TOS), you might want to take advantage of our new, second cloud location for the backups you decide to keep with us [2]. This way, you can get to your data even in the unlikely case of a major incident impacting the site where your main servers are located.
>>
>> Third, thanks for going through your servers and reducing some of them. Please note that Floating IPs are not deleted together with the respective servers - in fact, one of their use cases is to keep a service IP across server replacements. In case you do not need them anymore, just delete them in the "Floating IPs" section in our control panel.
>>
>> It was not my intention to enforce an exact budget. If you need resources going a little beyond that rough CHF 5000 per year in order to reasonably run something useful, please go ahead. In case it is considerably more, we might also be able to find a solution to split the cost - after all, we work hard to be our users' favorite cloud provider, and do not want to stop you from using us :-)
>>
>> Glad to hear you work with Canonical! Ubuntu is the distribution powering most of our own infrastructure, and - you guessed it - most of our customers' virtual servers. It was a no-brainer to support the new 20.04 LTS release as early as possible.
>>
>> Again, we are happy to support Inkscape, and if there is something we can help you with, please do not hesitate to contact us.
>>
>>
>> [1]: https://www.cloudscale.ch/en/news/2019/11/19/even-more-power-thanks-to-pl...
>> [2]: https://www.cloudscale.ch/en/news/2019/11/06/geo-redundancy-with-two-clou...
>>
>>
>> Best regards from Zurich - Switzerland,
>> Markus
>>
>> --
>> Markus Furrer
>>
>> cloudscale.ch AG
>> Venusstrasse 29
>> CH-8050 Zürich
>>
>> Fon: +41 44 55 222 55
>> Fax: +41 44 55 222 56
>> Web: https://www.cloudscale.ch
>>
>>
>>> On 27 Apr 2020, at 18:56, Bryce Harrington <bryce(a)bryceharrington.org> wrote:
>>>
>>> Hi Markus,
>>>
>>> Thank you again for your sponsorship of Inkscape, and I apologize for
>>> going over the limits. I've freed up resources we're not actively using
>>> and brought the usage down to 15.55 CHF. There are a couple more
>>> servers I think I can remove as they were for new services that I think
>>> the setup work did not get completed.
>>>
>>> Regarding how cloudscale.ch's sevices are being used, they are hosting
>>> the primary communication channels for the Inkscape project's
>>> development work:
>>>
>>> * Mailman3 - All of Inkscape's user and development mailing lists are
>>> hosted from a cloudscale host (Flex-4 with 100GB). We had run into
>>> memory limitation issues running on a 2GB node, so appreciated being
>>> able to scale up to Flex-4 to solve the issue.
>>>
>>> * Mediawiki - Inkscape's institutional memory is its collection of
>>> wiki pages, which has been migrated to a cloudscale host (Flex-2
>>> node with 200GB).
>>>
>>> * Rocket.Chat - The project has largely moved away from IRC to this
>>> modern chat system, which hosts a couple dozen channels for the
>>> various Inkscape teams to discuss their work. This was the first
>>> service we brought up at cloudscale and has been a resounding
>>> success.
>>>
>>> * Intranet - we also have one node we used for internal
>>> developer-focused web pages, such as transcripts from Inkscape's
>>> board meeting, and misc. cron jobs.
>>>
>>> * Backup - another node runs rsnapshot to backup the above services.
>>>
>>> Other services we've looked running include Kiwi TCMS, and a translation
>>> system called weblate. We also considered hosting an Inkscape community
>>> forum whose administrator no longer has time to maintain it, but he's
>>> also not had time to hand over the database. I think if we cancelled
>>> these efforts we can get the rate back under the limit, but I need to
>>> try to talk to the individuals working on those projects first.
>>>
>>> Thanks again for hosting Inkscape, and apologies again, I was more
>>> focused on keeping the CPU / RAM under control and didn't take into
>>> account the disk space resource needs.
>>>
>>> On a more personal note, last year I started a new job at Canonical,
>>> where I maintain the Ubuntu Server product. I'm very happy to see
>>> cloudscale.ch already lists our freshly released 20.04 LTS. :-)
>>>
>>> Bryce
>>>
>>> On Mon, Apr 27, 2020 at 03:00:33PM +0200, Markus Furrer wrote:
>>>> Dear Bryce
>>>>
>>>> Reviewing cloudscale.ch's sponsorship commitments, I am very happy that we support Inkscape - and will hopefully keep doing so for a long time to come.
>>>>
>>>> To my knowledge, the original sponsorship agreement was about servers totalling around 32 GB of RAM (which would add up to around CHF 5000 worth of services per year). Looking at your account, however, I noticed that current usage is at CHF 41.30 per day (i.e. CHF 15000 per year). Approx. one third of this amount actually covers virtual servers, and two thirds are for disk upgrades and floating IPs.
>>>>
>>>> Can you give me some more insights in how you are using our services, how they support your (or other contributors') workflows etc. And, since things generally tend to grow and accumulate over time: might there also be some room for optimization?
>>>>
>>>> I would be glad to hear back from you and understand your use case better. Thanks in advance for your beedback!
>>>>
>>>>
>>>> Best regards from Zurich - Switzerland,
>>>> Markus
>>>>
>>>> --
>>>> Markus Furrer
>>>>
>>>> cloudscale.ch AG
>>>> Venusstrasse 29
>>>> CH-8050 Zürich
>>>>
>>>> Fon: +41 44 55 222 55
>>>> Fax: +41 44 55 222 56
>>>> Web: https://www.cloudscale.ch
>>>>
>>
----- End forwarded message -----
2 years, 10 months
Developer presentations
by Thomas Holder
An idea I brought up in today's developer meeting:
Developer presentations to share knowledge, experience, and to promote
best practices.
Schedule: Either as part of the weekly developer meetings, or as a
separate event. E.g. once a month.
Ideas for topics:
* Warnings and Assertions best practices
* std::move and other modern C++ features
* How does Inkscape's garbage collection work?
* How to properly use signals (libsigc++)
* Why is direct manipulation of the XML tree discouraged?
* What is a node observer?
https://wiki.inkscape.org/wiki/index.php/Community_Development#Developer_...
I'd be willing to prepare some of these topics and to host the event.
I'll bring it up again in the next dev meeting, then we can maybe
settle on a schedule and see who is willing to contribute with a
presentation.
Thomas
2 years, 11 months
wiki access
by Epper Marshall
So I started following the instructions for compiling inkscape on Windows
and ran into some issues. I did figure out how to fix/get past the issues
but felt like the wiki could contain the information. I created a ticket:
https://gitlab.com/inkscape/inbox/-/issues/4112 but was wondering if I
could get wiki access to update the wiki. Or if someone else wants to
update the wiki that would be great too.
Regards
Epper Marshall
2 years, 12 months
openswatchbook hijacked
by Nozz
Hi,
when saving svg in inkscape 1.0.1, the file contains a link to openswatchbook dot org and that website appears to have been hijacked and is serving porn and possibly malware.
I'm new to inkscape so I was curious what that address is about and why it's in the generated svg file. If you could explain why a svg file needs url links in the first place I would love to know.
I don't know what relationship inkscape has with that website but you should contact whoever you think is the original owner and let them know of the situation.
Best regards
2 years, 12 months
