[SOT] Blocky fonts -- yet again. - Xwindows
This is a discussion on [SOT] Blocky fonts -- yet again. - Xwindows ; (Note newsgroups and followups.)
Well, this is a fine mess...I'll admit I was doing research
on a completely different issue in X (Unicode, mostly)
and ran into this. The good news: the average "man in
the street" non-developer or non-X ...
-
[SOT] Blocky fonts -- yet again.
(Note newsgroups and followups.)
Well, this is a fine mess...I'll admit I was doing research
on a completely different issue in X (Unicode, mostly)
and ran into this. The good news: the average "man in
the street" non-developer or non-X type will probably not
run into this -- certainly it's been awhile since I've seen
any exceptionally ugly blocky fonts in, say, Epiphany.
The bad news: the Wintrools will probably try to run with
this, at least here in COLA (I don't frequent CWX) so best
for me to get on ahead and hopefully find a good defense...
Also, I can't reproduce it here at work -- here, I have
a different set of fonts installed on my machine. I
*can* reproduce the "it lists but won't load issue".
For example, I can't seem to load the font
-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1
even though XListFonts returned it earlier as one of the
entrants from the wildcard search
-*-*-Medium-R-Normal--*-400-100-100-P-0-iso10646-1
Bizarre. Am I missing something so blatantly obvious
I don't see it? :-) At home I've installed every font in
Gentoo's /usr/portage/media-fonts that I could (there's
a couple with size/checksum issues, at least as of last
Friday; I'll have to try it again tonight).
The main issue, of course, is bad font display within X
programs *only*. Gtk and Qt encapsulate the issue and I've
yet to research those on a programmatic level. The Gnome
"Character Map" utility in particular should be especially
enlightening, with any luck, and it certainly doesn't seem
to have any specific troubles displaying fonts, unless it
can't find a font, in which case it displays a box with
a hex character in it. (Its main problem: if I ask for
a big size on certain fonts -- Terminal, for example --
it doesn't autoscale. This may be a feature.)
There's also an X concept of a "FontSet" -- required when
using Xutf8DrawImageString(), which, as one might expect,
draws UTF-8 encoded strings with foreground and background
(that's what the "Image" is for; it's an analogy with
XDrawImageString()). I'll want to research that next;
it should help on some of the issues I've seen here thus far.
The program itself is currently a 272-line affair (I wish
I could shrink it but there's a fair amount of machinery
involved) specifically designed to test various aspects
of X, and *only* X -- no widgets here. Basically, it
lists fonts, creates a window, loads a font, and then
displays some text upon receipt of an Expose event, and
has some very crude key processing; I can cycle through
fonts in the list using the arrow keys. I might program
something regarding size using the left-right arrow keys
in a subsequent version, but to do so requires requerying
the font list; the "400" in
-*-*-Medium-R-Normal--*-400-100-100-P-0-iso10646-1
^^^
indicates a 40-point font (the units are tenths of a point).
The results were at best spotty and at worst a font found
using XListFonts() -- which is supposed to return an array
of font "names" or descriptors, given a wildcard -- can't
be loaded later! I cannot explain this behavior and I
frankly consider it a bug, although part of it might be
simple ignorance.
ISO10646 support on the fonts I have is also spotty.
Some fonts work spectacularly well, displaying "pi"
(U+03C0) easily. Some fonts work middling well, displaying
ISO-8859-1 characters without difficulty but displaying
a "box" character for pi. Some fonts are clearly not
designed for ISO10646-1 despite being included in the list;
these display various things character-wise for e.g.,
"ABCDE".
And some fonts won't even load. Since Helvetica is such
a common font I suspect an issue with my setup, but there
are other fonts with this problem as well.
Again, bear in mind this is a pure X program, and
unlikely to be used nowadays for anything but research.
Most developers will use Gtk or Qt -- or Java.
I should note that this may be an issue with xorg 7.1;
I can't use xorg 7.1.1 yet because of that dratted nvidia
issue. (I tried it on my other box, though -- and it has
problems there, too.) The new drivers fixed some problems
but Gentoo for some reason is still blocking building of
the new X version -- probably because this is brand new
and they've not qualified it yet.
There's also the possibility that xfs is having some sort
of a problem. I for one do not know.
Sigh. It's still better than having baby malware flooding
one's bandwidth. :-)
--
#191, ewill3@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
-
Re: [SOT] Blocky fonts -- yet again.
The Ghost In The Machine wrote:
> (Note newsgroups and followups.)
>
> Well, this is a fine mess...I'll admit I was doing research
> on a completely different issue in X (Unicode, mostly)
> and ran into this. The good news: the average "man in
> the street" non-developer or non-X type will probably not
> run into this -- certainly it's been awhile since I've seen
> any exceptionally ugly blocky fonts in, say, Epiphany.
>
> The bad news: the Wintrools will probably try to run with
> this, at least here in COLA (I don't frequent CWX) so best
> for me to get on ahead and hopefully find a good defense...
>
> Also, I can't reproduce it here at work -- here, I have
> a different set of fonts installed on my machine. I
> *can* reproduce the "it lists but won't load issue".
> For example, I can't seem to load the font
>
> -adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1
>
> even though XListFonts returned it earlier as one of the
> entrants from the wildcard search
>
> -*-*-Medium-R-Normal--*-400-100-100-P-0-iso10646-1
>
> Bizarre. Am I missing something so blatantly obvious
> I don't see it? :-) At home I've installed every font in
> Gentoo's /usr/portage/media-fonts that I could (there's
> a couple with size/checksum issues, at least as of last
> Friday; I'll have to try it again tonight).
....
Have you found the actual file that contains that font?
What is the actual line of code and error message you get
when using gdb on it?
Does xlsfonts find it?
xlsfonts|grep -i '\-adobe\-helvetica\-medium\-r\-normal'
Can you display it in xfontsel?
-
Re: [SOT] Blocky fonts -- yet again.
In comp.os.linux.advocacy, Russell Shaw
wrote
on Tue, 29 Aug 2006 11:36:23 +1000
:
> The Ghost In The Machine wrote:
>> (Note newsgroups and followups.)
>>
>> Well, this is a fine mess...I'll admit I was doing research
>> on a completely different issue in X (Unicode, mostly)
>> and ran into this. The good news: the average "man in
>> the street" non-developer or non-X type will probably not
>> run into this -- certainly it's been awhile since I've seen
>> any exceptionally ugly blocky fonts in, say, Epiphany.
>>
>> The bad news: the Wintrools will probably try to run with
>> this, at least here in COLA (I don't frequent CWX) so best
>> for me to get on ahead and hopefully find a good defense...
>>
>> Also, I can't reproduce it here at work -- here, I have
>> a different set of fonts installed on my machine. I
>> *can* reproduce the "it lists but won't load issue".
>> For example, I can't seem to load the font
>>
>> -adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1
>>
>> even though XListFonts returned it earlier as one of the
>> entrants from the wildcard search
>>
>> -*-*-Medium-R-Normal--*-400-100-100-P-0-iso10646-1
>>
>> Bizarre. Am I missing something so blatantly obvious
>> I don't see it? :-) At home I've installed every font in
>> Gentoo's /usr/portage/media-fonts that I could (there's
>> a couple with size/checksum issues, at least as of last
>> Friday; I'll have to try it again tonight).
> ...
>
> Have you found the actual file that contains that font?
>
> What is the actual line of code and error message you get
> when using gdb on it?
>
> Does xlsfonts find it?
>
> xlsfonts|grep -i '\-adobe\-helvetica\-medium\-r\-normal'
>
>
> Can you display it in xfontsel?
That's what's so odd about all this. Presumably xlsfonts is a light
encapsulation around the XListFonts() X11 call:
$ xlsfonts -fn '-*-*-Medium-R-Normal--*-400-100-100-P-0-iso10646-1'
-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1
-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1
-adobe-new century schoolbook-medium-r-normal--55-400-100-100-p-0-iso10646-1
-adobe-new century schoolbook-medium-r-normal--55-400-100-100-p-0-iso10646-1
-adobe-times-medium-r-normal--55-400-100-100-p-0-iso10646-1
-adobe-times-medium-r-normal--55-400-100-100-p-0-iso10646-1
....
which is what my test program is getting, although I think
xlsfonts sorts them as well, since my test program is printing
them in a less logical order. I could sort -- not that it
would make a lot of difference.
So let's try one of these. Should work, right?
$ xterm -fn \
'-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1'
xterm: unable to open font
"-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1",
trying "fixed"....
Hmmm...
$ xterm -fn variable
'variable' works but the display is peculiar (since variable isn't
a fixed-width font). But at least it tried.
It gets uglier. Attempting to open this font causes a protocol crash,
in both xterm and my test program.
xterm -fn -misc-marlett-medium-r-normal--55-400-100-100-p-0-iso10646-1
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 45 (X_OpenFont)
...
This is not a happy font for raw X, wherever this one's coming from.
OpenOffice has no problems opening it, though it uses an entirely
different font naming scheme which just shows "Marlett". (Turns
out it's a symbols font.)
Note that this is on my work system, with no xfs installed.
I've not tried marlett on my home system. (Webdings didn't
open but it didn't crash there either.)
There's the possibility that I should be using an XFontSet,
which for Marlett is not unreasonable. X provides
XCreateFontSet() for just such an emergency; the result
can be passed into XmbDrawString(), XwcTextExtents(),
Xutf8TextPerCharExtents() (ooh), and a few other calls.
xfontsel doesn't like marlett or webdings either; select
either in the family list (fmly) and kaboom.
$ xfontsel
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 45 (X_OpenFont)
Value in failed request: 0x2e00045
Serial number of failed request: 1189
Current serial number in output stream: 1190
Bring xfontsel back up, and try selecting fmly helvetica,
rgstry iso10646, encdng 1, avgWdth 0, and wght medium
(in that order, although it might not matter). Oops,
it's stuck -- or maybe it's not able to display the text
example. Resizing the window more or less works for the
top two widgets. Switch fmly to luxi mono and the text
display comes back, so it's not a hang problem as such,
and apparently the actual widget code is robust enough
to deal with a bad font descriptor.
Courier, times, and new century schoolbook have the same
"no-display" problem (times new roman works, as does
courier new).
I'm not quite sure where to even start with all this
without even more investigation, but one would at least expect
the following:
[1] It shouldn't list fonts it can't load. Granted, scaled
fonts (avgWdth=0) are a little weird in X anyway, mostly
because X was designed before they were even conceived of,
but why is there a problem here?
[2] It shouldn't crash, though that might be excusable given
that part of X thinks the font is there, part of it does not.
The good news: OpenOffice is typical of "higher level" apps,
and doesn't crash when given marlett -- it just displays it.
I suspect other apps such as gedit and kate will not have
problems either; I'm going to have to look to see how they've
worked around this oddity in the source.
The bad news: I know enough of ISO10646 to know it's a bit
of a mess (mostly because of duplicate char encodings),
and there's little I -- or others, to be fair -- can do
about it; this is a situation that we'll just have to live
with unless one can sunset some of the older fonts or the
tools using them.
Of course ideally it wouldn't make any difference: open a font
in raw X, Gtk, KDE, GL[*], or even WinE, and they should all look
the same, except perhaps for subaliasing capabilities which
are implemented as either an X extension or "over" X, and
of course GL's 3-D capabilities.
But I'm not too concerned about pixel subaliasing or 3D here;
this stuff's more basic than that.
*OW* *waggles foot* Darn those alligators. Never mind
draining the swamp, I was just looking into it (specifically,
Unicode) and got sucked into all this. :-)
[*] GL has yet to standardize on a good method of font display
although some hacks are available.
--
#191, ewill3@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
-
Re: [SOT] Blocky fonts -- yet again.
After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
> $ xterm -fn \
> '-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1'
> xterm: unable to open font
> "-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1",
> trying "fixed"....
What do aterm, rxvt, eterm do?
--
Intel: where Quality is job number 0.9998782345!
-
Re: [SOT] Blocky fonts -- yet again.
In comp.os.linux.advocacy, Linonut
wrote
on Tue, 29 Aug 2006 17:52:43 -0500
:
> After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
>
>> $ xterm -fn \
>> '-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1'
>> xterm: unable to open font
>> "-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1",
>> trying "fixed"....
>
> What do aterm, rxvt, eterm do?
>
Good question.
aterm-0.4.2
$ aterm -fn "-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1"
aterm: can't load font
"-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1"
rxvt-2.7.10
$ rxvt -fn "-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1"
rxvt: can't load font
"-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1"
eterm-0.9.3
$ Eterm -F "-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1"
Eterm: Error: Unable to load font
"-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1".
Falling back on "fixed"
Eterm: Error: Unable to load font
"-adobe-helvetica-medium-r-normal--55-400-100-100-p-0-iso10646-1".
Falling back on "k14"
I wasn't hopeful. :-) If they're using plain old XLoadFont() or
XLoadQueryFont() they're going to fail given this current setup
(since my program isn't doing anything horribly special; neither
is xterm apart from falling back to "fixed").
Why, I don't know yet.
--
#191, ewill3@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
