Closed ctrlcctrlv closed 3 years ago
@ctrlcctrlv Currently the Designspace spec isn't part of the UFO Spec, it is over at https://github.com/fonttools/fonttools/tree/main/Doc/source/designspaceLib. Closing this, you should file this over there.
I believe you filed this against the wrong repo, the DS spec lives at https://github.com/fonttools/fonttools/tree/main/Doc/source/designspaceLib
Also I would recommend a less argumentative tone, thanks.
That's very confusing, given that https://daltonmaag.github.io/ufo-spec/extensions/proposals/ URL and also that it includes a link to #84, but nevermind that, I will do as you say, and also, in my newly filed issue, not be so argumentative. :-)
I recommend updating the website because I was weary of filing something like this against fonttools/fonttools, first of all, that's not a Dalton Maag repo, isn't it primarily a Google managed project? And secondly I thought that repo is for bug reports in fontTools libraries. But, OK, if that's what is preferred.
fonttools/fonttools is managed by the fonttools community
I mostly agree with @ctrlcctrlv, but please try to be kind. Saying stuff sucks gets people upset and defensive.
I misinterpreted current stewardship of Designspace, due to this page:
Containing quote:
This is a proposed update to the Designspace file format that standardises the following Dalton Maag practices[…]
It used to be on this URL:
https://daltonmaag.github.io/ufo-spec/extensions/proposals/designspace-5
Which looked like:
However, right after I opened, this URL became 404, so I guess, either, it was an oversight, or that was very coincidental. I don't quite understand why it's down though, because the deployment is active:
Doesn't seem to be a higher level issue either. My website is up, and they share same four IPs actually.
[fred@🍇葡萄🍇~]$ paste <(dig A ctrlcctrlv.github.io +short | sort -n) <(dig A daltonmaag.github.io +short | sort -n) | gawk '{ORS=""; print $0, " "; ORS="\n"; if ($1 == $2) print "✅" }'
185.199.108.153 185.199.108.153 ✅
185.199.109.153 185.199.109.153 ✅
185.199.110.153 185.199.110.153 ✅
185.199.111.153 185.199.111.153 ✅
Whatever. The point of stepping through all of the above is that I thought that Dalton Maag had somehow taken over Designspace spec, which I found annoying. (Because I thought that they may have done so in order to support proprietary fonts, i.e. making the free standard worse, keep better standards internally so that proprietary fonts can do things free fonts can't. This is definitely too conspiratorial line of thinking even if DM really were in control of the standard lol.)
But:
I apologize for ignorance on this matter, I submitted fonttools/fonttools#2434 without the sucks
. I'm much more forgiving of free software, a lot of my software sucks too (if not majority) :-P
@ctrlcctrlv That Dalton Maag page was part of a PR for mini specs in the UFO (an idea from July 2020 that has gone stale but isn't dead, see https://github.com/unified-font-object/ufo-spec/pull/124 — as an aside Dalton Maag contributes a lot to open source type software, this being an example).
The authoritative spec for the UFO is at http://unifiedfontobject.org; anything else is a demo/trial/PR/noise.
Via https://twitter.com/fr_brennan/status/1452644352417800197
I was talking to a bunch of designers and very surprised they don't even know what the binary format allows because Designspace spec has so thoroughly boxed them in.
Designspace allows only a fraction of what is possible in binary format, that is to say, while binary format allows either GPOS or GSUB to contain basically any number of FeatureVariations lookups, Designspace constrains itself to only GSUB LookupType 1, Single Substitution. Despite there being obvious use for all the other types, especially GPOS.
I propose to deprecate
<rule>
tag, replace with<fea>
tag.<fea>
tag will hold a subset of Adobe FEA code. It will not allow you to insert anything at the toplevel exceptlookup
. Alternatively, if people prefer,<fea>
tag can be provided in multiple and there will be an implied wrappinglookup … { … }
.Problem solved, no need for @simoncozens idea of complex "variable FEA syntax" (cf. https://github.com/adobe-type-tools/afdko/pull/1350, https://github.com/fonttools/fonttools/pull/2432), no need to change FEA standard at all.
Besides, changing FEA standard is confusing because what, you're adding FeatureVariations to instance UFO FEA's? What if they differ in any way?
OK, I guess Simon would say "well I want a new font format which will allow a toplevel FEA", which, fine. Or someone else might say "I want a multiple master UFO with a toplevel FEA". Again, fine. (I disagree to both, I like UFO, but no need to slow down progress over something like that.)