mozilla

Revision 135880 of User:ryoqun

  • Revision slug: User:ryoqun
  • Revision title: User:ryoqun
  • Revision id: 135880
  • Created:
  • Creator: ryoqun
  • Is current revision? Yes
  • Comment 20 words added

Revision Content

User:ryoqun

One of great videos: http://d.hatena.ne.jp/gyuque/20070327#1175005196

 

{{ localize('System.API.new-user-page-text') }}

 Hi, my real name is Ryo Onodera. I've started to work on Mozilla around svg. I'm also planning to document about it as I dive into the codebase deeper and deeper.

The following text are just random notes for my BIG dream, which filing a bug for it is too much IMHO. yet, any constructive comments are welcome.

Final, Ultimate Solution for RTL and vertical text!!

writing-mode -> writing-direction.

                          layout-direction > text-direction > glyph-direction????

and introduce rendering-direction

I'm thinking about implementing vertical text recently in more big way. Much like RTL pages, mirrors layout directions, we should do that too in vertical text. To that end, we decouple the concept layout-direction and rendering-direction. That means we completely layouts html pages vertically.

Examples:

  Current rendering can be thought as rendering-direction=lr-tb, layout-direction=lr-tb. To be compatible, the default values for rendering-direction and layout-direction must be this. In other words, even if this is big change, almost all existing pages don't need change.

Hebrew: rendering-direction=lr-tb, layout-direction=rl-tb

 If you want to horinzontally flip image at client side, you set rendering-direction=rl-tb.

Why "rendering-diretion" is needed? -> To overide image's rotaion from the current layout-direction.

For example, "Save image icon(floppy)" and usual images shouldn't be rotated at all.

But, justification icons should be rotated accordingly current layout-direction.

How about nested layout-direction and nested rendering-direction?

other than, text-direction, layout-direction also can be used for general layout. in other words, in GTK terminology, HBOX and VBOX are generized as just BOX with different value of layout-direction. Thus, I choosed "layout-direction" not "text-direction".

   nested layout-direction: maybe, authors wants absolute.

  nested rendering-direction:

DOM API, Events clientX, clientY

CSS's top bottom left right becomes the "top" "bottom" "left" "right" in layout-coordinate system not in rendering-coordinate system. Currently, there is no distinction between them. Currently, "top" means "preceeding part of page" and "less x value".

Or should we use Pango's way aka gravity? eg _WEST _SOUTH then rotating 90 180...

Which is better my proposal or pango's way?

  opinion: I hates discriminating not-English-way writing systems. I tested pango's api a bit, but the need to rotate is confusing. As a side note, I hate the treating of Japanese input system, as the IME. a hakiish solution. this means EVERY application/framework should be modified to be able to input japanese. well this is similer the character-encoding issue. Remember how Linux is clean, by using utf8 everywhere(file name, clip board, terminal, text file. etc.). I think the problem for IME is inventing the BEST api between application and human intervined between by "key event translator". Also, there is many such api especially in linux ;). Anyway, because API is move construct idea than "layout model", that problem is difficult to solve, i gues..  :( my model is writing-system neutoral. And, for RTL web-sites, because the exposured coordinates to Javascript matches the actual text flow, this signicantly simplifies application development in this situation. Thus no discrimition to not-english-language. Just every wrinting system gets sensiby treatment.

h

e

l

l

o

the above is writing-direction="tb-rl"? This forcibly enforces the attribute regardless the language's default layout-direction is "lr-tb".

maybe, writing-direction is for layouting of glyphs, and produces texts. layout-direction is for layouting of texts (ie css box) and produces pages.

this is complex, and adequately beyond author's desire... ;)

 lower-case and upper case..... -> ABSOLUTE and relative analogy to svg's <path>'s d="" attribute.

As for the auto bi-direction althorithm, we can translate it into like this:

the <p> element's rendering-direction="lr-tb" and layout-direction="rl-tb", and the majority hebrew text's writing-direction="rl-tb", yet some english words's text become writing-direction="lr-tb". Alternatively, we can reuse layout-direction, and leave "writing-direction" for forcible layout of texts like adove "hello" example. writing-direction applied indivisually into glyphs so, mirroed texts can happen. This cannot done with just "rendering-direction"?

About standards complice: of cource, this isn't of any CSS. yet CSS3 still is not finalized. And, CSS3's the future of "writing-mode" isnot claar. So, this propose can be any chance getting into the spec?

Implementation issues.

  Feasibility: not considering standarization, and massive efforts, this can surely be accomplished, i think. After all, this separation of concepts works really low level compared to html, css. Also, no matter what the variation of writing-systems can be, we humans and monitors are restricted into 2d geometry. Fortunately, no human don't use 3d glyphs... :D Also, I've tested very primitive proof of concept. from that, this layout model isn't fandamentally flawn. That said, we, humans, must exploit the 2d plane. so, to embed information efficiently, we use one axis for primitive atomic units, and the other axis to organize the first axis. this is similar to "number representaion system" -> 2*10 + 3 = 23. So, this model should be exhausive?

 The implementation has two stage. First is for block-level vertical layout awareness. First is for inline-level horizontal layout awareness. They closely corresponds for implementing RTL.

  Work amount: Tremoundrous period.

  Complexity: Firstly, we must boil/nail down this layout model in really solid. After that, we just need to massive mundane code rewrite. Can this be automatically done?

 Performance: Maybe not so so. just one "if"s around EVERY coordinate calculation :p But remember that we are converting many units already(pango units app units css units device units...) this is true for stirngs(utf16 <--> utf8). There should be no noticiable performance degration.

Authoring webpages using this facility.

As before, the difficulty of creating web-pages for only single writing system don't change. Equaly,   as determined they don't support horinzontal view, vertical web-pages can be accomplished as same difficulty by implicity assuming layout-coordinate axis and rendering-coordinate axis are same and hardcoding them. More importantly, how diffult mixed layout-direction web-pages and multi-writing-system-compatible web-pages is the prominent problem.

 

Revision Source

<p>User:ryoqun</p>
<p>One of great videos: <a class=" external" href="http://d.hatena.ne.jp/gyuque/20070327#1175005196" rel="freelink">http://d.hatena.ne.jp/gyuque/20070327#1175005196</a></p>
<p> </p>
<p>{{ localize('System.API.new-user-page-text') }}</p>
<p> Hi, my real name is Ryo Onodera. I've started to work on Mozilla around svg. I'm also planning to document about it as I dive into the codebase deeper and deeper.</p>
<p>The following text are just random notes for my BIG dream, which filing a bug for it is too much IMHO. yet, any constructive comments are welcome.</p>
<p>Final, Ultimate Solution for RTL and vertical text!!</p>
<p>writing-mode -&gt; writing-direction.</p>
<p>                          layout-direction &gt; text-direction &gt; glyph-direction????</p>
<p>and introduce rendering-direction</p>
<p>I'm thinking about implementing vertical text recently in more big way. Much like RTL pages, mirrors layout directions, we should do that too in vertical text. To that end, we decouple the concept layout-direction and rendering-direction. That means we completely layouts html pages vertically.</p>
<p>Examples:</p>
<p>  Current rendering can be thought as rendering-direction=lr-tb, layout-direction=lr-tb. To be compatible, the default values for rendering-direction and layout-direction must be this. In other words, even if this is big change, almost all existing pages don't need change.</p>
<p>Hebrew: rendering-direction=lr-tb, layout-direction=rl-tb</p>
<p> If you want to horinzontally flip image at client side, you set rendering-direction=rl-tb.</p>
<p>Why "rendering-diretion" is needed? -&gt; To overide image's rotaion from the current layout-direction.</p>
<p>For example, "Save image icon(floppy)" and usual images shouldn't be rotated at all.</p>
<p>But, justification icons should be rotated accordingly current layout-direction.</p>
<p>How about nested layout-direction and nested rendering-direction?</p>
<p>other than, text-direction, layout-direction also can be used for general layout. in other words, in GTK terminology, HBOX and VBOX are generized as just BOX with different value of layout-direction. Thus, I choosed "layout-direction" not "text-direction".</p>
<p>   nested layout-direction: maybe, authors wants absolute.</p>
<p>  nested rendering-direction:</p>
<p>DOM API, Events clientX, clientY</p>
<p>CSS's top bottom left right becomes the "top" "bottom" "left" "right" in layout-coordinate system not in rendering-coordinate system. Currently, there is no distinction between them. Currently, "top" means "preceeding part of page" and "less x value".</p>
<p>Or should we use Pango's way aka gravity? eg _WEST _SOUTH then rotating 90 180...</p>
<p>Which is better my proposal or pango's way?</p>
<p>  opinion: I hates discriminating not-English-way writing systems. I tested pango's api a bit, but the need to rotate is confusing. As a side note, I hate the treating of Japanese input system, as the IME. a hakiish solution. this means EVERY application/framework should be modified to be able to input japanese. well this is similer the character-encoding issue. Remember how Linux is clean, by using utf8 everywhere(file name, clip board, terminal, text file. etc.). I think the problem for IME is inventing the BEST api between application and human intervined between by "key event translator". Also, there is many such api especially in linux ;). Anyway, because API is move construct idea than "layout model", that problem is difficult to solve, i gues..  :( my model is writing-system neutoral. And, for RTL web-sites, because the exposured coordinates to Javascript matches the actual text flow, this signicantly simplifies application development in this situation. Thus no discrimition to not-english-language. Just every wrinting system gets sensiby treatment.</p>
<p>h</p>
<p>e</p>
<p>l</p>
<p>l</p>
<p>o</p>
<p>the above is writing-direction="tb-rl"? This forcibly enforces the attribute regardless the language's default layout-direction is "lr-tb".</p>
<p>maybe, writing-direction is for layouting of glyphs, and produces texts. layout-direction is for layouting of texts (ie css box) and produces pages.</p>
<p>this is complex, and adequately beyond author's desire... ;)</p>
<p> lower-case and upper case..... -&gt; ABSOLUTE and relative analogy to svg's &lt;path&gt;'s d="" attribute.</p>
<p>As for the auto bi-direction althorithm, we can translate it into like this:</p>
<p>the &lt;p&gt; element's rendering-direction="lr-tb" and layout-direction="rl-tb", and the majority hebrew text's writing-direction="rl-tb", yet some english words's text become writing-direction="lr-tb". Alternatively, we can reuse layout-direction, and leave "writing-direction" for forcible layout of texts like adove "hello" example. writing-direction applied indivisually into glyphs so, mirroed texts can happen. This cannot done with just "rendering-direction"?</p>
<p>About standards complice: of cource, this isn't of any CSS. yet CSS3 still is not finalized. And, CSS3's the future of "writing-mode" isnot claar. So, this propose can be any chance getting into the spec?</p>
<p>Implementation issues.</p>
<p>  Feasibility: not considering standarization, and massive efforts, this can surely be accomplished, i think. After all, this separation of concepts works really low level compared to html, css. Also, no matter what the variation of writing-systems can be, we humans and monitors are restricted into 2d geometry. Fortunately, no human don't use 3d glyphs... :D Also, I've tested very primitive proof of concept. from that, this layout model isn't fandamentally flawn. That said, we, humans, must exploit the 2d plane. so, to embed information efficiently, we use one axis for primitive atomic units, and the other axis to organize the first axis. this is similar to "number representaion system" -&gt; 2*10 + 3 = 23. So, this model should be exhausive?</p>
<p> The implementation has two stage. First is for block-level vertical layout awareness. First is for inline-level horizontal layout awareness. They closely corresponds for implementing RTL.</p>
<p>  Work amount: Tremoundrous period.</p>
<p>  Complexity: Firstly, we must boil/nail down this layout model in really solid. After that, we just need to massive mundane code rewrite. Can this be automatically done?</p>
<p> Performance: Maybe not so so. just one "if"s around EVERY coordinate calculation :p But remember that we are converting many units already(pango units app units css units device units...) this is true for stirngs(utf16 &lt;--&gt; utf8). There should be no noticiable performance degration.</p>
<p>Authoring webpages using this facility.</p>
<p>As before, the difficulty of creating web-pages for only single writing system don't change. Equaly,   as determined they don't support horinzontal view, vertical web-pages can be accomplished as same difficulty by implicity assuming layout-coordinate axis and rendering-coordinate axis are same and hardcoding them. More importantly, how diffult mixed layout-direction web-pages and multi-writing-system-compatible web-pages is the prominent problem.</p>
<p> </p>
Revert to this revision