>>>>> Francesco Poli <f...@firenze.linux.it> writes:
>>>>> On Tue, 14 Jul 2009 12:35:38 +0200 Sam Hocevar wrote:

[…]

 >> I can confirm the problem. It seems to be due to uxterm failing to
 >> render bold glyphs, as the following example shows:

 >> echo ▜; tput bold; echo ▜

 >> The second “▜” is rendered using the replacement character.
 >> Copy-pasting that character yields the original “▜” glyph.

 > Yes, I can reproduce the issue this way too.  I am using xterm/243-1:
 > the above command should feed the BTS version tracking accordingly...

        While this bug is caused by the very same lack of glyphs in the
        fonts XTerm is configured to use (and its inability to use,
        roughly, more than one at a time), I believe it's an issue
        sufficiently distinct from #449480 and #469943 (which were
        merged in some three years ago), as it arises in the case of
        discrepancies in the coverage between the -medium- and -bold-
        variants of the same font.

        It seems to me that this issue is somewhat deeper, as (according
        to xterm(1)) it's possible to configure XTerm to ignore the bold
        variant altogether and to rely on “overstruck” shapes instead:

--cut: xterm(1) --
  alwaysBoldMode (class AlwaysBoldMode)

      Specifies whether xterm should check if the normal and bold fonts
      are distinct before deciding whether to use overstriking to
      simulate bold fonts.  If this resource is true, xterm does not
      make the check for distinct fonts when deciding how to handle the
      boldMode resource.  The default is "false."

      boldMode   alwaysBoldMode   Comparison   Action
      ────────────────────────────────────────────────────
      false      false            ignored      use font
      false      true             ignored      use font
      true       false            same         overstrike
      true       false            different    use font
      true       true             ignored      overstrike
--cut: xterm(1) --

        However, using $ xterm -xrm '*alwaysBoldMode: true' still
        doesn't prevent XTerm from using the -bold- variant (as noticed
        by missing glyphs.)  The resource itself is not overridden, as
        per editres(1).

        OTOH, if (assuming default fonts) we're to switch to the “Huge”
        font via the Ctrl+Button3 “Unicode Fonts” menu, the overstruck
        shapes are used, as the font selected has no -bold- variant at
        all.

        (The code below was used to generate the test set of
        characters.)

$ (s=$(perl -we 'use strict; binmode (STDOUT, ":utf8");
                 foreach my $i (64 .. 95, 0x2580 .. 0x259f) {
                     printf ("U+%04x : ", $i) if ($i % 16 == 0);
                     printf ("%s%s", chr ($i), ($i % 16 == 15 ? "\n" : ""));
                 }') ; \
      tput bold ; printf %s\\n "$s" ; \
      tput sgr0 ; printf %s\\n "$s") 

-- 
FSF associate member #7257      http://sf-day.org/


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86y5lavm65.fsf...@gray.siamics.net

Reply via email to