39.42 KB, image/gif
146.88 KB, image/jpeg
68.48 KB, image/jpeg
204.50 KB, image/jpeg
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 Attachment"). 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 http://www.benyehuda.org/rachel/Rac001.html ? 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 (http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/HEBREW.TXT) does not include shin dot and sin dot as separate codepoints, but instead encodes UFB2A SHIN WITH SHIN DOT and UFB2B SHIN WITH SIN DOT at 0xD6 and 0xD7. ftang: could we solve this in the Unicode to MacHebrew convertor?
Assignee: mkaply → ftang
Status: UNCONFIRMED → NEW
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 mozilla.org. 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
Compare this screen shot to http://bugzilla.mozilla.org/attachment.cgi?id=83861&action=view
How about changing the summary of the bug to something more descriptive? anything with "diacritics" should be fine. Prog.
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
Status: ASSIGNED → NEW
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 http://developer.apple.com/fonts/OSXTools.html
Following Simon's recent fixes[*], this now WFM on OS X with all the fonts I tried. [*] See http://www.smontagu.org/blog/?p=299
Status: NEW → RESOLVED
Last Resolved: 12 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.