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)
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.
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.
Updated•15 years ago
|
QA Contact: amyy → i18n
Updated•3 years ago
|
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.
Description
•