- From: Wei Huang <daviseago@gmail.com>
- Date: Mon, 28 Nov 2011 14:51:12 +0800
- 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