xterm w/ proportional font - Xwindows

This is a discussion on xterm w/ proportional font - Xwindows ; Because pretty is nice, I've been trying to come up with a way to get a proportional font in my terminal. It seems this has traditionally been seen as a bad thing, and hence explicitly forbidden or done poorly by ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: xterm w/ proportional font

  1. xterm w/ proportional font

    Because pretty is nice, I've been trying to come up with a way to get a
    proportional font in my terminal. It seems this has traditionally been
    seen as a bad thing, and hence explicitly forbidden or done poorly by
    xterm, rxvt, and gnome-terminal.

    Q1: Can anyone suggest a terminal program that does it right?

    Thinking about why this is the case, several applications depend on
    fixed-width chars in order to do the right thing. Emacs, multi-column
    ls...

    However, I'm wondering whether simple heuristics couldn't allow you to
    get the best of both worlds. Here's a first cut, just as an example of
    what I have in mind:

    1) use proportional fonts, set the column-width to be max-width of font.
    2) lay out each letter proportionally spaced, but also keep track of
    where it would have been placed if monospaced.
    3) Keep track of words and sentences (word sequence). Both controlled by
    regexps.
    4) Lay out each word sequence like proportional text.
    5) each new word sequence is moved over to where the _monospaced_ text
    would start. This should allow ls to keep its columns lined up.
    6) If the end of line is reached, the last word sequence is laid out so
    that each word starts on its monospace location. This should keep
    some ascii-art happy.

    Basically, pretty simple ideas. So I'm wondering why no-one has thought
    about this before?

  2. Re: xterm w/ proportional font

    Johan wrote:
    > Because pretty is nice, I've been trying to come up with a way to get a
    > proportional font in my terminal. It seems this has traditionally been
    > seen as a bad thing, and hence explicitly forbidden or done poorly by
    > xterm, rxvt, and gnome-terminal.


    > Q1: Can anyone suggest a terminal program that does it right?


    probably none, since there are conflicting requirements

    > Thinking about why this is the case, several applications depend on
    > fixed-width chars in order to do the right thing. Emacs, multi-column
    > ls...


    > However, I'm wondering whether simple heuristics couldn't allow you to
    > get the best of both worlds. Here's a first cut, just as an example of
    > what I have in mind:


    > 1) use proportional fonts, set the column-width to be max-width of font.


    XFree86 xterm does this (gnome terminal probably copies that ;-)

    > 2) lay out each letter proportionally spaced, but also keep track of
    > where it would have been placed if monospaced.
    > 3) Keep track of words and sentences (word sequence). Both controlled by
    > regexps.
    > 4) Lay out each word sequence like proportional text.
    > 5) each new word sequence is moved over to where the _monospaced_ text
    > would start. This should allow ls to keep its columns lined up.
    > 6) If the end of line is reached, the last word sequence is laid out so
    > that each word starts on its monospace location. This should keep
    > some ascii-art happy.


    unless _each_ character is on the monospace location, there are applications
    that won't work.

    > Basically, pretty simple ideas. So I'm wondering why no-one has thought
    > about this before?


    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net

  3. Re: xterm w/ proportional font

    On Mon, 01 Dec 2003 13:44:58 +0000, Thomas Dickey wrote:
    > Johan wrote:
    >> Q1: Can anyone suggest a terminal program that does it right?

    >
    > probably none, since there are conflicting requirement

    ...
    >
    > unless _each_ character is on the monospace location, there are applications
    > that won't work.


    Understood. I was hoping for a pretty terminal for easy shell work, with
    the understanding that it would not look so good for vi. Optimising for
    the pretty case seems like the Gnome philosophy, so I'm suprized there
    are no candidates.

  4. Re: xterm w/ proportional font

    Johan wrote:
    > However, I'm wondering whether simple heuristics couldn't allow you to
    > get the best of both worlds. Here's a first cut, just as an example of
    > what I have in mind:
    >
    > 1) use proportional fonts, set the column-width to be max-width of font.
    > 2) lay out each letter proportionally spaced, but also keep track of
    > where it would have been placed if monospaced.
    > 3) Keep track of words and sentences (word sequence). Both controlled by
    > regexps.
    > 4) Lay out each word sequence like proportional text.
    > 5) each new word sequence is moved over to where the _monospaced_ text
    > would start. This should allow ls to keep its columns lined up.
    > 6) If the end of line is reached, the last word sequence is laid out so
    > that each word starts on its monospace location. This should keep
    > some ascii-art happy.
    >
    > Basically, pretty simple ideas. So I'm wondering why no-one has thought
    > about this before?


    Elvis (my vi clone) uses only fixed-pitch fonts on-screen, but can print
    using proportional fonts. So I've thought about it. I'm not sure my
    thoughts will help you, but here I go anyway...

    As of Elvis 2.2_0, each chunk of text is rendered separately. Chunks are
    basically just sequences of words and punctuation within a line, sharing
    the same font. Each proportional chunk is stretched or compressed to
    make it as wide as the equivelent fixed-pitch text would have been.
    This makes columns line up right, but it can be distracting to see the
    same font stretched by different amounts. (It still looks better than
    having large gaps between words though.)

    I'd like to rewrite that, so that proportional text may be compressed if
    it would be wider than the fixed-pitch text (which would be very rare!)
    but never expanded. Tabs and graphic characters would be handled
    specially -- Drawn as though in a fixed-pitch font, but jumping to
    an absolute horizontal position which is computed by pretending all
    preceeding text on that line was fixed-pitch. So table columns would
    line up right, and so would indented comments in source code.

    I'd also like to support proportional fonts on-screen. That's a separate
    issue. Luckily, I don't need to worry about people running EMACS inside
    an Elvis window!

    To implement proportional fonts in a terminal... My first thought is that
    you could draw characters in a fixed-pitch font if the terminal is in
    "raw" mode, and proportional font in "cooked" mode. That should keep
    curses/terminfo/termcap programs happy. However, I'm pretty sure that
    bash switched to raw mode while fetching a command line from the user,
    which would mean the terminal is almost always in raw mode.

    Curses/terminfo/termcap supports a variety of terminal initialization
    strings which are intended to switch the terminal into full-screen mode
    or back to normal scrolling mode again. I think you can safely use that
    string to switch between fixed (in full-screen mode) or proportional
    (in normal mode) fonts. The only potential problem I can think of is
    that pagers such as "less" probably switch to full-screen mode but would
    otherwise be perfectly happy with proportional fonts.

    Columns in an "ls" listing would be an interesting challenge. You want
    to use proportional fonts, but still make the columns line up right.
    The columns aren't always tab-delimited; sometimes they're delimited
    by spaces. By default, "ls" always uses at least two spaces between
    columns, though, so you can treat single spaces as proportional characters
    and multiple spaces as a column-alignment clue.

    How about this set of rules:

    1) If the terminal has received the "start full screen mode" escape
    sequence, then all lines are displayed entirely in fixed-pitch
    characters. If it has received the "end full screen mode" then the
    screen may use proportional characters.

    2) If the terminal is in "raw" mode then the line that the cursor is on
    should be drawn in fixed-pitch characters (so bash's line editing
    works correctly). Other lines may use proportional characters.

    3) In a line that may use proportional characters, any tabs, graphic
    characters, or multi-space sequences should be drawn in fixed-pitch
    and start at the absolute column they would have started at in a totally
    fixed-pitch line. Other characters (letters, digits, punctuation, and
    single spaces) should be drawn in a proportional font.

    There would still be some weirdness. For one thing, proportional text is
    usually about 30% narrower than fixed-pitch text, so proportional text
    would tend to be crammed against the left edge of the window. Also, when
    typing English text it is customary to leave two spaces after the period
    at the end of a sentence; with the above rules, this would leave a large
    gap on the screen.

  5. Re: xterm w/ proportional font

    Johan wrote:
    > On Mon, 01 Dec 2003 13:44:58 +0000, Thomas Dickey wrote:
    >> Johan wrote:
    >>> Q1: Can anyone suggest a terminal program that does it right?

    >>
    >> probably none, since there are conflicting requirement

    > ..
    >>
    >> unless _each_ character is on the monospace location, there are applications
    >> that won't work.


    > Understood. I was hoping for a pretty terminal for easy shell work, with
    > the understanding that it would not look so good for vi. Optimising for
    > the pretty case seems like the Gnome philosophy, so I'm suprized there
    > are no candidates.


    not only vi. I find proportional fonts in a table of numbers makes it
    less readable. (This happens to not be a problem with _some_ proportional
    fonts, which make the decimal digits all the same size, but is not a rule
    followed by most). Line-drawing wouldn't work well, either.

    As for why there are no candidates - probably because there are few
    applications that people can use as models.

    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net

  6. Re: xterm w/ proportional font

    In article ,
    Johan wrote:
    >Because pretty is nice, I've been trying to come up with a way to get a
    >proportional font in my terminal. It seems this has traditionally been
    >seen as a bad thing, and hence explicitly forbidden or done poorly by
    >xterm, rxvt, and gnome-terminal.
    >
    >Q1: Can anyone suggest a terminal program that does it right?


    nope. doing what you ask about is "wrong".

    >
    >Thinking about why this is the case, several applications depend on
    >fixed-width chars in order to do the right thing. Emacs, multi-column
    >ls...
    >
    >However, I'm wondering whether simple heuristics couldn't allow you to
    >get the best of both worlds. Here's a first cut, just as an example of
    >what I have in mind:
    >
    >1) use proportional fonts, set the column-width to be max-width of font.
    >2) lay out each letter proportionally spaced, but also keep track of
    > where it would have been placed if monospaced.
    >3) Keep track of words and sentences (word sequence). Both controlled by
    > regexps.
    >4) Lay out each word sequence like proportional text.
    >5) each new word sequence is moved over to where the _monospaced_ text
    > would start. This should allow ls to keep its columns lined up.
    >6) If the end of line is reached, the last word sequence is laid out so
    > that each word starts on its monospace location. This should keep
    > some ascii-art happy.
    >
    >Basically, pretty simple ideas. So I'm wondering why no-one has thought
    >about this before?



    1) is _trivially_ accomplished _without_ any program modifications, by
    creating a 'derived' font where every character width is the max-width.
    requires *ZERO* programming changes in any application.


    Recognizing 'words' and/or 'word sequences' is NOT a trivial issue, when
    you start considering things like program source code, proper names,
    and multiple languages.

    For columns, should things _within_ a column be 'flush left', 'flush right',
    'centered'?

    substantial 'excess spacing' between "words" looks *worse* than fixed-pitch.

    your 5) + 6) do _not_ do anything for many types of things that rely on
    column alignment. consider the following trivial ASCII art of a box:

    +--------+
    | |
    | |
    | |
    +--------+

    if the row of hyphens is treated as a single 'word', then the vertical bars,
    which would be treated as separate 'words' will *not* line up with the plus-
    signs. OTOH, if hyphens are treated as separate 'words' then guess what
    happens to an embedded-hyphen-containing word in regular text. Suddenly,
    you've got bunches of white-space where you *don't* want it.

    Consider what happens when the 'column' of data that should line up has
    _leading_ white-space. In amounts that varies by row. E.g., a column
    of dollar-and-cent amounts, ranging, from a few pennies to several tens of
    thousands of dollars.


    The information required to do a 'correct', or 'proper', or 'appropriate'
    layout of 'something' is simply *NOT*AVAILABLE* in the 'formatted' thing
    itself. This is why word-processor programs -- not to mention _real_
    'layout and composing' systems -- keep all sorts of 'extra' information in
    the 'internal'-format files used to create the formatted output.

    For the 'general case', you simply *cannot* 'reverse engineer' those
    underlying decisions from the formatted output. *Regardless* of what
    form that output is -- Fixed-width characters, proportional fonts, or
    something else. A 'trained eyeball' can do a fairly good job, but there
    is a _lot_ of reasoning/decision-making going on 'behind the scenes',
    that is not easy to identify, nor to pin down as to exactly what the
    'inputs' are to that decision, and how each input affects the decision.
    Some things _are_ 'obvious by inspection', but nobody can say _why_ they
    are so 'obvious'.



  7. Re: xterm w/ proportional font

    It may be an AI-hard tar pit to make a terminal be fixed-width when you would want it and proportional when you would want it, but sometimes a purely proportional terminal is desirable... and available, with a slightly hacked stylesheet for Ajaxterm. The following is the stylesheet I'm using to use a fully proportional-font terminal, modulo commenting out the body line setting the term to use the JonathansCorner.com background. I'm finding that a proportional-width terminal is nice enough that fixed-width terminals are not a first choice even for code...

    pre.stat {
    margin: 0px;
    padding: 4px;
    display: block;
    /* font-family: monospace; */
    font-family: Verdana, sans;
    white-space: pre;
    /* background-color: black; */
    /* background-image: url(http://jonathanscorner.com/images/background.jpg); */
    /* border-top: 1px solid black; */
    color: #302000;
    display: none;
    }
    pre.stat span {
    padding: 0px;
    }
    pre.stat .on {
    background-color: #080;
    /* font-weight: bold; */
    color: white;
    cursor: pointer;
    }
    pre.stat .off {
    background-color: #888;
    /* font-weight: bold; */
    color: white;
    cursor: pointer;
    }
    pre.term {
    margin: 0px;
    padding: 4px;
    display: block;
    /* font-family: monospace; */
    font-family: Verdana, sans;
    /* font-size: larger; */
    font-weight: normal;
    white-space: pre;
    /* background-color: black; */
    /* background-image: url(http://jonathanscorner.com/images/background.jpg); */
    /* border-top: 1px solid white; */
    /* color: #eee; */
    color: black;
    }
    /* pre.term span.f0 { color: #000; } */
    pre.term span.f1 { color: #b00; }
    pre.term span.f2 { color: #0b0; }
    pre.term span.f3 { color: #bb0; }
    pre.term span.f4 { color: #00b; }
    pre.term span.f5 { color: #b0b; }
    pre.term span.f6 { color: #0bb; }
    /* pre.term span.f7 { color: #bbb; } */
    pre.term span.f8 { color: #666; }
    pre.term span.f9 { color: #800; }
    pre.term span.f10 { color: #080; }
    pre.term span.f11 { color: #880; }
    pre.term span.f12 { color: #008; }
    pre.term span.f13 { color: #808; }
    pre.term span.f14 { color: #088; }
    pre.term span.f15 { color: #888; }
    /* pre.term span.b0 { background-color: #000; } */
    pre.term span.b1 { background-color: #000; }
    pre.term span.b2 { background-color: #0b0; }
    pre.term span.b3 { background-color: #bb0; }
    pre.term span.b4 { background-color: #00b; }
    pre.term span.b5 { background-color: #b0b; }
    pre.term span.b6 { background-color: #0bb; }
    pre.term span.b7 { background-color: #bbb; }

    body
    {
    /* background-color: #888; */
    /* background-image: url(http://jonathanscorner.com/images/background.jpg); */
    /* font-size: larger; */
    font-weight: lighter;
    }
    #term {
    float: left;
    }

+ Reply to Thread