Closed Bug 385622 Opened 17 years ago Closed 17 years ago

Hebrew diacritics (vowel points/nikud/nikkud) disappear completely when missing from specified font

Categories

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

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: smontagu, Unassigned)

Details

Attachments

(1 file)

Attached file testcase
(spun off from bug 60546)

In pre-cairo Windows builds, if text with Hebrew diacritics specified a font that didn't contain glyphs for the diacritics, the diacritics would be displayed as non-combining characters between the base characters, as in attachment 268243 [details].

In current trunk builds, almost all diacritics are simply not displayed.

(If no diacritics at all were displayed, I would think that this was our bug. Since some are displayed (e.g. U+05C1 SHIN DOT and U+05B9 HOLAM in the testcase), I suspect that this is by design in the font)
Yup, this is WORKSFORME (or even INVALID). Fixed Miriam Transparent (mriamfx.ttf) simply contains empty glyphs for most Hebrew diacritics, and it occurs to me that maybe that's what "Transparent" means!?

Gecko, Opera and IE all display the testcase identically. Safari on Windows treats the diacritics as spacing characters and then doesn't display them.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
What's going on with this bug?  The bug claims that when Hebrew diacritics are missing from a given font, they're not fetched from another font to be displayed; instead, nothing is displayed.

Somon in comment #1 said he could reproduced this, and that he also sees the same behavior other browsers (Gecko, Opera, IE).  I can confirm that I see this same behavior in Mozilla (trunk) and IE.

Therefore, the RESOLVED/WORKSFORME status -- the maintainer could not reproduce your bug -- makes no sense.  Everyone here CAN reproduce this.

So, the question is just whether this is intended behavior, or not?  If it is working as intended, the resolved status should be RESOLVED/INVALID.  But there seems to be no strong and authoritative claim that this is actually the way it's supposed to work.

So, I'd like more info about this.  Why is it working this way? What's the theory of operation?  Can we get that?  I'd like this to change to NEEDINFO until we have that info.

Personally, I'm not tremendously bothered by this current behavior; it's way better than the previous bugs.  But just think it will be useful in the long run to definitively say how this is supposed to be.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Bugzilla won't let me change this to NEEDINFO for whatever reason.

I think the first question to answer is whether this occurs (as the summary suggests) in any font with Hebrew consonants but without diacritics, or whether it's specific to the "Transparent" fonts.

On the question of why these fonts are called Transparent, see http://blogs.msdn.com/michkap/archive/2007/01/30/1556199.aspx
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: