-
Notifications
You must be signed in to change notification settings - Fork 448
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 add <fea>
#2434
Comments
<sub>
and possibly `<rule><sub>
and possibly <rule>
Note that I only proposed variable scalars in AFDKO. Feature variation syntax was @punchcutter’s thing. But both will still be needed because Designspace is not the only way to represent font variations. |
Yes, and it won't be too hard (I don't think) to just add to UFO spec that FeatureVariations aren't valid in instance UFO FEA's. Do your changes to fontTools have a function like |
One thing to consider: with |
Other question: why not allow |
(For the record, including .fea in designspace is a hard no from me, in case I'd have a vote in this.) |
Interesting - why? |
@belluzj As I understand it, in the binary format, #!/usr/bin/env python3
# This script is to be used because the Designspace XML format <rules/> element is incomplete and cannot express the full range of possibilities provided by GSUB.
# So, what we do is, we put the feature that we actually want to trigger when the OPSZ design axis is ≥ 48px into `ss01`. We then compile the font with the `ss01` and a fake FeatureVariations table that just changes `A` to `A.alt`.
# We then run this script to replace our fake lookup (only written to be replaced by us now with this script) with all the lookups triggered by ss01. Ta-da…
import sys
import fontTools.ttLib as tt
(_, otf) = sys.argv
f = tt.TTFont(otf)
lli = []
for e in f["GSUB"].table.FeatureList.FeatureRecord:
if e.FeatureTag == "ss01":
lli = e.Feature.LookupListIndex
f["GSUB"].table.FeatureVariations.FeatureVariationRecord[0].FeatureTableSubstitution.SubstitutionRecord[0].Feature.LookupListIndex = lli
f.save(otf) It takes the contents of feature |
The |
I think the point is that there’s nothing remotely special about rvrn as a feature, in terms of variations. Any feature can get a replacement table. |
The point of rvrn is that it's supposed to be applied first, regardless of lookup order, before any shaping features, and in all language systems, and it's always on. Hence: required variations — as opposed to any other feature variations that can, of course, be anywhere. |
@simoncozens was right, that was indeed my point. I am indeed aware that the number 1920365166 ( |
Let me soften/qualify: I don't think .fea should be embedded in .designspace like Frederick suggests. I'm open to add a field that references an external .fea file. (One per .designspace doc? One per Sidenote: The |
@justvanrossum I'm OK with dropping the part of the proposal that talks about putting FEA code in XML text children. I thought it was cool but if you really don't like it, what's most important to me is that this is possible, not necessarily how it's done; if we can put FEA path as an attribute, that works for me as well. |
I have updated the proposal. |
<sub>
and possibly <rule>
<fea>
コピペ of unified-font-object/ufo-spec#194: (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 … { … }
.The new proposal is to have
<fea>
be a child of<rule>
.Problem solved, no need for @simoncozens idea of complex "variable FEA syntax" (cf. adobe-type-tools/afdko#1350, #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.)
Alternatively,<rule>
can be kept, and<sub>
deprecated instead, with<fea>
living inside<rule>
instead of becoming the new toplevel. I don't like this since it makes less sense, I would rather<fea>
hold the<conditionset>
and have afilename
attribute, but whatever, it's OK.Detailed proposal
Add new section § 5.1.4 fea element as follows:
fea
element must have afilename
attribute pointing to an Adobe FEA.fea
without filename, or pointing to a non-existent filename, should be ignored when compiling a font; strict parsers can consider this an error.lookup {}
block, including thelookup
block.<fea>
appear before, after, or between<sub>
elements, the features within are to be applied in their XML order.The text was updated successfully, but these errors were encountered: