實作豎排文字／排版（Fwd: Implementing vertical text/layout support）
Kang-Hao (Kenny) Lu
敬請關注！
原文討論串→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 <dba...@dbaron.org>
Reply-To: dev-pl...@lists.mozilla.org
To: dev-pl...@lists.mozilla.org, dev-tec...@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
Peter Peng
From: Peter Peng <sin...@gmail.com>
Date: Mon, Nov 21, 2011 at 2:42 AM
Subject: Re: 實作豎排文字／排版（Fwd: Implementing vertical text/layout support）
To: "Kang-Hao (Kenny) Lu" <kenn...@csail.mit.edu>
恕我岔題，
shi chuan
Shi Chuan Web Developer
Twitter: @shichuan | Skype: shichuanr
shic...@gmail.com | www.blog.highub.com
jobinson
jobinson
.----------------.
end | | start
'----------------'
after
2 | 1
Wei Huang
我知道一個"竹取web JS版"可以改為直書。
中文方面的開發，我感覺中國人自己確實貢獻很少，很多都是西方人開發。日本、台灣感覺還好些，我們大陸這邊真未感覺到誰要解決這些問題。對傳統的割裂態度，在技術上必然如此結果。
直書好像在webkit已經實現了（日本人做的），這樣將來chrome也能支持。現在Mozilla也打算做，真是好消息。
缺字問題同樣的中文信息化裡的問題，古籍、佛經等都有很多字不能顯示。我個人覺得只有動態組字，才能真正解決此問題，否則unicode再如何加字，也是有限的。不過在現階段，在Web應用上，不知道利用Google的web
font是否可以解決缺字的問題。也只是我個人的一點想法。
可嘆現今中國就是像我這樣有想法的人多，踏實肯幹的人少。
2011/11/21 Peter Peng <sin...@gmail.com>: