Início / unix / Perguntas / 690694
Accepted
user001
Asked: 2022-02-15 18:36:09 +0800 CST

configurações do emulador de terminal controlando a renderização do tipo de letra em negrito

  • 772

O efeito do tipo de letra em negrito (ANSI: CSI 1 m) parece depender do emulador de terminal. Por exemplo, executando o seguinte script em diferentes emuladores de terminal

#!/bin/sh
echo "TERM = $TERM"
for mode in 0 2 1 '1;2'; do
    printf '\033[%s;38;5;%dm\033[48;5;%dm%s\033[0m\n' "$mode" 0 15 "testing ($mode)"
done

dá a seguinte saída

insira a descrição da imagem aqui

Dos emuladores de terminal testados, apenas xtermrenderiza corretamente o texto em negrito (modo=1). Os outros emuladores de terminal parecem selecionar uma cor mais brilhante para o tipo de letra em negrito (geralmente também combinando isso com um tipo de letra em negrito). Estranhamente, stproduz texto em negrito devidamente colorido quando recebe os parâmetros 1;2, correspondentes a bold;faint.

Pensando que talvez esses emuladores de terminal esperem diferentes sequências de controle para fonte em negrito, verifiquei terminfo, mas encontrei unanimidade

$ for term in xterm-256color st-256color rxvt-unicode-256color tmux-256color; do printf "%-24s" "$term"; TERM=$term tput bold | cat -v; echo; done
xterm-256color          ^[[1m
st-256color             ^[[1m
rxvt-unicode-256color   ^[[1m
tmux-256color           ^[[1m

Isso leva à pergunta: quais parâmetros do emulador de terminal controlam o efeito do tipo de letra em negrito? Como evitar a mudança para cores mais brilhantes? Isso pode ser corrigido através Xresourcesou terminfopersonalização? (Como um aparte, existem parâmetros correspondentes para vim? Ele mostra um comportamento semelhante, que não corresponde necessariamente ao do emulador de terminal em que é executado.)

colors terminal-emulator

2 respostas

  1. Best Answer

    Há apenas uma sequência de escape que resulta em negrito, CSI 1 mcomo você notou.

    Por causa disso, não há realmente uma maneira de alterar o comportamento do lado do aplicativo (por exemplo vim, 's), nem mesmo por meio de configurações como as definições de terminfo. (Vou refinar esta declaração em um segundo.)

    A maneira de obter o comportamento desejado é configurar o emulador de terminal de acordo. Você está procurando xterm +pcou urxvt +is, ou sua configuração Xresource correspondente, conforme mostrado no manual. Não sei se sttem essa opção.

    Eu realmente não acho que tmuxtenha essa opção, pois não pode controlar como o emulador gráfico realmente se comportará. Teoricamente, pode tentar o truque que mencionarei em um segundo, mas realmente não acho que funcione.

    Para dar um pouco de contexto histórico:

    De acordo com os padrões, CSI 1 msignifica "negrito ou intensidade aumentada", portanto, estritamente falando, ambos os comportamentos estão corretos. Historicamente, os emuladores de terminal gráfico habilitavam ambos.

    Isso meio que fazia sentido com a paleta de cores tradicional 8/16. Nem tanto com a paleta estendida de 256 cores que mais tarde se tornou difundida, e nem tanto com RGB, suportado pela maioria dos emuladores de terminal gráfico hoje em dia. E é muito ruim que não haja uma sequência de escape que produza de forma confiável as primeiras 8 cores da paleta (praticamente as 8 cores preferidas do usuário) em negrito.

    Vendo isso, recentemente vários emuladores de terminal fizeram uma mudança para não iluminar a cor, apenas tornando a fonte mais ousada (o que você está procurando). Eu não acho que nenhum dos terminais que você mencionou fez essa alteração do padrão ainda, mas meu conhecimento pode facilmente estar desatualizado sobre eles.

    Mencionei que pode haver uma maneira de alterar o comportamento do aplicativo.

    Existem duas sequências de escape para solicitar uma das primeiras 8 cores da paleta: a legada ( CSI 30..37 m) e a de 256 cores com esse índice ( CSI 38;5;0..7 m). Certas versões de determinados emuladores de terminal podem se comportar de maneira diferente para os dois, se combinadas com o atributo bold/bright CSI 1 m. Por exemplo, se bem me lembro, algumas versões xtermmudaram para cores mais brilhantes apenas se os escapes de cores herdados fossem usados, mas não se os de 256 cores. Se bem me lembro, o xterm mais tarde mudou esse comportamento.

    De qualquer forma, se você usar esse emulador de terminal, uma solução alternativa pode ser modificar setafem seu terminfo para emitir as sequências de 256 cores para as primeiras 8 cores, em vez dos códigos herdados.

    Isso não mudará o comportamento do negrito/brilhante CSI 1 msobre a cor de primeiro plano padrão, e eu definitivamente recomendo configurar o emulador de terminal em vez de usar este hack terminfo.

    Se você estiver interessado em mais detalhes suculentos/cabeludos, você pode estar interessado nestes links, bem como em outras páginas vinculadas de lá:
    https://bugzilla.gnome.org/show_bug.cgi?id=762247
    https:// bugzilla.gnome.org/show_bug.cgi?id=791596

    • 0

  2. Como egmont apontou , o comportamento bold-as-bright pode ser suprimido em xterme urxvtexecutando xterm +pcou urxvt +is. Para aqueles que se perguntam sobre st, seu comportamento bold-as-bright é implementado xdrawglyphfontspecs()em xc ,

    /* Change basic system colors [0-7] to bright system colors [8-15] */
if ((base.mode & ATTR_BOLD_FAINT) == ATTR_BOLD && BETWEEN(base.fg, 0, 7))
    fg = &dc.col[base.fg + 8];

    onde BETWEEN()é, como o próprio nome sugere,

    #define BETWEEN(x, a, b)    ((a) <= (x) && (x) <= (b))

    A substituição se aplica apenas às primeiras 8 cores da paleta de cores tradicional 8/16, que se alinha com as observações de egmont. O cabeçalho st.h define ATTR_BOLD_FAINTcomo o bit a bit de ATTR_BOLD = 1<<0e ATTR_FAINT = 1<<1. O remapeamento de cores, portanto, ocorre apenas quando o atributo bold está definido, mas o atributo fraco também não está definido. Intencional ou não, passar sequências de escape para os atributos bold ( CSI 1 m) e fraco ( CSI 2 m) produz fonte em negrito, conforme mostrado na pergunta, por não satisfazer essa condicional.

    Em princípio, pode-se aproveitar a condicional bold-but-not-faint para obter texto em negrito, alterando a sequência de escape para o atributo bold em st.info de seu valor canônico ( \E[1m) para \E[1;2m, ou alternativamente definindo o valor fraco atributo sempre que o atributo bold é definido (modificando case 1de tsetattr()in st.c para term.c.attr.mode |= (ATTR_BOLD | ATTR_FAINT)). Embora qualquer uma dessas alterações produza os resultados desejados (testado com o script na pergunta ), nenhuma delas é recomendada (por vários motivos).

    Uma abordagem mais direta (e preferida) é simplesmente remover a condicional bold-as-bright em xdrawglyphfontspecs()e, como se vê, já existe um patch que faz exatamente isso.

    • -1

relate perguntas