Why did uxterm contain code that I didn't need?

[Joseph Rosevear]

Help!

I'm learning new things, but I don't even have the words to describe what
I'm learning. It all started when I noticed that some characters would
appear as annoying dashed boxes. I tried to ignore them, but I couldn't.

I did a little poking around and I found uxterm (a command in the form of
a script). I found that if I opened a "uxterm", that it could print the
actual characters instead of the dashed boxes.

Here is some text you can try this on, if you are interested:

“Hello” — World…
€ こんにちは α β γ δ ∑ ∆ √ ∫

On my Slackware 15.0 the above is mostly unreadable when pasted into an
"xterm", but fine and good in the "uxterm".

What I really needed, though was the ability to open "xterms" that could
manage text without making the dashed boxes. Perhaps I could harness the
uxterm command for my purposes? I didn't succeed.

I did manage, however to modify an existing script of mine making minor
changes.

I started by adding the "-class UXTerm" and "-u8" tricks from the uxterm
script to the xterm invocation in my script, but that wasn't enough. So
I removed my old font ("-fn 7x14") and replaced it with

-fa 'DejaVu Sans Mono' -fs 10

Then it worked! My old script had new life and could manage without
dashed boxes.

But then I discovered that with the above font changes I didn't need "-
class UXTerm" or "-u8". The DejaVu Sans Mono font (size 10) alone was
good enough.

So what was going on? And why did uxterm contain code that I didn't need?

I was (and am) happy to have a solution. I just wish I had a better
understanding to go with it.

So here I am. Can anyone help?

-Joe

[Lew Pitcher]

Post by Joseph Rosevear
Help!
I'm learning new things, but I don't even have the words to describe what
I'm learning. It all started when I noticed that some characters would
appear as annoying dashed boxes. I tried to ignore them, but I couldn't.

Normally, those "dashed boxes" only appear when the font you've selected
does not support the character you want to display.

Post by Joseph Rosevear
I did a little poking around and I found uxterm (a command in the form of
a script). I found that if I opened a "uxterm", that it could print the
actual characters instead of the dashed boxes.

That's probably because the uxterm command goes out of it's way to locate
a suitable UTF-8 font for your chosen LOCALE among all the fonts for that
LOCALE in your system.

Post by Joseph Rosevear
“Hello” — World…
€ こんにちは α β γ δ ∑ ∆ √ ∫
On my Slackware 15.0 the above is mostly unreadable when pasted into an
"xterm", but fine and good in the "uxterm".
What I really needed, though was the ability to open "xterms" that could
manage text without making the dashed boxes. Perhaps I could harness the
uxterm command for my purposes? I didn't succeed.
I did manage, however to modify an existing script of mine making minor
changes.
I started by adding the "-class UXTerm" and "-u8" tricks from the uxterm
script to the xterm invocation in my script, but that wasn't enough. So
I removed my old font ("-fn 7x14") and replaced it with

On my Slackware 14.2 system, font "7x14" is an alias for the
-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1
font. I don't know about Slackware 15.0, but Pat V rarely changes things
that already work, so it probably aliases the same way there. If you
want to check, look at the contents of /usr/share/fonts/misc/fonts.alias
for the line that starts with "7x14".

FWIW, the key to that alias is the "iso8859-1", which tells us that "7x14"
maps the glyphs for ISO/IEC 8859-1 8-bit single-byte coded graphic character
set, Latin alphabet No. 1 (see https://en.wikipedia.org/wiki/ISO/IEC_8859-1).
This characterset consists of 191 characters from the Latin script, and only
maps to unicode in the first 128 characters.

Post by Joseph Rosevear
-fa 'DejaVu Sans Mono' -fs 10
Then it worked! My old script had new life and could manage without
dashed boxes.

Sure it worked, the "DejaVu Sans Mono" font is a unicode-aware font that
supports a wide range of unicode characters. The "7x14" font that it
replaced doesn't include the same character support.

Post by Joseph Rosevear
But then I discovered that with the above font changes I didn't need "-
class UXTerm" or "-u8". The DejaVu Sans Mono font (size 10) alone was
good enough.

Probably not. I haven't looked at what the -class and -u8 options to xterm
do to the display, but your problem was strictly related to the choice of font.

Post by Joseph Rosevear
So what was going on? And why did uxterm contain code that I didn't need?

Because uxterm does more than support /your/ needs, so it includes code to
support a wide variety of needs as well.

Post by Joseph Rosevear
I was (and am) happy to have a solution. I just wish I had a better
understanding to go with it.
So here I am. Can anyone help?

HTH

[Joseph Rosevear]

Post by Lew Pitcher
Probably not. I haven't looked at what the -class and -u8 options to
xterm do to the display, but your problem was strictly related to the
choice of font.

Post by Joseph Rosevear
So what was going on? And why did uxterm contain code that I didn't need?

Because uxterm does more than support /your/ needs, so it includes code
to support a wide variety of needs as well.

I appreciate your taking a crack at an answer!

FWIW I decided to go with what I had. It seemed I got success with my
scripts that called xterm when I used DejaVu Sans Mono. My life was made
complicated, however when I tried to embody that choice of font in a
variable. It occured to me that that was what the user really needed--a
way to work with my scripts yet still have control over the font.

I found that this worked in my .fvwm2rc:

SetEnv font "-fa DejaVuSansMono -fs 9"

And the value assigned to variable "font" was then available in my
scripts. So the problem was solved.

Note however that I used "DejaVuSansMono" and not "'DejaVu Sans Mono'".
That was the complication I referred to above. Removing the single
quotes and the spaces in the font name was a simple, but not obvious
solution.

I thought you would like to see where this bunny trail went. So there
you are!

Thanks for your help!

-Joe

[Lew Pitcher]

Post by Joseph Rosevear

Post by Lew Pitcher
Probably not. I haven't looked at what the -class and -u8 options to
xterm do to the display, but your problem was strictly related to the
choice of font.

Post by Joseph Rosevear
So what was going on? And why did uxterm contain code that I didn't need?

Because uxterm does more than support /your/ needs, so it includes code
to support a wide variety of needs as well.

I appreciate your taking a crack at an answer!
FWIW I decided to go with what I had. It seemed I got success with my
scripts that called xterm when I used DejaVu Sans Mono. My life was made
complicated, however when I tried to embody that choice of font in a
variable. It occured to me that that was what the user really needed--a
way to work with my scripts yet still have control over the font.
SetEnv font "-fa DejaVuSansMono -fs 9"
And the value assigned to variable "font" was then available in my
scripts. So the problem was solved.
Note however that I used "DejaVuSansMono" and not "'DejaVu Sans Mono'".
That was the complication I referred to above. Removing the single
quotes and the spaces in the font name was a simple, but not obvious
solution.

Yah. X11 fonts are like that. Mostly because modern X11 installations
use two types of fonts, of which only one is native to X11.

The DeJaVu fonts are the /other/ type of font, and need an X11 "extension"
to be usable in X11.

I mentioned the /usr/share/fonts/misc/fonts.alias file, which translates
an X11 font alias into an X11 font name. Well, for the TrueType fonts
(of which the DeJaVu fonts are one set of examples), there are two more
translation files:
/usr/share/fonts/TTF/fonts.dir and /usr/share/fonts/TTF/fonts.scale

These files, along with the xft font rendering extension, allow X11 to
display characters with one of the TrueType fonts. And, in these two
files is where those spaces get lost (and found).

For instance, the Truetype font file is "DejaVuSans.ttf" (no spaces),
which the fonts.dir and fonts.scale file "translate" into various
X11 font names like -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
(note the spaces).

Older X11 applications will use the X11 font name, while newer applications
may use the TTF font name, or even the name /embedded within/ the truetype
font.

Post by Joseph Rosevear
I thought you would like to see where this bunny trail went. So there
you are!

That's what you get for taking the Red pill :-)
Welcome to the Matrix
8-)

Post by Joseph Rosevear
Thanks for your help!
-Joe

[Joseph Rosevear]

Post by Lew Pitcher

Post by Joseph Rosevear
FWIW I decided to go with what I had. It seemed I got success with my
scripts that called xterm when I used DejaVu Sans Mono. My life was
made complicated, however when I tried to embody that choice of font in
a variable. It occured to me that that was what the user really
needed--a way to work with my scripts yet still have control over the
font.
SetEnv font "-fa DejaVuSansMono -fs 9"
And the value assigned to variable "font" was then available in my
scripts. So the problem was solved.
Note however that I used "DejaVuSansMono" and not "'DejaVu Sans Mono'".
That was the complication I referred to above. Removing the single
quotes and the spaces in the font name was a simple, but not obvious
solution.

Yah. X11 fonts are like that. Mostly because modern X11 installations
use two types of fonts, of which only one is native to X11.
The DeJaVu fonts are the /other/ type of font, and need an X11
"extension"
to be usable in X11.
I mentioned the /usr/share/fonts/misc/fonts.alias file, which translates
an X11 font alias into an X11 font name. Well, for the TrueType fonts
(of which the DeJaVu fonts are one set of examples), there are two more
/usr/share/fonts/TTF/fonts.dir and /usr/share/fonts/TTF/fonts.scale
These files, along with the xft font rendering extension, allow X11 to
display characters with one of the TrueType fonts. And, in these two
files is where those spaces get lost (and found).
For instance, the Truetype font file is "DejaVuSans.ttf" (no spaces),
which the fonts.dir and fonts.scale file "translate" into various X11
font names like -misc-dejavu
sans-medium-r-normal--0-0-0-0-p-0-iso10646-1 (note the spaces).
Older X11 applications will use the X11 font name, while newer
applications may use the TTF font name, or even the name /embedded
within/ the truetype font.

Post by Joseph Rosevear
I thought you would like to see where this bunny trail went. So there
you are!

That's what you get for taking the Red pill :-)

Hey, thanks for that explanation. I followed up by searching in
duckduckgo on "X11 extension for fonts", and I found this:

https://x.org/releases/X11R7.7/doc/xorg-docs/fonts/
fonts.html#Two_font_systems

I didn't understand it all, but the "Two font systems" section and some
words near the end of "Core fonts and internationalisation" seemed to
echo what you wrote above.

Post by Lew Pitcher
Welcome to the Matrix 8-)

Matrix, indeed!

-Joe