361986 - [cairo-cocoa] Arabic letters aren't connected

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[Uri Bernstein]

Arabic letters aren't connected at all - they all just appear in their final forms.

Comment 1

[Uri Bernstein]

(In reply to comment #0)
> they all just appear in their final forms.

That should read: "...their isolated forms".

 

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Argh.  Arabic looked right to me, but I never zoomed in -- I can see the problem now, I think.  Just to verify though, can you give me a small testcase with both correct and incorrect rendering?

Comment 3

[Uri Bernstein]

Attachment: testcase

Comment 4

[Uri Bernstein]

Attachment: screenshot

Correct (left) and incorrect (right) rendering of the testcase.

Comment 5

[Uri Bernstein]

On a different Mac system, I'm not seeing this problem - meaning that it likely depends on the availability (or unavailability) of certain fonts.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I noticed this the other night...http://www.aljazeera.net was all disconnected, while http://news.bbc.co.uk/hi/arabic/news/ is fine.

At first I thought it was our default of Lucida Grande (which has no Arabic glyphs, but which caused font fallback to work in Carbon/QD era, and was set as the default in order to work around bug 246527), but I tried changing fonts, to no effect (in fact, no apparent font change happens at all).

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm, I can't reproduce this.. and both aljazeera and bbc arabic look fine, all with a clean profile.  Can you guys try with the latest nightly and a clean profile, to see if we can track down what the problem is?

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I spent a little time with this in Cm 2007011822 on 10.3.9, both with a fresh profile and without, though the profile seemed to be irrelevant....

So far, when I disable TITUS CyberBit and the FreeSerif/Mono/Sans, Arabic displays properly on Uri's testcase and on al-Jazeera.  This is sort-of expected, since those fonts have Arabic glyphs but aren't AAT fonts (and we're specifying Lucida Grande, which has no Arabic glyphs, as a default still from bug 246527 in the pre-Cairo era), and standard ATSUI font fallback can be random and won't know to exclude those fonts (see the issue with MS Office 2004 fonts, Safari, and disconnected Arabic glyphs), though it's sort-of unexpected in that the very same setup pre-Cairo fell back to a working Arabic font.

However, even (with those fonts disabled), I can't seem to get us to actually use Geeza Pro (no variation of Carbon/Cocoa/PostScript font names seems to work); it looks like maybe Al Bayan is being used instead.

Even worse, when I specify Baghdad or Asfhan (which have the same name all over, Baghdad/Asfhan), we won't use that--so when I specify Baghdad for all Arabic fonts and re-enable TITUS CyberBit and the Free*, I'm back to disconnected glyphs in TITUS CyberBit :(

It almost seems like we're ignoring any font prefs and just querying what fonts have Arabic glyphs and then selecting one at random(?) (TITUS CyberBit would be the last font alphabetically on my Mac to have Arabic glyphs, and Al Bayan the first...).

How BBC then works is also beyond me...it specifies "Decotype Naskh" in its CSS (note the font is "DecoType Naskh" on the Mac).  Moreover, no combination of the Cocoa/PostScript fonts names (the latter removes the space) and capital/lower "t" allows me to set DecoType Naskh as the default font and have other Arabic text displayed in the face :(

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: testcase with lang=ar

I've discovered a bit more: I can make Uri's testcase work, and honor font pref choices (even when TITUS et al. are active), when I set a "lang=ar" attribute on a relevant element.  Neither aljazeera nor the BBC seem to set any lang attributes in their HTML, which might explain why they break (except, as I mentioned before, BBC works fine as-is).

Maybe now we're only calling for Arabic fonts specifically when we there's an explicit lang reference to an Arabic script language (and otherwise just asking for a font that has those glyphs)?

Comment 11

[Isam Bayazidi]

I just downloaded the nightly build from Feb 1st:
Version 2007013122 (1.1a2+)

and the problem is fixed in it .. tested many sites in arabic (Araby is my first language) and it seems that it is fixed in the nightly build of Feb 1st. 

Comment 12

[Samuel Sidler (old account; do not CC)]

The nightly you downloaded is a branch nightly, not a trunk one. This bug only affects the trunk (in Camino, that's 1.2+).

Comment 13

[Mike Connor [:mconnor]]

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I thought that this might be fixed by the patch in bug 364786 (which fixes mac font fallback), but I get identical results even if I back that patch out -- the testcases look correct, as does aljazeera.  Can one of you guys who saw this patch a few months ago retest and see if it hasn't been fixed in the interim?

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Vlad, it does look like something fixed things here--*if* I remove/disable Fixedsys Excelsior (which is the font that has been recommended that we set as the default Ethiopic monospace font on the Mac in bug 299222 comment 7).  

I guess we can not recommend/set that font (my patch there is still awaiting review, so another change won't hurt :P  Maybe I should just fix bug 153296 there, too, since changing Arabic fonts seems to work now....), unless you want to figure out why fallback is erroneously selecting that font (when it's enabled, I'm seeing it used in all cases mentioned here, except the BBC).

Comment 16

[Simon Montagu :smontagu]

I'm not sure if it's the same bug as this, but I just noticed that installing the Code2000 font breaks the ordering of Devanagari short vowels. A good testcase for this is the main page of Hindi Wikipedia http://hi.wikipedia.org: "विकिपीडिया" ("Wikipedia") appears as text at the top of the page, in the page title, and as a graphic below the Wikipedia logo at the top left, and even for non-Devanagari readers the misrendering stands out.

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Both are non-AAT fonts, and both Arabic and Indic languages need AAT fonts for ligatures/glyph reordering on Mac OS X.

Does it break if you have DevanagariMT set as your Devanagari font?  If so, it is this bug (or the remaining issue in it, comment 15), because we're failing to use to the right font for some reason.  

(I don't see anything in hi.wikipedia.org specifying a specific font except for two minor places, so we should be using the font we specify in the prefs.)

Comment 18

[John Daggett (:jtd)]

Attachment: render text for all mac fonts

(In reply to comment #16)

Yes, I think these problems are definitely related.  In both cases, the Arabic / Devanagari text renders fine when a font containing the right tables for ATSUI is specified.  Not sure what the test is exactly, whether we test for specific Unicode ranges, then do the font substitution ourselves or what.

The attached test case shows the Arabic / Hindi text in the testcase for different fonts.  The Arabic text renders correctly with:

  Al Bayan
  Baghdad
  DecoType Naskh
  Geeza Pro
  KufiStandardGK
  Nadeem

The Devanagari renders correctly with:

  Devanagari MT

Note: not sure but some of these fonts may not be installed by default with 10.4.  I ran the "optional installs" from the 10.4 install CD to load additional fonts.

Comment 19

[John Daggett (:jtd)]

Attachment: Devanagari correct and incorrect screenshot

Comment 20

[John Daggett (:jtd)]

Added code to dump out the name of the substituted font.  In almost all cases, Arial is substituted for the text run containing the Arabic text.  All the fonts that render correctly, Al Bayan, Baghdad, etc., contain TrueType morph ('morx') tables.  Arial contains Arabic glyphs but no 'morx' table, same for 'Times New Roman'.  On systems without these fonts, the testcase renders fine.

For Devanagari, 'Ashkar Unicode' is substituted instead of 'Devanagari MT'.  The 'Ashkar Unicode' font has no 'morx' table.  On a system without this font, Devanagari MT is used and everything renders correctly.

As a side note, setting the default font for Devanagari to 'Devanagari MT' didn't work, the font fallback code added 'Times-Roman' to the fallback list.  I'll investigate more tomorrow and write up a new bug.

Comment 21

[John Daggett (:jtd)]

Argh, all.js in the prefs code is busted.  There's no entry for font.default.x-devanagari in the Mac OS X version, so instead of looking for 'font.name.serif.x-devanagari', the font fallback system looks for 'font.name..x-devanagari'.  The all.js badly needs a test to make sure everything is copcetic, something that would assure that if font.name.monospace.xxx exists, font.default.xxx also exists.

Comment 22

[John Daggett (:jtd)]

Wrote a simple test program to verify that ATSUI renders incorrectly when certain fonts are used, looks like older TrueType fonts that don't contain the right morphing information.  Arial is the most common example of this, it contains Arabic glyphs but no 'morx' table for handling contextual ligature information.

The puzzling aspect of this is that other font's don't appear to map to Arial, but when ATSUMatchFontsToText is used, they do.

Comment 23

[John Daggett (:jtd)]

Attachment: quick cocoa ATSUI test program source

Comment 24

[John Daggett (:jtd)]

Attachment: quick cocoa ATSUI test program image

Save as xxx.dmg to use

Comment 25

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #21)
> Argh, all.js in the prefs code is busted.  There's no entry for
> font.default.x-devanagari in the Mac OS X version, so instead of looking for
> 'font.name.serif.x-devanagari', the font fallback system looks for
> 'font.name..x-devanagari'.

John, when I finish the patch for bug 299222, should I include font.name.default pref sets for languages that Mozilla supports but which no suitable (AAT) Mac font currently exists, in order to help work around the prefs code bug?  (My current patch is doing that even while not setting the prefs for the fonts themselves.)

Is there anything else I should do in the patch to help mitigate problems like this in the future when we go to add new fonts once AAT ones become available?

(And am I correct in presuming that the goal of *this* bug now is to prevent non-AAT fonts from being used to render langGroups which require AAT fonts on the Mac?)

Comment 26

[John Daggett (:jtd)]

Attachment: quick cocoa ATSUI test program source, v0.2

add in code to show for list of fonts, run through the match fonts algorithm

Comment 27

[John Daggett (:jtd)]

Attachment: quick cocoa ATSUI test program, app and project files

Comment 28

[John Daggett (:jtd)]

The attached test app shows that ATSUI clearly has problems rendering various scripts correctly depending upon the script, even if the user has fonts on his system that allow text runs in a given script to be rendered correctly.  Problem fonts are those that contain glyphs for a given script but lack the proper information in 'mort' or 'morx' tables to handle rendering contextual forms.  Webkit makes the assumption that fonts that include one of these tables can handle Arabic but this is incorrect, there are several Chinese fonts shipped with 10.4 that contain Arabic glyphs and 'morx' tables but don't render Arabic correctly.  So that's not really the perfect solution.

One thing that still puzzles me is that ATSUMatchFontsToText substitutes different fonts for the *exact* same text when used in my test app vs. in FF3 trunk.  I'm guessing this means that the particular font chosen is a function of the order in which some sort of internal font list is initialized.   So if some random font is chosen for a text run that includes Arabic or Devanagari, there's always a chance a problematic font will be chosen as a substitute font by ATSUI.

I think the best solution is to add a "default fallback" font into the list of fallback fonts for given scripts that are known to work.

Existing fallback, done per-script:

  [style-specified font]
  [user-chosen script fallback font]
  [user-chosen unicode fallback font]
  [font chosen via ATSUMatchFontsToText]

Proposed fallback mechanism, done per-script:

  [style-specified font]
  [user-chosen script fallback font]
  [*** default fallback font ***]
  [user-chosen unicode fallback font]
  [font chosen via ATSUMatchFontsToText]

The user could still cause themselves problems if they happened to choose a fallback font that was a "bad" font for a given script (e.g. ArialMT for Arabic) but I think that's much, much less likely to occur than the general case of font fallback from a random font causing a bad font to be substituted because of the way ATSUMatchFontsToText does its lookup.

Comment 29

[John Daggett (:jtd)]

(In reply to comment #25)

Smokey, if you could update 299222 with your latest version that would be great, even if it's a work-in-progress.  I think having 'font.name.default.xxx' is probably the best way to go but I haven't tested it yet.  The jist of my testing is that there's no good way to verify that a font is suitable and beyond that it's tricky getting ATSUI to avoid specific fonts as part of it's font substitution algorithm.

We probably need this mechanism if for also avoiding specific fonts with bugs, like Ayuthaya under 10.5 right now (see bug 392209).

Comment 30

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'm pretty sure that we already put in default fallback fonts after the user-specified ones, no?  If not, we probably should, though Stuart should chime in here.

Comment 31

[John Daggett (:jtd)]

Attachment: Arial forms have the same problem in 10.5, build 9A527

Comment 32

[John Daggett (:jtd)]

Attachment: Times New Roman under 10.5 9A527 using test app

Comment 33

[John Daggett (:jtd)]

The user specifed default font for a script is stored in font.name.xxx.yyy where xxx is serif, sans-serif, etc. and yyy is the script code (e.g. ar, x-devanagari).  A system default is specified in font.name-list.xxx.yyy:

font.name.default = "serif"
font.name.serif.ar = "Al Bayan"
font.name-list.serif.ar = "Al Bayan"

As long as we specify these, ATSUMatchFontsToText won't use "bad" fonts like ArialMT for Arabic.  So once changes for bug 299222 have been implemented, this should be fixed for the most part.  Only when the style is explicitly set to a "bad font" will the problem occur.

Comment 34

[John Daggett (:jtd)]

Attachment: debug code for dumping out ATSUI font matching info

This is debug code that dumps out the characters in text runs along with the specific fonts matched within each run.

Comment 35

[John Daggett (:jtd)]

With fix for 299222, this will only occur when the style for a text run contains Arial, Times New Roman, or any of the other newer Microsoft / Monotype fonts that contain glyphs for Arabic but do not contain a morphing table (morx).  We can work around this problem, but for now I've filed a bug with Apple and will wait a bit to see what happens with that.

Comment 36

[John Daggett (:jtd)]

Mail to Apple regarding problems with ATSUMatchFontsToText matching OpenType fonts with Arabic glyphs:

As for the Arabic issue, I'm not sure 5481396 is just a duplicate of 3855571, the problem is more related to ATSUMatchFontsToText.  If ATSUI can't render OpenType fonts with Arabic glyphs, that's fine, but in that case ATSUMatchFontsToText shouldn't match fonts like Arial for Arabic text, that's really the crux of our problem.  For Arabic text, it's not just whether the cmap table contains a mapping for a character but also whether the font has a morphing table, right?  This is actually a larger issue than it appears, fonts like Arial and Times New Roman are a big pain on the web, authors specify them in stylesheets without ever considering weird side effects like this.  On 10.4, users that install Microsoft Office will experience this problem as Office includes versions of fonts like Arial and Times New Roman that contain glyphs for Arabic but no morphing tables.  Depending upon the order of font lookup that ATSUMatchFontsToText uses (order in the font cache?), ATSUI apps will suddenly stop displaying Arabic correctly because ATSUMatchFontsToText is finding Arial before other fonts.  So I would say that (1) ATSUMatchFontsToText should pick a substitute font when and OpenType font like Arial is specified for Arabic text and (2) never substitute an OpenType font for other fonts that don't contain Arabic glyphs.

WebKit is actually doing some fancy footwork to avoid this problem, after matching the font they look for a morphing table and run through their own shaping algorithm if it doesn't.

Font matching loop:
http://trac.webkit.org/projects/webkit/browser/branches/feature-branch/WebCore/platform/mac/FontMac.mm#L412

Morphing table check:
http://trac.webkit.org/projects/webkit/browser/branches/feature-branch/WebCore/platform/mac/FontDataMac.mm#L297

Comment 37

[John Daggett (:jtd)]

Response from Apple:

Ah, yes.  We thought about the font fallbacks issue and OT shaping  
(or lack of) and have a solution for Leopard.

Comment 38

[Simon Montagu :smontagu]

(In reply to comment #36)
> WebKit is actually doing some fancy footwork to avoid this problem, after
> matching the font they look for a morphing table and run through their own
> shaping algorithm if it doesn't.

We could probably do that too if we wanted to: we have our own shaping algorithm which we used to use on platforms like Win9x and Linux-without-Pango: ArabicShaping() in intl/unicharutil/util/nsBidiUtils.cpp. Under thebes it's unused, and I was planning to remove the code but haven't done so yet.

Comment 39

[John Daggett (:jtd)]

With the latest 10.5 seed (9A559, 24 Sept 2007), ATSUMatchFontsToText no longer matches against Arial, Times New Roman, etc.  So this problem will not occur under 10.5 but will still occur for 10.4.

Comment 40

[John Daggett (:jtd)]

Attempt to handle remaining issues with Arabic matching against OpenType fonts containing Arabic glyphs (e.g. recent versions of Arial) as part of porting Windows font selection code to Mac, bug 396137.

Comment 41

[John Daggett (:jtd)]

Once bug 396137, the port of cmap font matching code, is checked in fix this by checking within the Mac ReadCMAP code for Arabic support and disabling it for fonts lacking AAT mort/morx tables.  Test against Arial, Times New Roman and weird Chinese fonts that shipped with 10.4.

Comment 42

[John Daggett (:jtd)]

Attachment: testcase for fonts with Arabic, Devanagari, Thai glyphs

Testcase with specific fonts specified.  Problems for specific fonts when rendering with latest trunk:

Arial - arabic not joined
Arial (bold) - arabic not joined (but Arial (italic) ok)
Code2000 - arabic not joined, devanagari order incorrect
DejaVu Sans - arabic not joined
ST* fonts - arabic not joined
Akshar Unicode - devanagari order incorrect
Times New Roman - arabic not joined
Times New Roman (bold) - arabic not joined (but Times New Roman (italic) ok)

Comment 43

[John Daggett (:jtd)]

Attachment: patch, clear cmap for fonts lacking support for complex scripts

When reading in the cmap table, explicitly check to see if a font reports to support either Arabic or Devanagari.  If it does, then verify that it has a mort/morx table which is needed by ATSUI to do shaping and reordering of complex scripts.  If the font lacks one of these tables, clear the codepoints for Arabic/Devanagari from the cmap.

The one hack is that the Chinese fonts STSong, STXihei, etc. that ship with 10.4 contain a morx table but lack one without shaping information for Arabic.  Explicitly exclude these, yech.

Comment 44

[Simon Montagu :smontagu]

Comment on attachment 298887 [details] [diff] [review]
patch, clear cmap for fonts lacking support for complex scripts

Why only Arabic and Devanagari? I would think we need to do the same for at least all the other Indic scripts.

Comment 45

[John Daggett (:jtd)]

(In reply to comment #44)
> (From update of attachment 298887 [details] [diff] [review])
> Why only Arabic and Devanagari? I would think we need to do the same for at
> least all the other Indic scripts.

Yes, most likely, but there are AAT fonts for Devanagari that ship with Mac OS X.  I'll confirm this, but I'm not really sure of other Indic scripts for which AAT fonts are available.  Apple is shifting to OpenType so I doubt an extension of support will occur.  Once we support CoreText (10.5 only!), which includes support for OpenType Layout, we should be able to eliminate this workaround, at least for 10.5 users.

Comment 46

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Any Indic script for which we set a default font on the Mac has AAT fonts: 

Bengali
Devanagari
Gujarati
Gurmukhi
Tamil

Of these, all the fonts are shipped with the OS except for the Bengali ones, which are free third-party AAT fonts :)  There are also third-party AAT fonts for Malayalam and Khmer, but these are for-purchase only (http://xenotypetech.com), so we didn't set them as defaults.  (In addition, there are free third-party AAT fonts for Telugu and Kannada from http://web.nickshanks.com, but Mozilla does not declare langGroups for those scripts.)

Comment 47

[John Daggett (:jtd)]

Comment on attachment 298887 [details] [diff] [review]
patch, clear cmap for fonts lacking support for complex scripts

I'm going to rework this patch to check for a set of languages in addition to Arabic and Devanagari.  Rather than test a single character (cheap hack!), I'll set up a method of gfxSparseBitmap to test a range.

Comment 48

[John Daggett (:jtd)]

Attachment: patch, v.0.2, iterate through series of ranges (in progress)

Iterate over a set of complex script ranges and check for morphing tables if needed.

Comment 49

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I noticed today while looking at something else that aljazeera and bbc are again displaying as isolated glyphs for me on the trunk.  

Ignoring any possible fallout from the font-name-matching changes in the last week or so, I've done two things locally since I've last looked at this, I think: re-enabled all the Windows Arabic TTFs that TextEdit could handle, and upgraded to 10.5.1.  I suspect the former is the problem, since TextEdit is using CoreText now, but I wanted to mention it here before I forgot.  

I'll try disabling them all again, and try John's latest patch, and do some other testing this weekend; hopefully either solution will solve this.

Comment 50

[John Daggett (:jtd)]

(In reply to comment #49)
> I noticed today while looking at something else that aljazeera and bbc are
> again displaying as isolated glyphs for me on the trunk.  
> 
> Ignoring any possible fallout from the font-name-matching changes in the last
> week or so, I've done two things locally since I've last looked at this, I
> think: re-enabled all the Windows Arabic TTFs that TextEdit could handle, and
> upgraded to 10.5.1.  I suspect the former is the problem, since TextEdit is
> using CoreText now, but I wanted to mention it here before I forgot.  

Most likely you've added in a version of Arial that supports Arabic, that's the most common cause of this, you'll only see this problem for pages that explicitly specify a font like Arial or Times New Roman that has Arabic glyphs but not the mort/morx tables needed by ATSUI to render correctly.  I haven't tested this, but the Apple folks claim that OpenType layout tables are fully supported by CoreText, that's probably why TextEdit seems to render everything just fine.

I need to do some more testing with OpenType fonts for Indic languages and Thai/Lao but the patch for this should be checked in sometime this week after the B3 branch is created and the tree is open again for non-B3 blockers.  If you want to test with your own build, use the initial patch as the v.0.2 patch is still in progress, I haven't tested it yet.

Comment 51

[John Daggett (:jtd)]

Tested the existing code with a bunch of Thai OpenType fonts from the Thai Linux WG, most of them display fine, although some of the vowel marks don't render perfectly.  I'd rather not exclude OT fonts for Thai unless they render in a completely unreadable form, which is not the case.

Thai Linux WG fonts:

ftp://linux.thai.net/pub/thailinux/software/thai-ttf/

More Thai fonts:

http://www.wazu.jp/gallery/Fonts_Thai.html

Comment 52

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #50)
> (In reply to comment #49)
> > I noticed today while looking at something else that aljazeera and bbc are
> > again displaying as isolated glyphs for me on the trunk.  
> > 
> Most likely you've added in a version of Arial that supports Arabic, that's the
> most common cause of this, you'll only see this problem for pages that
> explicitly specify a font like Arial or Times New Roman that has Arabic glyphs
> but not the mort/morx tables needed by ATSUI to render correctly.  I haven't

No, it was an old copy of the Windows Traditional Arabic I had running around for some reason.  CoreText doesn't work with the font, so I have no idea why it was enabled at all, but it was.  

Had a busy weekend and didn't get to try your patch, but when I do get the time, I'll test whatever's the latest version with at least that problematic Traditional Arabic :-)

Comment 53

[John Daggett (:jtd)]

Attachment: patch, v.0.9, iterate over ranges for complex scripts looking for morphing table

Within MacOSFontEntry::ReadCMAP, iterate over Unicode ranges for Arabic, Indic scripts and Tibetan and to make sure the font has an AAT mort/morx table which is required to render these scripts via ATSUI.  If not, clear out that range from the cmap.  The implementation of gfxSparseBitSet has been extended to support testing and clearing ranges.  TestRange is optimized for the negative case, where the bitset does not contain the range.

Tested under both 10.4 and 10.5 with both AAT and OpenType fonts for Arabic, Devanagari, Bengali, Tibetan, and Thai.  I specifically excluded Thai as OpenType Thai fonts seem to render relatively well, although some vowel combinations seem to overlap a bit the result is basically readable so I'd prefer we don't disable these fonts.

Comment 54

[John Daggett (:jtd)]

(In reply to comment #52)
> No, it was an old copy of the Windows Traditional Arabic I had running around
> for some reason.  CoreText doesn't work with the font, so I have no idea why it
> was enabled at all, but it was.  

I'm curious why this occurred, the font matching code should hit the pref fonts first, before looking through system fonts.  So as long as you have the pref fonts enabled, the system fonts should never be checked.  Unless the page *explicitly* references the name of your font.

Comment 55

[Simon Montagu :smontagu]

Can you attach a screenshot of Thai in an OpenType font? I'm afraid I won't be able to review this properly before I get back home, but I'll try to get to it before the end of the week.

Comment 56

[John Daggett (:jtd)]

Attachment: screenshot, thai rendering with ATSUI, both AAT and OT fonts

This shows the rendering for Thai AAT fonts that ship with Mac OS X (Ayuthaya - Silom) and for OT fonts from the Thai Linux WG (Garuda - Norasi).  The placement of the vowel above the fourth character doesn't seem ideal for the OT fonts, it overlaps the rest of the character unlike the AAT fonts but still, it's basically readable.  I don't think it's reasonable to disqualify Thai OT fonts because they lack an AAT morphing table.

Keep in mind also that the concern here is mostly about fonts that are commonly specified in stylesheets, like Arial.  As long as preference fonts cover all characters for a given language, other fonts for that language will never get picked up unless they are explicitly included in a style.  So in general we don't need to worry about hiding bad fonts so much as we need to prefer "good" fonts, which is where the pref settings help immensely.

Comment 57

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #54)

> I'm curious why this occurred, the font matching code should hit the pref fonts
> first, before looking through system fonts.  So as long as you have the pref
> fonts enabled, the system fonts should never be checked.  Unless the page
> *explicitly* references the name of your font.

That's exactly what's happening for the BBC and al-Jazeera.  It's fairly common for Arabic sites to specify Arabic Transparent, Traditional Arabic, Simplified Arabic, Arial and Tahoma for their stylesheet fonts.

The BBC does call "Decotype Naskh" 10 fonts down the line (which matches "DecoType Naskh" on Mac OS X), but that seems to be more of an accident than thinking of Mac fonts ;)

Comment 58

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Patch v0.9 does fix the unconnected glyphs/bad font selection problems with BBC/al-Jazeera and Traditional Arabic enabled :)

Comment 59

[John Daggett (:jtd)]

checked in

Comment 60

[sam]

Thanks John for your help, I have the same problem with arabic text, I'm using the latest firefox 2.0.0.13 en-us on a windows xp sp2 msi laptop, I suspect the problem was from office xp which was crashing frequently so I uninstalled office and its language pack. I still have the problem and I read through this thread and downloaded the last patch you posted (0.9) but how to apply/install it?

Comment 61

[Peter Weilbacher]

sam, the problem in this bug is about an issue in the Firefox development version that is specific to MacOSX. It has nothing to do with any problem you might be seeing with Firefox 2.0.0.x on Windows. I suggest you ask for help in one of the support groups listed on <http://www.mozilla.org/support/#newsgroups> or one of the forums linked from <http://support.mozilla.com/>.