Use FMGetFontFamilyTextEncoding instead of FontToScript in

RESOLVED WONTFIX

Status

()

Core
Internationalization
P3
normal
RESOLVED WONTFIX
16 years ago
3 years ago

People

(Reporter: Frank Tang, Assigned: nhottanscp)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
in EnumerateFont  ( gfx/src/mac/nsDeviceContextMac.cpp ), we use FontToScript to
decide the lang group of a font. According to 
http://developer.apple.com/techpubs/macosx/Carbon/text/FontManager/Font_Manager/Functions/Accessing_Fo_mily_Objects.html#//apple_ref/C/func/FMGetFontFamilyTextEncoding
we should use FMGetFontFamilyTextEncoding  instead to decide a font. 

OSStatus FMGetFontFamilyTextEncoding (
    FMFontFamily inFontFamily, 
    TextEncoding oTextEncoding
);
This function is a replacement for the Script Manager function FontToScript. You
should use the function FMGetFontFamilyTextEncoding instead of the function
FontToScript to assure your application supports font formats other than the
resource fork TrueType and PostScript Type 1 fonts. Unlike the FontToScript 
function, the state of the font force flag is ignored and the script system of
the font family is not mapped to the zero even if it is disabled in the current
application process.

Once you have obtained the text encoding, you can use Text Encoding Converter
Manager function RevertTextEncodingToScriptInfo to extract the script as follows:

status = FMGetFontFamilyTextEncoding (myFontFamily, &myTextEncoding);

status = RevertTextEncodingToScriptInfo (myTextEncoding,

&myScriptCode);


Notice that in  nsDeviceContextMac :: InitFontInfoList() , the classic build said 

short fondID;
...
 gFontInfoList->Put(&key, (void*)fondID);
and later on in 
932 bool nsDeviceContextMac :: GetMacFontNumber(const nsString& aFontName, short
&aFontNum)
933 {
934 //┬ąTODO?: Maybe we shouldn't call that function so often. If nsFont could
store the
935 //        fontNum, nsFontMetricsMac::SetFont() wouldn't need to call this at
all.
936 InitFontInfoList();
937 FontNameKey key(aFontName);
938 aFontNum = (short)gFontInfoList->Get(&key);
939 return (aFontNum != 0) && (kFontIDSymbol != aFontNum);
940 }

1141 EnumerateFont(nsHashKey *aKey, void *aData, void* closure)
1142 1143 {
1144 EnumerateFontInfo* info = (EnumerateFontInfo*) closure;
1145 PRUnichar** array = info->mArray;
1146 int j = info->mCount;
1147 1148 short fondID = (short) aData;
1149 ScriptCode script = ::FontToScript(fondID);

Both place cast the value of the gFontInfoList hash to a FontID, but since in
the carbon build nsDeviceContextMac :: InitFontInfoList():

 FMFontFamily fontFamily;
...
gFontInfoList->Put(&key, (void*)fontFamily);

we should cast them to a FMFontFamily in these two places and do proper processing.
(Reporter)

Updated

16 years ago
Summary: Use FMGetFontFamilyTextEncoding instead of FontToScript in → Use FMGetFontFamilyTextEncoding instead of FontToScript in
Whiteboard: MacOS X
(Reporter)

Comment 1

16 years ago
assign this bug
Status: NEW → ASSIGNED
(Reporter)

Comment 2

16 years ago
It's not too bad
typedef SInt16                          FMFontFamily;

so we probably dont' need to change the data type from Short to FMFontFamily now.
(Reporter)

Comment 3

16 years ago
The following places is already outside TARGET_CARBON, so we don't need to worry 
about:

/gfx/src/mac/nsDeviceContextMac.cpp, line 887 -- ScriptCode script = 
::FontToScript(fondID);

We need to take care the following:

/gfx/src/mac/nsDeviceContextMac.cpp, line 1149 -- ScriptCode script = 
::FontToScript(fondID);
/gfx/src/mac/nsUnicodeFontMappingMac.cpp, line 117 -- ScriptCode script = 
::FontToScript(fontNum);
/gfx/src/mac/nsUnicodeMappingUtil.cpp, line 326 -- ((script < smUninterp) && 
(::FontToScript(fontID) != script)))
/gfx/src/mac/nsUnicodeRenderingToolkit.cpp, line 836 -- ScriptCode script = 
::FontToScript(fontNum);
974     ScriptCode script = ::FontToScript(fontNum);
(Reporter)

Comment 4

16 years ago
mark it m94
Target Milestone: --- → mozilla0.9.4

Comment 5

16 years ago
Is the 0.9.4 milestone realistic?  We are branching on Friday.
(Reporter)

Comment 6

16 years ago
move to m0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Reporter)

Updated

16 years ago
Priority: -- → P3
(Reporter)

Comment 7

16 years ago
move to m0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Reporter)

Updated

16 years ago
Blocks: 103669
(Reporter)

Comment 8

16 years ago
move to m97
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

16 years ago
Keywords: intl
QA Contact: andreasb → ylong
(Assignee)

Comment 9

16 years ago
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Reporter)

Comment 10

16 years ago
mass move unimportant m9.8 bug to m9.9 for now. 
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Reporter)

Comment 11

16 years ago
give this to nhotta and remove target
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → ---
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.2alpha → ---

Updated

13 years ago
Blocks: 120401
1. FMGetFontFamilyTextEncoding is broken on Mac OS X (eg. returns smKorean for
windows Arial)
2. Scripts or "font encodings" are no longer exists (again: OS X).

As a result of (2), we started to remove FontToScript and
FMGetFontFamilyTextEncoding calls (see bug 120401).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: intl
Resolution: --- → WONTFIX
Whiteboard: MacOS X
You need to log in before you can comment on or make changes to this bug.