Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[designspace] Proposal to deprecate <sub> and possibly <rule> #194

Closed
ctrlcctrlv opened this issue Oct 25, 2021 · 7 comments
Closed

[designspace] Proposal to deprecate <sub> and possibly <rule> #194

ctrlcctrlv opened this issue Oct 25, 2021 · 7 comments

Comments

@ctrlcctrlv
Copy link

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 except lookup. Alternatively, if people prefer, <fea> tag can be provided in multiple and there will be an implied wrapping lookup … { … }.

Problem solved, no need for @simoncozens idea of complex "variable FEA syntax" (cf. adobe-type-tools/afdko#1350, fonttools/fonttools#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.)

@benkiel
Copy link
Contributor

benkiel commented Oct 25, 2021

@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.

@benkiel benkiel closed this as completed Oct 25, 2021
@anthrotype
Copy link
Member

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.

@ctrlcctrlv
Copy link
Author

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.

@anthrotype
Copy link
Member

fonttools/fonttools is managed by the fonttools community

@eliheuer
Copy link

I mostly agree with @ctrlcctrlv, but please try to be kind. Saying stuff sucks gets people upset and defensive.

@ctrlcctrlv
Copy link
Author

ctrlcctrlv commented Oct 25, 2021

I misinterpreted current stewardship of Designspace, due to this page:

http://web.archive.org/web/20211025155230/https://github.com/daltonmaag/ufo-spec/blob/gh-pages-dama/_proposals/designspace_5.md

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:

image

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:

image

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 rather blame a corporation for not fixing things than individuals for breaking them, even tho I know who individuals are

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 ctrlcctrlv changed the title Designspace <rule> sucks [designspace] Proposal to deprecate <sub> and possibly <rule> Oct 25, 2021
@benkiel
Copy link
Contributor

benkiel commented Oct 26, 2021

@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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants