Closed Bug 254585 Opened 20 years ago Closed 16 years ago

can't recognize the repertoire of Windows TTFs without Mac (PID=1) cmaps

Categories

(Core Graveyard :: GFX: Mac, defect)

Product:
Core Graveyard
Component:
GFX: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jshin1987, Unassigned)

References

Details

(Keywords: intl) 

Gfx;Mac incorrectly recognizes the character repertoire covered by Windows
truetype fonts without Mac (PID=1) cmaps. For instance, Gfx:Mac fails to
recognize that Un fonts (Korean truetype fonts) covers characters in Mac Korean
because UnFonts don't have Mac Korean cmap while it has MS Unicode cmap.

See bug 120401 comment #64 and bug 1020401 comment #66.
I'm not sure you define it well. When the font contains the needed characters in
the unicode CMAP, there is no problem (meaning: it takes it from that CMAP), at
least that's what i got from your comment...

In other words: fonts like Arial (form windows) work fine (for me).
All those Korean fonts I tried have well-defined MS Unicode cmap (PID=3, EID=1)
clearly indicating that they cover 2350 syllables in Mac Korean as well as 
8,822 syllables not covered by Mac Korean but Mac:Gfx fails to recognize that
they cover 2350 syllables in Mac Korean. 

> When the font contains the needed characters in
> the unicode CMAP, there is no problem (meaning: it takes it from that CMAP), at
> least that's what i got from your comment...

  When did I say that? 

(In reply to comment #1)

> In other words: fonts like Arial (form windows) work fine (for me).

  That doesn't prove anything. Arial works because it does have Apple Unicode
cmap as well as Mac Roman and MS Unicode cmap. 



maybe i didn't understand.

anyway i'm quting myself here (from my last comment in bug 120401), maybe that's
what we need to do:

"We also know this is becuase of the quickdraw converter, maybe the problem is
relevant for complex scripts only, we already disable the converter for Hebrew
and Arabic, maybe we need to do the same for other scripts as well."
(In reply to comment #3)

>   That doesn't prove anything. Arial works because it does have Apple Unicode
> cmap as well as Mac Roman and MS Unicode cmap. 

are you sure? i'm talking about windows Arial.

> We also know this is becuase of the unicode (==> quickdraw) converter, maybe
the problem is
> relevant for complex scripts only, 

It's not specific to complex scripts. It's generic as I wrote in comment #0.
Quickdraw string drawing APIs don't work properly unless there's a Mac XXX
(where XXX is Roman, Korean, Japanese, SC, TC, Cyrillic, etc) Cmap (or probably
Mac Unicode cmap). On the other hand, ATSUI string drawing APIs work well
*without* Mac XXX Cmaps.  

> we already disable the converter for Hebrew
> and Arabic, maybe we need to do the same for other scripts as well."

  That's what we did in the patch for bug 120401 that was backed out later,
isn't it? Ok. We did it for all the scripts and I guess you're suggesting that
we should do it only for 'some' scripts. That doesn't solve this bug although it
kinda works around the issue in _some_ cases. 

  Perhaps, we have to resort to look 'into' fonts to figure out whether a Mac
XXX cmap is present and skip quickdraw APIs if one is not found. 

  In the meantime, we'd better release note that Windows truetype fonts without
Apple/Mac Cmaps don't work properly. 

  'The' ultimate solution would be to fix bug 121540 so that we let Quickdraw
APIs 'rest in peace' :-)
(In reply to comment #5)
> (In reply to comment #3)
> 
> >   That doesn't prove anything. Arial works because it does have Apple Unicode
> > cmap as well as Mac Roman and MS Unicode cmap. 
> 
> are you sure? i'm talking about windows Arial.

I'm 110% sure (at least my copy of Arial does have Mac Unicode, Mac Roman and
Windows Unicode cmaps).  If in doubt, why don't you test it yourself? 


> I'm 110% sure (at least my copy of Arial does have Mac Unicode, Mac Roman and
> Windows Unicode cmaps).  If in doubt, why don't you test it yourself? 
> 
I wasn't sure because Mac OS X has its own version of Arial, this is not the
same font.

(I can't test it by myself, because i'm no near my mac at the moment).

we need to create a static bool HasAppleCMAP(font number) function and check for
it before returning the converter.
*** Bug 255319 has been marked as a duplicate of this bug. ***
Blocks: 275951
Assignee: sfraser_bugs → joshmoz
QA Contact: mac
Hello. Jungshik Shin.

I found out that I was added to this bug list. Probably this one is related to
one of my previous bug report.
May I test if it occurs on my Mac?
Where can I get the Windows Un fonts? It is usually a Unix font.

BTW, as far as I know, the Windows Arial font is the Mac Helvetica
font.(Typography-wise, not the format or whatever-wise. )

(In reply to comment #11)

> May I test if it occurs on my Mac?
> Where can I get the Windows Un fonts? It is usually a Unix font.

They're just TTFs and can be used whereever TTFs are supported, Windows,
Linux/Unix or Mac OS X.
 
> BTW, as far as I know, the Windows Arial font is the Mac Helvetica
> font.(Typography-wise, not the format or whatever-wise. )

Yup, it's well-known that MS didn't want to pay to Adobe for Helvetica so that
they commissioned Monotype to come up with a similar-looking Arial. The same is
true of Times vs Times Roman. However, that's not relevant here.
 


> > BTW, as far as I know, the Windows Arial font is the Mac Helvetica
> > font.(Typography-wise, not the format or whatever-wise. )
> 
> Yup, it's well-known that MS didn't want to pay to Adobe for Helvetica so that
> they commissioned Monotype to come up with a similar-looking Arial. The same is
> true of Times vs Times Roman. However, that's not relevant here.

So, did you use the Helvetica, or MS Arial font provided by the MS Office for Mac?
( or whatever.. )

OK. I tried installing Unfonts.
You can download the unfonts at http://travelphrases.info/gallery/Fonts_Korean.html.

If I remember it correctly, the Un fonts worked before. Oh.. Now I remember this.
I reported this bug before. After some time, the fonts started not to work.
Am I right?

It doesn't work still.
Things are displayed as rectangluar garbage characters.
Because they are Unicode fonts, I tried UTF-8. However, for just being sure, I
also tested them with EUC-KR.

If someone has a Windows TTF font to a Mac TTF font converter, then we may be
able to test if the omitted Mac cmap causes the problem surely.
However according to Mr. Shin's report, he seemed to test it already.
Blocks: 313037
I'm considering MLTE adaptation and posted a patch at bug 121540. The patch is a fairy simple trial sort of thing, but it looks to me that the Un fonts are working with it. If you guys have time please examine it.

*** Bug 317037 has been marked as a duplicate of this bug. ***
Assignee: joshmoz → nobody
Is this bug still relevant to the current codebase?
No, we use either Mac or Windows style Unicode cmaps.  So Windows TTF fonts will work just fine as long as some form of Unicode cmaps exists.
How do we want to resolve bugs in Widget:Mac and Gfx:Mac bugs that don't {still|also} exist in Widget:Cocoa or Gfx:Thebes?  

I actually started going through my lists of some of these bugs a while ago, and while I moved some bugs that still existed (or were misfiled to begin with!) into Cocoa/Thebes, I wasn't sure how we planned on resolving ones that were still valid bugs for Gecko 1.8.1 but which no longer mattered in 1.9 and up.  WONTFIX?  WFM?
I think that if they're critical bugs on 1.8.1, they should be nominated for blocking1.8.1.next so we can triage them and get them fixed (for Thunderbird and distros). If not, they should be resolved as WONTFIX after their version has been set to 1.8 branch.

(This bug, for example, says trunk.)
This is old behavior, Thebes code uses Unicode cmaps exclusively.  If someone feels this needs to be fixed on the 1.8 branch, please reopen.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Version: Trunk → 1.8 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.