Closed Bug 202921 Opened 21 years ago Closed 17 years ago

font.name-list (fontset) support on Gfx:GTK/Xlib

Categories

(Core :: Layout: Text and Fonts, defect)

defect
Not set
major

Tracking

()

RESOLVED WONTFIX
mozilla1.7alpha

People

(Reporter: roland.mainz, Assigned: jshin1987)

References

Details

(Keywords: intl)

Attachments

(1 file, 1 obsolete file)

[Spin-off of bug 202009 ("Some Japanese characters in UTF-8 document display as
?")]
The default font prefs in aix.js do not work for non-AIX clients on AIX Xserver.
X11 fonts are defined by the (X-)server side but aix.js defines the defaults on
the client side.
This works as long both X client(=Mozilla/Phoenix/GRE/etc.) and Xserver are
running on AIX - but this fails horribly when the client runs (for example) on
Solaris but displays itself on an AIX Xserver...
Depends on: 202009
Status: NEW → ASSIGNED
The prototype patch uses an enumeration of possible font canidates - if one
choice is not available the next one gets picked-up.

Pro:
- This should work with all X client/server-combinations and fixes the bug

Contra:
- "font.name." is not the best way to do this. Win32 has "font.name-list." to
define a list of system default fonts - however that feature never ported to
gfx/src/gtk&&gfx/src/xlib ... ;-(
For the log:
The "dt-interface user-*" font names are used on Solaris/HP-UX/AIX/OSF1 etc.
(e.g. all OSes which have CDE - and the same Unix vendors use the same
fonts.alias entries for Gnome, too) for the OS system fonts (they are defined in
fonts.alias for the matching locale and map to the OS specific default fonts)
Does anyone know who initially implemented the "font.name-list."-feature in
gfx/src/windows/ ?
I did. But don't bug me at that. For details, take a good reading at bug 61883
instead.
Severity: normal → major
Target Milestone: --- → mozilla1.4beta
Comment on attachment 122160 [details] [diff] [review]
New prototype patch for 2003-04-25-08-trunk which implements "font.name-list." support on Unix

rbs:
Requesting r= ...
Attachment #122160 - Flags: review?(rbs)
Comment on attachment 122160 [details] [diff] [review]
New prototype patch for 2003-04-25-08-trunk which implements "font.name-list." support on Unix

rbs:
ping! - still alive ? :)
Attachment #122160 - Flags: superreview?(rbs)
Comment on attachment 122160 [details] [diff] [review]
New prototype patch for 2003-04-25-08-trunk which implements "font.name-list." support on Unix

-    nsCAutoString name("font.name.");
-    name.Append(*mGeneric);
-    name.Append(char('.'));
-    name.Append(USER_DEFINED);
-    gPref->CopyCharPref(name.get(), getter_Copies(value));
+    AppendGenericFontFromPref(value, USER_DEFINED, (*mGeneric).get());
     if (value.get()) {
       mUserDefined = value.get();
       mIsUserDefined = 1;
     }
   }

Undo this one. The user-defined font is somewhat special, and is
not treated as a font list. There won't be a hard-wired name-list
for fonts that are supposedly 'user-defined'. This area is not well
docummented and the cause of much confusion so far (see dup of bug 159254).


#1)
   nsCAutoString prefix("font.name.");
   prefix.Append(*mGeneric);
   nsFontSearch search = { this, aChar, nsnull };
   FIND_FONT_PRINTF(("	    Search all font prefs for generic"));
   gPref->EnumerateChildren(prefix.get(), PrefEnumCallback, &search);
   if (search.mFont) {
     NS_ASSERTION(search.mFont->SupportsChar(aChar), "font supposed to support
this char");
     return search.mFont;
   }
#2)
   //
+  // Search all font prefs for generic in vendor-defaults ("font.name-list.")
+  //
+  nsCAutoString namelist_prefix("font.name-list.");
+  namelist_prefix.Append(*mGeneric);
+  nsFontSearch namelist_search = { this, aChar, nsnull };
+  FIND_FONT_PRINTF(("	    Search all font prefs for generic"));
+  gPref->EnumerateChildren(namelist_prefix.get(), PrefEnumCallback,
&namelist_search);


No, the philosophy between |pref->EnumerateChildren| and the name-list is
different. You might have to abandon EnumerateChildren altogether.

The problem with |pref->EnumerateChildren| is that if in #1 you pass, say
font.name.serif, it will iterate through the |subtree| of children
font.name.serif.*, i.e., it will go through font.name.serif.x-western,
font.name.serif.ja, font.name.serif.he, etc, _before_ going to #2 and
doing font.name-list.serif.x-western, etc.

Whereas the desired intention is that it exhausts a language first, i.e.,
font.name.serif.x-western and font.name-list.serif.x-western, before
trying other things.

What you need to join all those searches into is something like:

  // try mLanguage, i.e.,
  font.name.mGeneric.mLanguage + font.name-list.mGeneric.mLanguage

  // try other languages (including therefore the user's locale)
  char **prefKeys = nsnull;
  prefBranch->GetChildList("font.name.mGeneric.", &count, &prefKeys);	 
  for (i = 0; i < count; ++i) {
     // prefKeys[i] is, e.g., "font.name.mGeneric.x-western"
     lang = prefKeys[i].RFind('.'); // pseudo-code
     try prefKeys[i] + font.name-list.mGeneric.lang
  }

Have another look at the other codes that I pointed to you.
Just note that rather than using prefBranch->GetChildList() to get 
the langs in some random order, GfxWin has prioritized the ordering
in a sort of dynamic way since there are many good fonts on Windows.
Attachment #122160 - Flags: superreview?(rbs)
Attachment #122160 - Flags: superreview-
Attachment #122160 - Flags: review?(rbs)
Attachment #122160 - Flags: review-
jshin@mailaps.org:
Do you still want to take this bug ?
After working on bug 208213, I got too scared to play with XLFD-based font
selection code ;-)
Depends on: 215537
This could be rather useful for many different situations. For instance, see bug
227815. It'd be even greater if there's a UI, but some people would be very much
against adding anything to the font selection UI that they regard as 'cryptic'
as it is now.
Keywords: intl
OS: AIX → All
Summary: Default font prefs in aix.js do not work for non-AIX clients on AIX Xserver → font.name-list (fontset) support on Gfx:GTK/Xlib
Target Milestone: mozilla1.4beta → mozilla1.7alpha
Jungshik Shin:
Can you take this bug please ? I doubt I can provide a patch in the near future
(e.g. not for the 1.7alpha deadline).
Over to jshin for now...
Assignee: Roland.Mainz → jshin
Status: ASSIGNED → NEW
This is obsoleted now by GFX:Thebes, right? Should be resolved, perhaps WONTFIX as GFX:Gtk/Xlib is gone?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: