Closed Bug 9100 (text-dir) Opened 25 years ago Closed 23 years ago

[bidi] Text direction ignored (dir, BDO, ‎ and ‏)

Categories

(Core :: Layout: Text and Fonts, defect, P3)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: bugzilla, Assigned: smontagu)

References

(
URL
)

Details

(Keywords: helpwanted, html4, relnote, Whiteboard: relnote-user)

Attachments

(2 files)

A test case using both &lrm; and <BDO> methods
(deleted), text/html
Details
Attachment 61906 with a Hebrew character at the end
(deleted), text/html
Details
It would appear that HTML 4.0's BDO tag is not supported yet.
Assignee: don → karnaze
Component: Browser-General → HTMLTables
QA Contact: leger → chrisd
Setting QA Contact
Assignee: karnaze → troy
Component: HTMLTables → Layout
Summary: <bdo dir="rtl"> ignored → {html40}<bdo dir="rtl"> ignored
This isn't tables. Changing component to layout (or should it be i18n...) and reassigning, since karnaze doesn't seem to have look at it yet. He has enough bugs as is.
QA Contact: chrisd → petersen
Assignee: troy → kipp
The issue isn't BDO per say. We map that to a SPAN content object which is fine. The inline code doesn't seem to support 'rtl' layout
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee: kipp → nisheeth
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Accepting bug...
*** Bug 12740 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M15
Not a beta stopper. Setting milestone to M15...
Blocks: html4.01
Summary: {html40}<bdo dir="rtl"> ignored → <bdo dir="rtl"> ignored
Right to left text direction (dir=rtl) appears to be the only supported in table cells. Full HTML 4.0 compliance should include right to left in paragraph, and default right to left for a document <html dir=rtl> Bug 14362 "DIR attribute not working in P element" is related to this bug. I'm not sure of the dependence. Need a title "direction right to left attribute (dir=rtl) not fully supported", so that seaching on direction turns up this problem.
Moving bugs out by one milestone...
Target Milestone: M15 → M16
non-essential for m16
Target Milestone: M16 → M17
URL: http://mars.superlink.net/~robinl/htm... → http://www.robinlionheart.com/stds/ht...
Summary: <bdo dir="rtl"> ignored → direction right-to-left attribute (dir="rtl") ignored
Keywords: html4
Moving to M19.
Target Milestone: M17 → M19
Marking FUTURE, html4, relnote, helpwanted. I don't think this bug will be fixed for FCS.
Keywords: helpwanted, relnote
Target Milestone: M19 → Future
I think this is working now. w32 200007068 at least working for me right now with <html dir=rtl> stuttt Dup bugs 14362, and 19312?
Blocks: 42183
Just to report, this is not working as of build 2000080208. I don't think we can release Mozilla without this, because we would not be fully HTML compliant, in addition this feature is extremly important for foreign web sites. So I would like to nominate this for nsbeta3. (If someone could change the keywords line for me.) Also the platform and OS are wrong - should be all.
Blocks: 24366
*** Bug 14362 has been marked as a duplicate of this bug. ***
CHanging platform/OS to All.
OS: Windows 98 → All
Hardware: PC → All
Well, here's what I've turned up thanks to Teruko and Frank: Frank wrote: Read this <http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2>http://www.w3.org/TR/html4/ struct/dirlang.html#h-8.2 dir = LTR | RTL [CI]  This attribute specifies the base direction of directionally neutral text (i.e., text that doesn't have inherent directionality as defined in [UNICODE]) in an element's content and attribute values. It also specifies the directionality of tables. Possible values:  LTR: Left-to-right text or table.  RTL: Right-to-left text or table. Latin characters (such as ASCII) are NOT directionally neutral text. Latin text are Right to Left text. Arabic and Hewbrew characters are Left to right text. Both of them are NOT directional neutral text. So it seems then that the test on http://www.robinlionheart.com/stds/html4.html would be thus invalidated since it uses ASCII text. Can anyone check this against hebrew/arabic/anything that goes in the other direction? Thanks. Also, here is another URL. The end result is that the text is right justified, which would make sense. According to the spec, any text labeled as RTL would start on the right-but since the text is ASCII, it'll start on the right, but output the text (which is inherently directional->LTR) also to the right and thus only seem as right-justified. In other words, to my knowledge its working fine. The question is how it behaves in inherently <-RLT languages. Also adding keyword qawanted.
Keywords: qawanted
Will this be fixed when IBM's BIDI branch lands?
Comments from the Bidi team: At the moment we do no Bidi processing if a document does not contain any right-to-left characters. If you save that page locally and add some Hebrew or Arabic, the text in the BDO example is reversed. This decision was based on the HTML 4 spec, with the intention of avoiding the overhead of Bidi processing for pages that don't need it. However, when I look again at the text of the spec: If a document does not contain a displayable right-to-left character, a conforming user agent is not required to apply the [UNICODE] bidirectional algorithm. I suppose you could argue either that as soon as you have a BDO tag with dir=rtl, it counts as displayable right-to-left characters, or that the user agent is not required to apply the Unicode bidirectional algorithm, but is required to support the BDO tag in any case. Thoughts, anyone?
Uh-sorry abou that. In order to illustrate the behavior I was speaking of in my reference above, go to: slip/projects/marvin/html/p_dir.html and you'll see latin (ASCII) text laid out (like this for those w/o internal access): blah blah blah blah blah blah (the latter being right justified)
Blocks: robin's
Whiteboard: relnote-user
Rewrote summary so this will come up in searches for "dir" and "BDO"
URL: http://www.robinlionheart.com/stds/ht... → http://www.robinlionheart.com/stds/ht...
Summary: direction right-to-left attribute (dir="rtl") ignored → Text direction ignored (dir, BDO, &lrm; and &rlm;)
Component: Layout → HTML Element
QA Contact: petersen → lorca
Tossing over to i18n? No one better in my opinion...I sure won't be able to check this. One hot potato, that-a-way!
Component: HTML Element → Internationalization
QA Contact: lorca → teruko
This looks like a duplicate of bug 3687.
Agreed. *** This bug has been marked as a duplicate of 3687 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified as dup.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Add "bidi" to summary so this will come up in "bidi" searches.
Summary: Text direction ignored (dir, BDO, &lrm; and &rlm;) → [bidi] Text direction ignored (dir, BDO, &lrm; and &rlm;)
This is not a dup of 3687. 3687 is about Bidi not working on the Mac. This is about the URL specified not working. This is definitely an issue, although we behave the same as IE.
Status: VERIFIED → REOPENED
Component: Internationalization → BiDi Hebrew & Arabic
Resolution: DUPLICATE → ---
Reclosing as INVALID. The first testcase is invalid, because <dir=rtl> does not reverse the direction of inherently left-to-right text. It sets the direction of directionally neutral characters to right-to-left. See http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2 The second testcase is invalid, because &lrm; and &rlm; are not overrides. They are left-to-right and right-to-left *markers*, and have no more effect than any other left-to-right or right-to-left character. See the section on "Implicit Directional Marks" in http://www.unicode.org/unicode/reports/tr9/
really closing this time
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → INVALID
Verified as invalid.
Status: RESOLVED → VERIFIED
From http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2 dir = LTR | RTL [CI] This attribute specifies the base direction of directionally neutral text. ^^^^^^^^^ This attribute and description applies to most inline and block elements. However, in the description of the BDO tag in http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2.4: dir = LTR | RTL [CI] This mandatory attribute specifies the base direction of the element's text content. This direction overrides the inherent directionality of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ characters as defined in [UNICODE]. In other words, <BDO dir="RTL">Latin letters</BDO> should display as srettel nitaL I'd suggest reopening.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
>In other words, <BDO dir="RTL">Latin letters</BDO> should display as >srettel nitaL Did you reopen because you have a testcase in which this doesn't happen? If so, please attach it.
I've tried this test case in both quirks mode and HTML4-Transitional. Neither mode produces right-to-left Latin text in Mozilla build 2001121303 (the latest mozillazine reviewed build) on Windows ME.
momoi, does IQA test on Windows ME? It seems we have a platform-specific problem. http://www.people.fas.harvard.edu/~dbaron/css/test/bidi2 and the friends it links too are excellent test pages for this issue.
> momoi, does IQA test on Windows ME? It seems we > have a platform-specific problem. I'll leave this question to either IQA or standards QA. However, I would like to suggest the following for those in Mozilla Bidi: 1. Engineers involved in Bidi should help define areas of testing first and publish on Mozilla.org. You will be able to get more help from the net. 2. Idetify platform/language needs and prioritize them. Publish this list. 3. If platform differences are anticipated on certain issues,e.g. font width/height, BDO, etc., create a list of such special attention cases. This is where engineer's help is particularly appreciated. For this particular case (BDO), HTML standards QA as well as IQA should be looking at BDO test cases on various platforms.
To: d_yerrick@hotmail.com Damien, it is true that your test case does not show any effect of the <BDO> tag. For your test case, the platform does not seem to matter. My question is: is your test case a correct one for BDO? Doesn't BDO override inherent directionality of the text? What is the base directionality of your test case? Your test case will work if you add something like the following to the body element: ... <body dir="rtl"> ... <bdo ... My question is: would this difference reasonable given the specification of BDO?
<BDO> tag is there to override effects of the text which is already following the bidi algorithm. The test case damien posted does not seem to meet this basic requirement since it has no charset info that indicates bi-directionality of the text or any text-related directional attribute whose effect must be reversed.
I don't think I agree with comment 36. My understanding is that all text has a directional attribute (defaulting to left-to-right), whether explicitly set or not. Damien's test case works for me on W2K (with Hebrew and Arabic installed), but not on Linux, even though dbaron's test cases which I linked to in comment 33 work on both platforms. This is certainly not expected behaviour, and needs to be fixed. Accepting the bug.
Assignee: nisheeth → smontagu
Status: REOPENED → NEW
Blocks: 115713
I identify this as a regression, after testing some more combinations of builds and OSs.
With regard to comment 37, I would like to continue this discussion a bit more, if nothing else to resolve some questions in my mind. This relates to why at all we need <BDO> tag as opposed to a directionality attribute in an element, e.g. <P dir= ..>. My understanding is that <BDO> is used to override the bi-directional algorithm. It would not be needed where bi-directional algorithm is not applied. (Maybe this is where my understanding needs to be corrected.) But let me quote the following from HTML 4.01 concerning DIR attribute: http://www.w3.org/TR/html401/struct/dirlang.html#adef-dir "The [UNICODE] specification assigns directionality to characters and defines a (complex) algorithm for determining the proper directionality of text. If a document does not contain a displayable right-to-left character, a conforming user agent is not required to apply the [UNICODE] bidirectional algorithm. If a document contains right-to-left characters, and if the user agent displays these characters, the user agent must use the bidirectional algorithm." and this comment on <BDO>: http://www.w3.org/TR/html401/struct/dirlang.html#edef-BDO "The bidirectional algorithm and the dir attribute generally suffice to manage embedded direction changes. However, some situations may arise when the bidirectional algorithm results in incorrect presentation. The BDO element allows authors to turn off the bidirectional algorithm for selected fragments of text." I have been wodnering why one would specifically use <BDO> when "dir" attribute may do the job. I don't know if Mozilla distinguishes birectional context as the one in which it contains RTL characters (or specific encoding or DIR="RTL" attribute.) or just any text where there is inherent directionality of some kind. I don't deny that every character has inherent directionality. My question is in what context <BDO> needed?
BDO is needed for overriding the bidi behaviour of characters. If you only use a 'dir' attribute on some element, the text in the element still will reorder with respect to the bidirectional algorithm, the value of 'dir' only setting the overall direction. BDO stops that from happening, explicitly marking all character within to have the directionality mentioned. Quoting UAX #9, <http://www.unicode.org/unicode/reports/tr9/>, "right-to-left override, for example, can be used to force a part number made of mixed English, digits and Hebrew letters to be written from right to left."
The HTML standard also suggests using BDO to make visual pages standard compliant: Such documents do not conform to the present specification. If necessary, they can be made to conform to the current specification (and at the same time will be displayed correctly on older user agents) by adding BDO markup where necessary. For another situation where BDO might be used, see the first example in http://www.w3.org/International/Group/1999/10/typography/ (W3C Member Access required). For the record, I believe that it would be consistent with the standard to ignore BDO in pages with only Latin text, like attachment 61906 [details]. See my email to mkaply quoted in comment 18. This is what the IBM Bidi implementation originally did, but we changed it because so many test suites for HTML 4 conformance includes a BDO test using Latin text.
OK. Comment 40 and comment 41 makes it clear. If bidi algorithm is implemented to apply to any text context, as opposed to just bi-directional text context, then damien's test case needs to work. That would make the definition of <BDO> less clear (to me) but nonetheless would not be inconsistent with oher parts of HTML 4.01. My questions are answered. Thanks.
http://www.people.fas.harvard.edu/~dbaron/css/test/bidi2 works for me. When I added a single Hebrew character to the end of attachment 61906 [details], the bidi began to work for me. Apparently, the presence of at least one Hebrew or Arabic character turns on the bidi support. Does this behavior make the bug into a wontfix, with known workaround "Put any Hebrew character somewhere in the file"? And are there other directionalities (e.g. top-to-bottom for CJK) that I can apply in CSS?
>And are there other directionalities (e.g. top-to-bottom for CJK) that I can apply >in CSS? Wait for CSS3 ;-) http://www.w3.org/TR/css3-text/
This is quite a recent regression: it works in the latest nightly I have, 2001120504. I am downloading other nightlies to narrow down the period that it regressed, and then I will start grovelling through bonsai to identify the cause.
Of the builds I have at hand, 20011207 Win32 build has damien's test case working but 20011210 Win32 build does not. So the regression happened between 2001-12-07 and 2001-12-10.
I have identified the cause of the regression and filed bug 115921.
Depends on: 115921
I just added a version of attachment 61906 [details] to the layout regression tests. Thank you, Damian, for your contributions to this issue.
All the testcases look OK in current builds (since bug 115921 was fixed)
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Verified as workforme with 01-20 trunk build.
Status: RESOLVED → VERIFIED
Alias: text-dir
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: teruko → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: