[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part IV: Japanese Vertical Text Design Awards & Miscellaneous Commentary [css-fonts][css-rhythm]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

Tate Yoko Award

   - The working group hosted a talk by Kobayashi-sensei on the
       challenges in typography currently faced by the Japanese
       language community.
   - Many different use cases were raised for further thought by the
       working group.
   - The group appreciated Kobayashi-sensei's insights and expertise
       on line rhythm, kanbun, step-sizing, and other topics.
   - Suggested to add class=advisement to paragraph recommending
     authors use 'font-variant-*' instead of 'font-feature-settings';
     this point also needs better evangelism among the authoring community.


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: none

Tate Yoko Award

   Note: The speaker for this topic was not minuted; just the working
         group's side discussions on his talk.

   <bobbytung> Tate Yoko Award: https://tategaki.github.io/awards/

   <ChrisL> When kerning is enabled, the OpenType kern feature is
            enabled (for vertical text runs the vkrn feature is
            enabled instead).
   <fantasai> Should be using font-kerning, not font-feature-settings
   <fantasai> https://www.w3.org/TR/css-fonts-3/#font-kerning-prop
   <fantasai> font-kerning should handle this correctly.
   [would make sense to check the source code]
   [Yanagi-san will contact the authors and clarify what they're doing]

   hiroshi: (shows http://wwwc.webcrow.jp/)
   hiroshi: The problem is that some browser put "より" on the right
            side instead of center.
   fantasai: Maybe bug of Chrome.
   (seems Edge works ok)
   fantasai: Hopefully can be fixed
   <fantasai> https://www.w3.org/TR/css-writing-modes-3/#inline-alignment
   <fantasai> https://www.w3.org/TR/css-writing-modes-3/#text-baselines
   <fantasai> “In vertical typographic mode, the central baseline is
              used as the dominant baseline when text-orientation is
              mixed or upright. Otherwise the alphabetic baseline is
              used. ”
   Rossen: Please let us know if there are bugs.
   <Florian> Having checked with the author, he was not aware of the
             higher level properties that should be used (when
             possible) instead of font-feature-settings. Maybe there
             is an effort to do on the readability of the spec of
             this topic
   <fantasai> Florian, maybe can use class=advisement, but I think
              it's mostly a problem of implementations releasing
              font-feature-settings before higher-level features were
   <Florian> fantasai: agree about both points
   <BogdanBrinza> Microsoft Edge public bug tracker:

   zhengxu: Would like to know the priority of font rendering issues.

   <astearns> currently looking at a requirement for line breaking at
              punctuation - not covered by CSS at the moment
   <astearns> in this case, if a line is too long to fit with no
              punctuation to break at, there are several
              possibilities. Maybe you'd break the line as normal,
              maybe you'd have overflow (to scroll to)
   <astearns> the way it's currently done is to add a <br> in the
              markup after the punctuation
   <Rossen> It sounds like they want to have the ability to size the
            block to the size of the minimum line length
   <astearns> maximum, yes
   <fantasai> yeah, we can do that
   <fantasai> max-content
   <Rossen> basically <div style="width: min-inline-content;">...
   <Rossen> max-content will result in the longest possible line
   <Rossen> min-content will result in the longest possible word...
   <fantasai> It's also important to know whether this is a stylistic
              choice or if it's based on type of content (prose vs
   <Rossen> so if we assume that they need the shortest line then we
            don't have that
   <fantasai> they're using the longest one afaict
   <fantasai> the breaks are at punctuation
   <fantasai> and are forced
   <Rossen> right, but then he said something about wanting to have
            smaller size of the container and use scrolling...
   <fantasai> Yeah, that's nowrap :)
   <fantasai> We can solve this case
   <fantasai> Once we have line break transformations correctly
              implemented, we can even handle the choice between the
              left and right cases at the style level
   <fantasai> by using pre-lines for the right case, and normal for the left (white-space)

   [wrt complaint that italics is not interoperable for vertical text]
   <fantasai> https://lists.w3.org/Archives/Public/www-style/2013Jul/0065.html
   <fantasai> “RESOLVED: Leave synthesis of italics in vertical text undefined.”

   [discussion of mousewheel direction]
   <fantasai> fantasai: if the primary scroll direction and page
              progression direction are not derived from the same
              information, pages will print/scroll incorrectly when
              they are designed for scrolling/printing
   <fantasai> (mousewheel should follow primary scroll direction /
               page progression direction)
   <BogdanBrinza> Edge supports -ms-scroll-translation property with
                  vertical-to-horizontal value:
   <dbaron> But there seems to be a desire for horizontal scrolling,
            but only once various UI issues (e.g., mousewheel) are
   <dbaron> is the page progression direction determined by
            writing-mode on the root?
   <dbaron> (and is there propagation from body to root?)
   <fantasai> yes
   <fantasai> body, actually
   <fantasai> because WebKit
   <fantasai> we take writing-mode and direction from body (or root
              if no body) to determine the scroll directions and page
   <astearns> so fantasai is saying we need more slashes?

   <dbaron> https://drafts.csswg.org/css-text/#propdef-text-transform
   <dbaron> full-width
   <dbaron> Puts all typographic character units in fullwidth form.
            If a character does not have a corresponding fullwidth
            form, it is left as is. This value is typically used to
            typeset Latin letters and digits as if they were
            ideographic characters.
   <dbaron> ... which seems like it ought to work here.
   <fantasai> we only trigger tate-chu-yoko on ascii digits, currently
   <fantasai> so there's an interaction here that's a bit tricky
   <fantasai> (originally we did any digits, but jdaggett wanted a
   <BogdanBrinza> https://blogs.windows.com/msedgedev/2016/08/11/edgebug-twitter/#rfzCkGZwfebJuxTA.97
   <BogdanBrinza> ^ #EdgeBug

   <dbaron> florian talks about https://www.w3.org/Submission/CSJTUWT/
   <dbaron> Florian's summary of the key part of Kobayashi-sensei's
            point was I think that the things that are most important
            for legibility in Japanese are line length and character
            spacing (related to character grid and line grid), and
            today they're all horrible on the Web
   <dbaron> (I should have tried to write it down right as he said
            it, though)
   <dbaron> jlreq is https://www.w3.org/TR/jlreq/ , for the record

   <tantek> who showed the dot-leader example on the screen?
   <dbaron> https://drafts.csswg.org/css-content/#leaders
   <dbaron> The current spec for Leaders feels more like a feature
            wishlist than a spec

   <astearns> Could you automatically shift the color over video
              continuously using blend modes?
   <myles> astearns: think of the perf
   <myles> astearns: and it would have to pierce through compositing
           layers making it expensive
   <astearns> it would make my eyes hurt to try to read
              shifting-color text anyway
   <myles> Yes
   <flackr> astearns, myles ^ it's not nice on the eyes, but seems to
            work in chrome at least
   <flackr> http://jsbin.com/faputep/edit?html,css,output
   <bobbytung> Should it be resolved with TTML?
   <myles> bobbytung: if the content uses TTML :P
   <BogdanBrinza> https://blogs.windows.com/msedgedev/2016/04/20/building-a-more-accessible-web-platform/#Iym2qYXS7kFCQydY.97
                 Section "Improved web legibility in high contrast"

Rhythm discussion notes
   Scribe: fantasai

   - Current discussion is on rhythm
   - Koji is projecting a document with two columns that shows the
       text rhythm being kept when the text is interrupted by an
       image, the rhythm is not resumed, it is merely restarted as a
       result, the columns don't align across the gap.
   - Koji asserts that there are professional users for whom this is
   - They would prefer to insert extra space to resume the rhythm
   - Koji also asserts that for casual users, they prefer to not
       insert extra space in order to resume the previous rhythm.
   - Kobayashi-sensei asserts that there are no such people.
   - He draws some content.
   - Says that the top and bottom of the page need to be aligned
   - The drawing is of two columns or two facing pages. Problem is
       them not being aligned, the reason is because of inserted

   - (two interruptions in the text)
   - (in the middle, the text isn't aligned to the line grid)
   - If tried to align, the spacing before and after the image would
       be uneven. If there is just one column, don't do this.
   - This kind of adjustment is not done automatically in DPT
       software, can be done by setting fixed position for the
       middle? block of text
   - If you just have one column, being even is better; if you have
       two, lining up is better
   - Since it's not achieved so far in DTP, not requiring that Web
       does it but he wishes that we solved that problem.
   - If we did some kind of vertical justification by spreading the
       leftover space... Can't get into details, it's more
       complicated, so far hasn't been solved

   - Another problem is when you have cite-outs
   - You want to line up the sidenote with the thing being annotated,
       there is also this requirement.
   - In DTP software, they would draw a line and attach things to it.
   - (There are various names for these kinds of alignment)
   - If you go in inline direction, have problem of things lining
       up... justification is generally solved by DTP software.
   - Florian explains: this is a similar problem to justification,
       which is a mostly solved problem; the vertical equivalent
       isn't solved.
   - Kobayashi-sensei continues...
   - It's a problem worth solving, but also it's hard.
   - The desire to align the bottom edge of things is also strong.
   - But that might be different from print and web; on print it's
       really important, but on the Web less important maybe because
       we are scrolling.
   - Maybe we have one less constraint when playing wiht this
       justification-like thing, that we don't need to have the
       bottom align.
   - But when we print, it does matter.
   - So just wants us to make sure that this problem is important and
   - Please think about this; let's go to next topic.
   - Kobayashi-sensei has written a 50page thesis on this available
       on the web, written in Japanese, Title is Something Something
       Vertical Something.
   <bobbytung> The Document Mr. Kobayashi mentioned is here (in
       japanese): http://www.cas-ub.com/project/publications/nihongokumihan.pdf

   myles: This was super awesome, thank you very much

   koji: I want to emphasize, from his statement, while line grid is
         important, in some cases there are more important things
         than aligning to the grid.
   koji: If those things happen, breaking rhythm is better.
   koji: In this discussion, people really want grid to be strong,
         while I feel grid is one of criteria, and when there is more
         important concern, need to shift.

   <dbaron> So one thing I wanted to understand was when he was
            talking about how breaking the rhythm was ok in one
            column but not when columns lined up -- and talked about
            having the thing that broke the rhythm top-aligned within
            the gap rather than centered -- I was wondering if anyone
            actually ever *wanted* it top-aligned, or that was just a
            deficiency of the software being used.
   dbaron: [example of image in the middle breaking the rhythm, and
            how image was top-aligned rather than centered]
   dbaron: In the multiple-column case, and wondering if idea of
           having that image top-aligned within the space
   dbaron: rather than centered within the space
   dbaron: was because of limitations in the software.
   dbaron: Was it preferable to have it centered, if that was
   Kobayashi-sensei: Ideal is centered
   kobayashi-sensei: but some things are better top-aligned, e.g.
                     side notes.

   [kobayashi-sensei draws some text with interruption as an image.
       Goal is to get spacing even on either side
       Draws a different example of vertical text, end-note of
       paragraph (after-paragraph note) end of chapter/section etc.
       This note is inserted at the end of the paragraph... has
       smaller text and line-spacing
       Spacing between lines and note is equal, but the space after
       the note is bigger
       There are cases where you center, and others where you start
       For this situation, end notes, but not only
       also for pull-quotes (or block quotes?)
       In this case do the same as for end notes
       But some people like it centered

   myles: Is difference between two cases because vertical vs
          horizontal text, or difference is because image vs text.
   Kobayashi-sensei: Depends on content, not on writing mode.
   [Although this is a bit nuanced... according to Kobayashi-sensei,
       such end notes are more appropriate in vertical text, an
       footnotes are better for horizontal text.
       Also depends on if it's the kind of footnote you want people
       to read or if you want people to ignore them.

inline step sizing

   <murakami> http://www.cas-ub.com/project/publications/nihongokumihan.pdf
   fantasai: In print, the kihonhanmen size is chosen so that if
             it's all Japanese characters then everything fits
   fantasai: but on the web you don't choose the size -- the width is
             chosen by the width of the window
   fantasai: we have a request for step size of line box to be an integral
             multiple of the character count -- but then on the web we have
             extra space. What do we do with the extra space?
   [Kobayashi-sensei draws a book:
       text is single column; index page is double column
       different text sizes
       if you have exact line length on both, because font size etc.
       are all different; size of content area on page is different.
       You want index to be smaller than main content
       The extra space is distributed evenly around
       but sometimes you want to be slightly bigger on top
       this is independent of whether vertical or horizontal writing
       because humans have very good perception of equality in
       horizontal dimension,
       but there's an optical illusion, that things that look
       centered vertically aren't quite
       and this extra space is added to accommodate
       So you want centered, but ideally you want perceptual
       centering, which is not quite the same

   <astearns> the need to specify whether to center, top align or
              align baselines (for side notes) is why there are so
              many values for the box-snap property


   kanbun are Japanese version of Chinese writing, has little
       annotations around the characters
       It's for High School students
       (skk was explaining this)
   Kobayashi-sensei: There was this kind of material in JISX4051, but
                     JLREQ considered it too advanced.
   skk: Challenge to create e-textbook using HTML/CSS/EPUB and this
        is becoming a requirement.
   Kobayashi-sensei: There's a lot of variations in this display, so
                     creating a spec and implementations for this,
                     it's extremely difficult.
   Florian: It's important Japanese cultural thing, but also horribly

   skk: Currently working around with abspos.
   fantasai: That's probably the right solution.
   koji: Kobayashi-sensei said, there were two types of Kanbun. First
         step is Japanese textbook with box of kanbun, but more
         advanced is whole book in kanbun, so need to page or scroll
   koji: Latter case is hard to do in abspos or svg

   Makoto: If you use a ?, then visual sequence is different from
           oral sequence.
   [Makoto points out the ordering of the example, it jumps around]
   dbaron: So you write it in Chinese grammar.
   ?: It's originally Chinese poetry.
   koji: Order is Chinese, and the check mark here, it means read the
         earlier one first.
   koji: The numbers say which needs to be read first in more
         complicated cases.
   Kobayashi-sensei: On the right side it's the readings annotations
   Kobayashi-sensei: Some of the annotations are how to read the
                     Chinese character in Japanese, others are how to
                     conjugate in Japanese
   Kobayashi-sensei: This character here has multiple possible
                     Japanese readings
   Kobayashi-sensei: This mark says which one to use
   myles: This is really scary
   Kobayashi-sensei: Sometimes have one annotation, sometimes have
   Kobayashi-sensei: Depending on expected level of the reader, will
                     but varying levels of annotations
   Kobayashi-sensei: This is just one type of example
   xidorn: I've seen much more complicated examples, e.g. with a
           pronunciation for multi-character word
   Florian: Sometimes root of word is written with Chinese character,
            and conjugations are hanging off it.

   fantasai: You can get the layout into HTML+CSS using abspos. Not
             perfect, but probably best we can do, certainly for a
             long while.
   kobayashi-sensei: Best to just give up.
   fantasai: Use inline-grid for each one and its annotations :)
   [Makoto draws
       placement in example projected is incorrect
       ordering annotation should be left edge of gap between two
       pronunciation should be to the side,aligned to the bottom
       or to the top
   fantasai: I recommend marking it up as multi-level ruby and
             handling the display by styling each ruby as inline-grid.

   Kobayashi-sensei: If you have both reading and conjugation, they
                     stick together and grow downward.
   Kobayashi-sensei: In a child's book, character can be really big,
                     and you can have long annotation with wrapped
                     annotation text.
   koji: Annotations here are explaining Chinese, so can be really
   ChrisL: Animation: follow the dot.


   Kanai: Here is a photograph of a Japanese cookbook.
   Kanai: Here there is a bracket symbol.
   Kanai: Explains how to make a custard... ingredients are bracketed
          together for this step.
   fantasai: Need stretchy brackets for math as well.
   dbaron: Looks a bit like a border image.
   <dbaron> it would be a little hard to do with a border-image
   <dbaron> to get the alignment points right

   fantasai: Do it with list items and the unicode box drawing
             characters, giving the first and last special characters.
   ?: line-spacing would break that

   koji: Is this particular to Japanese?
   bobbytung: No, also in Chinese.
   Florian: In English not quite the same, but have curly braces
            doing similar things.
   Kobayashi-sensei: This is not that common in Japanese either.
   Murakami-san: Inline block with big curly bracket?
   [warichu discussion]
   <dbaron> you can do it with border-image by setting roughly 1em
            border-image-width for the top and bottom sides, and
            leaving border-image-width as 1 on the left and right,
            and only having a border-width on the left

   myles: How important is this?
   Kanai: I'm a recipe book lover, so I always see this type of
          layout in cookbooks.
   Florian: Things that have lots of lists.
   ??: I never see this
   ??: It's not important
   ??: for this cookbook, it's a graphic support, designer can do.
       You can use image or list tag
   ??: issue of character alignment

   [discussion of using SVG]
   dbaron: border-image can do the right kind of stretching
   ??: Not a must, just nice to have.
   Murakami-san: Can already do with border-image.
   Florian: One difficulty is if you try to line up this corner with
            the font, because you need to guess the font metrics.
   koji: Best solution is custom paint.
   dbaron: Don't see how that's any better than border image.

   [skk wraps up]

Received on Saturday, 27 May 2017 00:54:49 UTC