實作豎排文字／排版（Fwd: Implementing vertical text/layout support）

幾天前 Mozilla 的 dbaron 在 mozilla.dev.platform 上宣佈要實作豎排的信。
敬請關注！

原文討論串→http://groups.google.com/group/mozilla.dev.platform
/browse_thread/thread/84a3ec78e915829d/4580c02150adc1a1

-------- Original Message --------
Subject: Implementing vertical text/layout support
Date: Tue, 15 Nov 2011 21:56:34 +1300
From: L. David Baron <dbaron@dbaron.org>
Reply-To: dev-platform@lists.mozilla.org
To: dev-platform@lists.mozilla.org, dev-tech-layout@lists.mozilla.org
Newsgroups: mozilla.dev.platform
Followup-To: mozilla.dev.platform

At the Layout/Graphics work week, we met today (10-11am NZDT on
Tuesday November 15) to discuss a strategy for implementing vertical
text and layout support in Gecko.  I'm going to attempt to summarize
that discussion.

We discussed the work that would be needed to implement vertical
text and vertical layout support.  At a high level, these pieces
(and the people likely to work on them) are:
 - block and miscellaneous layout [birtles]
   - logicalization (replace RTL, add vert)
   - orthogonal flows
 - line layout (line-relative)
 - text and font layout [jdaggett]
 - style system [sjohnson, with advice from dbaron/bz]
   - declaration storage
   - logical properties

See below for further details on these.


Elika explained a number of features of the specification, which is
http://dev.w3.org/csswg/css3-writing-modes/ .  This explanation
included the following illustrations:

Among the most important points is that there are things in CSS that
are relevant to three different sets of coordinates.  Many existing
properties apply to physical coordinates:

                      top
               .----------------.
          left |                | right
               '----------------'
                     bottom

However, in order to accomodate vertical writing, block formatting
is described according to a set of coordinates which, for LTR
writing such as this, are:

                     before
               .----------------.
         start |                | end
               '----------------'
                     after

We had some discussion about whether it's desirable to provide
logical properties (e.g., margin-before, margin-after).  They seem
likely to be needed for the UA style sheet (unless we want very
silly defaults for vertical), but perhaps less likely to be useful
beyond it.

In addition, within a line, there is a third set of coordinates (for
example, because in some cases text within a line might not line up
with the block directions (e.g., for Mongolian):

                      over
               .----------------.
     line-left |                | line-right
               '----------------'
                     under


The changes needed to support vertical layout are substantially
different between the areas of code that care about text and inline
formatting and those that do not.  One goal is that the layout code
that is not related to text and inline layout shouldn't have to deal
with extra complexity to handle vertical layout correctly (like
block frame, scroll frame, etc., currently do have extra complexity
for RTL).  That said, this code may need to carefully choose the
correct method (in terms of operating on logical vs. physical).

We think this is likely to mean that we want frame coordinates to
remain primarily physical (by the current APIs), since that's likely
what's needed for callers outside of reflow, but we're likely to
want APIs that return the various logical forms as well, and
possibly simple methods for transforming logical/physical for a
given frame.  I expect that reflow of non-inline non-replaced frame
classes to operate mostly in logical directions but then set
physical coordinates (in common code) by the end of reflow.
However, this bit is not at all certain:  it's worth experimenting a
little bit to see what's going to lead to simpler code.  It's also
worth investigating what approaches other implementations (in
particular, WebKit) have taken.  On the other hand, code for drawing
text and for many replaced elements (e.g., images, videos, plugins)
will largely need to operate in physical coordinates.  In the case
of text, it will also need substiantial knowledge of what it's doing
for vertical text.  It's not clear to me how far into the inline
code that type of code will need to permeate.

Additionally, there's almost certainly a need for logical box
properties in the UA style sheet, although how useful they'd be
outside the UA style sheet is questionable.  However, to do logical
box properties for the full start/end/before/after set rather than
the limited start/end set we do now, we need to do the following two
bugs first:
  https://bugzilla.mozilla.org/show_bug.cgi?id=649145
    storage within CSS declaration blocks (CSSDeclaration) should
    preserve order of properties
  https://bugzilla.mozilla.org/show_bug.cgi?id=649142
    support logical box properties (-start/-end) without hidden
    longhand properties
The first of these should probably be a substantial redesign of the
CSS declaration storage, with improvements to performance (while
maintaining or improving memory use) kept in mind throughout.  Such
a redesign probably should take some ideas from the work in
https://bugzilla.mozilla.org/show_bug.cgi?id=553456 , although there
are a number of things in the work there that I don't like, and that
redesign doesn't have the key aspect of preserving order.


This leads to the plan that we want to start this work from three
sides, with three people leading the work:
 (1) [birtles] working on making the necessary parts of block and
 similar code operate in terms of logical directions (while leaving
 appropriate replaced elements operating in physical directions)
 (Note: this should probably be preceded by some additional
 examination of typical usage patterns of various APIs.)

 (2) [jdaggett] working on the text rendering and layout aspects

 (3) [sjohnson] working on the logical box properties and the
 preparatory work for that.

The intent would be that progress on items (1) and (2) would at some
point meet in the middle, which is likely to be among the more
complex areas.  Additionally, after doing (1) we'd also proceed to
doing the work for correct sizing at the points where writing
direction changes.

-David

Received on Saturday, 19 November 2011 14:15:40 UTC