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

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
11 years ago
11 years ago

People

(Reporter: smontagu, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Created attachment 269568 [details]
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)
(Reporter)

Comment 1

11 years ago
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Comment 2

11 years ago
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.
(Reporter)

Updated

11 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 3

11 years ago
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
Last Resolved: 11 years ago11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.