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

+ Reply to Thread
Results 1 to 5 of 5

Thread: [SOT] Blocky fonts -- yet again.

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

  2. 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?

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

  4. 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!

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

+ Reply to Thread