Xterm.js: Dessinez manuellement des glyphes aux pixels parfaits pour les caractères Box Drawing et Block Elements

Créé le 10 sept. 2019 · 24Commentaires · Source: xtermjs/xterm.js

Détails

Navigateur et version du navigateur: Chrome 76.0.3809.132 (64 bits), FireFox 69.0 (64 bits)
Version du système d'exploitation: Windows 7 Pro 64 bits
version xterm.js: ^ 3.14.5

Étapes à suivre pour reproduire

index.html:

<!doctype html>
<html>

<head>
    <link rel="stylesheet" href="node_modules/xterm/dist/xterm.css" />
    <script src="node_modules/xterm/dist/xterm.js"></script>
</head>

<body>
    <div id="terminal"></div>
    <script>
        var options = {
            rows: 30,
            cols: 80,
            fontFamily: '"Courier New", "DejaVu Sans Mono", "Everson Mono", FreeMono, "Andale Mono", monospace',
            fontSize: 12,
            convertEol: true
        };
        var term = new Terminal(options);
        term.open(document.getElementById('terminal'));

        term.write('           ╔═════════════════════════════════════════════════════════╕\n');
        term.write('           ║                                                         │\n');
        term.write('           ║              ╔═══════════════╦════════╤════════╗        │\n');
        term.write('           ║              ║               ║        │        ║        │\n');
        term.write('           ║              ║               ║        │        ║        │\n');
    </script>
</body>

</html>

Il y a plusieurs problèmes liés mais cela n'aide pas:

https://github.com/xtermjs/xterm.js/issues/475
https://github.com/xtermjs/xterm.js/issues/992

arerenderer help wanted typenhancement

Source

anatoly-spb

👍1

Commentaire le plus utile

J'ai fait quelques expériences avec le dessin manuel de certains personnages.
Page de démonstration: https://roguelike.solutions/xterm/xtermtest.html

Le code est approximatif, mais disponible ici: https://github.com/xtermjs/xterm.js/compare/master...guregu : box-drawing

Actuellement, il s'agit de deux parties, l'une est boxDrawingLineSegments qui emprunte un algorithme à iTerm2. Il définit 7 types de points d'ancrage verticaux et horizontaux arbitraires par cellule de caractère et trace des lignes ou des courbes qui leur correspondent. Cela fonctionne pour presque toutes les lignes de dessin de boîte, mais ne fonctionne pas pour les caractères en pointillés qui nécessitent plus de points d'ancrage. Avoir un contrôle précis sur le dessin des lignes signifie également que nous n'avons pas besoin de couper horizontalement pour éviter les débordements. J'essaie de penser à une meilleure façon de les représenter qui fonctionnera également avec les lignes pointillées.
Peut-être qu'au lieu de diviser les cellules en 7 points quelque peu arbitraires, nous pouvons à la place définir des emplacements tels que «gauche», «centre», «centre moins n pixels devicePixelRatio», etc.
De plus, iTerm2 est GPL2 et j'ai essayé de l'écrire pour être aussi original que possible et éviter les problèmes de licence, mais je ne sais pas où la ligne figurative est dessinée ici. C'est une autre raison d'utiliser un algorithme original plus sophistiqué. Considérez l'implémentation actuelle comme une preuve de concept.

Vient ensuite boxDrawingBoxes (nécessite un meilleur nom 😅) qui divise une cellule de caractère en huitièmes et remplit les rectangles qui leur correspondent. Cela suffit pour dessiner les caractères du bloc solide, y compris les nouveaux du bloc Symbols for Legacy Computing. Cela devrait être suffisant pour prendre en charge les caractères quadrants également, mais pour prendre en charge les sextants, il faudra diviser les caractères en sixièmes. Permettre la définition d'un diviseur serait suffisant pour prendre en charge la plupart des caractères de type bloc.

Je ne prend pas encore en charge les caractères polygonaux du bloc Symbols for Legacy Computing, mais l'utilisation de techniques similaires devrait fonctionner pour eux. Je ne sais pas trop comment dessiner les caractères d'ombre comme les ° ░ ▓, mais peut-être qu'ils pourraient être spéciaux. Il y a aussi la question de savoir jusqu'où nous voulons aller avec cela.

Pour nettoyer le code, nous pourrions peut-être définir une interface pour dessiner des segments, et ses implémenteurs pourraient être des lignes, des courbes, des n-ièmes boîtes, etc. Tout cela est très expérimental, mais si cela semble être une bonne idée, je le serais heureux de contribuer (et d'ajouter le support du moteur de rendu WebGL).

guregu le 5 mai 2020

❤3

Tous les 24 commentaires

Je pense que cela dépend de la police utilisée, je ne peux pas reproduire en utilisant le moteur de rendu canvas (par défaut).

Tyriar le 10 sept. 2019

@Tyriar comment puis-je partager les informations nécessaires?

anatoly-spb le 10 sept. 2019

Pouvez-vous essayer d'utiliser cette police ? Votre fontFamily et Hack fonctionnent tous les deux pour moi sur ma boîte Windows 10.

Tyriar le 10 sept. 2019

J'ai essayé ce qui suit sur ma machine Windows 10 64 bits domestique dans le navigateur Yandex (basé sur Chromium):

<!doctype html>
<html>

<head>
    <link rel='stylesheet' href='//cdn.jsdelivr.net/npm/[email protected]/build/web/hack.css'>
    <link rel="stylesheet" href="node_modules/xterm/dist/xterm.css" />
    <script src="node_modules/xterm/dist/xterm.js"></script>
</head>

<body>
    <div id="terminal"></div>
    <script>
        var options = {
            rows: 30,
            cols: 80,
            fontFamily: 'Hack',
            fontSize: 12,
            convertEol: true
        };
        var term = new Terminal(options);
        term.open(document.getElementById('terminal'));

        term.write('           ╔═════════════════════════════════════════════════════════╕\n');
        term.write('           ║                                                         │\n');
        term.write('           ║              ╔═══════════════╦════════╤════════╗        │\n');
        term.write('           ║              ║               ║        │        ║        │\n');
        term.write('           ║              ║               ║        │        ║        │\n');
    </script>
</body>

</html>

Voici le résultat:

La même chose sur Chrome:

J'ai également essayé d'imprimer dans Visual Studio Code avec le nœud:

anatoly-spb le 10 sept. 2019

FYI: Certains terminaux, y compris gnome-terminal (vte) et konsole dessinent manuellement les caractères U + 2500..257F (ou même jusqu'à 259F), plutôt que de les retirer de la police, afin de fournir un look magnifiquement connecté.

Par coïncidence, ces deux émulateurs ont adopté une approche technique assez similaire: définir l'apparence de (la plupart de) ces glyphes comme une image bitmap 5x5 avec des tailles de "pixels" inégales qui sont calculées à l'exécution en fonction de la taille de la police.

egmontkob le 11 sept. 2019

@egmontkob Lulz, je me souviens avoir fait de même dans mon ancien émulateur. Je me suis toujours demandé pourquoi xterm.js ne montre pas ce comportement, mais n'a jamais enquêté.

@Tyriar J'ai juste fait quelques tests avec différentes polices avec chrome et FF avec ces résultats - je vois dans chaque moteur avec chaque police répertoriée dans la démo un petit espace (testé dans le canevas et le moteur de rendu DOM). L'espace lui-même varie avec la taille de la police et la police elle-même, FF est d'un pixel avec un écart plus grand (nous avons ce décalage de pixel dans FF également à d'autres endroits / problèmes).

Conclusion: Toutes mes polices testées montrent des espaces (de peu visibles à un espace important), donc je pense que les glyphes ne couvrent tout simplement pas complètement la hauteur (juste une supposition, n'ont pas inspecté les glyphes uniques avec un outil de police). Les différences d'espaces sont principalement liées au rendu de police qui essaie de l'arrondir / l'aligner sur une taille de police donnée.

De plus, je ne vois aucun écart dans vscode (pas même le moindre, testé avec mc ). Vous ne savez pas ce que vscode fait différemment ici, peut-être qu'un correctif général peut emprunter cela? En plus de dessiner nos propres glyphes comme suggéré par @egmontkob, nous pourrions nous en tirer avec une approche plus simple pour DOM - dessinez simplement ces points de code en question avec une taille de police légèrement plus grande. Pour les autres moteurs de rendu où nous maintenons des états de glyphe de canevas de toute façon , l'approche de

jerch le 12 sept. 2019

Peut-être que vscode (ou du moins ma configuration) a de la chance avec sa taille de police, sa famille, le niveau de zoom de la fenêtre, etc.

nous pourrions nous en sortir avec une approche plus simple pour DOM - dessinez simplement les points de code en question avec une taille de police légèrement plus grande

Nous ne devons pas et ne devrions pas couper les cellules dans le moteur de rendu DOM, donc je ne pense pas que ce soit une option.

À condition que cela n'ajoute pas trop de code * nous pourrions coder en dur nos propres glyphes pour ceux-ci 👍, ce serait bien si cela était cohérent avec le moteur de rendu DOM.

* J'ai des doutes à ce sujet

Tyriar le 12 sept. 2019

Maintenant que # 2572 a été marqué comme dup, ce bogue concerne définitivement U + 2500..257F "Box Drawing" et U + 2580..259F "Block Elements" aussi.

Gardez également un œil sur les prochains (Unicode 13) U + 1FB00 "Symboles for Legacy Computing" , voir par exemple VTE 189 .

egmontkob le 22 nov. 2019

👍1

@egmontkob Lol, je suppose que ces nouveaux glyphes sont également censés s'aligner parfaitement? Décidément, qui a besoin d'un moteur de rendu de polices, si on peut le faire à la dure ...

jerch le 22 nov. 2019

😄1

J'adorerais comprendre les raisons pour lesquelles aucune des polices ne fonctionne correctement. Mais je n'ai ni le temps ni la motivation pour enquêter.

egmontkob le 22 nov. 2019

Une chose intéressante que cela pourrait faire que les polices ne pourraient pas est de remplir la cellule entière lorsqu'une hauteur de ligne est spécifiée.

Tyriar le 23 nov. 2019

Comportement amusant supplémentaire (terminal vscode):
out3
Pour moi, changer les tailles de police, en utilisant la police hack mentionnée précédemment n'aide pas, l'espacement reste. Cependant, à en juger par le gif ci-dessus, les caractères de bloc semblent être placés de manière incorrecte. Il y a un espace de pixel en bas et la différence entre les blocs 7/8 et 8/8 (pleins) semble plus petite qu'entre les autres.

nojus297 le 15 avr. 2020

Sur macOS (écran Retina, devicePixelRatio = 2) + Chrome, l'utilisation de la police Hack me donne de petits écarts verticaux comme celui-ci:
Screen Shot 2020-04-28 at 20 44 51
Mais après avoir fouillé, j'ai remarqué que transformer BaseRenderLayer._clipRow en un no-op les rend correctement:

ce qui me porte à croire que cela pourrait être un problème d'écrêtage.

guregu le 28 avr. 2020

👍1

@guregu, le moteur de rendu du canevas de par sa conception doit

Ceci est toujours marqué comme une aide recherchée et peut-être que cela ne peut / devrait être fait que dans le moteur de rendu webgl, auquel cas il s'agirait de gérer ces caractères particuliers spécialement lors du dessin du caractère sur l'atlas de texture:

https://github.com/xtermjs/xterm.js/blob/45077d710627fb2aec61ac2dfc41879d8c32371e/addons/xterm-addon-webgl/src/atlas/WebglCharAtlas.ts#L304 -L306

Tyriar le 28 avr. 2020

FWIW J'ai réussi à le réparer sans déranger le clipping.
Le problème n'était pas l'écrêtage, mais l'utilisation de middle comme textBaseline provoquait un léger désalignement.
Changer le textBaseline en bottom totalement résolu le problème pour moi.
Diff: https://github.com/xtermjs/xterm.js/compare/master...guregu : maître
Je peux envoyer un PR si ça a l'air bien, mais je ne suis pas sûr que ça va gâcher autre chose.

Y a-t-il une raison particulière pour laquelle il a été défini sur middle auparavant?
J'ai remarqué qu'il définit le texte normal légèrement plus bas, mais cela ressemble à la façon dont Terminal.app rend le texte.

Voici une capture d'écran du code en cours d'exécution depuis le début de ce PR sans le correctif:
Screen Shot 2020-04-28 at 22 29 03
Le voici avec le correctif appliqué:

guregu le 28 avr. 2020

@guregu auparavant, le moteur de rendu webgl utilisait top, mais il a fini par aligner le texte en haut:

Je crains que cela n'arrive si nous utilisons bottom

Voir https://github.com/xtermjs/xterm.js/issues/2613 , https://github.com/xtermjs/xterm.js/issues/2645 , https://github.com/microsoft/vscode/issues / 95813

Tyriar le 28 avr. 2020

Ce n'est pas non plus parfait même en ignorant le problème d'alignement du bas (notez les encoches sur la ligne horizontale):

Je pense que dessiner manuellement des glyphes parfaits est la voie à suivre.

Tyriar le 28 avr. 2020

La sortie Btw @ nojus297 ressemble à peu près à un problème de décalage de 0,5 px. Je suis tombé sur des problèmes d'anticrénelage avec un décalage de 0,5 moi-même l'autre jour, lorsque j'ai joué avec des soulignements bouclés auto-dessinés. Je ne sais pas si cela s'applique ici du tout (toujours pas utilisé pour le code de rendu lol).

jerch le 28 avr. 2020

Est-ce que vous pourriez également vérifier votre niveau de zoom pour vous assurer qu'il est 1. Devrions-nous peut-être le baisser de 0,5 px lorsque la taille de la police est étrange? 🤔

Tyriar le 28 avr. 2020

J'ai pris des captures d'écran de mes modifications et de la version inchangée et j'ai exécuté une différence dessus. Le texte normal est en fait exactement le même. La seule différence réside dans les caractères du dessin de la boîte.
download
(le magenta est la partie différente)

Fondamentalement, le nœud de ce problème est que, pour une raison quelconque, le texte qui occupe toute la hauteur d'une cellule est poussé vers le haut de quelques pixels et coupé lors de l'utilisation de middle comme textBaseline .
Il est facile de le vérifier si vous le mettez en surbrillance.
XTERM_BROKE
^ version non fixée, vous pouvez voir qu'il y a quelques pixels vides au bas de la ║

En ce qui concerne les encoches sur la ligne horizontale, Terminal.app semble avoir le même problème. C'est peut-être un problème de police? Aucune idée.
Capture d'écran de Terminal.app:
Screen Shot 2020-04-29 at 0 02 04

Cependant, même avec les changements, je vois encore des bizarreries, comme l'utilisation du curseur provoque l'apparition de minuscules encoches noires. Cela ne se produit pas sur les versions réelles. Peut-être lié aux autres encoches?
Cela provient de xterm.js et se produit sur les versions modifiées et inchangées:
rendering-oddness

Quoi qu'il en soit, je suis d'accord pour que le rendu de ces personnages soit spécialement la voie à suivre. J'essaie juste de trouver la raison pour laquelle cela se produit en premier lieu.

guregu le 28 avr. 2020

J'ai demandé à des amis de tester mon correctif sur Windows et cela ne fait qu'empirer les choses 😅
On dirait un boîtier spécial, c'est le seul moyen infaillible. Désolé pour ça.
Le problème du curseur est probablement un problème distinct. Effacer tout le canevas pendant clearCursor le corrige. On dirait que le caractère de dessin de boîte horizontale dessine un peu plus large que la largeur de la cellule?

guregu le 28 avr. 2020

@guregu merci de l'avoir regardé.

On dirait que le caractère de dessin de boîte horizontale dessine un peu plus large que la largeur de la cellule?

Peut-être, nous permettons cela. Quelque chose qui peut fonctionner est de couper le glyphe de caractère à la taille d'une cellule uniquement pour ces caractères de dessin de boîte?

Tyriar le 28 avr. 2020

J'ai fait quelques expériences avec le dessin manuel de certains personnages.
Page de démonstration: https://roguelike.solutions/xterm/xtermtest.html

Le code est approximatif, mais disponible ici: https://github.com/xtermjs/xterm.js/compare/master...guregu : box-drawing

guregu le 5 mai 2020

❤3

Tout cela est très expérimental, mais si cela semble être une bonne idée, je serais heureux de contribuer (et d'ajouter le support du moteur de rendu WebGL).

@guregu beau travail, une contribution serait géniale, il vous suffit de vous assurer qu'elle n'est pas trop dérivée de l'algorithme iTerm2 car la GPL2 est collante. Je suggérerais de ne faire cela que pour le moteur de rendu webgl (pas pour le canevas car il va être mis au rebut). Définitivement basé les lignes sur devicePixelRatios afin que la largeur soit excellente sur tous les moniteurs.

mais l'utilisation de techniques similaires devrait fonctionner pour eux. Je ne sais pas comment dessiner les caractères d'ombre comme les ° ░ ▓

Celles-ci devraient être relativement faciles à faire, mais elles pourraient également être facilement différées. Le problème principal dans ce domaine est celui du solide.

Tyriar le 5 mai 2020

👍1

Cette page vous a été utile?

0 / 5 - 0 notes