- Acting chair: Liang Hai
- Scribe: Simon Cozens
- Agenda: #48
None
-
Liang: Discuss CJK punctuation spacing topic at Meeting 10.
-
Liang: invite Florian, Ken Lunde (about the chws feature etc), and Koji for the CJK punctuation issue.
-
Liang: Schedule next meeting with a Doodle pool. Prioritizing the aforementioned guests and Nat.
Bobby de Vos,* Christopher Chapman,* David Corbett,* Erin McLaughlin,* Greg Hitchcock, Ian Prest, Jany Belluz,* John Hudson,* Josh Hadley,* Kamile Demir, Laurence Penney,* Liang Hai,* Nat McCully,* Nate Willis,* Ned Holbrook,* Neil Patel,* Norbert Lindenberg, Renzhi Li, Richard Ishida, Simon Cozens,* Vladimir Levantovsky*
* Formal participants of the FTCG.
Liang: changed W3C affiliation to Typotheque. Technically no longer acting chair. We have no chair! Everyone is welcome to volunteer, and you can nominate anyone on our W3C page. That was how I accidentally became the chair! Technically we will need a new chair, but I feel I have not been very good at maintenance, so if anyone is interested, please leave your GitHub username so you can be added as a repo maintainer. This helps with approval of Pull Requests, etc. Have been thinking about reverting the branch protection to a more relaxed one as currently we don’t have significant contributions to the repo.
New people to self-introduce
Richard Ishida: I18N lead at W3C. Don’t expect to follow everything but would like to listen in.
Liang: Please talk about your tools and things happening in the WG!
Peter Constable: New affiliation! Now working for Microsoft. New role encompasses Unicode / OpenType standard coordination.
Liang: Last time we had some next steps about the script itemization issue: proposal to UTC. No progress since last month so someone needs to take the lead on that. I also need to collect test cases on that.
Peter: I was anticipating to work on the proposal but was waiting for new position to start.
Liang: Keep nagging Peter for the proposal!
John: Font reordering proposal. In Indic shaping model (v2 and USE) there’s a bunch of features that are applied, then reordering, then more features. All discretionary stuff happens afterwards. Idea is orthographic shaping, then reordering, then typographic refinement. However, as in some scripts conjuncts can be ligated / half-form / explicit virama, this affects the reordering. In Devanagari, a font with a vertical ligature for a pair of retroflex consonants as the default rendering would be handled in cjct which is applied before reordering. The ligature forms, and let’s say there’s a short i-vowel matra. The reordering puts this before the whole ligature. Then the discretionary features. But the convention is that if that combination was displayed with an explicit virama/halant, if it’s the default in this font or the user has inserted a ZWJ, the reordering fails as the vowel only moves to before the last consonant. The virama forms an explicit barrier to the reordering.
Richard: The W3C article has pictures!
John: General problem is that the reordering is dependent on the [conjunct] prior to reordering. In picture in article, a cluster with an explicit vowel-killer is not having its i-matra moved all the way. Because the reordering is dependent on cluster formation / display as a result of the features prior, we don’t have a way to afterwards make any stylistic difference. Can’t be done as a stylistic set to always show the vertical or horizontal layout, and still have the correct reordering. The reordering has already happened when discretionary features are applied, so the only way is to use the control characters, which is awkward for users, requires keyboarding / search-and-replace macros etc. If stacked ligatures are the default but the user always wants horizontal layout / explicit virama, they can’t style that by selecting text and hitting a button. This has been a long problem as it means we need to make decisions about what the default display is going to be even though that may not be user preference. My idea is that we define some new discretionary features that would be processed prior to reordering. I don’t think there’s a reason why not, although there are some practical issues.
Peter: This is going back over 15 years! I specced out the revised shaping behaviour for Uniscribe (dev2 etc.). My recollection is that that reordering behavior is conditioned by having a separate halant and you can control it by ligating. If you want the side-by-side conjuct with visible virama you can ligate consonant/halant.
John: That isn’t the problem.
Liang: There isn’t an opentype feature to control this before the reordering.
Peter: It’s not clear to me there needs to be one.
John: One scenario is the opposite one - the user wants explicit halant with ikar stopping at the halant and not moving to the front of the consonant. When cjct feature has been used to ligate but the user wants to use horizontal display. The user currently has to use ZWJ and can’t make a stylistic choice.
Peter: OK, I can see the issue.
John: It works both ways, whichever the default is - conjuct or horizontal. These cases are complicated by the possible presence of a reph or ikar within that sequence.
Renzhi: One approach would be instead of choosing a set of fixed features would be to add a flag to features to make them apply before reordering.
Norbert: Then implementations that haven’t been updated to recognize the flag would apply the lookups at the wrong time.
Simon: I have some ideas for how OTL 2.0 could be made more general.
Liang: My feeling is Indic2 is already too smart! It’s intended that Indic shaping requires preprocessing but when preprocessing is split into two or more parts in between the application of features it becomes two features. Why should this be controlled by shaping at all? ISCII encoding is bad and why is it OpenType’s job to fix it? Why not just switch to another font with same outlines but different GSUB table.
I would prefer us to move to a more understandable topic!
Simon: Small announcement. Last year's meeting to do with UFO file format and as part of that we talked about how feature languages should interact with that. We will have that discussion in the next couple of weeks. Link to the issue in the agenda. If you’re interested in talking about future directions about the feature language. Example: How to handle variable font, features across designspace, Certainly needed for Adobe FEA. Also to share what we feel can be useful, esp for the Adobe syntax.
Bobby: Yes, sign up for Doodle poll! My group produces fonts in minority scripts using Graphite/Adobe. We’ve extended the Adobe language to help us. We’re doing lots of things to minority scripts that aren’t used in the main language so we need all the powers of FEA. One thing is: font designers will place an attachment point and how do we get that to our lookups. We have a tool which reads the UFO and puts the anchors into FEA. When talking about OpenType they said treat OpenType as an assembler. We extended it as a macro assembler to give it more power. We addressed some semantic issues like having classes on both sides of a substitution. Adobe FEA has mark class but not base class. We generate base class anchor statements and then produce an attachment state. It also works for cursive attachment as well.
We can also use this for mark-to-mark, and for ligature attachment. Our preprocessor expands everything to standard FEA.
For more advanced problems we have a for loop. One example calculates a right guard. In graphite marks keep their width, so when you add a mark the position is advanced including the width of the mark. This calculates the width and if it’s greater than zero we can adjust the spacing. You can put Python into this and do whatever you can get Python to do!
Ifinfo can conditionally run through our FEA file. If you have multiple families using the same feature file we can make things conditional on the name of the font etc. We can reuse our code across families. Kernpairs will read the kerning information out of a UFO and put in the kerning statements. We allow classes on both sides of sequence mappings. You can have nested classes. Classes in alternate lookups.
Used in production, Python 3, MIT license, on Github. See documentation in agenda link. We use it across a lot of our fonts.
Liang; FEAx a better name than FEE!
John: What about variable fonts? You can’t currently specify multiple GPOS sets and have them interpolate in FEA.
Bobby: We’re not making variable fonts, although we are interpolating in masters. So the kerning values may change. This will let you produce weight-specific positioning information. We run this on master FEAx and for each UFO gets custom positioning statements. Martin said the kerning values would interpolate nicely in a variable font.
John: If you have a variable font with GPOS, you can interpolate, the problem is making one in the first place.
Renzhi: If the topology of the kerning table changes between masters, you may have to dice the metrics to make the interpolation work!
John: Mostly it’s a tool issue, the tools have been built to share GSUB and GPOS exists separately but if you put it
Simon:
[Introducing the status quo of building VF, the fontmake approach of building static fonts first when merge them]
[“One shot” solution directly builds binaries from source with variation knowledge. But this means OTL code needs to be aware of the designspace, etc.]
[Demo: dots in an Arabic font pops up when there isn’t enough space between two tall stems around.]
Glad to hear some people find this useful! I like to write articles describing how writing systems work in a way that creates paralells across orthographies. To do that I need lots of little tools myself - Uniview, character pickers, etc. I also wanted to mention what I do at the W3C. W3C I18N WG does three things: writes educational materials to show content authors and developers how to use the features which make the web international, [xxx] specifications coming out of W3C and Unicode, and we started surveying languages around the world to try to find barriers to their use on the web.
Language matrix shows languages on the side and typographic/web features on the top, colors indicate whether there are obstacles. We have a bunch of groups we’ve put together based around a repo, repos cover most of the world now; don’t necessarily deal with their languages can be added. Described in https://w3c.github.io/i18n-drafts/getting-started/languagedev.en
We need more help. Please participate! We’d love to hear the barriers that you’re facing to use their language and script on the web. You can get involved in different levels. Another page https://www.w3.org/International/talks/1810-paris/ - a talk on “making the WWW worldwide”.
We have a framework in which to do this work which looks pretty good. Same framework across all these languages. Documents where we’re trying to document the gaps which exist and now starting to look at what we need to do to bridge them. Look at specifications; is it specified, does it work in browsers, etc. Planning to track all that. We have questions and requests for information. My personal stuff: https://r12a.github.io/
Liang: This stuff is a little further from the topics we talk here but we need to make sure the technology we talk about here is directed towards specific needs, not just to make English fonts fancier. From the tons of documentation W3C have been working on we can find some techincal requirements we need to work on, as well as lots of resources that can be very helpful for your understanding of the situation. Richard also knows a lot of people in various fields and can put you in touch with the experts!
Richard: One app in particular - Uniview. Quite useful because you don’t need a font to see them. I’ve created glyphs for all of them.
Jany: We spend all day on this site!
https://r12a.github.io/uniview/
Liang: Particularly helpful as it is on the web and you can share it.
Vlad via Liang: Not much happening other than minor updates to COLR1
Vlad: They happened in public Github. We’re wrapping that up and next stage is open ballot. Right now informal drafting process. Once formalised it will be harder to make significant changes. Everything else we’ve been updating is being packaged for presentation to the WG. Last discussion on GitHub was mainly about how to present the changes. We want to paint them as final touches, not a final version of the spec.
Lorp: I haven’t seen much / any evidence of the team working with any type designer or graphic designer on the potential of this new format. Working with a real designer might show up some limitations or expectations they have from SVG which might turn out to be trickier than they expected.
Liang: OT has never been implementation-driven!
Lorp: Would be good to get someone with extensive experience with SVG involved.
Vlad: Has been an effort to implement this internally for Noto Emoji design. It was Noto Emoji that exposed the fact that without variable color the data structures would blow the file size of the font.
Greg: Peter has been working on this. Google and MS designers are working on this and a feedback loop has been established.
Vlad: May not have direct feedback but comes through the implementers.
Lorp: Could we work towards public demos at ATypI May?
Liang: No specific plans for next meeting so no need to schedule experts, so default to next month.
Liang: Florian’s issue?
Ned: Can we get Ken involved?
ACTION: Liang: invite Florian, Ken Lunde (about the chws feature etc), and Koji for CJK punctuation issue.
ACTION: Liang: Schedule next meeting with a Doodle pool. Prioritizing the aforementioned guests and Nat.
ACTION: Discuss CJK punctuation spacing topic.
Nat Mc: jlreq met last night and said there are some issues which still needed to be added to fonts to allow correct display of Japanese typography and they would be discussing this in their next meeting. We should get the concerns around chws and current implementation around the table.
Liang: Feel free to use the issue tracker as a suggestion point to create agenda issues for the next meeting. Next meeting in around four weeks. Now we need to consider this topic!