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

Status: RESOLVED WONTFIX

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

Description

[Roland Mainz]

[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...

Comment 1

[Roland Mainz]

Attachment: Prototype patch for 2003-04-21-08-trunk

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 ... ;-(

Comment 2

[Roland Mainz]

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)

Comment 3

[Roland Mainz]

Does anyone know who initially implemented the "font.name-list."-feature in
gfx/src/windows/ ?

Comment 4

[rbs]

I did. But don't bug me at that. For details, take a good reading at bug 61883
instead.

Comment 5

[Roland Mainz]

Attachment: New prototype patch for 2003-04-25-08-trunk which implements "font.name-list." support on Unix

Comment 6

[Roland Mainz]

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= ...

Comment 7

[Roland Mainz]

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 ? :)

Comment 8

[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.

Comment 9

[Roland Mainz]

[e-mail]:
Do you still want to take this bug ?

Comment 10

[Jungshik Shin]

After working on bug 208213, I got too scared to play with XLFD-based font
selection code ;-)

Comment 11

[Jungshik Shin]

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.

Comment 12

[Roland Mainz]

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).

Comment 13

[Roland Mainz]

Over to jshin for now...

Comment 14

[Peter Weilbacher]

This is obsoleted now by GFX:Thebes, right? Should be resolved, perhaps WONTFIX as GFX:Gtk/Xlib is gone?