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

Re: 實作豎排文字/排版(Fwd: Implementing vertical text/layout support)

From: Wei Huang <daviseago@gmail.com>
Date: Mon, 28 Nov 2011 14:51:12 +0800
Message-ID: <CAJPS4ybwW9EtpoBfbgprFV=aX66j3FfJoQ4p-xRuT3r6Dqz4MA@mail.gmail.com>
To: Peter Peng <sinsun@gmail.com>
Cc: W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>, 火狐俱樂部 <moztw-general@googlegroups.com>, Mozilla 開發 <dev-general-zh@lists.mozilla.org>
Peng先生所說的日本網站,及台灣模仿都是哪些,可否介紹一下,我想這對大家都有借鑒意義。
我知道一個"竹取web JS版"可以改為直書。
中文方面的開發,我感覺中國人自己確實貢獻很少,很多都是西方人開發。日本、台灣感覺還好些,我們大陸這邊真未感覺到誰要解決這些問題。對傳統的割裂態度,在技術上必然如此結果。

直書好像在webkit已經實現了(日本人做的),這樣將來chrome也能支持。現在Mozilla也打算做,真是好消息。

缺字問題同樣的中文信息化裡的問題,古籍、佛經等都有很多字不能顯示。我個人覺得只有動態組字,才能真正解決此問題,否則unicode再如何加字,也是有限的。不過在現階段,在Web應用上,不知道利用Google的web
font是否可以解決缺字的問題。也只是我個人的一點想法。

可嘆現今中國就是像我這樣有想法的人多,踏實肯幹的人少。

2011/11/21 Peter Peng <sinsun@gmail.com>:
>
>
>
> 恕我岔題,
> 直排網頁的實作,
> 可能最早出現於日本。
> 可能最好的排版,會發生在日本。
> 不要小看日本對於美的執著,
> 我想,先是日本的某一直排網站顛覆了大家的觀點,
> 然後台灣模仿,
> 呃,不好意思,中國會山寨。:P
> 其實基本上我們中國人有太多數位化的工作。
> 首先,補足字體。
> 康熙字典都還有太多字沒有字型。
> 再來,最需要直行排版的就是古籍了。
> 首先,當然是《四庫全書》、《十三經注疏》、《二十四史》、《永樂大典》、《康熙字典》。
> 這些資料網路都有,但是要做到排版滿意的,我可以肯定的說,日本第一。
> 這有點傷感情,不過日本對於傳統是不遺餘力的。
> 讓之上
> On Sat, Nov 19, 2011 at 10:15 PM, Kang-Hao (Kenny) Lu
> <kennyluck@csail.mit.edu> wrote:
>>
>> 幾天前 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 Monday, 28 November 2011 06:51:40 UTC

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