- Acting chair: Liang Hai
- Scribe: Caleb Maclennan
- Agenda: #28
None
- @simoncozens: Introduce the JSTF implementation experiments at Meeting 6
- @lianghai: Create and maintain a list of actionable items (distinct from any proposals) in the GitHub issue tracker
Bobby de Vos,* Caleb Maclennan,* Chris Chapman,* Chris Lilley,* David Corbett,* David Singer,* Duncan MacMichael, Fred Brennan,* Greg Hitchcock, John Hudson,* Jonathan Kew,* Josh Hadley,* Liang Hai,* Makoto Murata, Mehmet Oğuz Derin,* Nat McCully,* Nate Willis,* Ned Holbrook,* Norbert Lindenberg, Renzhi Li, Sairus Patel,* Suzuki Toshiya,* Vladimir Levantovsky*
* Formal participants of the FTCG.
The IRC channel recorded the following nicks:
liang, alerque, copypaste, dsinger, cjchapman, MURATA, Norbert, devosb, josh_hadley, mpsuzuki, mehmetoguzderin, reli_msft, GregH, John_Hudson, Vladimir, ned, dscorbett, spatel2, chris, nmccully, jfkthame
<reli_msft> Andrew Glass said he has conflict and won't attend
liang: Anybody new here? Next time I hope to use a personal zoom account so we can be more friendly to non-members.
liang: Attention to W3C COC, if you have other suggestions for how to be welcoming to newcomers let us know.
(None this time.)
liang: In the last meeting Simon did a great job (I talked too much) but we didn't have full resolution on some issues. Re Action 1, because of W3C arrangement with MIT we can't easily access some controls, next time maybe we will use a personal paid Zoom account. We avoided other W3C meeting conflicts, but Simon is not here because of other conflicts. During this meeting please note which items we don't have time to discuss and propose them for the next meeting agenda. We'll skip Simon's items today. I'll try to balance time slot selections based on who is interested in specific topics, please note if there are some you are interested in. We have people in different time zones, so when picking meeting times it is helpful to know who is interested in what.
liang: So Peter C. just announced today that OpenType 1.8.4 was released on Twitter. Check out the change log, it's pretty extensive. Anyone want to comment on this release, call attention to any changes?
Vladimir: Just want to remind everyone that the working draft amendment process has started, definitely requires more proposals and participation to be complete. The impetus for the amendment started as the COLR proposal but covers lots of issues, if there is anything you want to include you are welcome to make proposals. There is a draft posted on the mailing list and a number of related issues posted on GitHub. We have until maybe mid December to gather contributions for the next working group meeting in January.
liang: What's the relation to OT 1.8.4 and the OFF now?
Vladimir: 1.8.4 collected a bunch of minor changes, corrections, typos, technical fixes, etc. Most was community contributed. But introducing those by amendment would be an insurmountable amount of work. When we were discussing COLR and other changes that needed to go to the next amendment now vs. what would go into the next full edition 5 we decided the OT 1.8.4 would be better suited for the latter.
liang: For those not familiar with the current process of preparing a standard through ISO it's a very different process than current modern software release process.
Vladimir: (scribe missed some) Many small changes like typos, copy editing, mixed small fixes are easier to do in the next full version than to do by amendment.
liang: Working on the agenda I categorized topics into sections: some proposals to do tasks or spawn projects, or some FYI projects just useful to be aware of. One interesting one to be aware of from John H. The summary is short but the topic is very deep.
liang: The related issue here is basically links extracted from Google Docs or other places, let's go through them briefly. The first one is what prompted me to have this group. There is a huge group between complex scripts and how some languages are actually shaped. Today I will introduce some more specific proposals as part of this as specific paths that we can more closely relate to the UNicode standard. 3. Haven't heard more on this frontier, but someday we may need an overhauled font format. 4. 5. 6. Fred would you like to move this item to the next meeting's agenda?
this proposal should be withdrawn to be honest, it is very old and was from before we even knew what this group would be
it's from before this group even had a name
it needs total rewrite to be actionable
copypaste: oh, it's sad to hear that you think about withdrawing IDS rendering...
mpsuzuki: do you want to talk more about it? it doesn't need to be withdrawn, but my document are just broad ideas
there's nothing actionable for the format
i don't say "add a field to X table" etc.
copypaste: ah, I'm interested in this item, but yet I'm not ready to propose something concrete in this meeting, sorry. I would check in later, for a future meeting.
mpsuzuki: let's talk more and decide whether or not we want to talk about IDS shaping at next meeting or not.
ok!
copypaste: thanks!
im still interested in the issue but i don't yet have concrete recommendations :)
copypaste: good to hear that you keep your interest!
liang: 7. Behdad; we can pretty easily add more shaping? to OTL. (scribe got lost) 8. 9. 10. 11 is similar to 3, maybe should be merged. 13.
John_Hudson: GH Issue 23: These are discussions from the last 5-6 years in OT working group or VF working groups. Stalled because of lack of maintainers for OT spec which has plagued us for a while. Some also because we never settled on an approach to take. Issue 23 relates to fantasai's proposal, idea is to allow fonts to have script specific vertical metrics.
John_Hudson: in OT we have script specific tagging so we have infrastructure. The related WG focused on the BASE table and things like the possibility to have deeper descenders for Arabic, taller ascenders for Vietnamese, etc. Fairly simple model but something that needs to be specced into OT 1.9 or OFF and supported through existing models.
John_Hudson: The existing BASE table isn't well understood and what it is for is rather specialized, what is defined is limited. Mostly used by CJK fonts and software that handles them and adjusting baseline alignment between Latin and CJK.
John_Hudson: We can coordinate with the W3C, they had a recent idea about leading for frames and boxes, looking at metrics in fonts but recognizing that those are limited in their understanding of scripts and unreliable. If we hand something more specific that had the designated funcion there would be an impetus to get the BASE tables correct.
nat: The reason to use BASEtable in to allow other scripts to be aligned with CJK. If we have font designers involved and adding metadata we wouldn't need so many heuristics to guess how to align stuff. True that Latin font metrics are Latin specific and basically useless for cross-script alignment. There isn't a mechanism for this kind of controls, if we had entries that document fonts ascender, descender, etc. in your font then even if your font doesn't have other scripts the shaper can compare with other values to align between fonts. And for variable fonts improving how the BASE table handles values is already being fixed.
John_Hudson: When the first discussions started we were in pre-variable days, needs review now. The majority of font developers don't understand where this data will be used and most tools don't support it, no useful interface to preview what values do. CJK use of em-space is standardized and can be useful for this, but since other scripts don't standardize this it's less useful.
nat + john: (Some discussion scribe missed)
liang: Can you scribe for a few minutes?
(more missed baseline / script discussion)
copypaste: About number 6 briefly, document was from before this group. I'm still interested in the issue but nothing is actionable right now. The issues aren't defined enough to say what to add to what table. We'll talk more before the next meeting to organize it to be actionable.
Fred: Still interested in the IDS shaping proposal issue. No concrete proposal though. Suzuki wants to talk more about it and we may have more to share.
copypaste: thank you for commenting on that!
ned: Since Adobe products are the primary consumers of the BASEtable so far it would be helpful to have as much information as possible. We see value in the BASE table whether or not it has immediate uses and want to understand better what it could do.
\o/
ned: Our products do currently support line metrics, as a point of experimentation we have that in place. Not language specific because the BASE table isn't language specific just script, if that should be addressed we should overhaul it to take language tags but if we are just talking scripts we have some precedent for doing that already. You can put stuff in there that is script specific as a key value pair. sidebar or ideographic representation, want to see coordination with ____, so naive script item association doesn't work really well, need to be tagged with what after not what came before. We would like to see more use of the BASE table if it is good for that, and as John noted we need tooling that facilitates its use and we should talk about better authoring tools.
(scribe’s zoom died)
(scribe back)
liang: Ned is it okay with Apple to attribute comments to your name?
Ned: Okay as long as there is the opportunity to note what is not to be noted. The more than we surface line metrics and different script baselines (in tooling?) the better.
John_Hudson: Also some related CSS possibilities to explore here, when you have scripts with non-matching values which end of things you want to adjust, downstream discussions need to be had.
Ned: A call was put out in regard to that.
sarius: As nat has noted Adobe has been using the BASE table. We did specify at some point what min/max meant, whether mean or typographic. The consensus was that it really was the typographic value. Third more and more as engines don't trust the values in fonts and use more heuristics—as we add more and more values we should talk to platforms that have concerns about even reading
these values. We want the info to be useful and to be read and used.
Renzhi: (scribe unable to follow, sorry my bad)
<reli_msft> alerque1 points: 1. we already have BaseLangSysRecord so we could leverage that; 2. Care about compatibility: make the new metric behavior opt-in instead of opt-out.
John_Hudson: issue 24, post line breaking layout. BIG topic. The topic originally came up in April 2014, discussions went round and round then and in later meetings.
John_Hudson: First OTLB, then gsub, then OT, then gsub, round and round, then the layout engine takes over and line breaking gets done and no other OT rules get applied. Where this could be used in justificacion, for example current Arabic justification is pretty crude. Inserting kashida is purely character based. Word as an example looks at the space needed on the line, looks at places it could insert kashida, looks at how many it could fit, allows them to overlap. Only works with flat kashidas, doesn't work with curved kashida, doesn't work with some styles of Arabic such as Nastaliq, doesn't handle script specific behavior. Important because all OTL happens before line breaking, nothing happens afterwards. Some scripts have special ways of handling the change of direction that end up in different runs. Idea was maybe we could apply some features to a single line with no breaks in a single direction. One idea I had was to have a ring fence of things that could happen post line break.
Notes on BASE table: As far as CJK metrics, the ‘ideo’, ‘idtp’, icft’ and ‘icfb’ entries are intended for use by fonts to align their glyphs in a harmonious way to other CJK fonts, and to inform the layout engine what the intended CJK line height should be.
Adobe uses the ‘ideo’ baseline to ‘idtp’ as the CJK line height (aka the CJK embox) for that font, and aligns all other fonts’ CJK emboxes to that line height’s top, center, or bottom as needed. When setting a non-CJK font in such a CJK line, the app has to use a heuristic to align it properly, calculating that non-CJK font’s CJK embox. If all fonts had a BASE table entry for the CJK embox, such heuristics would be unnecessary.
The Ideographic Character Face BASE table entries are used when you want to align something to the average black area of ideographs in the font, or you want to express what you assume to be the size of ideographs you have in mind when sizing the glyphs in your font. For example, kana subset fonts or Hangeul subset fonts that lack ideographs can set the ‘icft’ and ‘icfb’ BASE table entries to what they want the ideal ideographic siz[CUT]
John_Hudson: Another idea would be a flag to have certain lookups apply to certain features after line breaking, make those options available to post-linebreak shaping. Of course existing software does it's own line breaking already, a lot of different algorithms, editors, browsers, etc. will do different line breaking even given the same text input, font, and space.
nmccully: Comment about cross-script justification. There is a need for layout engines to have a user facing idea of creating a priority order for scripts in a line. Some scripts have different priorities. English=space out glyphs, scare glyphs. Perhaps when quoting Arabic words in some other script paragraph you may not want that word to stretch like it might in a native Arabic context. If there was some way to specify this it would go a long way to achieve desired results. Already running into with Korean/Japanese.
John_Hudson: Question of prioritization of what happens post-linebreaking. We have the JITS table, Simon out to figure out if it was implementable, verdict was it was almost there but not quite. As Nat said you could specify some methods to use over others in say, Arabic. Back to prioritizing scripts over others; some of me feels this isn't quite font level information. Dependent on content of paragraph / line. Is this embed Arabic in Latin or vice versa? Already a weird gray area in various algorithms.
ACTION: Simon to introduce JSTF experiment experiments.
knuth-plass paper: http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf
reli_msft: If someone wants to do justification via the JSTF table or whatere is there an approach they could follow? (apologies from scribe who can't hear well)
liang: You're on for a minute.
back
nmccully: (justification)
John_Hudson: Issue 25. Proposed axis mostly optical with one clear effect, ___ had idea of parametric axis, not present user with 20 sliders, map parametrics to virtual axis that a user would control that mapped to multiple values in parametric axis and controlled them in unison. (scribe got lost in the forest) Part of this discussion got lost through the mess of 4 companies having a lot of impetus to get a variable system out the door, later once something shipped not so much impetus to continue innovating.
liang: I'm out for a minute, sorry.
spatel2: is it worth introducing a break change?
liang: is the situation of multiple axes sharing the same tag (and thus allowing higher-order interpolation) providing a way forward for non-breaking changes?
John_Hudson: Separate topic. We should at least document the situation in the spec and define how the behavior should be.
reli_msft: avar2 would simplify the hoi situation.
John_Hudson: corporate culture. I can see different companies may see breaking changes differently.
(Scribe back. Missed the current topic though.)
Norbert: Recent Khmer discussion. Confusability issue. Different and incomplete cluster definitions between specs and implementations.
Norbert: Another meeting this Friday if anyone is interested let me know.
liang: I'll try to update the issue in relation to that discussion. For the next meeting, we already have JSTF tables to discuss. Any other topics you want to see in the next meeting.
John_Hudson: Not specific topics but there is a lot of stuff mapped out here. Great to get together and discuss; but we don't have a way to get from these discussions to work items. Khmer work might be an example, but we need a workflow for how to get from discussions to a work item.
chris: Though we did, work not done here, spawn working groups for specific tasks.
John_Hudson: In theory yes, but ___
liang: Task is to sort through all the issues and sort them into major topics that there is enough energy to work on. This group is everyone's side project.
John_Hudson: Is there a way to take topics from here for discussion and move from a 'topic' to 'a thing to make'? How do we find the appropriate channel to work on any given topic as a work item once we get to the point where we know there is something we want to make?
spatel2: Does the CG spawning a WG indicate we think that idea has higher priority than others?
liang: Official time up, no official resolutions, but staying to chat.
spatel2: What does the CG spawning a group mean?
liang: Group forming purely based on interest and volunteering to do a charter etc, not really a group endorsement of priority.
Norbert: Also different ways to charter groups. For 32bit ideas for example a group could just evaluate what the issues / benefits might be and come back to report.
+1 to Liang's point of not needing a group for every exploratory discussion
liang: Investigation doesn't really need a new group. Lots of overhead (see this group) that is not needed just for research. New groups needed for technical contributions.
spatel2: We can also keep discussing on OFF forums as has been happening for a long time.
liang: Yes, especially for lower level stuff. Hopefully we can offload more and more format level discussions to OFF GitHub or wherever so we can focus on more distinct fields. 32 bit proposal is quite actionable but somebody needs to keep pushing it. Feel free to open issues for new topics, comment on existing ones, to get ideas forward somebody has to write something and respond and so on. Eventually it becomes actionable. font-text issue tracker more used as a lightweight forum.
ACTION: liang to create and maintain a list of action items.
John_Hudson: Need an issue tracker to track issues.
liang: Most of the other items from today's agenda were from me or Simon who is not here, will just carry over. At a good place to do some documentation work, I'll try to kick start some of that stuff.