Closed Bug 60546 Opened 24 years ago Closed 17 years ago

[BiDi] Unicode Hebrew/Yiddish Diacritics do not correctly align in some fonts.

Categories

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

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: arthur.barrett, Assigned: mkaply)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(9 files)

The Font Frankruehl displayed correctly rendering this page in IE, wrong in Bidi-Mozilla
36.91 KB, image/gif
Details
http://www.qsm.co.il/Hebrew/HebrewTest/test5.htm in Mozilla font Tahoma (from Office 2000)
168.36 KB, image/jpeg
Details
http://www.qsm.co.il/Hebrew/HebrewTest/test5.htm in IE5.5 using Font Tahoma (from Office 2000)
164.61 KB, image/jpeg
Details
Looks fine in Build#2002053012
43.36 KB, image/png
Details
a png image which demonstrates incorrect rendering in Fx 2.0.0.4
49.03 KB, image/png
Details
a png image which demonstrates incorrect rendering in Fx 3.a alpha 5
47.12 KB, image/png
Details
a png image which demonstrates correct rendering in IE6
62.17 KB, image/png
Details
Hebrew Characters - Bad Placement of Vowel Points - with font Miriam Fixed Transparent
12.76 KB, image/jpeg
Details
Hebrew Characters - Good Placement of Vowel Points - with font Miriam
13.87 KB, image/jpeg
Details 
When Unicode web pages containing Hebrew/Yiddish Diacritic marks are displayed 
using the BiDi version of mozilla 
(ftp://ftp.software.ibm.com/ps/products/warpzilla/bidi-win32-rel-11-13.zip) 
they appear BESIDE the character that they should appear BENEATH.

When the font is altered in preferences (and force font) to Lucidia Sans 
Unicode, then they appear correctly.

Fonts that work in IE5 but not Mozilla include:
Tahoma (tested)
Frankruehl (reported by 3rd party)

Some explanation as to why some fonts work and others do not would be useful, 
but ultimately it would be prefferred if they all could work.
I got these comments from Mark David, from Yiddish Information Processing 
(uyip.org).

Oh, I see.  Someone got this to work with the Lucida font, but not the
normal Windows Hebrew fonts.

The Lucida font is broken for Hebrew.  My Microsoft sources say this
is known, but cannot be changed for compatibility with existing
applications.  This font has been around since Windows NT 3.51, around
1994.  

In fact, Internet Explorer with Hebrew extensions has not been fixed
to compensate for Lucida's problems, and only works for the standard
Hebrew fonts, and displays nikud wrong ONLY with Lucida.

It's very nice to have "special" code that makes it display Hebrew
correctly, but the display code should also handle correctly constructed
fonts, in particular the standard Hebrew fonts supplied with Hebrew-enabled
Windows 98/NT/2000 and with Hebrew extensions for Internet Explorer 5.  
E.g., Arial, Times-Roman, Tahoma, Frankruehl, et al.

Sure enough I could reproduce this with a plain text page

http://uyip.org/rotshd-cp1255.txt

I simply had to explicitly say the encoding is Hebrew Windows Code Page 1255
under View -> Character Coding.

Reassign to mkaply, cc erik.
Assignee: nhotta → mkaply
Arthur is this still a problem in the latest nightlies?
I will check ASAP, however we just relocated our office and so this may take me 
a few days.
Arthur any luck reproducing?
new bidi code should be checked in by mkaply soon pending review of his changes.
Look for the bug out there.
Tested with a WinNT 4.0 compiled copy of the latest (9/Jan/01) BiDI source code.
 Still does exactly the same thing.  This is not good ...

No-one has yet offered an explanation as to why this is happening either...

I will upload a binary copy of the WinNT build some time over the weekend and
post a URL when available.

The source code is from ftp://ftp.software.ibm.com/ps/products/warpzilla

Marking NEW as per comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
URL of binary for Win NT is:
http://march-hare.com/downloads/bidimoz.zip

It is a debug build weighing in at 48Mb.

To reproduce with teh text file, you need to Choose the character coding (View
-> Character Coding -> More -> Middle Eastern ) Hebrew (Windows 1255).

http://uyip.org/rotshd-cp1255.txt

And set the font (Preferences, Font, Hebrew) to Tahoma.

To reproduce with the Unicode HTML page (See attachment), set the character set
to Unicode UTF-8 and set the preferences font for Unicode to Tahoma.

So I guess this means that it is not Unicode specific, since it also reproduces
with CP1255 ?




After some e-mails from Lina I thought I should clarify:

I am using standard Windows NT 4.0 + SP4.  I've never heard of "Hebrew Enabled" 
versions, and do not need "Hebrew Enabled" for these same pages to work fine in 
IE5 (even with Tahoma).  I have heard of the Microsoft localised Hebrew Windows 
NT, but not Hebrew Enabled....

I will now attach bitmaps of Lina's page in both bidi Mozilla, and ie5, on the 
same machine, same font etc etc.

(http://www.qsm.co.il/Hebrew/HebrewTest/test5.htm)

After investigating a number of different fonts from different sources, I have
come to the conclusion that Hebrew nikud is broken in all Microsoft Hebrew
fonts: Lucida Sans Unicode is broken in one way, and other fonts such as Tahoma
are broken in another way. Microsoft's own programs with Hebrew support (whether
Bidi enabled NT or IE5) are capable of displaying text in Hebrew script with
nikud correctly, but the standard text-output APIs are not.
Finding a workaround for this problem is not trivial: we will probably have to
detect text with nikud and send it to special output methods, while also
sniffing the current font to work out in what way it is broken and how to
compensate (or whether it is a compliant third party font).


Changed QA contact to andreasb@netscape.com.
QA Contact: teruko → andreasb
Summary: Unicode Hebrew/Yiddish Diacritics do not correctly align in some fonts. → [BiDi] Unicode Hebrew/Yiddish Diacritics do not correctly align in some fonts.
smontagu@il.ibm.com (Simon Montagu) on the 
netscape.public.mozilla.i18n newsgroup posted this

>
>= http://bugzilla.mozilla.org/show_bug.cgi?id=60546, right?
>

I dont personally agree, I think from the comments on 60546 that it is windows 
specific wheras this bug is on Sun/Solaris.


Oops - posted that last comment the wrong way around.

smontagu@il.ibm.com (Simon Montagu) on the 
netscape.public.mozilla.i18n newsgroup has suggested that
http://bugzilla.mozilla.org/show_bug.cgi?id=81367
and this bug (60546) are related.

I dont personally agree, I thought 60546
is windows specific wheras 81367 is Sun/Solaris.

If they are the same then does that help resolve it ?

confirming on win95, 2001063003
Switching QA contact to giladehven@hotmail.com.
QA Contact: andreasb → giladehven
Copied from n.p.m.i18n:

In spite of their otherwise good BIDI support, Mozilla 0.9.1 and 0.9.2
as well as the nightly build as of yesterday fail to display Hebrew
diacritics in correct positions above letters if the CSS property
TEXT-ALIGN is set to the value JUSTIFY, whether internally or
externally, for an inline element containing the combination of
Hebrew letters and diacritics. It took me a while to pin down this
as the environment of the buggy display.

----------------------------------------------------------------
Tsuguya Sasaki, PhD
E-mail: tsuguya@gol.com
WWW: http://www2.gol.com/users/tsuguya/
----------------------------------------------------------------
I'd attatch a sample of what Tsuguya is talking about, but Bugzilla currently 
wont let me.  

You can see it at http://mail.hlmm.com.au/diacritics.html

If you have problems with this URL - contact me direct.

The original example URL (as above) uses a stylesheet:
http://www2.gol.com/users/tsuguya/ts.css

This uses justify for the <body> tag - so it looks like this is the bug.
Component: Internationalization → BiDi Hebrew & Arabic
Mass-move all BiDi Hebrew and Arabic qa to me, zach@zachlipton.com. 
Thank you Gilad for your service to this component, and best of luck to you 
in the future.

Sholom.
QA Contact: giladehven → zach
Confirming this is still present in 0.9.5 for Linux.

The user reports:
diacritics are placed after, not with, corresponding letters.  My font setting 
is for Hebrew misc-fixed-iso8859-8; for Unicode (all styles) misc-fixed-iso-
10646-1.  In fact, I am certainly not seeing my Yiddish text in the latter 
font, even though Mozilla claims that it is using Unicode encoding.  I may be 
seeing it in the former font, but I'm not sure.  

The URL I am looking at is 
http://www.cs.uky.edu/~raphael/bavebter/numer.1.3/sholem.redak.utf.html
Blocks: 115713
*** Bug 127050 has been marked as a duplicate of this bug. ***
This may have something to do with OpenType Layout Tables which allow to display
spacing diacritics as if they were properly aligned nonspacing diacritics. But
this is just a guess. You can get some info about Visual OpenType at

http://www.microsoft.com/typography/developers/volt/

and

http://communities.msn.com/MicrosoftVOLTuserscommunity/

Gyula

It has nothing to do with OpenType Layout Tables.
Mozilla 0.9.9: Works under Windows, fails under Linux.
The bug is still there in Mozilla 1.0 Release Candidate 1.
I am using Windows 98 original edition.

*** Bug 140788 has been marked as a duplicate of this bug. ***
No improvement in Version 1.0 RC2.
Blocks: bidi_relnotes
The diacritics seems to render almost perfect on my build. Only problem I can
see is with the 'Holam' (?) sign, which is followed by an unnecessary space
(see second word, 'Ovadia', in http://www.qsm.co.il/Hebrew/HebrewTest/test5.htm
).
Of course this might be fixed in lately builds, I'm not sure.
Under Linux this is still a problem? Is there a bug for Linux or should I change
this bug to All OS?
re comment 32: I think the Holam problem is a bug in specific fonts. I see the
extra space after the Holam in Arial, Arial Unicode MS and Tahoma, not only in
Mozilla but also in Wordpad and IE. In other fonts, the extra space disappears.

re comment 33: we have bug 81367 for the corresponding problem on Unix systems,
and bug 144157 for a more limited problem with diacritics on Mac.
as of build 2002061603, the page still looks bad on osx,
Where can I get the build compiled by Sagie Maoz and when
will his corrections be added to the official build?

You must be confusing me with somebody else, I don't do patches :)
Attachment #89520 - Attachment description: Looks fins in Build#2002053012 → Looks fine in Build#2002053012
There is no available BiDi build yet that properly displays Yiddish.

AbiWord suffers from a similar bug:
http://bugzilla.abisource.com/show_bug.cgi?id=3768
Could the two teams join forces?

More bugs with screenshots that show the same wrong alignment: Bug 123218 and 
Bug 144157

*** Bug 123218 has been marked as a duplicate of this bug. ***
*** Bug 184910 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
Hardware: PC → All
*** Bug 196453 has been marked as a duplicate of this bug. ***
There seems to be a general problem with the diacritcs rendering after the base
character; I'm seeing the problem on Win98 with mozilla 1.3 except I'm not using
Hebrew; simply trying to combine a ^ with a z for example.
in addition there is something funny:
if I write: Hachodesch (&#1492;&#1495;&#1493;&#1491;&#1513;) hebrew is wrong
direction. it is right direction in internetexplorer.
if I write: Hachodesch (<bdo
dir="rtl">&#1492;&#1495;&#1493;&#1491;&#1513;</bdo>) it does not change
it I write: Hachodesch (<bdo
dir="ltr">&#1492;&#1495;&#1493;&#1491;&#1513;</bdo>) it displays correctly. But
wrong with internetexplorer.

this sample is from www.synagogenverein.at/bethaus.asp

this is a terrible thing :'(. not even unicodes but also "<bdo dir" tags are
misinterpreted!

please fix.

johannes
Comment 44 is completely unrelated to this bug. Can you please file a separate
report?
Not only for Yiddish, same for hebrew:
http://www.mechon-mamre.org/i/t/t0101.htm

Please fix so we can stop use IE.
Sometimes when the diacritics display incorrectly in the way described here, the
line of text goes beyond the margin, but sometimes it does not. Is this behavior
just a side-effect of this bug, or does it need its own bug? Such a bug has been
filed as bug 209468.
*** Bug 210122 has been marked as a duplicate of this bug. ***
See also bug 212808 which is partly a duplicate of this one. The behaviour of a
page of fully cantillated biblical Hebrew,
http://www.mechon-mamre.org/c/ct/c0101.htm (in Mozilla 1.4 on Windows 2000),
with font Ezra SIL (OpenType, designed specially for biblical Hebrew, from
www.sil.org) set as the default depends on the version of Uniscribe installed,
but even with the latest version of Uniscribe set for release with Office 11
there is a diacritic placement problem, not found with IE6.

Actually this is not really this bug at all as originally reported. It looks to
me as if this bug started with incorrect behaviour of some pre-OpenType
Microsoft etc fonts which would be the same in IE as in Mozilla. The problem I
am reporting has similar symptoms but is Mozilla specific. It seems to be a
matter of Mozilla failing to use Uniscribe and OpenType tables properly. Should
I open a new bug or continue this as bug 212808?

But comment 46 here may be related to what I am reporting, although
http://www.mechon-mamre.org/i/t/t0101.htm, on the same site as my problem page,
has no cantillation marks and is encoded in CP1255 rather than UTF-8.
*** Bug 212808 has been marked as a duplicate of this bug. ***
*** Bug 214801 has been marked as a duplicate of this bug. ***
*** Bug 221399 has been marked as a duplicate of this bug. ***
Is anybody working on this bug now? I'm trying to look into it. Is use of Pango
to display text in mozilla out of question? (Pango is a library used by GNOME
for displaying text, it seems to handle Hebrew diacritics successfully.)
As for using Pango on Linux, see bug 215219. My patch there works well for justified as  
well as unjustified text. However, I'm not dealing with Hebrew and Arabic in the patch 
because I'm not sure what Mozilla's internal Hebrew/Arabic routine does.  
  
On Windows, we have to use Uniscribe APIs instead of standard Windows text drawing APIs 
to render justified text correctly (see bug  218887) .   
 
BTW, is there any freely available opentype font for Hebrew supporting Hebrew diacritic 
marks?
Depends on: uniscribe
Keywords: intl
Re comment 54, see Ezra SIL from http://www.sil.org/computing/fonts/silhebruni/.
See also http://www.sbl-site.org/Resources/Resources_BiblicalFonts.aspx; the
long promised new Unicode Hebrew font will be very good, from what I have seen
of the beta, but unfortunately it is has not yet been released.

There is also an initiative for using the SIL Graphite rendering system within
Mozilla, see http://sila.mozdev.org/. This might be useful for rendering Hebrew
and Arabic. Unfortunately SIL's Hebrew font does not work with SIL's rendering
system, because it does not include a Graphite table.
Thanks for the info. about SIL opentype fonts for Hebrew. With them installed,
Mozilla on Win 2k works well for _unjustified_ Hebrew with diacritics (vowel
marks). That's expected because ExTextOutW (Win32 API) used by Mozilla  can take
care of complex script rendering given a 'enough' context on Win2k/XP (and
Hebrew/Arabic Windows 9x/ME for Hebrew/Arabic and Thai Win 9x/ME for Thai)
However, it doesn't work for 'justified' text. For that, we have to use
Uniscribe (bug 218887). Now, I'll see how Pango works on Linux. 

As for SILA, I'm aware of that, but as you pointed out, without Graphite fonts
for Biblical Hebrew, it's not useful. 


The URL returns 404, so I replaced it with the one from Bug 144157. It should be
sufficient for testing this bug.

Prog.
URL: http://www2.gol.com/users/tsuguya/wri... → http://www.mechon-mamre.org/i/t/t2801...
Blocks: 240501
Dov Grobgeld has submitted a patch to pango to use GPOS and GSUB tables in
Hebrew fonts. See
http://article.gmane.org/gmane.linux.region.israel.ivrix.discuss/921 and
http://bugzilla.gnome.org/show_bug.cgi?id=150785.
blizzard recently added nsFontMetricsPango to mozilla trunk. (the relevant bug
is bug 214715, but he just did it off-line) To test it, you need to install
pango 1.5 (plus the patch for GPOS/GSUB support in Hebrew mentioned ) and build
mozilla with 'enable-pango'.
Depends on: 214715
This is my first bugzilla comment in Mozilla, so please excuse me if I'm not too
familiar with how the rendering works.

From the discussion above, I don't understand if you are going all the way to
using pango. If you are the rest of this comment is irrelevant, as you will
receive the below functionality from pango.

If not you may want to consider to copy my heuristics that is encoded in the
Hebrew module. This heuristics does a reasonable job of nikkud placement for
fonts without GPOS and GSUB tables by simple rules such as "PATAH should be
centered below the character", "SHIN DOT should be right aligned", etc. The
result is imho really good enough.
(In reply to comment #60)
... 
> If not you may want to consider to copy my heuristics that is encoded in the
> Hebrew module. This heuristics does a reasonable job of nikkud placement for
> fonts without GPOS and GSUB tables by simple rules such as "PATAH should be
> centered below the character", "SHIN DOT should be right aligned", etc. The
> result is imho really good enough.

This result may be good enough for basic pointed Hebrew. But it will not be good
enough for fully pointed and accented Hebrew as use e.g. in the Bible text,
which is rendered successfully by pango with Dov's patch (see his samples).
There is a significant demand for reading the Hebrew Bible online, and several
sites at which it is available e.g. http://mechon-mamre.org/c/ct/c0.htm and
http://users.ntplx.net/~kimball/Tanach/Tanach.xml. These sites already work well
with IE, and in fact with Mozilla 1.7 on Windows XP. I hope Mozilla won't be
satisfied long term with a partial solution but will implement full pango
rendering of Hebrew - and I hope Dov's patch will make it into the pango trunk.
FYI, I got permission to and applied the (modified) patch to the main pango
trunk yesterday.

Regarding heuristics, it is true that the current heuristics that is in the
pango Hebrew renderer does not handle fully pointed and accented Hebrew. But I
am convinced that it may be changed to do that. The rendering heuristics has
access to complete bounding box information as well as the coding of the glyphs.
That is enough to do make sure that the various marks do not collide. Don't take
the current implementation in pango (which ignores accents) as an indication
that is not possible!

The problem with using opentype tables is pushed to the font designer who has to
create tables for several thousand potential combinations. One idea I have is to
use e.g. the online tenach to automatically generate all possible combinations,
and then use some automatic layout routine (e.g. involving distance transforms)
to generate all the different GPOS combinations... But now I am getting carried
away.

Thus my question remains. Is Mozilla moving over to using pango?

(In reply to comment #62)
> FYI, I got permission to and applied the (modified) patch to the main pango
> trunk yesterday.
> 
Great!
...
> The problem with using opentype tables is pushed to the font designer who has to
> create tables for several thousand potential combinations. One idea I have is to
> use e.g. the online tenach to automatically generate all possible combinations,
> and then use some automatic layout routine (e.g. involving distance transforms)
> to generate all the different GPOS combinations...

Sounds good for use with a font which doesn't have all the GPOS etc information
set up. But when you have a font like SBL Hebrew which has been designed
carefully so that all (or nearly all) of those several thousand combinations are
supported, surely it is better to use that information rather than try to do
better with heuristics.
Blizzard - this question is for you.

> Thus my question remains. Is Mozilla moving over to using pango?
*** Bug 257756 has been marked as a duplicate of this bug. ***
I don't think there's any official mozilla.org policy on this.  I will say,
however, that I've added support for pango in Mozilla.  I think we (Red Hat)
intends to ship this in some upcoming version of Fedora.  It does do a better
job with a lot of scripts including arabic and hebrew.  It's worth checking out.
I have just compiled firefox cvs with --enable-pango on debian unstable, 
I can see diacritic in the correct palce using culmus fonts.
(http://benyehuda.org/bialik/bia001.html)

but:
1. when using text-align justify the text gets all mixed up:
(http://www.mechon-mamre.org/c/ct/c0101.htm)
2. printing hebrew is reversed.
*** Bug 279490 has been marked as a duplicate of this bug. ***
*** Bug 279925 has been marked as a duplicate of this bug. ***
Blocks: 209468
Hi, I'm wondering when this will finally be fixed! For me, it's quite a serious
problem, not having the vowels and cantilation marks placed correctly. I have
the Ezra SIL SR font installed and am trying to look at the Bible with vowels
and cantillation marks at http://www.mechon-mamre.org/c/ct/c0101.htm .  

Some observations:

Aside from mozilla, the following applications seem to have the same problems:
epiphany, openoffice (both in linux and windows), scribus (and IIRC
mozilla/firefox in windows as well!)

The following apps do NOT have the problem:
MS IE, MS WORD, and Konqueror (I run it in gnome).
                    ^^^^^^^^^

So another linux app has managed to fix this!  Could we please fix it in Mozilla
soon?  Please?

Thanks,

HCY.
(In reply to comment #70)
> ... the Bible with vowels
> and cantillation marks at http://www.mechon-mamre.org/c/ct/c0101.htm .  
> 
> Some observations:
> 
> Aside from mozilla, the following applications seem to have the same problems:
> epiphany, openoffice (both in linux and windows), scribus (and IIRC
> mozilla/firefox in windows as well!)

I can confirm that this problem is still found with this page in Mozilla 1.7 on
Windows, and this continues when I edit the page in Composer and change the font
to SBL Hebrew. But the problem may be just with this page. The pages
http://www.cvkimball.com/Tanach/Genesis.DH.xml and
http://www.anastesontai.com/b-cantilee/en-cant.asp display the same text
correctly, with SBL Hebrew. Is there a subtle setting in the stylesheets causing
the difference?
I get the same problems with those sites as well.

HCY.
I'm fairly sure I've said this before, but if so I'll say it again.

On Windows the diacritics and cantillation marks are displayed correctly (via
Uniscribe), except where there is "align=justify" or the equivalent in CSS.

On Linux and other platforms, the problem exists with or without justification.
The Pango support which is currently in development (bug 214715, marked as
blocking this one) should bring Linux at least into line with Windows. The other
blocker, bug 218887 should cover the justify issue on Windows. I am adding bug
215219 as blocker, which is the Linux equivalent of bug 218887.
Depends on: CTL2
(In reply to comment #73)
> The Pango support which is currently in development (bug 214715, marked as
> blocking this one) should bring Linux at least into line with Windows.

It turns out that non-justified text in Linux builds with Pango enabled is
already at least on a par with Windows. See attachment 176897 [details] in bug 285007.


(In reply to comment #73)
> I'm fairly sure I've said this before, but if so I'll say it again.
> 
> On Windows the diacritics and cantillation marks are displayed correctly (via
> Uniscribe), except where there is "align=justify" or the equivalent in CSS.
> 
> On Linux and other platforms, the problem exists with or without justification.
> The Pango support which is currently in development (bug 214715, marked as
> blocking this one) should bring Linux at least into line with Windows. The other
> blocker, bug 218887 should cover the justify issue on Windows. I am adding bug
> 215219 as blocker, which is the Linux equivalent of bug 218887.

Is Uniscribe connected to Firefox?
(In reply to comment #73)
> On Windows the diacritics and cantillation marks are displayed correctly (via
> Uniscribe), except where there is "align=justify" or the equivalent in CSS.
> 
> On Linux and other platforms, the problem exists with or without justification.

I have been working on fixing these issues in Firefox - see my web page
http://blacksapphire.com/firefox-rtl/ for my latest work on these bugs.

For rendering Hebrew with vowels+cantillation marks, there are FIVE bugs present
as of Firefox-1.0.4:

1. (GTK-based Unix, including Linux). As previously described, the default
renderer does not render Hebrew properly, while Pango does.  Since some
languages render better in Pango and some in Mozilla default, it would be nice
to have it automatically select between the two for each language.

2. (All platforms).  In layout/html/base/src/nsTextFrame.cpp, PaintTextSlowly is
called when "align=justify" is used.  PaintTextSlowly does not render Hebrew
properly even with pango enabled.  I fixed it by making it always use
PaintUnicodeText/PaintAsciiText when bidi is enabled.  See the patch on my site.

3. (All platforms).  Justified text (with "align=justify") looks very strange,
because it treats whole sentences as a single word.  I fixed this in
layout/base/src/nsBidiPresUtils.cpp by changing CalculateCharType so it starts a
new text run when it sees a white space.  The Mozilla people might have a better
way to fix this.

4. (All platforms).  The Hebrew Biblical texts have the occasional single letter
that is larger or smaller than usual (e.g. Genesis 1:1 and Genesis 2:4).  When
"align=justify" is used, along with HTML to give a different-sized character (as
in the Mechon-Mamre texts), the odd character ends up as a different "run".  In
some situations (certain font sizes on Windows), the justify algorithm puts a
gap in between.  Justify really should only add extra space where there is
*actual whitespace*.  I haven't fixed this yet.

5. (All platforms).  Printing is all wrong with one or two words per line and
big gaps.  I have not tracked this one down.

Stephen, make sure your work and smontagu's aren't conflicting; he's working on
related issues in bug 297074.

I have been working with Stephen to test and submit his patches.  Upon trying
Deer Park, he finds that much of his code (against 1.0.4) is in the trunk.
I quote his email to me below:

>I tried the DP Alpha 2 release on Windows 2000.  Result:
>
>* Hebrew Today - same.
>* TanakhML - all over the place, same as Linux.
>* Mechon-Mamre - niqqud is all skew as in original Firefox 1.0.6.  My
>windows patch will fix this.
>
>I also noticed printing (at least the preview) seems to be fixed!!
>
>Priority 1: Prepare patch to fix Mechon-Mamre for you to submit.
>
>Priority 2: Fix TanakhML page.
>
>Priority 3: Think about how to get Pango enabled automatically per
>language, so it can be on by default in the build.

I think that this should be a separate bug.  I have filed this as
https://bugzilla.mozilla.org/show_bug.cgi?id=302514

>Priority 4: Test actual printing.
>
>Priority 5: Fix wobble when selecting in Pango patch on M-M text.  I
>know what the problem is: The pango renderer is ignoring the spacing
>chosen by the higher layers, which is used when align="justify" is on.

I hope this provides a reasonable update on status.
I've just upgraded to Firefox 1.5 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 Fedora/1.5-0.fc4 Firefox/1.5) on Linux (Red Hat Fedora Core 2).  Previously I'd been using Mozilla 1.7.3, and, by using a Mozilla build with Pango support and setting MOZ_ENABLE_PANGO as described upthread, I'd got Hebrew vowels to display correctly, i.e. within and around the preceding characters.

According to what I've seen, Firefox 1.5 is supposed to have Pango support built in.  However, it's rendering the Hebrew vowels between the characters, which is pretty much unreadable, and setting MOZ_ENABLE_PANGO makes no difference.

Is there a configuration issue of some kind I'm missing, or is this a new bug in Firefox?
*** Bug 349532 has been marked as a duplicate of this bug. ***
Looks like this bug has been around for six years now, without anyone taking it too seriously.

The suggestion of using a Tanakh (Bible) website to genetrate all possible conmbinations of consonants and vowels (= nikodot or nikodos = diacritical marks) will probably work for Hebrew, but not for Yiddish.  The diacritical marks in Yiddish are different from those in Hebrew: there is only partial overlap.  Furthermore, while Hebrew can be written without these marks (and read by proficient speakers), Yiddish cannot.

In fact there is only a small number of letter/mark combinations in Yiddish, I think fewer than in, say, French.  Fixing this problem in Yiddish is therefore not likely to be rocket science.
(In reply to John Clark, comment #81)
> Looks like this bug has been around for six years now, without anyone taking it
> too seriously.

It's likely that none of the developers who volunteer to fix bugs have found this one interesting enough. If you feel it's important and you wish to improve the chances of it being fixed, then you might want to start a bounty.

Prog.
It seems to work correctly with firefox 1.5.0.7. Was there switch to PANGO for text rendering?
This will be fixed when the new textframe code lands, or shortly afterwards.
Depends on: 333659
I find that, at least on Windows XP Media Center Edition and Windows XP Professional, Hebrew diacritics work properly when I have "Install files for complex script and right-to-left languages (including Thai)" checked in the Regional and Language Options section of the Control Panel, and do not work properly when I do not.
Comment #85 worked for me.  Problem solved.  Thank you very much.  John Clark.
I still see this bug in 2.0.0.4.

What's more interesting is that i see a similar bug in the latest released binary Gran Paradiso alpha 5. But in Gran Paradiso it is slightly different.

In Firefox 2 the vowel dot is somewhere in between its consonant and the next letter.

In Firefox 3 alpha 5 the vowel dot is rendered correctly in relation to its consonant, but after the consonant there's a space which shouldn't be there.

I attached three images which demonstrate rendering in Fx 2, Fx 3 and IE6. The words with vowel dots are accented with red.
The thing I think I figured out the other day: if a font doesn't itself have nikudes (nonspacing marks for vowel points, etc.), then Firefox tries to get them from other fonts.  It does an admirable job finding them; however, it applies them in the wrong way, i.e., devoting a whole new character cell to them.  You can see an example of this by selecting most of the "transparent" fonts on Windows, e.g., Miriam fixed transparent.  So, using this approach, I could reproduce the problem of having "nonspacing" marks become spacing and consume their own character cell on all platforms (Linux, Macintosh, Windows).
This illustrates, along with the next image uploaded, the point in my most recent post: Comment #91, Mark H. David 2007-06-13 09:51:57 PDT
Illustrates comment #91 by Mark H. David 2007-06-13 09:51:57 PDT
Note: I've created image files and uploaded them as attachments (id=268244) and (id=268243).

Note 2: Here's verion info for what I used create these attachments:
Mozilla Firefox for Windows
Firefox 2.0.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
(In reply to comment #90)
> I still see this bug in 2.0.0.4.

Yes, you would. As I said in comment 84, this will be fixed when the new textframe lands, which should be before Gran Paradiso Alpha 6. Checking "Install files for
complex script and right-to-left languages (including Thai)" works for many cases on 2.0.0.4, but not for justified text, as used in http://haharoni.wordpress.com/2007/06/12/meuhedet-si/

When using fonts without vowel points on trunk with new textframe, the vowel points simply don't appear. I'll file a new bug about that.
Is this fixed now that new textframe is turned on?
URL: http://www.mechon-mamre.org/i/t/t2801...
It's fixed on Windows. I don't know what the story is on Mac, and on Linux it isn't 100% perfect, but it will be better to file new bugs for remaining issues.
URL: http://www.mechon-mamre.org/i/t/t2801...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(In reply to comment #97)
> It's fixed on Windows. I don't know what the story is on Mac, and on Linux it
> isn't 100% perfect, but it will be better to file new bugs for remaining
> issues.

Simon, have you filed a bug for vowel points not showing up if missing
from a given font (i.e., not being substituted from another font), which
you reported and said you'd file a bug for in comment #95?  Thanks. 
Thanks for the reminder: filed bug 385622.
Flags: in-testsuite?
How can a fixed bug depend on an unresolved bug? Please consider removing dependence on bug 215219.
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: