Japan Language Requirements Task Force: Evolving the JLReq document -- 17 Sep 2019

<scribe> scribenick: dauwhe

<scribe> Meeting: TPAC Breakout on JLREQ

nmccully: welcome
... my goal is to introduce JLREQ
... and talk about thoughts about improving JLREQ
... including issues about the web, but not only the web
... I've been workinng at Adobe for 21 years
... I wrote the Japanese composition engine in InDesign
... and I'm interested in improving text composition across the creative suite
... and help bring those improvements to everyone via CSSWG, etc
... [ does presentation ]

<r12a> jlreq links: https://github.com/w3c/jlreq/ (scroll down)

<fantasai> Major groups involved in JLREQ: JAGAT, APL, IDPF (now W3C), JEPA, EBPA

<myles> http://www.ebpaj.jp/images/kumihan-en.pdf

<myles> http://www.ebpaj.jp/images/youbou.pdf

<myles> https://www.w3.org/Submission/2017/SUBM-CSJTUWT-20170102/jlreq-analysis.html

florian: I was part of making this doc; what this adds to the other docs is an analysis of whether we have a spec, and/or an implementation
... it's somewhat subjective
... a gap analysis was useful
... what should we focus on?

nmccully: there are a lot of orgs that are trying to codify their requirements, with many competing requirements
... it's interesting that things like ruby are not the highest priority for the publishing industry
... it's hard to wade through the gap analysis and come up with next steps
... our goal is for JLREQ to become more clear for implementers
... and help people make decisions of prioritization

<myles> https://juntajima.github.io/XMLPub_EPUBRSCheck/

nmccully: JAGAT has done a comparison of e-readers
... and they all have proprietary implementations on top of web tech
... kindle, kobo, ibooks, MS Edge, etc etc
... and they test various features across platforms--andriod, iOS, etc
... this is another indication that things are all over the map
... implementations differ greatly
... the new JLREQ task force will go through the gap analysis and add more information and background
... to guide the production of new tests
... to see if there are big holes in current implemtations
... there are new frontiers in layout around spacing, justification, etc
... we want definitive tests
... there has also been errata for JLREQ
... there are 35 open PRs right now
... and we want to improve the english translation

<myles> https://github.com/w3c/jlreq

nmccully: one comment about JLREQ is that there is no priority info
... I agree, but efforts to make granular prioritization risk separating features that should be together
... some features will be difficult or expensive to develop
... so we want to describe basic features that are still missing
... and then look at how many people are affected by more complex features
... to help prioritize

rniwa: it would be great if we could say what percentage of books are affected, what would enable more content

nmccully: the 2nd point is about the tests; we want what JLREQ describes to be possible to produce

myles: css tests?

nmccully: yes

florian: re: implementing jlreq
... we need to be careful about what we mean; it's meant to be high-level
... not an exacting description
... jlreq is not meant to be implemented; you derive a spec from jlreq and implement that
... it's not great if only one person does that work of reading jlreq and writing the specs
... but the process needs to be JLREQ > incubation of CSS spec > ? > profit

nmccully: that's a good point
... there does need an intermediate step of sharing and describing and specifying

Glenn: that's what we did in timed text WG
... but that was done independently of CSS

florian: absolutely
... but sometimes people come to APL, and say we're trying to implement JLREQ, but JLREQ is not a spec

makoto: but that's what people do

florian: there's a missing step

makoto: it provides hints, not answers

nmccully: common books... the picture I showed earlier, a simple book with lots of things going on within the lines
... and it's very different than western typography
... a criticism of JLReq is that it doesn't address other types of books
... like dynamic content, other verticals
... so we don't want to end up with a hybrid of western typesetting and japanese typesetting
... I find it more readable than JIS X 4051
... it was written with deep experience from the kumihan operators
... but it's hard to understand by people without a deep background
... we want to talk about text metrics
... it was not fully understood in jlreq
... these issues come back in issues from customers
... they want the fine control they had in print on the web
... so the standards should support what these people are trying to do, and then implementations can improve
... the pre-eminent type expert on the committee left some things out because there was not a single clear answer
... saying there's no clear answer is better than leaving it out, and saying why is better yet
... one example of what I'm talking about when I say there's great experience there is in this para (in preso)
... "spacing around punctuation"
... I couldn't make this para in InDesign due to a bug
... the 2nd line is compressed. 1/3em between something and something, 1/4 em between other punctuation
... because the last word is 3 syllables
... and that forces fourth line to be slightly extended
... but InDesign can't do compression unless you have a bunch of characters at line end (???)
... even if I had a keep restriction, it doesn't compress the line
... the amount of compression being different for these different clusters of punctuation was because of their experience
... and other operators would do it differently
... which is why japanese typesetting is highly customized, and needs to be highly customizable.
... that's what we're dealing with

(too much detail about typesetting to really scribe)

nmccully: there's subtleties to what operators do, which we haven't been able to teach to InDesign
... there's a lot of complexity, and a need of flexible implementations
... there's more than one way to do things
... some of these features might not be needed in all contexts

<myles> Direct quote: “We want a technology system that allows for the ultimate amount of customization for someone who has specific house rules. That’s not for everybody, and certainly not for most websites. However, making it available in the controls is superior to deciding on a spec that no one needs, and just saying ‘that’s what you get’ because that’s ugly.“

nmccully: JLREQ is not descriptive enough for an implementor to understand all of the constraints
... we need more explanation
... the document is good for designers, operators, and testers. It's very clear and well-organized
... I thought it was targeted at implementors, but it doesn't quite serve that purpose
... what I'm proposing to the task force is to make much more clear what are the differences between the conventions on the web today, and what's described in JLREQ as late 1980s practice.
... for example, CSS box layout is very different from how lines are described in the spec
... there's a blog (link????)

<myles> http://densyodamasii.com

nmccully: which goes through JLREQ in 9 installments
... comparing CSS to what is in JLREQ
... JLREQ should be compatible with this kind of view

rniwa: it would be useful to have documententation on how to achieve each section of JLREQ using today's CSS

r12a: there's a balance
... the original ideas was to make the *REQ docs to be technology-independent

rniwa: it could be two different docs

koji: I agree with richard
... I'm fine to change the goal
... but the original goal was for spec editors to find those differences, and write specs
... and for JLREQ to be tech-independent
... they tried to not talk about technology, just to describe traditional typesetting

nmccully: I know how difficult it is for an implementor to read a tech-independent description without connecting to what they already know

koji: i understand, but I'm describing the original purpose
... if we rewrite JLREQ to better suit implementors we lose original purpose
... or we could write separate docs. It's possible
... we need to decide

myles: there's a whole bunch of requirements. we support some and not others.
... it would good to know, if we support some new CSS property, how much will it help?

florian: the speed at which various documents change
... JLREQ is timeless, but CSS evolves more quickly
... so are we talking to spec editors who may be ahead of the curve?

nmccully: that's true
... we can achieve timeless and helpful description of correct practice in a way that the reader can figure out what it means to them

Makoto_: even if we limit our scope to technolgy-neutral requirement
... but JLREQ is very old-fashioned; they are not for the future of digital publishing
... so we should eliminate what is not required
... but may want to incorporate dynamic layout, which doesn't exist in traditional publishing

nmccully: I'm a hoarder :

myles: but it would be really helpful to know what is obsolete

rniwa: it would be sad to spend months on a feature that won't be used

florian: there can be disagreement about what is old-fashioned
... removing things brings in opinions
... but we need opinions to prioritize

r12a: we have a timeless doc here, other docs there, we should have connections
... in i18n we have a layout index whoich might help things connect

nmccully: I frame in my mind (this is my opinion) an idea for how I organize these levels of detail
... basic information (types of chars, em-box, lines and leading)
... the em-box is really important to trad typography
... the conventions on how those metrics were carried forward are important
... notes for implementors I think we can do without getting into the weeds
... we are grounded by how fonts are designed, we have origins, etc
... text might move around when you switch fonts, or switch layout conventions
... font metrics are important within the line as well as for line placement
... and this gets into the box model
... implementors need to understand. metrics are in conflict.
... when the em-box is not honored, the placement of text can be wrong
... and there are bad metrics
... when the embox is not honored, usability suffers
... (shows illustrator with terrible underline spacing)
... if JLReq is clear about the em-box, we can do better

florian: the css model is different from the indesign model
... and it biases in favor of avoiding collisions, by making things ugly
... JLReq talks about kihon-hanmen (????)
... (shows illustration)
... they placed photos in relation to the text blocks
... this depends on characters being square, and lends itself to grid designs
... we try to do this on the web but we can't make it responsive
... it's really hard to author this content in a web-like way
... we need better CSS, better education.
... space is really important (shows example of advertising)
... we see this always in print and nowhere in the web
... I want the web to be as beautiful as print
... but that's not possible today with the tools we have
... Tsuyokatsu is a designer who designs on paper with exacting measurements
... his staff then converts into InDesign
... this reinforces my observation of how important the em-box is
... but that's not how all the implementions work
... thanks. are there any other comments?

r12a: japanese is only one language
... and in w3c we are working on enabling many other languages.
... if you're interested talk to me
... there's groups on Indic, mongolian, all sorts of things

nmccully: there are lots of *-req docs

duerst: JLREQ is highly evolved, others not so much

- DRAFT -

Japan Language Requirements Task Force: Evolving the JLReq document

17 Sep 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output