01:44:01 RRSAgent has joined #jlreq 01:44:01 logging to https://www.w3.org/2019/09/18-jlreq-irc 01:44:09 RRSAgent, make log public 01:44:21 Meeting: Japan Language Requirements Task Force: Evolving the JLReq document 01:52:36 koalie has joined #jlreq 01:52:41 RRSAgent, make logs public 01:52:43 koalie has changed the topic to: https://w3c.github.io/tpac-breakouts/sessions.html 01:53:04 koalie has left #jlreq 01:57:22 dom has joined #jlreq 01:57:25 nmccully has joined #jlreq 01:58:44 shimazu has joined #jlreq 01:59:48 toshiakikoike has joined #jlreq 02:00:39 duga has joined #jlreq 02:00:41 ricea has joined #jlreq 02:00:43 dauwhe has joined #jlreq 02:00:48 present+ 02:00:51 MasakazuKitahara has joined #jlreq 02:00:54 suzuki has joined #jlreq 02:01:01 koizuka has joined #jlreq 02:01:01 rniwa has joined #jlreq 02:01:07 r12a has joined #jlreq 02:01:10 Zakim has joined #jlreq 02:01:10 present+ 02:01:19 JunGamo has joined #jlreq 02:01:23 present+ 02:01:25 present+ 02:01:29 present+ 02:01:33 michael_li has joined #jlreq 02:01:35 present+ 02:01:39 Bert has joined #jlreq 02:01:39 glenn has joined #jlreq 02:01:42 koji has joined #jlreq 02:01:42 scribenick: dauwhe 02:01:44 stantonm has joined #jlreq 02:01:46 present+ 02:01:55 present+ 02:02:02 astearns has joined #jlreq 02:02:07 Meeting: TPAC Breakout on JLREQ 02:02:09 present+ 02:02:10 TakeruYamada has joined #jlreq 02:02:18 nmccully: welcome 02:02:24 duerst has joined #jlreq 02:02:26 ... my goal is to introduce JLREQ 02:02:37 ... and talk about thoughts about improving JLREQ 02:02:47 DavidClarke has joined #jlreq 02:02:48 present+ 02:02:50 ... including issues about the web, but not only the web 02:02:58 ... I've been workinng at Adobe for 21 years 02:03:06 present+ 02:03:12 ... I wrote the Japanese composition engine in InDesign 02:03:26 xfq has joined #jlreq 02:03:34 ... and I'm interested in improving text composition across the creative suite 02:03:45 ... and help bring those improvements to everyone via CSSWG, etc 02:04:37 nmccully: [ does presentation ] 02:04:39 jlreq links: https://github.com/w3c/jlreq/ (scroll down) 02:06:12 myles has joined #jlreq 02:07:06 nigel has joined #jlreq 02:07:31 dauwhe has joined #jlreq 02:07:43 fantasai has joined #jlreq 02:09:03 skk has joined #jlreq 02:14:06 Major groups involved in JLREQ: JAGAT, APL, IDPF (now W3C), JEPA, EBPA 02:15:58 http://www.ebpaj.jp/images/kumihan-en.pdf 02:16:11 TakeruYamada has joined #jlreq 02:16:40 JunGamo has joined #jlreq 02:17:45 http://www.ebpaj.jp/images/youbou.pdf 02:18:29 https://www.w3.org/Submission/2017/SUBM-CSJTUWT-20170102/jlreq-analysis.html 02:18:46 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 02:18:52 ... it's somewhat subjective 02:19:04 ... a gap analysis was useful 02:19:09 ... what should we focus on? 02:19:42 nmccully: there are a lot of orgs that are trying to codify their requirements, with many competing requirements 02:20:05 ... it's interesting that things like ruby are not the highest priority for the publishing industry 02:20:25 ... it's hard to wade through the gap analysis and come up with next steps 02:20:41 ... our goal is for JLREQ to become more clear for implementers 02:20:52 ... and help people make decisions of prioritization 02:21:36 https://juntajima.github.io/XMLPub_EPUBRSCheck/ 02:21:39 ... JAGAT has done a comparison of e-readers 02:21:56 ... and they all have proprietary implementations on top of web tech 02:22:14 ... kindle, kobo, ibooks, MS Edge, etc etc 02:22:37 ... and they test various features across platforms--andriod, iOS, etc 02:22:54 ... this is another indication that things are all over the map 02:23:03 ... implementations differ greatly 02:23:30 ... the new JLREQ task force will go through the gap analysis and add more information and background 02:23:37 ... to guide the production of new tests 02:23:50 ... to see if there are big holes in current implemtations 02:24:11 ... there are new frontiers in layout around spacing, justification, etc 02:24:17 ... we want definitive tests 02:24:28 ... there has also been errata for JLREQ 02:24:48 ... there are 35 open PRs right now 02:25:10 ... and we want to improve the english translation 02:25:40 https://github.com/w3c/jlreq 02:25:45 ... one comment about JLREQ is that there is no priority info 02:26:10 ... I agree, but efforts to make granular prioritization risk separating features that should be together 02:26:37 ... some features will be difficult or expensive to develop 02:26:51 ... so we want to describe basic features that are still missing 02:26:54 dontcallmeDOM has joined #jlreq 02:27:08 ... and then look at how many people are affected by more complex features 02:27:15 ... to help prioritize 02:27:24 Mizushima has joined #jlreq 02:27:51 ???: it would be great if we could say what percentage of books are affected, what would enable more content 02:28:12 s/???/rniwa/ 02:28:15 nmccully: the 2nd point is about the tests; we want what JLREQ describes to be possible to produce 02:28:22 myles: css tests? 02:28:24 nmccully: yes 02:28:39 florian: re: implementing jlreq 02:28:48 michael_li has joined #jlreq 02:28:50 ... we need to be careful about what we mean; it's meant to be high-level 02:28:56 ... not an exacting description 02:29:17 ... jlreq is not meant to be implemented; you derive a spec from jlreq and implement that 02:29:35 ... it's not great if only one person does that work of reading jlreq and writing the specs 02:30:02 ... but the process needs to be JLREQ > incubation of CSS spec > ? > profit 02:30:10 nmccully: that's a good point 02:30:35 ... there does need an intermediate step of sharing and describing and specifying 02:30:45 ???: that's what we did in timed text WG 02:31:04 ... but that was done independently of CSS 02:31:07 florian: absolutely 02:31:14 s/???/Glenn/ 02:31:27 ... but sometimes people come to APL, and say we're trying to implement JLREQ, but JLREQ is not a spec 02:31:29 NJ has joined #jlreq 02:31:34 makoto: but that's what people do 02:31:39 florian: there's a missing step 02:31:49 makoto: it provides hints, not answers 02:32:21 nmccully: common books... the picture I showed earlier, a simple book with lots of things going on within the lines 02:32:28 ... and it's very different than western typography 02:32:46 ... a criticism of JLReq is that it doesn't address other types of books 02:33:04 ... like dynamic content, other verticals 02:33:25 ... so we don't want to end up with a hybrid of western typesetting and japanese typesetting 02:33:39 ... I find it more readable than JIS X 4051 02:33:56 ... it was written with deep experience from the kumihan operators 02:34:16 ... but it's hard to understand by people without a deep background 02:34:36 ... we want to talk about text metrics 02:34:53 ... it was not fully understood in jlreq 02:35:03 ... these issues come back in issues from customers 02:35:15 ... they want the fine control they had in print on the web 02:35:34 ... so the standards should support what these people are trying to do, and then implementations can improve 02:36:16 ... the pre-eminent type expert on the committee left some things out because there was not a single clear answer 02:36:31 ... saying there's no clear answer is better than leaving it out, and saying why is better yet 02:36:57 ... one example of what I'm talking about when I say there's great experience there is in this para (in preso) 02:37:08 ... "spacing around punctuation" 02:37:15 ... I couldn't make this para in InDesign due to a bug 02:37:43 Makoto_ has joined #jlreq 02:37:48 ... the 2nd line is compressed. 1/3em between something and something, 1/4 em between other punctuation 02:37:56 ... because the last word is 3 syllables 02:38:21 ... and that forces fourth line to be slightly extended 02:38:43 ... but InDesign can't do compression unless you have a bunch of characters at line end (???) 02:38:53 ... even if I had a keep restriction, it doesn't compress the line 02:39:15 ... the amount of compression being different for these different clusters of punctuation was because of their experience 02:39:22 ... and other operators would do it differently 02:39:43 ... which is why japanese typesetting is highly customized, and needs to be highly customizable. 02:39:48 ... that's what we're dealing with 02:40:45 (too much detail about typesetting to really scribe) 02:42:04 nmccully: there's subtleties to what operators do, which we haven't been able to teach to InDesign 02:42:25 ... there's a lot of complexity, and a need of flexible implementations 02:43:01 ... there's more than one way to do things 02:43:25 ... some of these features might not be needed in all contexts 02:44:01 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.“ 02:44:46 ... JLREQ is not descriptive enough for an implementor to understand all of the constraints 02:44:55 ... we need more explanation 02:45:16 ... the document is good for designers, operators, and testers. It's very clear and well-organized 02:45:38 ... I thought it was targeted at implementors, but it doesn't quite serve that purpose 02:46:23 ... 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. 02:46:40 ... for example, CSS box layout is very different from how lines are described in the spec 02:46:49 ... there's a blog (link????) 02:46:57 http://densyodamasii.com 02:47:03 ... which goes through JLREQ in 9 installments 02:47:12 ... comparing CSS to what is in JLREQ 02:47:27 ... JLREQ should be compatible with this kind of view 02:48:02 rniwa: it would be useful to have documententation on how to achieve each section of JLREQ using today's CSS 02:48:08 r12a: there's a balance 02:48:29 ... the original ideas was to make the *REQ docs to be technology-independent 02:48:38 rniwa: it could be two different docs 02:48:45 koji: I agree with richard 02:48:51 ... I'm fine to change the goal 02:49:05 ... but the original goal was for spec editors to find those differences, and write specs 02:49:17 ... and for JLREQ to be tech-independent 02:49:19 JunGamo has joined #jlreq 02:49:31 ... they tried to not talk about technology, just to describe traditional typesetting 02:49:56 nmccully: I know how difficult it is for an implementor to read a tech-independent description without connecting to what they already know 02:50:08 koji: i understand, but I'm describing the original purpose 02:50:22 ... if we rewrite JLREQ to better suit implementors we lose original purpose 02:50:32 ... or we could write separate docs. It's possible 02:50:38 ... we need to decide 02:50:50 myles: there's a whole bunch of requirements. we support some and not others. 02:51:07 ... it would good to know, if we support some new CSS property, how much will it help? 02:51:24 florian: the speed at which various documents change 02:51:37 ... JLREEQ is timeless, but CSS evolves more quickly 02:51:49 s/JLREEQ/JLREQ/ 02:52:01 ... so are we talking to spec editors who may be ahead of the curve? 02:52:11 nmccully: that's true 02:52:40 ... we can achieve timeless and helpful description of correct practice in a way that the reader can figure out what it means to them 02:53:05 Makoto_: even if we limit our scope to technolgy-neutral requirement 02:53:20 ... but JLREQ is very old-fashioned; they are not for the future of digital publishing 02:53:27 ... so we should eliminate what is not required 02:53:45 ... but may want to incorporate dynamic layout, which doesn't exist in traditional publishing 02:53:49 nmccully: I'm a hoarder : 02:54:07 myles: but it would be really helpful to know what is obsolete 02:54:23 rniwa: it would be sad to spend months on a feature that won't be used 02:54:33 florian: there can be disagreement about what is old-fashioned 02:54:42 ... removing things brings in opinions 02:54:55 ... but we need opinions to prioritize 02:55:10 r12a: we have a timeless doc here, other docs there, we should have connections 02:55:27 ... in i18n we have a layout index whoich might help things connect 02:55:50 nmccully: I frame in my mind (this is my opinion) an idea for how I organize these levels of detail 02:56:25 ... basic information (types of chars, em-box, lines and leading) 02:56:40 ... the em-box is really important to trad typography 02:57:10 ... the conventions on how those metrics were carried forward are important 02:57:24 ... notes for implementors I think we can do without getting into the weeds 02:57:44 ... we are grounded by how fonts are designed, we have origins, etc 02:58:07 ... text might move around when you switch fonts, or switch layout conventions 02:58:25 ... font metrics are important within the line as well as for line placement 02:58:30 ... and this gets into the box model 02:58:56 ... implementors need to understand. metrics are in conflict. 02:59:49 ... when the em-box is not honored, the placement of text can be wrong 02:59:53 ... and there are bad metrics 03:00:38 ... when the embox is not honored, usability suffers 03:00:50 ... (shows illustrator with terrible underline spacing) 03:01:36 RRSAgent, draft minutes 03:01:36 I have made the request to generate https://www.w3.org/2019/09/18-jlreq-minutes.html dauwhe 03:01:55 RRSAgent, make logs public 03:01:56 shimazu has joined #jlreq 03:01:57 rrsagent, make log public 03:02:29 ... if JLReq is clear about the em-box, we can do better 03:02:38 florian: the css model is different from the indesign model 03:02:54 ... and it biases in favor of avoiding collisions, by making things ugly 03:03:18 ... JLReq talks about kihon-komen (????) 03:03:27 ... (shows illustration) 03:03:39 s/komen/hanmen/ 03:03:43 ... they placed photos in relation to the text blocks 03:04:10 ... this depends on characters being square, and lends itself to grid designs 03:04:26 ... we try to do this on the web but we can't make it responsive 03:04:38 nigel has joined #jlreq 03:05:00 ... it's really hard to author this content in a web-like way 03:05:11 ... we need better CSS, better education. 03:05:30 ... space is really important (shows example of advertising) 03:05:42 ... we see this always in print and nowhere in the web 03:05:52 ... I want the web to be as beautiful as print 03:06:06 ... but that's not possible today with the tools we have 03:06:27 ... ??? is a designer who designs on paper with exacting measurements 03:06:35 ... his staff then converts into InDesign 03:06:49 ... this reinforces my observation of how important the em-box is 03:06:59 ... but that's not how all the implementions work 03:07:09 s/???/Tsuyokatsu/ 03:07:12 ... thanks. are there any other comments? 03:07:20 r12a: japanese is only one language 03:07:38 ... and in w3c we are working on enabling many other languages. 03:07:44 ... if you're interested talk to me 03:07:56 ... there's groups on Indic, mongolian, all sorts of things 03:08:12 nmccully: there are lots of *-req docs 03:08:31 duerst: JLREQ is highly evolved, others not so much 03:08:47 RRSAgent, draft minutes 03:08:47 I have made the request to generate https://www.w3.org/2019/09/18-jlreq-minutes.html dauwhe 03:09:10 duga has joined #jlreq 03:09:22 florian: writing modes is now PR. thanks who helped. 03:16:43 atsushi has joined #jlreq 03:18:23 dauwhe has joined #jlreq 03:34:06 dauwhe has joined #jlreq 03:50:36 dauwhe has joined #jlreq 03:53:41 dauwhe has joined #jlreq 04:03:07 dauwhe has joined #jlreq 04:19:54 duga has joined #jlreq 04:22:41 duga has joined #jlreq 04:24:52 dauwhe has joined #jlreq 04:28:10 toshiakikoike has joined #jlreq 04:29:39 dontcallmeDOM has joined #jlreq 04:30:22 rniwa has joined #jlreq 04:32:07 nigel has joined #jlreq 04:33:18 myles has joined #jlreq 04:34:41 shimazu has joined #jlreq 04:39:18 xfq has joined #jlreq 04:39:31 xfq has left #jlreq 04:42:06 skk has joined #jlreq 04:42:34 nmccully has joined #jlreq 04:43:44 dom has left #jlreq 04:46:55 atsushi has joined #jlreq 04:50:59 dauwhe_ has joined #jlreq 04:52:11 Zakim has left #jlreq 04:57:05 slides are here: https://lists.w3.org/Archives/Public/www-archive/2019Sep/att-0003/TPAC_JLREQ_2019.pdf 05:01:12 rrsagent, make logs public 05:01:23 rssagent, make minutes 05:16:42 shimazu has joined #jlreq 05:24:36 duga has joined #jlreq 05:27:32 dauwhe has joined #jlreq 05:29:54 myles has joined #jlreq 05:30:13 nigel has joined #jlreq 05:30:42 rniwa has joined #jlreq 05:30:44 rniwa has left #jlreq 05:31:08 toshiakikoike has joined #jlreq 05:33:46 dauwhe_ has joined #jlreq 05:36:41 shimazu has joined #jlreq 05:36:44 nigel_ has joined #jlreq 05:42:41 skk has joined #jlreq 05:45:48 atsushi has joined #jlreq 05:55:05 skk has joined #jlreq 06:13:41 nmccully has joined #jlreq 06:14:26 nmccully has left #jlreq 06:30:18 duga has joined #jlreq 06:32:01 shimazu has joined #jlreq 06:33:22 dauwhe has joined #jlreq 06:38:17 myles has joined #jlreq 07:04:35 nigel has joined #jlreq 07:10:42 myles has joined #jlreq 07:11:27 myles has joined #jlreq 07:21:58 nigel has joined #jlreq 07:22:32 nigel_ has joined #jlreq 07:23:05 duga has joined #jlreq 07:24:03 duga has joined #jlreq 07:24:07 dauwhe has joined #jlreq 07:31:05 myles has joined #jlreq 07:31:59 nigel has joined #jlreq 07:33:32 duga has joined #jlreq 07:34:13 toshiakikoike has joined #jlreq 07:34:49 shimazu has joined #jlreq 07:36:26 skk has joined #jlreq 07:53:22 Bert has left #jlreq 08:00:07 nigel_ has joined #jlreq 08:00:23 skk_ has joined #jlreq 08:25:18 dauwhe has joined #jlreq 08:27:30 shimazu has joined #jlreq 08:30:57 myles has joined #jlreq 08:33:09 toshiakikoike has joined #jlreq 08:35:01 nigel_ has joined #jlreq 08:35:06 dauwhe has joined #jlreq 08:35:46 nigel has joined #jlreq 08:44:11 dauwhe has joined #jlreq 08:46:33 skk has joined #jlreq 08:49:33 shimazu has joined #jlreq 08:58:02 shimazu has joined #jlreq 09:07:43 dauwhe has joined #jlreq 09:31:45 nigel has joined #jlreq 09:49:48 dbaron has left #jlreq 09:54:00 atsushi has joined #jlreq