Last Comment Bug 145503 - (writing-mode) CSS3 writing-mode (vertical text)
(writing-mode)
: CSS3 writing-mode (vertical text)
Status: NEW
: css3, dev-doc-needed, intl, meta
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal with 81 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://drafts.csswg.org/css-writing-...
: 114351 235443 271362 278707 309230 372857 393409 396396 (view as bug list)
Depends on: 789099 789103 1077521 1077525 1079125 1102175 1111955 1132308 1145743 1155980 1156996 1165167 1165746 1165797 1166120 1166147 1170129 1175074 1175509 1175517 1175859 1179741 1179952 1183691 1189131 1191801 1209411 1217841 1220352 1220353 1228810 1230456 1230975 1231239 1231656 1233361 1234122 1244601 1258635 1260054 1262974 1263792 1263810 1264812 1269152 1281055 649142 677302 735577 772321 789096 789104 875250 902762 902799 1040668 1074735 1076657 1077139 1077528 1079314 1090159 1090168 1091058 1097128 1097499 enable-writing-mode-dev 1102177 1104711 1105828 1106665 1108398 1110181 1111944 1112474 1113684 1115262 1115916 1117210 1117227 1117983 1118103 1118943 1119475 1119770 1120101 1120102 1120283 1120284 1121510 1122253 1122366 1124661 1126420 1127112 1127488 1130907 1130935 1130936 1130937 1131013 1131451 1133945 1133964 1134534 1134598 1136067 1136557 1137582 1137588 1138353 enable-writing-mode-release 1138495 1141867 1144501 1144505 1145934 1145936 1147834 1148660 1150250 1151993 1152254 1152941 1154227 1155261 1156021 1156366 1157752 1157758 1158549 1158653 1159305 1162418 1163455 1164835 1164852 1167930 1169311 1171858 1172762 1172774 1172777 1174450 1174504 1174507 1177076 1177600 1177606 1177614 1177690 1178059 1178250 1180528 1180643 1187605 1191855 1193488 1193518 1193519 1194493 1196887 1200137 1205787 1208169 1220438 1229743 1268282 1272997
Blocks: 104952 css3test 319163
  Show dependency treegraph
 
Reported: 2002-05-18 11:32 PDT by Kai Lahmann (is there, where MNG is)
Modified: 2016-06-25 10:23 PDT (History)
112 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Page test about writing-mode Attribute (1.56 KB, text/html)
2005-09-13 07:15 PDT, Vinicius Camara
no flags Details
patch_v0.00001 (15.32 KB, patch)
2009-04-28 01:04 PDT, Ryo Onodera
no flags Details | Diff | Review
Hand edited excerpt patch of gfxFont::Draw() (6.59 KB, patch)
2009-05-09 07:13 PDT, Ryo Onodera
no flags Details | Diff | Review
work-in-progress screenshot 1 (150.33 KB, image/png)
2009-05-19 01:12 PDT, Ryo Onodera
no flags Details
work-in-progress screenshot 2 (91.29 KB, image/png)
2009-05-19 01:13 PDT, Ryo Onodera
no flags Details
anonymous layout canvas creation. (40.63 KB, image/png)
2009-05-19 03:29 PDT, Ryo Onodera
no flags Details
an excerpt patch for nsLayoutCanvas (8.28 KB, patch)
2009-05-19 04:18 PDT, Ryo Onodera
no flags Details | Diff | Review
work-in-progress screenshot 3 (223.34 KB, image/png)
2009-06-02 23:28 PDT, Ryo Onodera
no flags Details
tb-lr test (3.77 KB, text/html)
2009-06-18 21:43 PDT, Yhn
no flags Details

Description Kai Lahmann (is there, where MNG is) 2002-05-18 11:32:31 PDT
please implement this option as -moz-writing-mode soon, coz it's very often
requested by page authors.
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-05-18 14:13:01 PDT
confirming... This will take oodles of work, though...
Comment 2 Håkan Waara 2002-05-18 18:01:47 PDT
Mark as NEW too.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-04-27 00:05:41 PDT
.
Comment 4 Anne (:annevk) 2004-04-11 03:26:07 PDT
*** Bug 235443 has been marked as a duplicate of this bug. ***
Comment 5 Michael Brewer 2004-04-11 20:43:21 PDT
(In reply to comment #3)
> .

Out of interest is this still been worked on? Being 2 years old and stuff :).
Thanks alot.
Comment 6 Anne (:annevk) 2004-04-12 00:27:27 PDT
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.
Comment 7 fantasai 2004-04-17 00:02:30 PDT
The entire Text Layout section has problems.

http://lists.w3.org/Archives/Public/www-style/2003Jul/0146.html
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-12-04 15:00:33 PST
*** Bug 271362 has been marked as a duplicate of this bug. ***
Comment 9 José Jeria 2005-01-17 08:13:01 PST
*** Bug 278707 has been marked as a duplicate of this bug. ***
Comment 10 Vinicius Camara 2005-09-13 07:15:53 PDT
Created attachment 195867 [details]
Page test about writing-mode Attribute

This page works fine using IE.
Comment 11 Phil Ringnalda (:philor) 2005-09-19 19:07:32 PDT
*** Bug 309230 has been marked as a duplicate of this bug. ***
Comment 12 Dave Townsend [:mossop] 2007-03-06 11:26:23 PST
*** Bug 372857 has been marked as a duplicate of this bug. ***
Comment 13 Jo Hermans 2007-08-23 09:32:01 PDT
*** Bug 393409 has been marked as a duplicate of this bug. ***
Comment 14 Gérard Talbot 2007-09-17 18:34:52 PDT
*** Bug 396396 has been marked as a duplicate of this bug. ***
Comment 15 Gérard Talbot 2007-09-17 18:36:59 PDT
writing-mode is written twice in the summary and vertical-text is not. Updating summary to help searching for duplicates.
Comment 16 satosi 2008-08-22 04:26:29 PDT
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!
Comment 17 O. Atsushi (Torisugari) 2009-01-28 04:42:58 PST
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
Comment 18 Makoto Kato [:m_kato] (PTO 6/20-21, 6/24) 2009-02-11 19:34:59 PST
"writing-mode" is moved to css3 Text Layout.  (Currently, there is no working draft.  Only editor draft)
Comment 19 Makoto Kato [:m_kato] (PTO 6/20-21, 6/24) 2009-02-11 19:35:35 PST
See http://dev.w3.org/csswg/css3-text-layout/
Comment 20 Ryo Onodera 2009-04-26 07:03:49 PDT
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
Comment 21 Ryo Onodera 2009-04-28 01:04:01 PDT
Created attachment 374869 [details] [diff] [review]
patch_v0.00001

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.....
Comment 22 Ryo Onodera 2009-05-09 05:00:13 PDT
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.
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-05-09 05:15:12 PDT
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?
Comment 24 Ryo Onodera 2009-05-09 07:13:01 PDT
Created attachment 376559 [details] [diff] [review]
Hand edited excerpt patch of gfxFont::Draw()

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.
Comment 25 fantasai 2009-05-09 12:17:26 PDT
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.
Comment 26 Ryo Onodera 2009-05-19 01:12:28 PDT
Created attachment 378274 [details]
work-in-progress screenshot 1

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. :)
Comment 27 Ryo Onodera 2009-05-19 01:13:36 PDT
Created attachment 378275 [details]
work-in-progress screenshot 2

Screenshot 2.
Comment 28 Ryo Onodera 2009-05-19 03:29:51 PDT
Created attachment 378297 [details]
anonymous layout canvas creation.

(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...
Comment 29 Ryo Onodera 2009-05-19 04:18:33 PDT
Created attachment 378305 [details] [diff] [review]
an excerpt patch for nsLayoutCanvas

(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.
Comment 30 fantasai 2009-05-19 11:12:30 PDT
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'?
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-05-19 12:11:48 PDT
+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!
Comment 32 Ryo Onodera 2009-06-02 23:28:17 PDT
Created attachment 381230 [details]
work-in-progress screenshot 3

(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.
Comment 33 Ryo Onodera 2009-06-13 05:53:22 PDT
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.
Comment 34 Yhn 2009-06-18 21:13:09 PDT
Also, we need tb_lr for Mongolian text. 

http://www.w3.org/TR/2003/CR-css3-text-20030514/#writing-mode
Comment 35 Yhn 2009-06-18 21:15:05 PDT
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.
Comment 36 Yhn 2009-06-18 21:43:46 PDT
Created attachment 384057 [details]
tb-lr test

Patch for "Page test about writing-mode Attribute"
Comment 37 Yhn 2009-06-18 21:44:49 PDT
tb-lr test uploaded
Comment 38 Yhn 2009-06-18 22:14:40 PDT
I download Minefield 3.6a1pre but it does not support tb-rl.
Comment 39 Yhn 2009-06-18 22:18:24 PDT
(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?
Comment 40 Yhn 2009-06-18 22:39:23 PDT
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.
Comment 41 Yhn 2009-06-18 22:42:21 PDT
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>
Comment 42 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-06-18 23:01:28 PDT
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.
Comment 43 Yhn 2009-06-18 23:17:40 PDT
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.
Comment 44 Yhn 2009-06-18 23:19:33 PDT
(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?
Comment 45 Jeff Walden [:Waldo] (remove +bmo to email) 2009-06-19 00:18:33 PDT
(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.
Comment 46 Ryo Onodera 2009-07-10 10:35:55 PDT
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/
Comment 47 Badral 2010-04-22 04:16:21 PDT
Can someone inform me about current status of this work? When would be supported tb-lr direction in Firefox?
Comment 48 tonda kavalec 2010-07-23 02:01:45 PDT
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. :)
Comment 49 周濟是母老鼠 2010-07-23 02:13:34 PDT
(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.
Comment 50 Roy Tam 2010-07-23 02:14:47 PDT
(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
Comment 51 tonda kavalec 2010-07-23 02:23:25 PDT
ok, I see. Well, I was partly correct with bottom to top.
Comment 52 Roy Tam 2010-07-23 02:26:59 PDT
(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.
Comment 53 tonda kavalec 2010-07-23 02:33:29 PDT
ok, I am sorry, delete my incorrect comments, please :(
Comment 54 almas 2010-12-17 00:28:30 PST
Hi there, When would firefox supports tb-lr direction? Could it be supported on Firfox 4.0?
Comment 55 Chen Zhixiang 2011-11-03 19:42:13 PDT
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...
Comment 56 almas 2011-11-03 22:09:04 PDT
@Chen zhixiang
It's already supported on Internet Explorer.
Comment 57 fantasai 2011-11-03 22:17:24 PDT
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". :)
Comment 58 石庭豐 (Seak, Teng-Fong) 2011-11-04 06:23:04 PDT
(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.
Comment 59 fantasai 2011-11-16 21:43:03 PST
*** Bug 114351 has been marked as a duplicate of this bug. ***
Comment 60 David Pottier 2011-12-14 18:34:16 PST
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.
Comment 61 Yhn 2011-12-17 01:09:36 PST
(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.
Comment 62 fantasai 2011-12-18 01:54:36 PST
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
Comment 63 Tyler Rasmussen 2011-12-29 06:59:43 PST
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?
Comment 64 tugstugi 2012-02-03 03:10:14 PST
Writing mode is already supported in IE. I think the firefox is the only one that doesn't support the writing mode.
Comment 65 almas 2012-02-04 02:09:58 PST
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.
Comment 66 Brian Birtles (:birtles) 2012-02-04 04:15:35 PST
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!
Comment 67 Brian Birtles (:birtles) 2012-02-20 21:26:12 PST
This looks really hard.
Comment 68 John Daggett (:jtd) 2012-02-20 22:01:32 PST
(In reply to Brian Birtles (:birtles) from comment #67)
> This looks really hard.

But you're very smart, no?
Comment 69 Tyler Rasmussen 2012-02-20 22:05:52 PST
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).
Comment 70 O. Atsushi (Torisugari) 2012-02-21 00:42:09 PST
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...
Comment 71 Tim Guan-tin Chien [:timdream] (please needinfo; OOO and on leave until July) 2012-02-21 04:01:24 PST
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!
Comment 72 Siqinbilige 2012-02-29 03:25:11 PST
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!
Comment 73 Rima E. Inoraha 2012-03-09 11:48:38 PST
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?
Comment 74 Brian Birtles (:birtles) 2012-03-11 16:18:23 PDT
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.
Comment 75 Siqinbilige 2012-04-01 18:37:46 PDT
Traditinal Mongolian script written using a top-to-bottom inline direction with a rightward (left-to-right) block flow direction.
Comment 76 Jet Villegas (:jet) 2012-07-19 14:28:43 PDT
To Simon Montagu per Q3 2012 Goals
Comment 77 Alan Gresley 2012-07-28 07:42:45 PDT
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
Comment 78 Yhn 2013-01-25 22:13:55 PST
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
Comment 79 Yhn 2013-01-25 22:16:53 PST
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).
Comment 80 Alan Gresley 2013-05-26 06:54:34 PDT
(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.
Comment 81 Yhn 2013-05-27 06:07:52 PDT
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.
Comment 82 Siqinbilige 2013-05-27 08:16:30 PDT
The Existing Traditional Mongolian Font ( as I know ) only can read t2b in vertical mode and r2l in horizontal mode.
Comment 83 Siqinbilige 2013-05-27 08:20:01 PDT
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.
Comment 84 Alan Gresley 2013-05-31 07:14:40 PDT
(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
Comment 85 Scott Johnson (:jwir3) 2013-07-09 10:39:13 PDT
I think the resolution here was a mistake.
Comment 86 Gérard Talbot 2014-11-30 08:55:06 PST
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
Comment 87 Gordon P. Hemsley [:GPHemsley] 2014-11-30 18:53:05 PST
(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.
Comment 88 Jeremy Morton 2014-12-03 06:05:45 PST
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.
Comment 89 Makoto Kato [:m_kato] (PTO 6/20-21, 6/24) 2014-12-03 14:03:13 PST
(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.
Comment 90 Krasnaya Ploshchad 2015-04-06 06:16:08 PDT
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
Comment 91 Krasnaya Ploshchad 2015-04-15 19:20:38 PDT
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
Comment 92 Krasnaya Ploshchad 2015-04-16 05:50:36 PDT
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
Comment 93 Krasnaya Ploshchad 2015-04-22 09:09:14 PDT
(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
Comment 94 Krasnaya Ploshchad 2015-05-30 02:46:10 PDT
(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: ✕
Comment 95 Krasnaya Ploshchad 2015-05-30 03:30:27 PDT
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
Comment 96 Gérard Talbot 2015-05-30 13:10:47 PDT
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

Note You need to log in before you can comment on or make changes to this bug.