Closed Bug 144157 Opened 21 years ago Closed 15 years ago

Hebrew nearly ok, still problem on Mac (diacritics)


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

Not set





(Reporter: shaul, Unassigned)




(Whiteboard: see comment 16)


(4 files, 1 obsolete file)

I don't know who to assign a bug in display of hebrew. On PC it seems to be 
fixed, on mac it is 99% fixed. But still there is 1% left and I am sure that it 
is nonsense. 

Contact me and I will email you screenshots.
No, please attach the screenshots to the bug (by clicking on "Create a New

I see that the URL contains Hebrew with diacritics, so it might be worth
comparing bug 123218 first, and marking duplicate if it is the same problem.
Assignee: bellot → mkaply
Component: French/fr-FR → BiDi Hebrew & Arabic
Product: Browser Localizations → Browser
QA Contact: bellot → zach
Version: unspecified → other
Mac OSX, build id 2002051403:
This does not look like a duplacate of  bug 123218 , but more of a 
duplicate to bug 60546 .
I am attaching a sreen shot: notice that the wrong position is not for 
characters with multiple diacritics, but with the base of some diacritics.

The font you see is Lucida grande (from OSX beta. the final OSX version 
of Lucida grande does not include a cmap for Hebrew)/
Due to bug 110655 and bug 132341  , it is close to impossible to control 
what font will display the page, and choose a good font for diacritics.
The screenshot looks to me _exactly_ as if the problem is with multiple
diacritics on the same consonant (given that shin dot and sin dot are
diacritics). It's also odd that the shin/sin dot itself doesn't appear, except
when there is no other diacritic (e.g. in 'tittosh', the third word from the
left in the first line of the second paragraph). 

Does the same thing happen at ?
There is no screenshot in bug 123218.

By the way, the screenshot here also displays a bug with the verse numbers which
I can't reproduce on other platforms.
Shaul sent me this screenshot by email.
Attachment #84201 - Attachment is obsolete: true
The symptoms of attachment 84268 [details] are similar but not identical to the OSX
screenshot in attachment 83861 [details]: on a consonant with a shin dot or sin dot and
another diacritic, there is a question mark after (to the left of) the consonant
and the other diacritic is attached to the question mark. The difference in the
OSX screenshot is that there the shin or sin dot seems to be appearing after the
consonant as empty space.

The apparent exception that I mentioned in comment 4 is not really an exception:
in "tittosh" we are seeing the holam on the tet (0xC9 in this encoding,
equivalent to U05B9), not the shin dot.

MacHebrew encoding
( does not
include shin dot and sin dot as separate codepoints, but instead encodes UFB2A

ftang: could we solve this in the Unicode to MacHebrew convertor?
Assignee: mkaply → ftang
Ever confirmed: true
we need to add logic into the nsUnicodeRenderingToolkit.cpp to fold two hebrew
unicode code point into one if the glyph does not exist .
The problem is we need to do "look ahead" when we try to display the first hebrew.
look at the mappint in the fb20-fb4f range.
will work on this when I have time. 
[ftang:] you need to change ATSUIFallbackGetDimensions, ATSUIFallbackDrawChar
and their callers. look at the Unicode 3.0 book page 804-806 for the table.
Assignee: ftang → yokoyama
Target Milestone: --- → mozilla1.2beta
bulk milestone change
Target Milestone: mozilla1.2beta → mozilla1.3alpha
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
Tested with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b)
Gecko/2003090803 on osx 10.2.6- now it looks worst then the older osx screen
shot. I am not sure if it is because mozilla is selecting a diffrent font, or
because we have a regression here.
It will be difficult to test, due to bug 120401
Depends on: 120401
OS: Mac System 9.x → MacOS X
How about changing the summary of the bug to something more descriptive?
anything with "diacritics" should be fine.

Summary: Hebrew nearly ok, still problem on Mac → Hebrew nearly ok, still problem on Mac (diacritics)
The bug is nearly fixed now, but only with mac fonts (Lucida Grande). There is
still a problem with Windows fonts, but that's a bug in the OS (see Safari,
Mellel, etc.).
Assignee: yokoyama → nobody
QA Contact: zach → bugs.mano
Whiteboard: see comment 16
(In reply to comment #16)
> The bug is nearly fixed now, but only with mac fonts (Lucida Grande). There is
> still a problem with Windows fonts, but that's a bug in the OS (see Safari,
> Mellel, etc.).

  Did you mean a problemw with 'diacritics' when you use Windows fonts or Hebrew
rendering in general with Windows truetype fonts? It's very likely to be the
former, in which case I wouldn't call it a bug. Mac OS X doesn't make use of
opentype GSUB/GPOS tables (present in Windows opentype fonts for Hebrew), but
relies on truetype mort table. If 'mort' table is absent, ATSUI can't handle
combining characters like diacritics. Needless to say, it'd be nice to see
GSUB/GPOS tables be taken advantage of on OS X, but that may never happen.  BTW,
you may be able to add 'mort' tables with OS X font tools. See

Following Simon's recent fixes[*], this now WFM on OS X with all the fonts I tried.

[*] See
Closed: 15 years ago
Resolution: --- → WORKSFORME
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: mano → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.