November 2021 - Inkscape Devel

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Regarding the serialization of Spiro control points
by Fred Brennan 28 Mar '22

28 Mar '22

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"

2 1

Inkscape PLC Meeting (moved to Nov 12, 2021)
by Ted Gould 03 Dec '21

03 Dec '21

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 1

Emoji handling - a mixed problem of system font management and application behavior - what is the part of inkscape
by Stefan Lechner 22 Nov '21

22 Nov '21

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 0

Thank You Message for Bryce Harrington
by Ryan Gorley 06 Nov '21

06 Nov '21

1 0