Closed Bug 119327 Opened 23 years ago Closed 4 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: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.