Comments (8)
@twardoch could you provide some situations where it would be useful to have this functionality?
from afdko.
It would be useful when the font developer has a standardized "template" or "master" FEA file(s) for a given glyph set, and the developer includes them via include();
and later extends some feature definitions. In general, it would greatly improve the usefulness of include
. One could easily modularize the template FEA files into script-specific portions and append them in sequence.
Also, it would be useful when extending the glyph sets of existing fonts. A tool wouldn't really need to present the developer with the entire existing FEA code. The developer would merely include some "patches". For example, let’s say that I add the glyphs uni0273
(LATIN SMALL LETTER N WITH RETROFLEX HOOK), and uni0273.smcp
to Source Sans Pro. I would merely need to write my uni0273.fea
file as follows:
include(SourceSansPro.fea);
feature smcp append {
script latn;
sub uni0273 by uni0273.smcp;
} smcp;
or
include(SourceSansPro.fea);
feature smcp +{
script latn;
sub uni0273 by uni0273.smcp;
} smcp;
That sort of thing. :)
A.
from afdko.
I see. Yeah, that could be useful.
from afdko.
I would say, this:
feature smcp {
sub a by a.sc;
sub b by b.sc;
...
sub z by z.sc;
} smcp;
feature liga {
sub f i by f_i;
} liga;
feature smcp +{
sub ampersand by ampersand.sc;
} smcp;
should create a lookup for liga, and two lookups for smcp, one of each is applied before the liga lookup and another after.
cc @brawer.
from afdko.
This actually already exists. If you provide multiple definitions of a feature, they are all used. Lookups are added in the order in which they are encountered, as always. Each separate definition of a feature generates at least one new lookup — no way to have the separate definitions for a single feature end up in the same lookup, without a lot of work. makeotf
does generate a warning when you do this, but not an error. No need for special syntax, like feature <tag> + {
.
from afdko.
Read,
Would it be possible to do something like that for the table definitions? It would be handy to be able to break apart the things like the OS/2 table for the general family things that you might want only in one place, and the font specific things. Say, defining the vertical metrics once for a family, but different Panose values per font.
I also understand that doing this could be a huge headache (what happens if there are multiple entries for the same value in different places), so I don't expect this at all. However, it would be a huge help in setting up FDK mastering for larger families where keeping things in one place only reduces possible errors.
from afdko.
You can accomplish this now by using the feature file include();
directive. This can contain fragments of definitions, not just whole table or feature definitions. I just checked, and makeotf is fine with a feature file include command that references a file which contains just the Panose definition.
from afdko.
Ah, my apologies. I remember trying this a couple of years ago and didn't get it to work (but perhaps I was trying with the name table). Very good to know, thank you, and apologies for not re-testing.
from afdko.
Related Issues (20)
- [otfstemhist] cannot specify glyphs via external glyph list
- [otfstemhist] -h reports unrelated options, wrong tool name HOT 1
- Unify format of external glyph names files across AFDKO tools
- [otfautohint/otfstemhist] Add tests
- use TTX tools to compile a otf file HOT 10
- [spot] alternate metrics ignored in class kern proof
- [otfautohint] (minor) outdated tool names
- [otfautohint] points “optimized away” in flex-like scenario (print only) HOT 15
- [tx] Crashing without error when using -decid option in -t1 mode
- Reordering of ligature substitution rules is considered harmful HOT 10
- [otfautohint] Mishinting of glyph? HOT 7
- [otfautohint] Consider adding flag to selectively skip overlap processing for some glyphs
- [makeotf] silently fails when GOADB has unexpected data
- [makeinstancesufo] & [checkoutlinesufo] multiprocessing vs progress bar, output improvement
- building fails on manjaro HOT 2
- [makeotf] substitution without target item does not fail HOT 8
- Pytest Error Encountered During AFDKO Compilation on Arch Linux HOT 6
- [checkoutlinesufo] XMLSyntaxError reading fontinfo.plist of temp UFO font HOT 3
- [makeotf] -r reports all unhinted glyphs individually HOT 1
- [buildmasterotfs] incompatible sources produced HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from afdko.