Why doesn't xterm support double-sized characters when using Xft fonts?












1















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:



enter image description here



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:



enter image description here



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?










share|improve this question





























    1















    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:



    enter image description here



    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:



    enter image description here



    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?










    share|improve this question



























      1












      1








      1








      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:



      enter image description here



      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:



      enter image description here



      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?










      share|improve this question
















      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:



      enter image description here



      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:



      enter image description here



      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 23 at 10:54









      grawity

      241k37510566




      241k37510566










      asked Jan 23 at 10:38









      BassBass

      452614




      452614






















          1 Answer
          1






          active

          oldest

          votes


















          1














          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, same test but next page...



          Konsole, likewise



          XTerm, same 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).






          share|improve this answer


























          • 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





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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          1














          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, same test but next page...



          Konsole, likewise



          XTerm, same 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).






          share|improve this answer


























          • 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





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
















          1














          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, same test but next page...



          Konsole, likewise



          XTerm, same 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).






          share|improve this answer


























          • 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





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














          1












          1








          1







          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, same test but next page...



          Konsole, likewise



          XTerm, same 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).






          share|improve this answer















          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, same test but next page...



          Konsole, likewise



          XTerm, same 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).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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'ing NCURSES_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






          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

          Alcedinidae

          Origin of the phrase “under your belt”?