- From: Eric Muller via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Nov 2020 14:08:45 +0000
- To: public-i18n-archive@w3.org
Re: glue. Yes, the concept is similar to TeX, but needs some refinement for Japanese, to account for JLREQ's priority between the various pairs of classes. That is, we need some way to model the fact that the glues in, e.g. cl-04/cl-21 expands before the glues in cl-19/cl-19 (i.e the color coding in appendices D & E). What I ended up with is that the width of a glue is a piecewise linear, monotonic, increasing, continuous function of some parameter t. This parameter t corresponds to how much the glue is compressed (t < 0) or expanded (t > 0). A t=0, the width is given by appendix B. I arbitrarily decided that the first step of expansion is between t=0 and t=1, the second step (red in App. E) is between t=1 and t=2, the third step (blue in App. E) is between t=2 and t=3, etc. Similarly for the compression and App. D. The width of a letter is just a constant function. Then you can sum up all the glues and letters on a line, by doing the point-wise addition of those functions, and you have the width L(t) of that line. It really captures all the (scalar) width the line could take, depending on how much you compress or expand it. The addition of piecewise linear, monotonic, ... functions is also a piecewise linear, monotonic, ... function. To justify the line to a target width W, you just need to figure out the value of t_justified such what L(t_justified) = W, and that's easy because of the nature of the functions. Then, for each glue in the line, its width is w(t_justified). My copy of JIS X 4051 is at the office, but IIRC, it has an appendix that has a whole bunch of equations, that correspond to appendix B, D, E of JLREQ. Those equations are a bit convoluted, but what I described is just a restatement of those equations. There is a little complication because some of the glue are not continuous: the glue between a punctuation and line end can only be 0 or 1/2em, nothing in between. But it's only at the end of lines, so I special cased it. I think it should be possible to deal with non-continuous functions, but I have not done that yet. All that works also well with ruby (including jukugo, and all the various overhang conditions), and I think it even works well with multiple ruby lines but I have not tried yet. Exercise left to the reader. Hint: model ruby as a graph where nodes are positions on the main line and on the ruby line(s), and arcs represent constraint of the form "this position must be to the left of that position". Compute the width of the graph much like the width of the line above, and use a point-wise max() for those nodes that have multiple incoming arcs. Solve as before. Use that t_justified for the longest path(s) in the graph, and justify/align independently the pieces that are not on the longest path (typically, ruby texts or ruby bases). -- GitHub Notification of comment by emuller-amazon Please view or discuss this issue at https://github.com/w3c/jlreq/issues/242#issuecomment-720493850 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 November 2020 14:08:47 UTC