Closed Bug 236856 Opened 20 years ago Closed 17 years ago

Brackets (parentheses) in RTL text are flipped when a non-Hebrew font is defined for Hebrew text on Win98

Categories

(Core Graveyard :: GFX: Win32, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: tsahi_75, Unassigned)

References

Details

(4 keywords)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.6) Gecko/20040113

when using Verdana font in RTL text, either with style or with the <font face= >
tag, brackets are fliped and non-alphanumeric characters (e.g. punctuation
marks) are changing order with the brackets, and generally behave unexpetedly.

testcase and screenshots coming up.

Reproducible: Always
Steps to Reproduce:
1.set a text in an html document to RTL (with div or otherwise)
2.set that text to use Verdana font, with style or with the font tag


Actual Results:  
you get something like )text in parentheses( and outside of them

Expected Results:  
get (text in parentheses) and outside

this does not happen with LTR text.

this does not happen on WinXP. i've set the OS field accordingly.

i've verified this bug exists at least since Mozilla 0.9.8. funny i didn't
notice it so far.
Attached file simple testcase
Attached image windows 98 screenshot
Attached image windows XP screenshot
the first screenshot was made on Win98SE, mozilla 1.6. the image was made with
the windows Paint, hence the bad colors.
this one was made on WinXP Pro, mozilla 1.6 (localized).
Note- Verdana has no Hebrew glyphs, so this is probably a font fallback issue.

(many Israeli sites that use "ready made" designs still define this font)
as far as i could tell (thx to xslf), verdana doesn't contain hebrew gliphs at
all, so when given a list of fonts, mozilla shouldn't be using it for hebrew.

it is also possible to select verdana (and any other font you have on your
system) as default hebrew font in the prefs, even if that font doesn't support
hebrew. in MS-Word, you can only select fonts that support the current input
language.
WFM with English-only Win98 using Verdana.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113

Even if this behavior is reproducible, I don't think it's a valid bug, for two
reasons:

1. Verdana doesn't have Hebrew glyphs.
2. Verdana is not set as a default font for Hebrew or UTF-8.

Bug 149796 and Bug 61883 would probably be better venues for this issue.

Prog.
(In reply to comment #6)
> WFM with English-only Win98 using Verdana.
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
>

i tested it on hebrew enabled win98, and you saw the thread on the
mozilla.org.il board about it. also, when i told about it to the localizers of
phpBB and they removed verdana from they're board's style, someonethere said it
helped him.

> Even if this behavior is reproducible, I don't think it's a valid bug, for two
> reasons:
> 
> 1. Verdana doesn't have Hebrew glyphs.

and therefore, mozilla shouldn't use it for hebrew, like it does now.

> 2. Verdana is not set as a default font for Hebrew or UTF-8.

this has no importance. when the documents sets the font, mozilla will use it,
and not the default.


(whoever added the "reply" link to bugzilla is a genious)
(In reply to comment #5)
> as far as i could tell (thx to xslf), verdana doesn't contain hebrew gliphs at
> all, so when given a list of fonts, mozilla shouldn't be using it for hebrew.

For hebrew- no. For punctuation- I am not sure what the currect behavier should
be in this case.

I wonder if this happens only with verdana, or with other fonts like it, which
have no Hebrew glyphs (if so, we got a font fallback issue)?

Tsahi- as I don't have access to win98, can you please test and see if this
happens with other English only fonts, like Georgia or Comic Sans MS.

wrt font selection in the prefrences, I  agree withprog about otherbugs that
cover the issue better
yep, this happenes also with other non-hebrew fonts.
(In reply to comment #9)
> yep, this happenes also with other non-hebrew fonts.

OK, updating summery.
Summary: brackets (parentheses) in RTL text are fliped when using Verdana font on Win98 → brackets (parentheses) in RTL text are fliped when a non-Hebrew font is defined for Hebrew text on Win98
Blocks: 240501
CONFIRMING.

in the last few days I have been working on win98, and this has been happening
in a lot of sites. It is really annoying when editing text in forms as well.

Mozilla should really keep the proper directionality even when using font fallback.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Layout: BiDi Hebrew & Arabic → GFX: Win32
Keywords: fonts, helpwanted, intl
Jshin, any idea what can be the reason for this behavior?
Assignee: mkaply → win32
Does this happen on non-Hebrew Win9x/ME only or does it also happen on Hebrew
Win98? I guess the former is the case.

This seems to be a bit tough to fix. I have a vague idea of what's going on
(Mozilla's reordering code in layout interacting with the font selection code in
Gfx/Win on non-Hebrew Win 9x/ME ....)
(In reply to comment #13)
> Does this happen on non-Hebrew Win9x/ME only or does it also happen on Hebrew
> Win98? I guess the former is the case.

I'm not using win98, so I can't verify this, but I guees the reporter has the
Hebrew Enabled version of Windows. You don't mean Hebrew *localized* version, do
you?
CCing Prog,

Prog, can you verify this behavior on the Hebrew Enabled version of Win98?
I already tested this issue on Win98 (non-Hebrew-enabled version) and it wfm.
Moreover, the two issues that I raised in comment #6 still stand. I really don't
think this bug is valid. 

Let's not waste development time working around OS limitations that have very
little real-life impact.

Prog.
probably, it's not worth 'fixing', but I'm just curious because prog said wfm
(on non-Hebrew-enabled Win98) while others seem to have a problem. 

As for Hebrew-enabled vs Hebrew-localized, I thought they're the same on Win9x,
but judging from what you wrote, there are Hebrew-enabled Win98 that's not
Hebrew-localized. 
With Win2k/XP, they're obviously different. All Win2k/XP are Hebrew-enabled
regardless of whether it's localized or not. 
according to Google Zeitgeist, 16% use Win98. according to the statistics on the
mozilla hebrew l10n site i run, more than 17% are using Win98 (commulative since
June '03). i assume you'll find similar numbers in mozilla.org's logs. now i
know the number of mozilla users throughout the world that have hebrew enabled
win98 is a small fraction, but i suspect that among those whow ever read hebrew
sites, the percentage is high enough to justify a fix.
I'm trying to understand. So, on Hebrew-enabled Win98, this bug shows up, right
? (but prog wrote it worked for him ... I'm confused). How about
non-Hebrew-enabled Win98? This is an important piece of information to determine
where to look to fix the bug. 

BTW, how do you enable Hebrew on non-Hebrew Win 98 (by 'non-Hebrew Win98', I
mean Win98 which is NOT localized for Hebrew)? 

To be effected by this "bug" one has to:

1. Use Win98 Hebrew Enabled (this part I assume, as it wfm on regular English Win98)
-and-
2. View a *Hebrew* document/page that explicitly specifies the *non-Hebrew* font
Verdana.

This is definitely a very rare scenario. The proper way to handle such pages is
by tech evangelism, not by bloating Gecko with needless workarounds.

(In reply to comment #19)
> BTW, how do you enable Hebrew on non-Hebrew Win 98 (by 'non-Hebrew Win98', Ia
> mean Win98 which is NOT localized for Hebrew)? 

You don't. You use an application that implements BiDi on its own - such as
Mozilla and most word processors. All you need to add is a font with Hebrew
glyphs and a customized Hebrew keymap if you wish to write Hebrew. It's the same
with other operating systems that don't implement BiDi, such as BeOS and OS X
prior to v10.2 (and thanks to Mozilla I have personally used Hebrew extensively
in both).

To simplify this:

Win98 Hebrew Enabled supports BiDi and comes with a Hebrew keymap
Win98 Local is the same, but has Hebrew GUI
Plain Win98 (English) has none of the above

Prog.
Prog, notice the (...) part of comment 4.
(In reply to comment #4)
> (many Israeli sites that use "ready made" designs still define this font)

Even if this is the case (and I'm not sure how much is "many"), it doesn't
change the fact that we're dealing with a tech evangelism issue. Hebrew pages
that specify non-Hebrew fonts are simply broken, and their authors should be
aware of this.

Prog.
(In reply to comment #22)

> it doesn't
> change the fact that we're dealing with a tech evangelism issue. Hebrew pages
> that specify non-Hebrew fonts are simply broken, and their authors should be
> aware of this.

That's not actually the case. It's  valid to specify 'non-Hebrew font, Hebrew
font, generic-font' via CSS because someone may want Latin letters to be
rendered with a 'non-Hebrew font' while wanting Hebrew letters to be rendered
with a Hebrew font.
Summary: brackets (parentheses) in RTL text are fliped when a non-Hebrew font is defined for Hebrew text on Win98 → Brackets (parentheses) in RTL text are flipped when a non-Hebrew font is defined for Hebrew text on Win98
(In reply to comment #19)
> I'm trying to understand. So, on Hebrew-enabled Win98, this bug shows up, right
> ? (but prog wrote it worked for him ... I'm confused). How about
> non-Hebrew-enabled Win98? This is an important piece of information to determine
> where to look to fix the bug. 
> 

prog. said he has non-hebrew-enabled win98, where it didn't show up. i had hebrew-enabled win98, where it did.

> BTW, how do you enable Hebrew on non-Hebrew Win 98 (by 'non-Hebrew Win98', I
> mean Win98 which is NOT localized for Hebrew)? 
> 
> 
you don't. win98 didn't have this option, like there is in winXP. you had to get a pre-compiled version with hebrew support (but not localized, if you so desire) that was sold in Israel.

oh well, by now there are less win98 users than there are Linux users, at least on our site. i don't know if this is worth fixing.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: