Bannière ASCII pour code source et README

Transformez un nom court en titre qui se voit dans un fichier ou un README. Entourez-le de commentaires, tenez la largeur, copiez.

Paramètres

Font

Espacement des lettres

Font size

Mode de remplissage

Ratio de cellule (largeur × hauteur)

Les lettres à chasse fixe sont plus hautes que larges. Une cellule 1×2 rapproche la bannière des formes d’origine.

Envelopper pour coller

Commentaire ou clôture

Les marques de commentaire s’ajoutent sur cet appareil après le dessin. Copier envoie ce que vous voyez.

Largeur de ligne

Nettoyage

Supprimer les espaces de fin ASCII seulement

Indentation

Ctrl + Entrée (⌘ + Entrée sur Mac) ou Générer. 0 / 500

Le texte est traité en mémoire serveur et détruit dès que la réponse part.
Rien n’est écrit sur disque, rien n’est journalisé. L’habillage en commentaires reste sur cet appareil.

Conseils

Un nom court, pas une phrase

La bannière est une grille de tout petits caractères qui forment de grandes lettres. Un nom aussi court qu’une fonction ou un fichier — init, main — garde ces formes lisibles. Une phrase entière use tant de cellules qu’on ne lit plus le mot. Deux mots ? Mettez-les sur deux lignes pour que chacun reste assez grand.

Les marques de commentaire comptent dans la largeur de ligne

Quand vous enveloppez la bannière en commentaires, chaque ligne gagne des caractères comme // et des espaces d’indentation. L’éditeur les compte aussi. Si le fichier tient à 80 caractères par ligne, mettez la largeur à 80. Ici ça peut sembler bon et déborder après collage. Ajuster à la largeur réduit jusqu’à ce que le bloc copié tienne.

Dans un /* /, un / du dessin termine le commentaire

En C et en Java, un commentaire va de /* au premier */. Si le remplissage dessine * et / côte à côte, la suite est lue comme du vrai code. Cette page insère un espace pour l’éviter. Un remplissage # ou . ne dessine jamais la paire. Envelopper chaque ligne avec // n’a pas de fermeture.

README et fichiers source n’acceptent pas les mêmes caractères

Un README accepte en général n’importe quel caractère. Certains arbres source — style noyau Linux, anciens contrôleurs — n’acceptent que lettres et symboles anglais. Des aplats comme █ se lisent bien dans un README et y sont refusés. Avant de coller dans ces fichiers, activez ASCII seulement et écrivez le nom en lettres anglaises.

Même en commentaires, restez dans les 80 colonnes

Écarter les lettres change l’allure du titre. Ajoutez les caractères qui en font un commentaire, et une ligne dépasse les 80 colonnes avant qu’on s’en rende compte. Surveillez ce budget.

Un fichier source avec un en-tête en commentaire, lu sur la règle des 80 colonnes. C’est la destination du collage, pas la boîte du générateur. init.c montre le dessin init en #, puis int init(void);, bien à gauche du trait rouge 80. — Dans init.c, en commentaire #

Deux volets du même dessin, lus à la colonne 80. Les marques de commentaire et l’alinéa comptent dans le budget de ligne. En haut, index reste à gauche de la règle ; en bas, // indenté passe dans le débordement rouge. — Sans commentaires, puis // indenté

Cas d'utilisation courants

📄

En tête d’un fichier source

Placez un nom de module court en tête d’un .c ou .py, en commentaires, à 80 caractères par ligne. C’est du texte ordinaire : le diff montre les mêmes lettres.

📂

Comme titre d’un README

Ouvrez un README GitHub avec le nom du projet en bannière. Entourez-le d’une clôture : pas d’hébergeur d’images, pas de lien cassé si le fichier bouge.

💻

À l’ouverture du terminal

Collez-le dans le message d’accueil, un fichier de démarrage du shell ou tmux. Une session SSH n’affiche pas d’image ; elle affiche ces lettres.

🔧

Pour marquer une section dans un script

Placez une bannière compacte au-dessus d’une cible Makefile ou d’un fragment de déploiement. Pas de police d’interface : uniquement des caractères déjà dans le fichier.

📝

Dans la description d’une pull request

Si le changement est une commande ou un binaire nommé, mettez une bannière clôturée dans la description de la pull request. Les relecteurs voient les mêmes lettres dans chaque client.

Questions fréquemment posées

Mon texte est-il envoyé à un serveur ?

Oui. Le texte va sur notre serveur, est dessiné en mémoire, devient une bannière, puis est détruit dès que la réponse part. Rien n’est écrit sur disque, rien n’est journalisé. Habillage, indentation et ASCII seulement restent sur cet appareil.

Quelle longueur de texte est acceptée ?

Jusqu’à 500 caractères par requête, sauts de ligne compris. Une bannière est en général un nom court : vous n’atteindrez pas le plafond en usage normal.

Pourquoi la bannière dépasse-t-elle 80 colonnes ?

Les marques de commentaire et l’indentation en tête de chaque ligne comptent dans la largeur. Réglez la largeur sur celle du fichier, puis Ajuster à la largeur. Si c’est encore trop à la plus petite taille, raccourcissez le nom.

Cela peut-il casser un commentaire /* */ dans mon code ?

Si le dessin contient */ et que vous enveloppez en /* */, le commentaire s’arrête là et la suite est lue comme du code. Cette page insère un espace dans cette paire. Un remplissage # ou . ne dessine jamais la paire.

Puis-je utiliser des lettres autres que l’anglais ?

Oui. Choisissez la face CJK, ou laissez Mono : kanjis, kanas et hangul saisis se dessinent quand même. Si vous collez dans un fichier qui n’accepte que lettres et symboles anglais, activez ASCII seulement et utilisez un nom anglais.

Quelle différence avec la conversion d’une image ?

Cette page dessine les lettres que vous tapez, dans une police. L’outil image transforme une photo en cellules. Gardez celui-là pour les photos ; celui-ci pour les noms à coller dans des fichiers.