W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > November 2011

@ݱƤrƪ]Fwd: Implementing vertical text/layout support^

From: Peter Peng <sinsun@gmail.com>
Date: Mon, 21 Nov 2011 02:44:25 +0800
Message-ID: <CAALmQ=Ftdn--xbWs29=0dh9Skpju-vUs1aLZ5LMGJH40UtpxqQ@mail.gmail.com>
To: W3C HTML5 忳p <public-html-ig-zh@w3.org>, Ѽֳ <moztw-general@googlegroups.com>, Mozilla }o <dev-general-zh@lists.mozilla.org>
---------- 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>


ڧDA
ƺ@A
i̦X{饻C
i̦nƪA|oͦb饻C
npݤ饻ۡA
ڷQAO饻Y@ƺAФFja[IA
MxWҥA
cAnNA|sC:P
򥻤Wڭ̤HӦhƦƪu@C
AɨrC
dr峣٦ӦhrSrC
AӡA̻ݭnƪNOjyFC
AMOm|wѡnBmQTg`nBmGQ|vnBmü֤jnBmdrnC
oǸƺAOnƪNAڥiH֩wA饻Ĥ@C
oI˷PAL饻DzάOlOC

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ŧGn@ݱƪHC
> 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
>
>
Received on Sunday, 20 November 2011 18:44:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:49 UTC