as described in bug 45678, gfx depends on locale for one minor font-correction issue. We need to figure out a cleaner way of fixing this problem.

There are many places where the language group is used to improve font display. If the page indicates a language group (often via charset encoding) then the font code uses it. If no language group can be determined from the page then the font code falls back to the user's locale. Thus it is important for the font code to have access to the locale. Consider displaying a Unicode page. What language group should the code look at for glyphs in the Han Unification area? Simplified Chinese Traditional Chinese Japanese Korean cHoOsInG tHe WrOnG fOnT pRoDuCeS uGlY rEsUlTs. iT iS ReAdAbLe JuSt As ThIs Is BuT wE dO gEt CoMpLaInTs FrOm uSeRs. Falling back to the user's locale does not produce perfect results but it does increase our odds of producing pleasing display. The gfx font code will continue to need access to the locale. Perhaps you could restate you goal in a way that would not harm the font code.

oh! I definitely don't think we should break anything! :) We just need to provide a way for gfx to get font hints or something without relying on the locale

Changed QA contact to ylong@netscape.com for now.

assigning to bstell

There probably should be a service for finding out the current local instead of sticking it in the device context. The device context is a convenient place but it's not the right place for storing this info.

Jon: I do not have enough context to understand your comment. Could you show a snippet of code?

After looking at the gfx code more this is similar to the ImageContainer problem. ImageConatiner code was added to gfx to extract a snapshot of the Image from the container. This made gfx aware of the internals of how ImageContainer was implemented which was not a good thing. Old way DrawImage(container, ...) New way DrawImage(container->getSnapshot(), ...) Now gfx does not need to know the internals of ImageContainer. The same logic applies to locale. gfx should not know the internals for the determining the local. I would remove this call which does not specify the langGroup NS_IMETHODIMP DeviceContextImpl::GetMetricsFor(const nsFont& aFont, nsIFontMetrics*& aMetrics) Change this call to: NS_IMETHODIMP DeviceContextImpl::GetMetricsFor(const nsFont& aFont, nsIAtom* aLangGroup, nsIFontMetrics*& aMetrics) { ASSERT(aLangGroup != NULL); if (nsnull == mFontCache) { nsresult rv = CreateFontCache(); if (NS_FAILED(rv)) { aMetrics = nsnull; return rv; } } return mFontCache->GetMetricsFor(aFont, aLangGroup, aMetrics); } Remove this function: GetLocaleLangGroup and the instance variable mLocaleLangGroup Then go fix the places in the source that call this code. Similar to the ImageContainer example. The complaint is not about using the Locale to help with font selection, instead the complaint is that gfx is not the right place for the code that determines it. The comment about the service was from looking at this code: void DeviceContextImpl::GetLocaleLangGroup(void) { if (!mLocaleLangGroup) { nsCOMPtr<nsILanguageAtomService> langService; langService = do_GetService(NS_LANGUAGEATOMSERVICE_CONTRACTID); if (langService) { langService->GetLocaleLanguageGroup(getter_AddRefs(mLocaleLangGroup)); } if (!mLocaleLangGroup) { mLocaleLangGroup = getter_AddRefs(NS_NewAtom("x-western")); } } } which is already a service, but it seems to need a fix up at the end for the western case. Is there no languageAtomService for western builds?

Even in Unicode (UTF-8) document, there are cases where derivation of 'langgroup' from the locale is not desirable or has to be overriden. That is, when langgroup is explicitely specified via 'lang' attribute in html documents, the value obtained from the attribute should be used instead of the one derived from the locale. Related to this are bug 105199, bug 102623, bug 102940, bug 94327, bug 91190, bug 62756.

--> ftang

bulk move NEW FUTURE bug to ASSIGN

-> to default owner (rather than ftang's WONTFIX)

I'm not sure that I agree with this bug as filed. There are probably call sites in widget- or xul-land that don't have any langGroup information to pass to gfx. On the other hand, if there are callers that could be passing a langGroup but aren't, it might explain some of the bugs we have about text being measured and rendered with different metrics. (In reply to comment #5) > There probably should be a service for finding out the current local instead of > sticking it in the device context. The device context is a convenient place but > it's not the right place for storing this info. It would probably be more appropriately named mFallbackLangGroup.