Closed Bug 119327 Opened 23 years ago Closed 3 years ago

Need to distinguish when the substitute font is local or global

Categories

(Core :: Internationalization, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: rbs, Assigned: rbs)

Details

(Keywords: intl)

Currently, the substitute font is always loaded by name. But as previous bugs 
have shown, just using the name for the global font can lead to troubles due to 
the fact that the charset is ignored. With my recent changes from bug 118617,
it is trivial to make the substitute font know where the font comes from. 
Specifically,

LoadSubstituteFont(HDC aDC, nsString* aName)
{
  LOGFONT logFont;
  HFONT hfont = CreateFontHandle(aDC, aName, &logFont);
  [...]
}

can be changed to:

LoadSubstituteFont(HDC aDC, nsString* aName, nsGlobalFont* aGlobalFont)
{
  LOGFONT logFont;
  HFONT hfont = CreateFontHandle(aDC, aName ? aName : aGlobalFont, &logFont);
  [...]
}

This way, if the font comes from the local list, the caller passes a null global 
font when calling LoadSubstituteFont(), if instead it comes from the global 
list, a null name is passed.

I am not planning to do anything about this for now. So feel free to consider 
this if you happen to pass by that code at some point. Not urgent, this bug 
hasn't bitten anybody AKAIK.
QA Contact: ruixu → ylong
Keywords: intl
Marking another little point so as not to forget:
        PRUint16* ccmap = GetCCMAP(aDC, logFont.lfFaceName, &fontType, nsnull);
-       if (ccmap) {
+       if (ccmap && ccmap != gEmptyCCmap) {
          ...
        }

GetCCMAP() oten returns the empty map, and there is no point doing anything once 
that map is returned.
QA Contact: amyy → i18n
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.