¹ê§@½Ý±Æ¤å¦r¡þ±Æª©¡]Fwd: Implementing vertical text/layout support¡^

---------- Forwarded message ----------
From: Peter Peng <sinsun@gmail.com>
Date: Mon, Nov 21, 2011 at 2:42 AM
Subject: Re: ¹ê§@½Ý±Æ¤å¦r¡þ±Æª©¡]Fwd: Implementing vertical text/layout support¡^
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>


®¤§Ú§ÃÃD¡A
ª½±Æºô­¶ªº¹ê§@¡A
¥i¯à³Ì¦­¥X²{©ó¤é¥»¡C
¥i¯à³Ì¦nªº±Æª©¡A·|µo¥Í¦b¤é¥»¡C
¤£­n¤p¬Ý¤é¥»¹ï©ó¬üªº°õµÛ¡A
§Ú·Q¡A¥ý¬O¤é¥»ªº¬Y¤@ª½±Æºô¯¸ÄAÂФF¤j®aªºÆ[ÂI¡A
µM«á¥xÆW¼Ò¥é¡A
§c¡A¤£¦n·N«ä¡A¤¤°ê·|¤s¹ë¡C:P
¨ä¹ê°ò¥»¤W§Ú­Ì¤¤°ê¤H¦³¤Ó¦h¼Æ¦ì¤Æªº¤u§@¡C
­º¥ý¡A¸É¨¬¦rÅé¡C
±dº³¦r¨å³£ÁÙ¦³¤Ó¦h¦r¨S¦³¦r«¬¡C
¦A¨Ó¡A³Ì»Ý­nª½¦æ±Æª©ªº´N¬O¥jÄy¤F¡C
­º¥ý¡A·íµM¬O¡m¥|®w¥þ®Ñ¡n¡B¡m¤Q¤T¸gª`²¨¡n¡B¡m¤G¤Q¥|¥v¡n¡B¡m¥Ã¼Ö¤j¨å¡n¡B¡m±dº³¦r¨å¡n¡C
³o¨Ç¸ê®Æºô¸ô³£¦³¡A¦ý¬O­n°µ¨ì±Æª©º¡·Nªº¡A§Ú¥i¥HªÖ©wªº»¡¡A¤é¥»²Ä¤@¡C
³o¦³ÂI¶Ë·P±¡¡A¤£¹L¤é¥»¹ï©ó¶Ç²Î¬O¤£¿ò¾l¤Oªº¡C

Åý¤§¤W

On Sat, Nov 19, 2011 at 10:15 PM, Kang-Hao (Kenny) Lu <
kennyluck@csail.mit.edu> wrote:

> ´X¤Ñ«e Mozilla ªº dbaron ¦b mozilla.dev.platform ¤W«Å§G­n¹ê§@½Ý±Æªº«H¡C
> ·q½ÐÃöª`¡I
>
> ­ì¤å°Q½×¦ê¡÷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
>
>