Open
Bug 145503
(writing-mode)
Opened 23 years ago
Updated 1 year ago
[META] CSS3 writing-mode (vertical text)
Categories
(Core :: Layout: Block and Inline, enhancement)
Core
Layout: Block and Inline
Tracking
()
NEW
People
(Reporter: bugzilla_kl, Unassigned)
References
(Depends on 53 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.
Reporter | ||
Updated•23 years ago
|
Severity: normal → enhancement
Summary: CSS3 writing mode → [RFE] CSS3 writing mode
Comment 1•23 years ago
|
||
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)
Updated•23 years ago
|
Priority: -- → P5
Target Milestone: --- → Future
Comment 3•22 years ago
|
||
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: cpetersen0953 → ian
Updated•21 years ago
|
Blocks: 104952, css-text-3
Comment 4•21 years ago
|
||
*** Bug 235443 has been marked as a duplicate of this bug. ***
Comment 5•21 years ago
|
||
(In reply to comment #3)
> .
Out of interest is this still been worked on? Being 2 years old and stuff :).
Thanks alot.
Comment 6•21 years ago
|
||
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
Comment 8•20 years ago
|
||
*** Bug 271362 has been marked as a duplicate of this bug. ***
Comment 9•20 years ago
|
||
*** Bug 278707 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
This page works fine using IE.
Comment 11•19 years ago
|
||
*** Bug 309230 has been marked as a duplicate of this bug. ***
Comment 15•17 years ago
|
||
writing-mode is written twice in the summary and vertical-text is not. Updating summary to help searching for duplicates.
Updated•17 years ago
|
Summary: CSS3 writing mode (writing-mode) → CSS3 writing mode (vertical text)
Updated•17 years ago
|
Summary: CSS3 writing mode (vertical text) → CSS3 writing-mode (vertical text)
Comment 16•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
"writing-mode" is moved to css3 Text Layout. (Currently, there is no working draft. Only editor draft)
Comment 19•16 years ago
|
||
Comment 20•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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?
Comment 24•16 years ago
|
||
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
Comment 25•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
Screenshot 2.
Comment 28•16 years ago
|
||
(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•16 years ago
|
||
(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•16 years ago
|
||
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!
Comment 32•16 years ago
|
||
(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•16 years ago
|
||
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•16 years ago
|
||
Also, we need tb_lr for Mongolian text.
http://www.w3.org/TR/2003/CR-css3-text-20030514/#writing-mode
Comment 35•16 years ago
|
||
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•16 years ago
|
||
Patch for "Page test about writing-mode Attribute"
Comment 37•16 years ago
|
||
tb-lr test uploaded
Comment 38•16 years ago
|
||
I download Minefield 3.6a1pre but it does not support tb-rl.
Comment 39•16 years ago
|
||
(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•16 years ago
|
||
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•16 years ago
|
||
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.
Comment 43•16 years ago
|
||
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•16 years ago
|
||
(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•16 years ago
|
||
(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•15 years ago
|
||
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/
Updated•15 years ago
|
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
Updated•15 years ago
|
Comment 47•15 years ago
|
||
Can someone inform me about current status of this work? When would be supported tb-lr direction in Firefox?
Comment 48•14 years ago
|
||
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•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
ok, I see. Well, I was partly correct with bottom to top.
Comment 52•14 years ago
|
||
(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•14 years ago
|
||
ok, I am sorry, delete my incorrect comments, please :(
Comment 54•14 years ago
|
||
Hi there, When would firefox supports tb-lr direction? Could it be supported on Firfox 4.0?
Comment 55•13 years ago
|
||
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•13 years ago
|
||
@Chen zhixiang
It's already supported on Internet Explorer.
Comment 57•13 years ago
|
||
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•13 years ago
|
||
(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
Comment 60•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Writing mode is already supported in IE. I think the firefox is the only one that doesn't support the writing mode.
Comment 65•13 years ago
|
||
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•13 years ago
|
||
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 68•13 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #67)
> This looks really hard.
But you're very smart, no?
Comment 69•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Updated•13 years ago
|
Severity: enhancement → normal
Priority: P5 → --
Whiteboard: spec unstable, wait for confirmation from WG
Target Milestone: Future → ---
Comment 75•13 years ago
|
||
Traditinal Mongolian script written using a top-to-bottom inline direction with a rightward (left-to-right) block flow direction.
Comment 77•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
The Existing Traditional Mongolian Font ( as I know ) only can read t2b in vertical mode and r2l in horizontal mode.
Comment 83•12 years ago
|
||
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•12 years ago
|
||
(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
Updated•11 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Comment 85•11 years ago
|
||
I think the resolution here was a mistake.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•10 years ago
|
Keywords: dev-doc-needed
Updated•10 years ago
|
Depends on: enable-writing-mode-dev
Comment 86•10 years ago
|
||
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•10 years ago
|
||
(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
Comment 88•10 years ago
|
||
notechnicalvalue |
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•10 years ago
|
||
notechnicalvalue |
(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.
Updated•10 years ago
|
Updated•10 years ago
|
Depends on: enable-writing-mode-release
Updated•10 years ago
|
Comment 90•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
(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
Updated•10 years ago
|
Comment 94•9 years ago
|
||
(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•9 years ago
|
||
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•9 years ago
|
||
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
Updated•9 years ago
|
Assignee: smontagu → nobody
Updated•9 years ago
|
Updated•8 years ago
|
Blocks: all-css-modules
Comment 97•7 years ago
|
||
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)
Updated•7 years ago
|
Updated•6 years ago
|
Type: defect → enhancement
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•