Why doesn't xterm support double-sized characters when using Xft fonts?
Whenever I configure xterm
to use core X11 fonts:
*.vt100.renderFont: False
*.vt100.locale: False
*.vt100.font: -monotype-courier new-medium-r-normal--*-120-*-*-m-*-koi8-r
it renders double-sized characters properly:
But when I configure it to use client-side fonts:
*.vt100.renderFont: True
*.vt100.faceName: Courier New:antialias=false
*.vt100.faceSize: 12
*.vt100.utf8: 1
*.vt100.utf8Fonts: True
*.vt100.utf8Title: True
it fails to render double-sized characters, which can be confirmed via the vttest
utility:
Both PuTTY (on Windows) and konsole
do use client-side fonts and still render the double-sized text properly.
Have I mis-configured my xterm
, or is this a known issue?
fonts xterm
add a comment |
Whenever I configure xterm
to use core X11 fonts:
*.vt100.renderFont: False
*.vt100.locale: False
*.vt100.font: -monotype-courier new-medium-r-normal--*-120-*-*-m-*-koi8-r
it renders double-sized characters properly:
But when I configure it to use client-side fonts:
*.vt100.renderFont: True
*.vt100.faceName: Courier New:antialias=false
*.vt100.faceSize: 12
*.vt100.utf8: 1
*.vt100.utf8Fonts: True
*.vt100.utf8Title: True
it fails to render double-sized characters, which can be confirmed via the vttest
utility:
Both PuTTY (on Windows) and konsole
do use client-side fonts and still render the double-sized text properly.
Have I mis-configured my xterm
, or is this a known issue?
fonts xterm
add a comment |
Whenever I configure xterm
to use core X11 fonts:
*.vt100.renderFont: False
*.vt100.locale: False
*.vt100.font: -monotype-courier new-medium-r-normal--*-120-*-*-m-*-koi8-r
it renders double-sized characters properly:
But when I configure it to use client-side fonts:
*.vt100.renderFont: True
*.vt100.faceName: Courier New:antialias=false
*.vt100.faceSize: 12
*.vt100.utf8: 1
*.vt100.utf8Fonts: True
*.vt100.utf8Title: True
it fails to render double-sized characters, which can be confirmed via the vttest
utility:
Both PuTTY (on Windows) and konsole
do use client-side fonts and still render the double-sized text properly.
Have I mis-configured my xterm
, or is this a known issue?
fonts xterm
Whenever I configure xterm
to use core X11 fonts:
*.vt100.renderFont: False
*.vt100.locale: False
*.vt100.font: -monotype-courier new-medium-r-normal--*-120-*-*-m-*-koi8-r
it renders double-sized characters properly:
But when I configure it to use client-side fonts:
*.vt100.renderFont: True
*.vt100.faceName: Courier New:antialias=false
*.vt100.faceSize: 12
*.vt100.utf8: 1
*.vt100.utf8Fonts: True
*.vt100.utf8Title: True
it fails to render double-sized characters, which can be confirmed via the vttest
utility:
Both PuTTY (on Windows) and konsole
do use client-side fonts and still render the double-sized text properly.
Have I mis-configured my xterm
, or is this a known issue?
fonts xterm
fonts xterm
edited Jan 23 at 10:54
grawity
241k37510566
241k37510566
asked Jan 23 at 10:38
BassBass
452614
452614
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
It's a known limitation. The manual page says (note the omission of TrueType fonts from the discussion):
Although xterm attempts to derive a bold font for other
font selections, the font server may not cooperate. Since
X11R6, bitmap fonts have been scaled. The font server claims
to provide the bold font that xterm requests, but the
result is not always readable. XFree86 introduced a feature
which can be used to suppress the scaling. In the X server's
configuration file (e.g., “/etc/X11/XFree86” or
“/etc/X11/xorg.conf”), you can add “:unscaled” to the end of
the directory specification for the “misc” fonts, which
comprise the fixed-pitch fonts that are used by xterm. For
example
FontPath "/usr/lib/X11/fonts/misc/"
would become
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
Depending on your configuration, the font server may have its
own configuration file. The same “:unscaled” can be added to
its configuration file at the end of the directory
specification for “misc”.
The bitmap scaling feature is also used by xterm to
implement VT102 double-width and double-height characters.
Handling double-width/double-height characters using TrueType fonts could be implemented differently, by drawing/clipping one character at a time with a font that's been double-sized. Of course, with fontconfig's metrics (which often ignore the nominal bounding box), there would be no guarantee that the result would look nice.
For what it's worth, PuTTY and konsole have their own problems with this test:
PuTTY doesn't handle the line-drawing part of the test, and Konsole's typically coming up with some odd window sizes. Also, if you look closely, there are minor discrepancies in the alignment of the single- and double-width text (ymmv).
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ingNCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).
– Bass
Jan 25 at 8:11
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397399%2fwhy-doesnt-xterm-support-double-sized-characters-when-using-xft-fonts%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's a known limitation. The manual page says (note the omission of TrueType fonts from the discussion):
Although xterm attempts to derive a bold font for other
font selections, the font server may not cooperate. Since
X11R6, bitmap fonts have been scaled. The font server claims
to provide the bold font that xterm requests, but the
result is not always readable. XFree86 introduced a feature
which can be used to suppress the scaling. In the X server's
configuration file (e.g., “/etc/X11/XFree86” or
“/etc/X11/xorg.conf”), you can add “:unscaled” to the end of
the directory specification for the “misc” fonts, which
comprise the fixed-pitch fonts that are used by xterm. For
example
FontPath "/usr/lib/X11/fonts/misc/"
would become
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
Depending on your configuration, the font server may have its
own configuration file. The same “:unscaled” can be added to
its configuration file at the end of the directory
specification for “misc”.
The bitmap scaling feature is also used by xterm to
implement VT102 double-width and double-height characters.
Handling double-width/double-height characters using TrueType fonts could be implemented differently, by drawing/clipping one character at a time with a font that's been double-sized. Of course, with fontconfig's metrics (which often ignore the nominal bounding box), there would be no guarantee that the result would look nice.
For what it's worth, PuTTY and konsole have their own problems with this test:
PuTTY doesn't handle the line-drawing part of the test, and Konsole's typically coming up with some odd window sizes. Also, if you look closely, there are minor discrepancies in the alignment of the single- and double-width text (ymmv).
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ingNCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).
– Bass
Jan 25 at 8:11
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
add a comment |
It's a known limitation. The manual page says (note the omission of TrueType fonts from the discussion):
Although xterm attempts to derive a bold font for other
font selections, the font server may not cooperate. Since
X11R6, bitmap fonts have been scaled. The font server claims
to provide the bold font that xterm requests, but the
result is not always readable. XFree86 introduced a feature
which can be used to suppress the scaling. In the X server's
configuration file (e.g., “/etc/X11/XFree86” or
“/etc/X11/xorg.conf”), you can add “:unscaled” to the end of
the directory specification for the “misc” fonts, which
comprise the fixed-pitch fonts that are used by xterm. For
example
FontPath "/usr/lib/X11/fonts/misc/"
would become
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
Depending on your configuration, the font server may have its
own configuration file. The same “:unscaled” can be added to
its configuration file at the end of the directory
specification for “misc”.
The bitmap scaling feature is also used by xterm to
implement VT102 double-width and double-height characters.
Handling double-width/double-height characters using TrueType fonts could be implemented differently, by drawing/clipping one character at a time with a font that's been double-sized. Of course, with fontconfig's metrics (which often ignore the nominal bounding box), there would be no guarantee that the result would look nice.
For what it's worth, PuTTY and konsole have their own problems with this test:
PuTTY doesn't handle the line-drawing part of the test, and Konsole's typically coming up with some odd window sizes. Also, if you look closely, there are minor discrepancies in the alignment of the single- and double-width text (ymmv).
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ingNCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).
– Bass
Jan 25 at 8:11
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
add a comment |
It's a known limitation. The manual page says (note the omission of TrueType fonts from the discussion):
Although xterm attempts to derive a bold font for other
font selections, the font server may not cooperate. Since
X11R6, bitmap fonts have been scaled. The font server claims
to provide the bold font that xterm requests, but the
result is not always readable. XFree86 introduced a feature
which can be used to suppress the scaling. In the X server's
configuration file (e.g., “/etc/X11/XFree86” or
“/etc/X11/xorg.conf”), you can add “:unscaled” to the end of
the directory specification for the “misc” fonts, which
comprise the fixed-pitch fonts that are used by xterm. For
example
FontPath "/usr/lib/X11/fonts/misc/"
would become
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
Depending on your configuration, the font server may have its
own configuration file. The same “:unscaled” can be added to
its configuration file at the end of the directory
specification for “misc”.
The bitmap scaling feature is also used by xterm to
implement VT102 double-width and double-height characters.
Handling double-width/double-height characters using TrueType fonts could be implemented differently, by drawing/clipping one character at a time with a font that's been double-sized. Of course, with fontconfig's metrics (which often ignore the nominal bounding box), there would be no guarantee that the result would look nice.
For what it's worth, PuTTY and konsole have their own problems with this test:
PuTTY doesn't handle the line-drawing part of the test, and Konsole's typically coming up with some odd window sizes. Also, if you look closely, there are minor discrepancies in the alignment of the single- and double-width text (ymmv).
It's a known limitation. The manual page says (note the omission of TrueType fonts from the discussion):
Although xterm attempts to derive a bold font for other
font selections, the font server may not cooperate. Since
X11R6, bitmap fonts have been scaled. The font server claims
to provide the bold font that xterm requests, but the
result is not always readable. XFree86 introduced a feature
which can be used to suppress the scaling. In the X server's
configuration file (e.g., “/etc/X11/XFree86” or
“/etc/X11/xorg.conf”), you can add “:unscaled” to the end of
the directory specification for the “misc” fonts, which
comprise the fixed-pitch fonts that are used by xterm. For
example
FontPath "/usr/lib/X11/fonts/misc/"
would become
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
Depending on your configuration, the font server may have its
own configuration file. The same “:unscaled” can be added to
its configuration file at the end of the directory
specification for “misc”.
The bitmap scaling feature is also used by xterm to
implement VT102 double-width and double-height characters.
Handling double-width/double-height characters using TrueType fonts could be implemented differently, by drawing/clipping one character at a time with a font that's been double-sized. Of course, with fontconfig's metrics (which often ignore the nominal bounding box), there would be no guarantee that the result would look nice.
For what it's worth, PuTTY and konsole have their own problems with this test:
PuTTY doesn't handle the line-drawing part of the test, and Konsole's typically coming up with some odd window sizes. Also, if you look closely, there are minor discrepancies in the alignment of the single- and double-width text (ymmv).
edited Jan 25 at 0:43
answered Jan 24 at 21:41
Thomas DickeyThomas Dickey
6,22621126
6,22621126
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ingNCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).
– Bass
Jan 25 at 8:11
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
add a comment |
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ingNCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).
– Bass
Jan 25 at 8:11
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ing
NCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).– Bass
Jan 25 at 8:11
Thank you Thomas for such a detailed response. I have to remark that PuTTY line drawing issues can be mitigated by export'ing
NCURSES_NO_UTF8_ACS=1
(for ncurses-based applications in UTF-8 locale).– Bass
Jan 25 at 8:11
1
1
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
...but that doesn't apply to vttest -hth
– Thomas Dickey
Jan 25 at 9:25
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
Nope, it doesn’t. I assume because vttest doesn’t use ncurses =)
– Bass
Jan 25 at 10:16
1
1
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
sure - ncurses is general (adapting to different types of terminals), but vttest is specific: vt100s never did UTF-8, since they came ~15 years before UTF-8 was thought of.
– Thomas Dickey
Jan 25 at 10:25
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397399%2fwhy-doesnt-xterm-support-double-sized-characters-when-using-xft-fonts%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown