One of great videos: http://d.hatena.ne.jp/gyuque/20070327#1175005196
Not implemented, update template.
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.
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.
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?
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?
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.