JLReq TF font SIG meeting notes 10/5

https://github.com/w3c/jlreq/issues/308 <https://github.com/w3c/jlreq/issues/308>

––––––––––––––––––––––––––––––––––––

JLReq TF font SIG meeting notes 10/5

Attendee

ando, atsushi, florian, karino, kida, koji, masao, miyata, murata, nat, shinyu, tahara, tajima, taro, tlk, toshi


updates re:UAX 50 change proposal

Kida updated the state of the proposal. It was finalised, and submitted to the UTC on 10/1 (and the document number L2/21-222 was assigned). However there happened to be an UTC meeting #169 <https://github.com/w3c/jlreq/issues/169> on 10/5 & 7, as the deadline of the document submission for that meeting is 9/27 Monday, most likely the proposal will not be covered at this time. The next meeting is on January.

When this proposal is agreed, all AJ1 fonts become UAX 50 compliant. It means the number of UAX 50 compliant Japanese fonts suddenly increase from only a few to hundreds of professional quality fonts.


Overview of supporting the layout of Japanese punctuations through OpenType fonts

https://docs.google.com/document/d/12xbvcy1_x2GTvln7nKhA0NEVke63uDpDasGCYbDxhu4 <https://docs.google.com/document/d/12xbvcy1_x2GTvln7nKhA0NEVke63uDpDasGCYbDxhu4>
Ishii-san went over the document he is developing, and explained the overview of how the layout of Japanese punctuations can be supported through OpenType features.


usage of terms

As the definition of many usual terms including full/halfwidth, beta, virtual body, etc. are found ambiguous, he avoided using them. More discussions would be necessary to decide on which terms the document should use (kida: actually it would also have impacts on the terms we’ll use in the digital text version of JLReq (aka JLReq version 3))

fwid (&hwid/twid/qwid)

However it allows implementing the feature with GPOS, doing so causes issues with applications. However it was requested to reduce the number of glyphs so it fits within 0xFFFF glyphs, no known fonts use GPOS to implement fwid. The document would recommend using GSUB.

palt / vpal

issues with kern: the OT speification states that “If 'kern' is activated, 'palt' must also be activated if it exists”. It also recommends that ‘kern’ “should be active by default”, and ‘palt’ “would be off by default”. There is a clear conflict within the spec. As the result there is a conflict between implementations. Browsers activate ‘kern’ by default and ‘palt” is off by default. Adobe fonts assume ‘palt’ is turned on when ‘kern’ is applied. so, turning on ‘kern’ without turning on ‘palt’ will make unexpected results (taro-san). wow…
palt/vpal can also be implemented with GSUB or GPOS (do we recommend GPOS?). Would recommend GPOS for the same reason for ‘fwid’.
discussions re: the term “haba (width)” and “okuri (advance)”. Use them carefully according to the context (bin-sensei)

halt / vhal

discussions re: the term “overlapping”. The space that should be removed are not necessarily overlapping (bin-sensei)
The specification expects or assumes that the resulting glyph be a half width. However, there are cases the glyphs are not a half of the body. the spec would need to be updated to clarify on this.

chws

like ‘kern’ it is defined between two specific glyphs. The assumption is that it is turned on by default for the whole document.

applications

has JLReq TF made recommendations on how punctuation should be processed at line starts and end? (ishii-san). wrote up a document but it is not yet official (bin-sensei). Let’s finish the document (kida).

how we proceed from here

the document is well written and very much useful. Ishi-san & kida would like to publish it through JLReq TF (agreed)
would like to discuss at CITPC also. we would be able to get additional feedbacks. first we’ll share the recorded video of today’s meeting with them, and also would like to invite Ishii-san in person for discussions. (kobayashi-san, tahara-san)
let’s provide feedback using comments feature on the google doc. If anything significant we can discuss on the list or the meeting.
(as seen in the discussions) there are issues with OT feature definitions. Ishii-san would like to develop this document with JLReq TF, publishing it through JLReq TF, and would like to propose revisions of the OT feature definitions (ishii-san). what is the official path? (murata-san). I think it is W3C cg-text github. will check (ishii-san)
would like to refer this document from the digital text version of JLReq (aka JLReq ver 3) (kida)

The digital text version of JLReq

We’ve been assuming that the digital text version of JLReq would be called JLReq ver 3, and and positioning it as such. Richard suggested to use a different name. after discussing with Kobayashi-san and Murata-san, we see benefits of using a different name. that is we can clearly focus on digital text (kida). Agreement by attendees. The tentative acronym is JDLReq.
in JDLReq I would like to include more background stories on why specific features are taking the current form. It is important to understand the history of the technology when we are evolving (kida)
Let’s discuss further at the next meeting.

The next font SIG meeting is on 10/16