Open Bug 145503 (writing-mode) Opened 22 years ago Updated 2 months ago

[META] CSS3 writing-mode (vertical text)

Categories

(Core :: Layout: Block and Inline, enhancement)

enhancement

Tracking

()

People

(Reporter: bugzilla_kl, Unassigned)

References

(Depends on 51 open bugs, Blocks 2 open bugs, )

Details

(4 keywords)

Attachments

(8 files, 1 obsolete file)

please implement this option as -moz-writing-mode soon, coz it's very often
requested by page authors.
Severity: normal → enhancement
Summary: CSS3 writing mode → [RFE] CSS3 writing mode
confirming... This will take oodles of work, though...
Keywords: helpwanted
OS: Linux → All
Hardware: PC → All
Summary: [RFE] CSS3 writing mode → CSS3 writing mode (writing-mode)
Mark as NEW too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → Future
Keywords: css3
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: cpetersen0953 → ian
Keywords: intl
*** Bug 235443 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
> .

Out of interest is this still been worked on? Being 2 years old and stuff :).
Thanks alot.
Please don't respond to bugs if you don't have to add something useful (this
will only slow down the development process). There are a lot of bugs and among
those bugs, CSS3 certainly isn't a priority.
Alias: writing-mode
The entire Text Layout section has problems.

http://lists.w3.org/Archives/Public/www-style/2003Jul/0146.html
Keywords: helpwanted
Whiteboard: spec unstable, wait for confirmation from WG
*** Bug 271362 has been marked as a duplicate of this bug. ***
*** Bug 278707 has been marked as a duplicate of this bug. ***
This page works fine using IE.
*** Bug 309230 has been marked as a duplicate of this bug. ***
writing-mode is written twice in the summary and vertical-text is not. Updating summary to help searching for duplicates.
Summary: CSS3 writing mode (writing-mode) → CSS3 writing mode (vertical text)
Summary: CSS3 writing mode (vertical text) → CSS3 writing-mode (vertical text)
Blocks: 319163
Reference : JIS X 4051

I need writing-mode attribute.
Firefox is the best browther, but It is inferior to IE in this.
In Asia,Some people think columnar writing is more legible than horizontal writing,too.
Especially, in Japan, Most novels(and newspapers) are written in columnar writing.

I hope this works in firefox,too!
I'm afraid there's little, if any, chance to be fixed.

IE8 has already changed the property name
from "writing-mode" to "-ms-writing-mode".
http://msdn.microsoft.com/en-us/library/ms531187(VS.85).aspx

fantasai's "Unicode Technical Note #22" suggests
judge-language-per-Unicode-chars methods.
Then Gecko is going to re-implement something
like Pango, which now we're using to choose fonts on linux?
Or integrate Pango on all platforms?
Indeed Pango seems able to render mixed-direction vertical-text.

http://www.unicode.org/notes/tn22/
http://www.pango.org/ScriptGallery
"writing-mode" is moved to css3 Text Layout.  (Currently, there is no working draft.  Only editor draft)
Hi. I'm recklessly trying to implement this. Well, when I imagine the amount of code to rewrite, I can't help but laugh. It may turn out that I can't handle this size of change... Definitely, I'll need help. OK, I'm a challenger.

Currently, I'm trying to render vertical text via svg's <text> without considering about overlapping and telling correct font metrics to upper layers. That's because I think this is rather shortcut code path to gfxFont::Draw() than via html. (Alternatively I can use Canvas's text API, but sadly, I don't know much about Canvas) In this way, when I play with possible next API for vertical text, I can comparably-quickly fiddle it.

thebes is ignorant about the vertical text layout provided by the trio of pango, fontconfig, and freetype. So, firstly I have to make it possible as soon as possible. Only then, I can contemplate how I integrate vertical text layout into the current vertical-ignorant rendering system..... As for the problem, I'm prematurely thinking about in this way which I put online here(Be careful, this is draft in every sense.):
https://developer.mozilla.org/User:Ryoqun
Attached patch patch_v0.00001 (obsolete) — Splinter Review
I started to write down what I've learned:
https://developer.mozilla.org/en/Gfx2

When I created the page, I did something wrong. Following pages should be removed. And the "2" in the above URL should be removed....
https://developer.mozilla.org/Gfx
https://developer.mozilla.org/Gfx2

Also this is the first patch. This illustrates what exactly I mean by "layout direction". This is cherry-picked changes. It won't build. But I can build on my tree and somehow It renders LRT and RTL correctly, vertical text incorrectly. Because I must to know how to get vertical metrics from glyphs. Anyway, this patch shows firstly I abstract LRT and RTL, which simplifies the code in itself. Then, Under the abstraction, I'm adding vertical one. But I don't know this design works across the whole gfx/gecko stack.....
Progress report 1.

I'm sick. Never-ending reading, reading, forgetting and reading. ;)

I'm thinking breaking down this whole bug into several parts like this:
Part. 1 gfx part:
Maybe, need to add "writing-mode" property to gfxFont. But I'm ignoring this currently. Because this is really a well-separated problem. I'm just using the heckery of using horizontal metrics as if vertical metrics. Because Japanese glyphs are almost square. ;) 
Part. 2 resolution part:
Without the aid of markup and style, we need detect English words inside vertical Japanese text. This is similar to the BIDI resolution. I'm ignoring this too, because the vertical pure Japanese text doesn't exposure such problem.
Part. 3 layout part:
I'm tackling this.
Originally I had two plans. One is using coordinate transformation. I thought this would be easier than the other, because once I applied the transformation correctly, glyphs will advance vertically even if the actual code increments x variables. This meant that I wouldn't need excessive code change. This is similar to the full-zoom. But that turned out to be fail. Because reflowing is so interleaved each other. There is no easy way for transforming those many coordinates passed by the raw nscoord! Even if I tried to do that, it would miss the first objective of the benefit of being easy in the first place. So, I moved to the plan 2.
Plan 2 is not easy but correct way. Inspect every coordinate variable and decide whether the number should be added or subtracted to X or from Y. As said, this is not easy, but in the course of it, the existing RTL code(which does similar job) will guide me considerably.
The text part in the reflow was beyond my intelligence. ;) I've given up that. I turned to images and specifically square ones because with them I don't need to worry swapping widths and heights. With this condition, I only need to worry to tile them from top-right to bottom-left when I resize the window. In the course of it, what I did in the kindergarten with wooden blocks will guide me considerably.
I think plan 1 is the right approach, if I understand your plans correctly.

We don't want to add a lot of complexity to block and inline layout by making every reference to x/y/width/height conditional on the block orientation. We also don't want to duplicate a lot of code by having two (or more) separate block and inline implementations. So I think the only reasonable approach is to use regular block and inline layout but transform coordinates when we enter Reflow and when we paint or handle events.

Can you explain in more detail why you don't think this will work?
Firstly, keep in mind that because I want to implement this purely from the passion, emotionally I rather want to do the correct way. Thus, following my opinions may be biased, and I may not be convinced until I fail to do with plan 2 due to the difficulty. Sorry for my selfishness and stubbornness.

Reason 1. I'm thinking that vertically- and horizontally- mixed pages should be considered. Images shouldn't be affected by the transformation and small English words too(such as trademarks). Web authors even may want to override such automatic resolution(For example, "unicode-bidi: bidi-override;"). Although this is purely my speculation, I'm thinking completely vertical websites don't appear. If used, vertical texts will be used only in the content not in the UI part. Vertical UI may be too odd, because all other UIs have been horizontal for long time.
As a conclusion, this means the reflow part with transformations can't be completely ignorant of the transformation itself. And at various parts, we will apply several transformations. That partly invalidates the purpose of transformation, first of all. Thus I think from the very first, I'm better off not using transformations.
Reason 2. BIDI layout is done by not using transformation. This means that although certainly doing plan 2 is hard, this may be alleviated because of the existing BIDI. Also, I'm even thinking that I introduce some mechanism of addressing both RTL and vertical layout at the same time. This is demonstrated in the attached patch.
Reason 3. I'm fearing that plan 1 would cause uncertain limitations as we refine the vertical layout support. And transformations may incur performance hit only when vertical text. This will worsen if transformations are used multiple times. Because I'm idealist, I don't really want to introduce the perception of second-class citizenship of the vertical text. We also should be aware that transformations must be applied not only to layout but to rendering and event handling, which likens the possibility of the performance problem. But I don't have the experience of how much exactly transformations are expensive...
Reason 4. I'm thinking plan 2 is not so complicated. No mater how we reflow the content, we have the conceptual inline text direction and text block direction. So, we will use the unified, single reflow codepath. So, my plan is to inspect the use of x, y, width and height, and separate them from the geometry concepts by using the coupled type for the abstraction called like this: nsLayoutRect.
We use the conceptional layout coordinate system only when reflowing. In the domain of rendering and event handling, we use the underlying rendering coordinate system. So we confine the coordinate juggling into minimal usage. It overall may be easier than the plan 1.

I've attached a hand-edited patch, which improves the first attached patch. It shows the idea I'm talking about. In it, including the existing RTL case and the forthcoming vertical case, I hide it under gfxLRect. When I usually compute the coordinate, I access via x and width, which is in the layout coordinate, but when I export the result of the computation, I access via rLeft and rTop, which in turn, is in the rendering coordinate.
Although this is really tiny, and I'm not certain about the feasibility, I'm hoping the same thing can be accomplished at the layout part. In other words, my primary job is to pack those directly stored raw nscoords into nsLRect or nsLSize where appropriate.

Last but not least, thanks for replying! Whichever the solution will be, I'll definitely need help. Also, reactions from other people encourages and motivates me in considerable degree.
Attachment #374869 - Attachment is obsolete: true
The rotation of Japanese glyphs with respect to the baseline should be handled at the font level. I'm not sure what the current APIs are for this, but it's definitely not something we should be doing in Gecko. Also, for the default case, you should not be running into any BIDI issues. The default case is defined so that text gets rotated 90deg clockwise, and the uprightness of CJK characters is handled by using the vertical variant of a font. There are CSS controls proposed for changing this (e.g. forcing upright Latin) but I wouldn't recommend tackling that in a first pass. You will have to handle mixed-direction pages, however. I recommend playing with IE8's implementation, they've been working with the CSSWG to try to get things right even though we don't have a full spec for this yet.
Progress report 2.

Hooray! Yummy screenshots. In following my comments, I'll reply to Comment 25 and write the state of progress in detail with some excerpt patches, because It seems I can't attach multiple file at once. First and foremost, I want to share my results with people, sorry. :)
Screenshot 2.
(In reply to comment #25)
As I wrote in Comment 22, this bug is broken into several parts. As you suggest I'm going to handle glyph rotations and such low-level rendering issue for vertical text in the gfx part. But when I make the layout part vertical-layout-aware, similar code used by RTL pages becomes necessary. As RTL implementation doesn't just end with RTL textruns, we need to modify the layout part to support vertical layout if I don't use the transformation solution.

I've played with IE7's implementation. One of things I found is that IE decides the height of vertical blocks from the height of the block as if it weren't vertical. I think this is one possible solution. But, I'm thinking we can treat vertical text blocks without explicit height as replaced elements and applying the 300px constant. Anyway, when using vertical text in the horizontal page layout, every such blocks should have height property to get any sensible page layout, I guess. That's because without heights, the layout part really don't know how much the height of vertical text block should stretch. Also, the more elaborate reason is that I want something below can have a sensible definition(I attached a mockup).

<style>
div  { writing-mode: lr-tb; }
vdiv { writing-mode: tb-rl; }
rdiv { writing-mode: rl-tb; }
</style>
<div>Something horizontal</div>
<vdiv>Something vertical</vdiv>
<vdiv>Something vertical2</vdiv>
<rdiv>Something horizontal2</rdiv>

In this example, an anonymous vertical layout canvas(In the following actual progress report 2, I'll explain what "layout canvas" is.) with the height of 300px is created much like anonymous blocks in CSS. I want the height of the layout to be content-independent to make this anonymous layout canvas creation to be consistent...
When we supported only lr-tb and rl-tb, we din't need to introduce this concept, because lr-tb and rl-tb can live with each other happily. But by introducing vertical text, we need to do something similar to this mechanism because we need to swap X axis and Y axis...
(Actual) Progress Report 2.
Up to now:
Firstly, I'll explain the screenshots. I modified the inline layout part to use nsLayoutCanvas. In the first one, inline images are reflowed. In the second one, actual text frames are reflowed. As you can see, borders are positioned in the wrong place although I've succeeded to swap the height and width of the sum of LineBoxes.

Layout Canvas(I borrowed the term 'canvas' from http://www.w3.org/TR/CSS2/intro.html#canvas):
This is what I'm currently experimenting as the solution for the support of writing-mode in the layout part. It is an abstraction for an infinite rectangular area in the layout coordinate system used only for reflowing frames, and it is almost completely separated from the rendering coordinate system. The first design(gfxLRect) which is being used in gfxFont::Draw doesn't well suit to the layout part. Just LayoutRects weren't enough. I needed some area in which LayoutRects are moved around.
By nsLayoutCanvas, we can make the performance loss really smaller than gfxLRect. The actual coordinate arithmetic are done without any overloaded operator functions, and I convert the layout coordinates into the rendering coordinates only when I output to or input from the outside reflow contexts. The code for the declaration and definition and the essential part of using nsLayoutCanvas is attached. As a last note, perhaps, this is the best benefit: code modification will be minimal.

Now:
What I'm desperately lacking is the experience in the Mozilla codebase. I'm doing everything in a very hackish way with the liveliness of printfs. Whenever I want to make every small design experiments, I must observe, experiment and conclude to know how things are working. This is time-consuming and it hampers my development and hurts my motivation. Thus, I can't really plan the time schedule. If you'd like things to happen a lot sooner, a mentor as in GSoC is needed. But even if no one helps me, because Mozilla and my platform(Ubuntu) is fully open sourced, theoretically with good time and effort, it's not infeasible that I'll eventually do every work needed. I'm not sure writing-mode is in such high priority and I'm eligible to request a mentor. Anyway, I hope my motivation won't get irreversibly exhausted....

From now:
  Integrate RTL into layout canvas.
  Make blocks-in-blocks layout code layout-canvas-aware.
    anonymous layout canvas creation?
  Use correct top, right, bottom and left of margins border and padding.
  Mixed content and nsLayoutCanvas of different direction
  Expand various parts of specs.
    allow text-align: top and bottom.
      (in implementation's view, this is synonym for
       left and bottom, respectively)
    allow float: top and bottom.
      (in implementation's view, this is synonym for
       left and bottom, respectively. But, I need to
       do work hard for areas across different layout directions.)
    create horizontal-align: left and right.
      (this is similar to vertical-align. but in the 
       case of vertical text, the vertical-align's
       implied typography doesn't apply well.)
  Columns(needs to fix Bug 422089)
  Polish the modification(including the gfx part) and freeze the design.

In the future:
  Lists
  Tables

Although my design isn't still well thought, any comments will be welcomed. Especially, if you have any questions in my progress report, let me know. I'll try to explain.
You want to look at IE8 not IE7. IE7 is totally different. In IE8, IIRC, the default height of a vertical block is the viewport height. 7Paul Nelson and I discussed this and neither of us wanted to standardize the automagic behavior of IE7.

Don't implement horizontal-align, just use vertical-align. We really don't need a separate property for this.

Are you implementing 'block-progression: tb | rl | lr', or just 'writing-mode'?
+nscoord nsLayoutCanvas::GetLeft () const {
+    switch (ld) {
+    case LAYOUT_DIRECTION_LR_TB:
+    case LAYOUT_DIRECTION_RL_TB:
+        return GetRLeft();
+    case LAYOUT_DIRECTION_TB_RL:
+        return GetRTop();
+    }
+}

+  psd->mLeftEdge = aLC.GetLeft();
+  psd->mX = aLC.GetLeft();
+  psd->mRightEdge = aLC.GetRight();

Unfortunately I don't think the performance impact on horizontal text is going to be acceptable ... replacing a simple load with a function call containing a switch is going to be very expensive in run time and also code size. That is why I think we reallyneed to leave block, inline, table, xul, MathML etc layout as-is and have your "layout canvas" objects actually rotate things, as I said in comment #23.

So I think that even if you managed to produce a gigantic patch that actually does everything you want to do, it's quite likely we still wouldn't take it due to extra code size and slow down of horizontal layout.

(In reply to comment #24)
> Firstly, keep in mind that because I want to implement this purely from the
> passion, emotionally I rather want to do the correct way. Thus, following my
> opinions may be biased, and I may not be convinced until I fail to do with
> plan 2 due to the difficulty. Sorry for my selfishness and stubbornness.

No problem, I'm very glad you're enthusiastic!

> Reason 1. I'm thinking that vertically- and horizontally- mixed pages should
> be considered. Images shouldn't be affected by the transformation and small
> English words too(such as trademarks). Web authors even may want to override
> such automatic resolution(For example, "unicode-bidi: bidi-override;").
> Although this is purely my speculation, I'm thinking completely vertical
> websites don't appear. If used, vertical texts will be used only in the
> content not in the UI part. Vertical UI may be too odd, because all other UIs
> have been horizontal for long time.

I agree.

> As a conclusion, this means the reflow part with transformations can't be
> completely ignorant of the transformation itself.

That's true, but the transformation knowledge can be limited to a few places, which is better than changing everything.

> And at various parts, we will apply several transformations.

That is not a problem.

> That partly invalidates the purpose of
> transformation, first of all. Thus I think from the very first, I'm better off
> not using transformations.

I don't think your logic here is correct.

> Reason 2. BIDI layout is done by not using transformation. This means that
> although certainly doing plan 2 is hard, this may be alleviated because of the
> existing BIDI. Also, I'm even thinking that I introduce some mechanism of
> addressing both RTL and vertical layout at the same time. This is demonstrated
> in the attached patch.

Bidi isn't going to help you very much. With Bidi we basically lay out top to bottom, left to right and then after laying out each line we move stuff around horizontally to its final position ("bidi reordering" phase). That won't work for you.

> Reason 3. I'm fearing that plan 1 would cause uncertain limitations as we
> refine the vertical layout support. And transformations may incur performance
> hit only when vertical text. This will worsen if transformations are used
> multiple times. Because I'm idealist, I don't really want to introduce the
> perception of second-class citizenship of the vertical text. We also should be
> aware that transformations must be applied not only to layout but to rendering
> and event handling, which likens the possibility of the performance problem.
> But I don't have the experience of how much exactly transformations are
> expensive...

Generally event handling is insignificant for performance. Painting is generally much less of a performance problem than layout, and simpler too, so we prefer to do things during painting instead of layout when possible.

We need to optimize for the common case, and the common case is horizontal text. If that means we can't get equal performance for horizontal and vertical text, that's the way it has to be. I do think that taking the "plan 2" approach would actually lead to *slower* vertical text performance than "plan 1", because it will slow down *all* layout a lot.

> Reason 4. I'm thinking plan 2 is not so complicated. No mater how we reflow
> the content, we have the conceptual inline text direction and text block
> direction. So, we will use the unified, single reflow codepath. So, my plan
> is to inspect the use of x, y, width and height, and separate them from the
> geometry concepts by using the coupled type for the abstraction called like
> this: nsLayoutRect. We use the conceptional layout coordinate system only
> when reflowing. In the domain of rendering and event handling, we use the
> underlying rendering coordinate system. So we confine the coordinate juggling
> into minimal usage. It overall may be easier than the plan 1.

Certainly something like nsLayoutRect is the right way to go if you want to do "plan 2", but I still insist that it will be much more work than plan 1.

One more comment: if you create a new kind of object like "layout canvas", don't call it "canvas" (which is already used for at least 2 different things in layout).

Thanks!
(In reply to comment #30)
OK, I looked at IE8.

I've relaxed the original idea of horizontal-align in Comment 29. Currently, I think horizontal-align is just synonymous for vertical-align, much like float: top, bottom will be allowed in vertical text. Generally, I think web developers shouldn't be confused with 'width', 'height', 'top', 'right', 'bottom', 'left', 'horizontal', 'vertical', 'offsetLeft' and 'offsetTop'. As this is the case in the rtl layout, those should really be of physical dimension not reflowing/layout one.

As for the last question, I'm not sure what you exactly wanted to ask me. I'm doing whatever needed to render the vertical text layout. Maybe, the answer is that I'm implementing the both.

(In reply to Comment #31)
I renamed nsLayoutCanvas to nsLayoutTransform.

Thanks for notifying me the performance-wise problem at early stage! Accordingly, I've changed my approach. Still I'm not using transformations by means of gfx or actual transformation matrix. But I've moved the crux part from each line layout to block frame. My current actual design is that nsIFrame::mRect is in the rendering coordinate system. In other words, immediately before I set nsIFrame::SetRect in the reflow stage, I transform coordinates.
I don't know this still intolerably worsens the performance, yet this should be way better than that of the original one. I no longer re-construct nsLayoutCanvas at each nsLineLayout construction and the loading issue you mentioned.
Also, sorry about ignoring your suggestion, but still I can't resort to Plan 1. In the worst scenario, my change won't be accepted. That's fine. At least, doing Plan 2 teaches me a lot about the gecko codebase. Then, should I be completely knocked down by the mere practical difficulty, performance regression, etc of Plan 2, I would turn to the Plan 1 with the very knowledge acquired from Plan 2.

Progress Report 3
For some time, the work had stagnated, yet recently I've regained some motivation and finally I've reached to another milestone.

Now, blocks are vertical layout aware.
Progress Report 4.

http://www.flickr.com/photos/39168120@N03/3605426181/sizes/o/

Still, I'm continuing to grasp the big picture of the mozilla codebase.
As a small concrete milestone, I was hacking on nsColumnSetFrame. Here is the screenshot. The use of columns in this way in the paper media is very common in Japan at least. So, I'll put some effort to do it right when supporting the vertical text, especially the treatment of floats. In the course of it, to fix bug 422089 is important. Also, we may need to consider such use cases in the CSS3/Text WG.
Also, we need tb_lr for Mongolian text. 

http://www.w3.org/TR/2003/CR-css3-text-20030514/#writing-mode
in China, most Mongolian site use tb_rl and some special work to make it from left to right. 

e.g.

mng.ulaaq.com

shown correctly in IE.

But it would be great if we have tb_lr support.
Attached file tb-lr test
Patch for "Page test about writing-mode Attribute"
tb-lr test uploaded
I download Minefield 3.6a1pre but it does not support tb-rl.
(In reply to comment #33)
> Progress Report 4.
> 
> http://www.flickr.com/photos/39168120@N03/3605426181/sizes/o/
> 
> Still, I'm continuing to grasp the big picture of the mozilla codebase.
> As a small concrete milestone, I was hacking on nsColumnSetFrame. Here is the
> screenshot. The use of columns in this way in the paper media is very common in
> Japan at least. So, I'll put some effort to do it right when supporting the
> vertical text, especially the treatment of floats. In the course of it, to fix
> bug 422089 is important. Also, we may need to consider such use cases in the
> CSS3/Text WG.

I download Minefield 3.6a1pre but it does not support tb-rl. which Minefield are you using?
See this: 

http://blogs.msdn.com/ie/archive/2009/05/29/the-css-corner-writing-mode.aspx

IE8 supports:

lr-tb

rl-tb

tb-rl

bt-rl

tb-lr

bt-lr

lr-bt

rl-bt

All these layouts


I hope Firefox can meet the IE standard or do better than it.
And its example...

<html>
	<head>
    		<meta http-equiv="X-UA-Compatible" content="IE=8" >
		<title>writing-mode, sample 1: vertical text, auto width/height</title>
		<style type="text/css">
			body { 
				font: 14pt Georgia, serif; 
				color:green;
			}
			div {
				color: red;
				border: 2px black solid;
				padding:.25em;
			}
		</style>
	</head>
	<body>
		This text is in the body. It is left to right, top to bottom.
		<div style="writing-mode: lr-tb">

		This text is in the first block.<br>
		Its direction is left-to-right. Its block progression top-to-bottom.
		The block has width:auto and height:auto. 
		</div>
		<div style="writing-mode: tb-lr">
		This text is in the second block.<br>
		Its direction is top-to-bottom. Its block progression is left-to-right.
		The block has width:auto and height:auto. 
		</div>
	</body>
</html>
Yohan, there is no finished patch here, and no indication that anything has been checked in, so you should not expect it to be fixed in any build you download. Your comments are not helping get this bug fixed.
I mean, repair lr-tb,rl-tb,tb-rl,bt-rl,tb-lr,bt-lr,lr-bt,rl-bt together, not just tb-rl. I mention them here in case you repair tb-rl only.
(In reply to comment #42)
> Yohan, there is no finished patch here, and no indication that anything has
> been checked in, so you should not expect it to be fixed in any build you
> download. Your comments are not helping get this bug fixed.

But how did Ryo Onodera make that image from Minefield?
(In reply to comment #44)
> (In reply to comment #42)
> > Yohan, there is no finished patch here, and no indication that anything has
> > been checked in
> 
> But how did Ryo Onodera make that image from Minefield?

No *finished* patch, he's working on one that's as yet *unfinished* but perhaps partially works (only partially of course, else it would be finished).  Further, I also request you to refrain from commenting.
Progress Report 5
I'm making progress slowly. Because I'm still not fluent with the codebase, just more and more time will be needed to educate myself. Also, spamming this bug page with no actual patch nor no design discussion is rather annoying, I think. So, I've launched my personal blog site, which will include following progress reports. I wish I do that in more frequent manner ;) Also, if you're interested, you can pull my mercurial repositories for the working branch[2] and test files[3]. Well, they are VERY UGLY. The resulting executables vomit quite a bit of ASSERTIONs. Yet, at least I want soneone to check that this builds on Ubuntu 9.04 and barely works. ;)

Lastly, as the actual report, I'm getting being admitted that the sheer amount of work needed for Plan 2 (not using gfx transformations) is unpractical... Nevertheless, I'll continue Plan 2 to teach myself the codebase. Up to now, I've succeeded to make various parts of layout to do the right job. In detail, see screenshots[4]. The current Plan 2 general design strategy is to make it possible in the future for |writing-mode: lr-tb;| to take the fastest-possible codepath, which only be slowed down by |if|s scattered around many parts to check if it's the common case. Only inside the |if|s, I'll deal with other |writing-mode|s. In other words, I'm making nsHTMLReflowStatus's member variables and nsIFrame::mRect are always in the physical dimention.

At the moment, I'm working on rotating English words/sentences inside the vertical layout 90degrees clockwise.

[1] http://ryoqun.mooo.com/wordpress/
[2] http://ryoqun.mooo.com:8000/
[3] http://ryoqun.mooo.com:8001/
[4] http://www.flickr.com/photos/39168120@N03/
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
Can someone inform me about current status of this work? When would be supported tb-lr direction in Firefox?
I don't think it would be necesarry or good to implemenent not existig combinations like: bt-*, tb-rl. As far as I know, there is RL in arabic languages, and TB in some asian languages (japanese, chinese). Never a combination of both. There is no language with direction of bt. May be this comment can save a bit of resources. :)
(In reply to comment #48)
> I don't think it would be necesarry or good to implemenent not existig
> combinations like: bt-*, tb-rl. As far as I know, there is RL in arabic
> languages, and TB in some asian languages (japanese, chinese). Never a
> combination of both. There is no language with direction of bt. May be this
> comment can save a bit of resources. :)

Not true. Chinese and Japanese traditionally written in tb-rl direction.
(In reply to comment #48)
> I don't think it would be necesarry or good to implemenent not existig
> combinations like: bt-*, tb-rl. As far as I know, there is RL in arabic
> languages, and TB in some asian languages (japanese, chinese). Never a
> combination of both. There is no language with direction of bt. May be this
> comment can save a bit of resources. :)

TB implies tb-rl in CSS3.
http://www.w3.org/TR/2001/WD-css3-text-20010517/#PrimaryTextAdvanceDirection
ok, I see. Well, I was partly correct with bottom to top.
(In reply to comment #51)
> ok, I see. Well, I was partly correct with bottom to top.

And No here.
Tifinagh and Batak script are in bt-* writing system.
ok, I am sorry, delete my incorrect comments, please :(
Hi there, When would firefox supports tb-lr direction? Could it be supported on Firfox 4.0?
CSS3 writing-mode is not Flexiable, i think
SVG's text path can make characters drawn along arbitary path
this is good,
but how about along any 3D path(consider 3D layout...), and user even could position each character's orientation using some calc(...) expression?

Sorry, perhaps it goes too far...
@Chen zhixiang
It's already supported on Internet Explorer.
That would be totally out-of-scope for this bug, so I'm not going to go into the details of why vertical text is not the same as text on a path. It's a different feature, so it'd be a different bug report. But I think the answer to that would be "use SVG". :)
(In reply to Chen Zhixiang from comment #55)
> CSS3 writing-mode is not Flexiable, i think
> SVG's text path can make characters drawn along arbitary path
> this is good,
> but how about along any 3D path(consider 3D layout...), and user even could
> position each character's orientation using some calc(...) expression?
> 
> Sorry, perhaps it goes too far...

This bug (or most of other bugs for FF) is about FF's support to *known* W3C standards (in our case CSS3+HTML3/4/5..)  It's not about making up our own standards/features to do something nice.
No longer blocks: css-text-3
The issue with FF handling Classical Mongolian Script goes back 10 years and we still have no support for tb-lr. IE <shudder> seems to have done it. Why can't FF implement it for FF 8 and 9?

I can remember when Mosaic was setting the standards for the web and an email to Marc Andreessen was the only search engine. I think FF should still be setting standards, and at worst, the least we could do is keep up with IE, which renders tb-lr.

Computers are a big part of the world culture. This is where people are talking to each other today. If Classical Mongolian is not used in the world of computers: on websites, in operating systems, in technical language, then Mongolian culture won't be part of that world.
(In reply to David Pottier from comment #60)
> The issue with FF handling Classical Mongolian Script goes back 10 years and
> we still have no support for tb-lr. IE <shudder> seems to have done it. Why
> can't FF implement it for FF 8 and 9?
> 
> I can remember when Mosaic was setting the standards for the web and an
> email to Marc Andreessen was the only search engine. I think FF should still
> be setting standards, and at worst, the least we could do is keep up with
> IE, which renders tb-lr.
> 
> Computers are a big part of the world culture. This is where people are
> talking to each other today. If Classical Mongolian is not used in the world
> of computers: on websites, in operating systems, in technical language, then
> Mongolian culture won't be part of that world.

Indeed.
Please, if your comment is not actively contributing towards a fix, do not post it here. Complaining does not count as contributing. Bugzilla is an open system, but it only works if we are all courteous, and this is one of the rules of Bugzilla etiquette. Please read:
  https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Per the URL on this bug (and since that 01 February 2011 Working Draft), the writing-mode values for CSS (not SVG) are "horizontal-tb | vertical-rl | vertical-lr" Update implementations and tests to match latest specs.

Also, -webkit-writing-mode is now working; is the spec stable enough to implement a -moz-writing-mode?
Writing mode is already supported in IE. I think the firefox is the only one that doesn't support the writing mode.
Why firefox developers don't doing this until now. It's about 10 years?

Firefox developers are lazy or something?
I think that it's very useful and important issue. People must change their browsers to Chrome or Safari because of fast little fox is tired and can't do new things? Sorry for ma English.
Thank you for your support and concern! Please remember, Mozilla is not a company but a community and we would love you to join us and help us! You can get started here: http://www.mozilla.org/contribute/

If you have further questions, please make use of the discussion forums: http://www.mozilla.org/about/forums/ (Please don't reply here, Bugzilla is for fixing bugs)

On another note, this feature has not been overlooked. I too want to use this feature and while I can't promise times, I hope I can contribute to implementing this soon. Thanks again!
This looks really hard.
Assignee: nobody → birtles
Status: NEW → ASSIGNED
(In reply to Brian Birtles (:birtles) from comment #67)
> This looks really hard.

But you're very smart, no?
Browsers that have implemented this feature have had a difficult time making it work properly when applied to a <td> (does not work in Chrome, IE9 results in improperly sized cells, as revealed when the cells have borders).
I think this bug should be split into several parts, for there seem some developers who have tried/abandoned this so far.

The first step would be to rename tons of variables. In Thebes, "advance" and "width" are used in the same (or mixed) sense, but actually they are clearly different concepts. Most of the cases, s/width/advance/, s/advanceWidth/advance/, s/glyphWidth/glyphAdvance/ and so on...
Hi birtles \^_^/

We met at MozCamp Asia; if you have question on how vertical text should look, ask colleagues in Japan or us at Taiwan!
We are working on traditional mongolian script recently.
Traditional mongolian scritp is flow left to right and top to bottom.
We created traditional mongolian font for Windows(opentype) and Mac OS X(aat, include iOS). with that the traditional mongolian script can display on IE,Chrome,Safari correctly.( The webkit support Chrome and Safari) 

Our traditional mongolian script home page at http://www.mongolfont.com/

But on the Firefox can not display vertical way. becauce Firefox did not support CSS writing-mode:tb-lr. In The Mongolia the share of Firefox was over 50%. The traditional mongolian script can not display correct way without CSS writing-mode:tb-lr.

We hope this works in Firefox,too!
Can i help with testing this feature anyhow? I'm a developer of MediaWiki, the software behind Wikipedia, and i mostly deal with localization and font support. I already enabled the vertical-lr support for Webkit in the English Wikipedia. It's far from being perfect, but it's a good start for testing. I'd like to test it on Gecko, too.

Here and there on the Internet i see that -moz-writing-mode is supposed to work in some Nightly builds, but i cannot see it working now. Is it possible to enable it somehow, maybe by switching something in about:config?
Hi Amir, this feature is still a long long way off. Keep watching the bug and when you see comments like "Landed on m-c" you can start to look forward to nightly builds. When we get to that point, we'd love your help with testing!

We try to keep bugzilla to technical discussion. Status information will be available here: https://wiki.mozilla.org/Platform/Features/Vertical_text

For questions, please head to irc.mozilla.org #developers, or email me.
Depends on: 677302
Severity: enhancement → normal
Priority: P5 → --
Whiteboard: spec unstable, wait for confirmation from WG
Target Milestone: Future → ---
Traditinal Mongolian script written using a top-to-bottom inline direction with a rightward (left-to-right) block flow direction.
Depends on: 772321
To Simon Montagu per Q3 2012 Goals
Assignee: birtles → smontagu
This does not just have to apply to traditional Mongolian script written using a top-to-bottom inline direction with a rightward (left-to-right) block flow direction. It could also apply to Latin script written using a top-to-bottom inline direction with a rightward (left-to-right) block flow direction.

It's simply being able to do the below but have the glyphs being vertically aligned but on a central vertical axis.

A
x
y
M

At the moment, they are aligned to the left.

It is what you expect from something like a neon sign with vertical Latin script where the vertical axis of each glyph is at the center.

Here is more ambitious use of this technique which simulates digital rain. http://css-3d.org/enter-the-matrix.htm
Depends on: 789096
Depends on: 789099
Depends on: 789103
Depends on: 789104
Old Tur(In reply to Roy Tam from comment #52)
> (In reply to comment #51)
> > ok, I see. Well, I was partly correct with bottom to top.
> 
> And No here.
> Tifinagh and Batak script are in bt-* writing system.

And Old Turkic
An serious issue is rtl text in tb-lr text. Syriac text inserted in Mongolian text should share exactly the same direction (Mongolian was origined from Syriac eventually).
Depends on: 875250
(In reply to Yhn from comment #79)
> An serious issue is rtl text in tb-lr text. Syriac text inserted in
> Mongolian text should share exactly the same direction (Mongolian was
> origined from Syriac eventually).

What do you mean by direction. Syriac text inserted in Mongolian text should run rtl (the opposite inline direction). At one time during the development from Syriac to Old Mongolian, the inline progression was changed from running right to left to left to right.
Syriac is r2l but not b2t. So it should run t2b in Mongolian text, and Mongolian text inserted in Syriac should run the same inline direction as Syriac do (i.e. t2b==r2l)

(In reply to Alan Gresley from comment #80)
> (In reply to Yhn from comment #79)
> > An serious issue is rtl text in tb-lr text. Syriac text inserted in
> > Mongolian text should share exactly the same direction (Mongolian was
> > origined from Syriac eventually).
> 
> What do you mean by direction. Syriac text inserted in Mongolian text should
> run rtl (the opposite inline direction). At one time during the development
> from Syriac to Old Mongolian, the inline progression was changed from
> running right to left to left to right.
The Existing Traditional Mongolian Font ( as I know ) only can read t2b in vertical mode and r2l in horizontal mode.
Sorry.
There is a mistake in Comment 82. r2l -> l2r
The Existing Traditional Mongolian Font ( as I know ) only can read t2b in vertical mode and l2r in horizontal mode.
(In reply to Yhn from comment #81)
> Syriac is r2l but not b2t. So it should run t2b in Mongolian text, and
> Mongolian text inserted in Syriac should run the same inline direction as
> Syriac do (i.e. t2b==r2l)

I believe you are missing something. Old Mongolian runs ltr inline regardless of the block progression. Over time, you have a development from Syriac alphabet, Sogdian alphabet, Old Uyghur alphabet and finally the Mongolian script. At one time during it's development, the
inline progression was changed from running right to left to running left to right. The inline progression was also rotated 90 degrees clockwise [1] [2]. Note how the Cyrillic script is written within vertical Mongolian script in the image [3]. Latin script would be written the same way as the Cyrillic script (both ltr scripts). I would expect Syriac to be written rtl in horizontal script and btt (logical rtl) in vertical script.

1. http://lists.w3.org/Archives/Public/www-style/2010Oct/0014.html
2. http://fantasai.inkedblade.net/style/discuss/vertical-text/#logical-orientation
3. http://fantasai.inkedblade.net/style/discuss/vertical-text/diagrams/mongolian-vectors.jpg
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
I think the resolution here was a mistake.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Depends on: 902762
Depends on: 902799
Blocks: css3test
Depends on: 1074735
Depends on: 1076657
Depends on: 1077139
Depends on: 1077521
Depends on: 1077525
Depends on: 1077528
Depends on: 1078198
Depends on: 1079125
Depends on: 1079314
Depends on: 1082017
Depends on: 1082844
Depends on: 1083104
Depends on: 1083134
Depends on: 1083748
Depends on: 1083848
Depends on: 1081867
Depends on: 1083892
Depends on: 1084370
No longer depends on: 1078198
No longer depends on: 1082017
No longer depends on: 1082844
No longer depends on: 1083134
No longer depends on: 1083748
No longer depends on: 1083848
No longer depends on: 1083892
No longer depends on: 1084370
No longer depends on: 1081867
No longer depends on: 1083104
Depends on: 1090159
Depends on: 1090168
Depends on: 1091058
Depends on: 1097128
Depends on: 1097499
Depends on: 1102175
Depends on: 1102177
Depends on: 1104711
Depends on: 1105828
Hello,

Why is this bug report *_not_* a "meta" bug report? Just asking...

"
meta 	A placeholder bug for tracking the progress of other bugs. Meta bugs are made dependent on other bugs so that interested parties can be kept up-to-date with status via one bug, without having to receive all the mails related to all the bugs related to the development of a particular area.
"

Everything I see in this bug report suggests that this bug report is a "meta" bug report for CSS3 writing-modes .

Gérard
(In reply to Gérard Talbot from comment #86)
> Hello,
> 
> Why is this bug report *_not_* a "meta" bug report? Just asking...

It looks like this was originally filed as a regular bug, intended to have patches and whatnot. But it later evolved into a meta bug and the actual implementation was done elsewhere.

> "
> meta 	A placeholder bug for tracking the progress of other bugs. Meta bugs
> are made dependent on other bugs so that interested parties can be kept
> up-to-date with status via one bug, without having to receive all the mails
> related to all the bugs related to the development of a particular area.
> "
> 
> Everything I see in this bug report suggests that this bug report is a
> "meta" bug report for CSS3 writing-modes .
> 
> Gérard

I'm not sure how much it buys you, but I've gone ahead and added the meta keyword.
Status: REOPENED → NEW
Keywords: meta
Depends on: 1106665
Anyone have an idea of when this is likely to be implemented in Gecko?  Kind of embarrassing that Webkit has it, IE has had it for 10 years, but Gecko still doesn't.
(In reply to Jeremy Morton from comment #88)
> Anyone have an idea of when this is likely to be implemented in Gecko?  Kind
> of embarrassing that Webkit has it, IE has had it for 10 years, but Gecko
> still doesn't.

This bug is a meta bug.  You can try vertical layout when using Nightly with layout.css.vertical-text.enabled=true.
Depends on: 1108398
Depends on: 1110181
Depends on: 1111944
Depends on: 1112474
Depends on: 1113684
Depends on: 1115262
Depends on: 1115916
Depends on: 1117210
Depends on: 1117227
Depends on: 1117983
Depends on: 1118943
Depends on: 1119475
Depends on: 1119770
Depends on: 1120101
Depends on: 1120102
Depends on: 1120283
Depends on: 1120284
Depends on: 1121510
Depends on: 1122253
Depends on: 1122366
Depends on: 1124661
Depends on: 1126420
Depends on: 1127112
Depends on: 1127488
Depends on: 1130907
Depends on: 649142
Depends on: 1131013
Depends on: 1131451
Depends on: 1132308
Depends on: 1133945
Depends on: 1133964
Depends on: 1134534
Depends on: 1134598
Depends on: 1134849
Depends on: 1136067
Depends on: 1136557
Depends on: 1137582
Depends on: 1137588
Depends on: 1138353
Depends on: 1138495
Depends on: 1141867
Depends on: 1118103
Depends on: 1122253
Blocks: 1144501
Depends on: 1144505
No longer blocks: 1144501
Depends on: 1144501
Depends on: 1145743
Depends on: 1145934
Depends on: 1145936
Depends on: 1148660
Depends on: 1150250
Well, in my opinion, in the Firefox mobile, these images should have vertical style if you select a text in an element which is using vertical typesetting: handle-start.png, handle-middle.png, handle-end.png.

http://zh.m.wikipedia.org/wiki/%E8%92%99%E5%8F%A4%E5%A4%A7%E6%B1%97
Depends on: 1151993
Depends on: 1152254
Depends on: 1152941
Depends on: 1154227
I found a small program for vertical typesetting, when I browse this Wikipedia article, several CJK punctuations will become mojibake. This issue is appearing in Firefox for Android version 38.

https://zh.m.wikipedia.org/wiki/%E8%B1%8E%E6%8E%92
Well this page looks have a bad typesetting in Firefox for mobile version 38, some texts looks out of table.

https://incubator.m.wikimedia.org/wiki/Wp/mvf/%E1%A0%B3%E1%A0%A0%E1%A0%B4%E1%A0%A2%E1%A0%A9?oldid=2895098
Depends on: 1155261
Depends on: 1155980
Depends on: 1156021
Depends on: 1156366
(In reply to Krasnaya Ploshchad from comment #92)
> Well this page looks have a bad typesetting in Firefox for mobile version
> 38, some texts looks out of table.
> 
> https://incubator.m.wikimedia.org/wiki/Wp/mvf/
> %E1%A0%B3%E1%A0%A0%E1%A0%B4%E1%A0%A2%E1%A0%A9?oldid=2895098

You can get font file from here if you want to test this page for mobile devices:
http://trans.mglip.com/css/css.css
Depends on: 1157752
Depends on: 1157758
Depends on: 1158549
Depends on: 1158653
Depends on: 1159305
Blocks: 1162418
Depends on: 1163455
Depends on: 1164835
Depends on: 1164852
Depends on: 1165167
Depends on: 1165746
Depends on: 1165797
Depends on: 1166147
Depends on: 1166120
Depends on: 1167930
No longer blocks: 1162418
Depends on: 1162418
Depends on: 1169311
(In reply to Makoto Kato (:m_kato) from comment #89)
> (In reply to Jeremy Morton from comment #88)
> > Anyone have an idea of when this is likely to be implemented in Gecko?  Kind
> > of embarrassing that Webkit has it, IE has had it for 10 years, but Gecko
> > still doesn't.
> 
> This bug is a meta bug.  You can try vertical layout when using Nightly with
> layout.css.vertical-text.enabled=true.

Hi, I enabled this parameter in Firefox 38.0 (both desktop and mobile version), then I made a test for a vertical text that is inserting in a horizontal table. If this text placed incorrect in Firefox, this text looks out of table. Here is my result.

https://incubator.m.wikimedia.org/wiki/Wp/mvf/%E1%A0%B3%E1%A0%A0%E1%A0%B4%E1%A0%A2%E1%A0%A9?oldid=2895098
Desktop: ✓
Mobile: ✕

https://incubator.wikimedia.org/wiki/Wp/mvf/%E1%A0%B3%E1%A0%A0%E1%A0%B4%E1%A0%A2%E1%A0%A9?oldid=2895098
Desktop: ✕
Mobile: ✕
Well, I have installed Menk Qagan Tig font in my computer and phone in the last comment, then I dropped this font to made a test again, this page placed incorrect:

https://incubator.wikimedia.org/w/index.php?title=Wp/mvf/%E1%A0%B3%E1%A0%A0%E1%A0%B4%E1%A0%A2%E1%A0%A9&oldid=2895098
Krasnaya Ploshchad,

Please understand that this bug report is a meta-bug. So, it is not the proper place to post comments about problems you see. There are better places, better bug reports to do what you want to do.

If you want to help, please try to be helpful. 

Bug writing guidelines
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines

What to do and what not to do in Bugzilla
https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla

How to Really, Really Help Developers on Bugs -- Minimal Testcases
https://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

--------------

I have looked at your incubator.wikimedia.org webpages in comment 94 and comment 95 and I did considerable research (hint: this is also what you should do before creating a bug report) and double-checking.

I have created a quick draft test based on your comments and I have put it in bug 1077521 comment 5 for now.

Gérard
Depends on: 1170129
Depends on: 1147834
Depends on: 1172762
Depends on: 1172774
Depends on: 1172777
Depends on: 1174450
Depends on: 1174504
Depends on: 1174507
Depends on: 1175074
Depends on: 1175509
Depends on: 1175517
Depends on: 1175859
Depends on: 1177076
Depends on: 1177600
Depends on: 1177606
Depends on: 1177614
Depends on: 1156996
Depends on: 1178059
Depends on: 1178250
Depends on: 1179741
Depends on: 1177690
Depends on: 1179952
Depends on: 1180528
Depends on: 1180643
Assignee: smontagu → nobody
Depends on: 1183691
Depends on: 1187605
Depends on: 1189131
Depends on: 1191801
Depends on: 1191855
Depends on: 1193488
Depends on: 1193518
Depends on: 1193519
Depends on: 1194493
Depends on: 1040668
Depends on: 1196887
Depends on: 1200137
Depends on: 1205787
Depends on: 1208169
Depends on: 1209411
Depends on: 1217841
Depends on: 1220352
Depends on: 1220353
Depends on: 1220438
Depends on: 1228810
Depends on: 1229743
Depends on: 1230456
Depends on: 1231239
Depends on: 1231656
Depends on: 1233361
Depends on: 1234122
Depends on: 1258635
Depends on: 1262974
Depends on: 1263792
Depends on: 1263810
Depends on: 1264812
Depends on: 1268282
Depends on: 1260054
Depends on: 1269152
Depends on: 1272997
Depends on: 1274368
No longer depends on: 1274368
Depends on: 1281055
Depends on: 1230975
Depends on: 1283721
Depends on: 1289015
Depends on: 1292455
Depends on: 1301610
Depends on: 1303916
Depends on: 1323517
Depends on: 1333274
Depends on: 1361631
Depends on: 1383584
Depends on: 1385211
CSSWG resolved to publish a CR of the spec: https://logs.csswg.org/irc.w3.org/css/2017-08-04/#e847806
Summary: CSS3 writing-mode (vertical text) → [META] CSS3 writing-mode (vertical text)
Depends on: 1242660
Depends on: 1276735
Depends on: 1387690
Depends on: 1387758
No longer depends on: 1189131
Depends on: 1439891
Depends on: 1444320
Depends on: 1464593
Depends on: 1475491
Depends on: 1475651
Depends on: 1485581
Depends on: 1486086
Depends on: 1486179
Depends on: 1547172
Type: defect → enhancement
Depends on: 1604327
Depends on: 1604328
Depends on: 1587953
Depends on: 1680666
Depends on: 1696208
Depends on: 1765664
Depends on: 1765668
Depends on: 1766530
Depends on: 1767091
Severity: normal → S3
Depends on: 1804854
Depends on: 1843863
You need to log in before you can comment on or make changes to this bug.