French/Unicode pour l'assembleur

From DPWiki
Jump to navigation Jump to search
Languages: English Français
Avertissement:
Ce texte utilise l’encodage UTF-8 (unicode). Si les apostrophes
et les guillemets de ce paragraphe apparaissent comme des caractères
aléatoires, vous avez peut-être un navigateur incompatible ou 
des polices de caractères non disponibles. Vérifiez que le
“jeu de caractères” ou le “codage” Unicode (UTF-8) est sélectionné.
Il se peut également que vous deviez changer la police de 
caractères par défaut.


Cette page rassemble les réponses à diverses questions liées à l'assemblage en Unicode, et aux conversions en général, à la fois entre Latin-1 et UTF-8, et entre Latin-1 et ASCII. Les termes “Unicode” et “UTF-8” sont utilisés de façon interchangeable. Ils ne désignent pas exactement la même chose, mais en pratique si vous savez déjà ce qu'est l'UTF-16 vous n'avez sans doute pas besoin de lire cette page.

Est-ce obligé?

Et bien, non, il n'est pas obligé de passer à l'Unicode. Sauf si votre texte est en chinois. Ou en arménien, en grec ou en hindi, ou dans n'importe quelle langue qui n'utilise pas l'alphabet latin. Ce cas est clair. Mais il y a d'autres situations où le Latin-1 ne marchera pas, y compris la plupart des langages d'Europe de l'Est. Hormis ces cas, on arrive dans les situations nécessitant un choix de votre part. Est-ce que votre texte a beaucoup de mots en grec? Est-ce que le caractère principal s'appelle Phœbe? Est-ce que l'original utilise des guillemets „comme ceci“?

Certes, d'accord, mais comment faire?

La technique dépend de votre éditeur de texte ou votre logiciel de post-processing. Il faut faire deux choses: enregistrer le texte en UTF-8 au début, et ensuite s'assurer que le texte reste en UTF-8 quand on réouvre un fichier déjà enregistré. Votre éditeur peut faire cela automatiquement, ou non. Si votre éditeur n'affiche pas de façon claire l'encodage utilisé, vous pouvez vous simplifier la vie en insérant quelques caractères inhabituels au début du fichier, comme le paragraphe d'avertissement du début. Si l'encodage est mauvais, une séquence comme “þ” (avec les guillemets) s'affichera comme du charabia: par exemple “þ”, ou ‚Äú√æ‚Äù.

Est-ce que le BOM fera exploser mon ordinateur?

Le BOM (Byte Order Mark) est un caractère invisible qui est parfois placé tout au début des fichiers UTF-8. Consultez le paramétrage de votre éditeur de texte pour détecter s'il place un BOM, et si vous pouvez choisir de ne pas l'insérer. Un BOM ne cause pas de problème dans les fichiers en texte brut (les outils des whitewashers savent en tenir compte). Mais le BOM ne doit pas être présent dans vos fichiers HTML car il y cause des problèmes.

Comment nommer le fichier?

Le fichier en texte brut doit avoir un nom terminant par “UTF-8” (en minuscules ou majuscules, le tiret étant optionnel). Cela était auparavant imposé par le logiciel des whitewashers. Maintenant c'est plus une convention de confort, pour indiquer clairement que le fichier est supposé être en Unicode. (Ou pour le distinguer d'un autre fichier qui n'est pas en Unicode).

Texte brut

Vos fichiers issus du post-processing peuvent ou non inclure une version HTML. Vous aurez toujours une version en texte brut. La leçon 1:

Le texte brut n'est pas identique à l'ASCII (ou le Latin-1)

Le mot “texte brut” n'est pas interchangeable avec “ASCII/Latin-1”. Si jusqu'à présent vous assimiliez l'un à l'autre, séparez bien les deux notions.

Le texte brut est un format de fichiers. Il signifie au sens propre du texte et rien d'autre. Pas d'italiques, pas de changement de tailles, pas de liens en couleur, juste des mots. Si vous êtes assez âgés pour vous rappeler les machines à écrire, c'est à quoi ressemble le texte brut.

ASCII est un jeu de caractère, une méthode d'encodage. Il indique quelles lettres sont utilisables. Il s'agit pour l'ASCII des caractères que l'on voit sur un clavier de langue anglaise: lettres non accentuées, chiffres, quelques signes de ponctuation et symboles courants comme & et *. Ce qu'il y a de particulier avec l'ASCII est qu'il est une sorte de dénominateur commun d'un grand nombre d'encodages différents basés sur les caractères latins, donc si votre éditeur de texte cafouille et décide que votre fichier est encodé en ISO-Latin-9 ou Baltic Rim DOS, les lettres non accentuées et les chiffres seront toujours affichés correctement.

(Note du traducteur: manque un paragraphe sur le Latin-1?)

Et ensuite?

Juste après avoir converti le fichier original en Unicode, il ne présente aucune différence visible. La seule chose que le changement permet est de rendre possible d'ajouter ou de restituer des caractères qui ne pouvaient pas figurer tels quels dans l'encodage initial.

Voici quelques modifications envisageables. Si votre éditeur de texte a une option permettant de conserver la casse (les majuscules/minuscules), utilisez cette option; à défaut, utilisez un mode de recherche qui respecte la casse et remplacez séparément les mots en majuscules et en minuscules. Certaines modifications indiquées plus bas seront bien plus rapides et sûres si vous utilisez les expressions régulières, mais comme pour tout le reste en post-processing, il y a toujours moyen de faire sans.

Attention: réfléchissez à deux fois avant de changer tous vos doubles signes moins -- en un tiret d'un cadratin —. Les fichiers en texte brut sont souvent lus dans une police à espacement fixe (si le texte contient un tableau ou une autre forme de formatage, une police à espacement fixe sera le seul choix commode) et dans ce cas il deviendra impossible de distinguer vos tirets de ponctuation de simples traits d'unions. D'un autre côté, si vous aimez utiliser des tirets d'un demi-cadratin pour indiquer des intervalles de nombres, n'hésitez pas : cela n'aura pas d'importance si le résultat ressemble à un trait d'union.

Lettres

Cherchez tous les [oe] et convertissez-les en œ. C'est très laid en espacement fixe, mais ça reste un caractère reconnaissable. Recherchez également les OE et Oe sans crochets (certains imprimeurs n'avaient pas de ligature majuscule Œ).

Si vous pouvez utiliser les expressions régulières, faites une recherche globale pour \[..\] (crochet ouvrant, deux caractères quelconques, crochet fermant), ou \[\D\D\] s'il y a des notes de bas de page à deux chiffres. Pratiquement tout ce que vous allez pêcher ainsi sera des caractères avec signes diacritiques qui se convertissent facilement, comme [~e] en ẽ. Vous trouverez également les notes minimalistes [**] qu'il faudra bien traiter à un moment ou un autre.

Attention! Quand on commence les remplacements, comme de remplacer [oe] en œ, ou bien déactivez les expressions régulières, ou bien utilisez le \backslash, sinœn vœus risquœz d'êtrœ œxtrêmœmœnt œmbêté.

Nombres

Pratiquement toutes les fractions peuvent être converties. Cherchez \d/\d (chiffre, barre oblique, chiffre) et voyez ce que ça donne. Les fractions 1/2, 1/4 et 3/4 sont en Latin-1. Unicode a l'ensemble des possibilités pour /3, /5, /6 (pas /7) et /8. Attention: si vous avez des tableaux utilisant les fractions, le résultat peut être assez laid selon les polices de caractères, certaines ne respectant pas l'espacement fixe.

Pour ces raisons, je déconseille l'usage de fractions autres que les 3 caractères présents en Latin-1, et uniquement quand il n'y a pas d'autre fractions dans le livre. (Note du traducteur)

Dans certains cas vous pouvez également souhaiter remplacer les chiffres en exposant, pas uniquement les trois ¹²³ du Latin-1 mais la série entière ⁴⁵...⁹⁰, ainsi que les chiffres en indice ₀₁...₈₉. Comme pour les fractions, ils peuvent ne pas s'afficher de façon homogène.

En essayant sur deux ordinateurs différents, soit ils sont complètement illisibles, soit ils ne s'affichent tout simplement pas! Je déconseille de les utiliser. (Note du traducteur)

Désolé, il n'y a pas de caractères Unicode pour les chiffres elzéviriens. Cela dépend uniquement de la police de caractères utilisée.

Symboles et Ponctuation

Convertissez les guillemets droits et apostrophes en leur forme courbe. Mais à moins d'être très doué en expressions régulières, vous devrez certainement en traiter certains à la main. Faites attention aux citations sur plusieurs paragraphes, et aux textes qui utilisent les guillemets simples ‘comme ceci’. Il est peu probable que vous veniez à bout de passages comme

‘’Tain’t so!’ said M’Guire

à coup d'expressions régulières.

Note du traducteur: je ne suis pas d'accord avec l'impératif ici. Le texte est parfaitement lisible avec des guillemets droits, si le post-processeur veut se fatiguer c'est son droit mais je ne vois pas de raison d'en faire une obligation. Quant aux apostrophes, la recherche sera rendue plus difficile en convertissant les apostrophes en leur variante courbe ' -> ’.

Si votre texte utilise des guillemets en “9 inférieur” comme signes de répétition „ „ vous pouvez les trouver par une recherche globale pour des guillemets entourés d'espace—recherche que vous auriez faite de toute façon.

Si le livre ne contient que quelques notes de bas de page très espacées, vous pouvez choisir de restituer des symboles originaux comme † et ‡.

Alphabets non latins

Restituez les écritures autres que l'alphabet latin, comme le grec et, si possible, les autres scripts (hébreu, arabe...). En fonction de vos logiciels, vous pouvez peut-être convertir le grec en partie automatiquement. Si vous avez des fragments de grec éparpillés dans le livre, il peut être plus simple de collecter l'ensemble du grec dans un fichier, de le dé-transcrire en bloc, et de remettre les fragments à leur place ensuite. La façon la plus simple de restaurer les accents qui ont été perdus lors des tours de relecture est de demander de l'aide dans l'un des forums d'aide sur le Grec: il n'y aura alors plus qu'à copier et coller la réponse donnée sur le forum.

Ne jetez pas la translittération d'origine. Vous en aurez besoin plus tard.

Avant d'aller plus loin

Une fois que vous avez tout en place, faites une copie pour la version HTML, si vous en prévoyez une. Le moment adéquat dépend de votre technique de post-processing. Mais si votre texte contient quelque caractère que ce soit hors de l'alphabet latin, vous devrez générer l'HTML avant de vous débarasser des translitérations.

HTML

Si votre fichier en texte brut est en UTF-8, l'HTML peut être également en UTF-8 (et c'est sans doute le plus simple), mais ce n'est pas obligatoire. En fait vous pouvez faire un HTML en UTF-8 même si le fichier texte est en Latin-1. Comme l'HTML a sa propre façon d'indiquer le jeu de caractères employé, il n'y a pas besoin de convention particulière de nommage du fichier.

Une autre solution est de conserver le fichier HTML en ASCII ou en ISO-8859-1, et d'insérer les caractères qui sont en dehors de ce jeu de caractères sous la forme d'entités, comme indiqué plus bas.

En-tête, jeu de caractère et entités

L'en-tête HTML doit correspondre à l'encodage que vous avez choisi en enregistrant le fichier, sous peine que le navigateur HTML affiche n'importe quoi à l'endroit des caractères non ASCII. Si vous êtes en Latin-1, vous devez avoir une ligne comme ceci vers le début de votre fichier HTML:

<meta http-equiv = "Content-Type" content = "text/html; charset=ISO-8859-1">

Pour l'UTF-8, changez la fin de la ligne ainsi:

charset=UTF-8">

Ne soyez pas impressionné par le terme charset. On dirait que cela signifie l'ensemble des caractères autorisés, mais en fait tout document HTML peut afficher n'importe quel caractère. La déclaration charset indique simplement à votre “agent” (le jargon HTML pour dire “navigateur”) comment il doit interpréter ce que vous avez écrit dans votre fichier pour afficher ce qui est vu par le lecteur. Si vous utilisez des entités pour tous vos caractères non ASCII, comme &auml; pour ä et &aelig; pour æ, alors le “charset” a peu d'importance, et peut être mis à US-ASCII si vous voulez. Mais votre fichier HTML sera bien plus facile à lire et à éditer si les caractères figurent dans le fichier directement et pas sous forme d'entité.

Si vous utilisez le XHTML, vous devez également indiquer le même jeu de caractère dans la déclaration XML, c'est-à-dire que la première ligne de votre fichier doit également ressembler à:

<?xml version="1.0" encoding="UTF-8"?>

Quand l'en-tête ne suffit pas

Quelques très vieux navigateurs ne savent pas lire la déclaration charset, mais savent quand même lire le fichier en UTF-8 une fois paramétré. Vous pouvez donc souhaiter inclure une note du transcripteur au début du fichier HTML en suggérant au lecteur de vérifier leur choix d'encodage. Cela se fait en général facilement sur un menu quelque part, ou bien enfoui dans les préférences. Dans les navigateurs qui ne font pas de susbtitution de police de caractères, les lecteurs peuvent aussi avoir besoin de changer leur police par défaut. Malheureusement ce paramètre-ci est enfoui dans les préférences.


Le grec et autres horreurs

Au moment de commencer à créer le fichier HTML, le texte Grec devrait être à côté de la translitération issue de la relecture, de préférence sous une forme homogène comme μῆνιν [Greek: mênin]. Cela rend plus simple la conversion en un fragment HTML incluant la translittération dans une bulle d'aide:

 <span class = "greek" title = "mênin">μῆνιν</span>

Les autres caractères spéciaux (tout ce qui peut ne pas s'afficher correctement dans le navigateur du lecteur) devraient également comporter un popup ou un sorte de description. Il faut moduler cela en fonction du public ciblé. Si toutes les pages du texte contiennent de grandes citations en grec, vous pouvez raisonnablement supposer que le lecteur saura se débrouiller. Mais par exemple pour un dictionnaire étymologique, certains lecteurs apprécieront d'avoir la translittération en popup même s'ils ne lisent pas l'alphabet grec.

Attention aux liens

Si votre fichier HTML contient des liens dérivés de mots du texte, comme des entrées d'index ou des titres de chapitre, regardez attentivement. Indépendamment du charset utilisé, les noms de liens doivent être en ASCII uniquement (de préférence des lettres, chiffres et caractère souligné uniquement). défaites les ligatures æ et œ; convertissez les lettres accentuées d'une façon ou d'une autre; remplacez les espaces par des _ ou retirez-les; etc.

Attention! Ni le validateur HTML, ni le vérificateur de liens ne signale d'erreur si les liens contiennent des caractères non ASCII. Et tant que vous ne suivez vos liens que sur votre propre fichier en local sur votre ordinateur, vous ne détecterez probablement pas de problème. Mais dès qu'il s'agit de liens entre fichiers différents, ou à travers internet, il y a un risque d'erreur. Autant éviter de prendre le risque.


Rétro-Conversion vers le Latin-1

Est-ce obligé? Si votre texte de base est en UTF-8, faut-il également faire une version Latin-1 et/ou ASCII? La réponse dépend de ce qu'il y a dans votre fichier. Les whitewashers utilisent un programme nommé Unitame, qui contient une liste de conversions à utiliser pour générer automatiquement un fichier Latin-1 à partir de l'UTF-8. Tous les signes diacritiques absents du Latin-1 sont retirée, et les symboles de ponctuation courants sont remplacés par l'équivalent le plus proche. La ligature œ est remplacée par oe (sans crochets) et en majuscules Œ devient Oe. Le tiret d'un cadratin — est converti en deux signes moins --.

Si le fichier contient des caractères non latins, ou des caractères spéciaux non ASCII, le rapport obtenu lorsqu'on soumet les fichiers aux whitewashers contiendra la ligne “Unitame says xxx characters need to be handled manually” (Unitame dit que tel ou tel nombre de caractères doivent être traités à la main). Ce message s'adresse principalement aux whitewashers, qui diront donc soit “Zut, j'ai ça à faire”, soit “Chic, le PP s'en est occupé” si vous fournissez vous-même une version Latin-1. Les dagues †, ‡, le caractère “bullet” • (à ne pas confondre avec le point médian latin-1 ·), et les fractions doivent être converties à la main. Si vous avez des caractères grecs, c'est le moment d'utiliser la translittération.

Si vous êtes curieux, téléchargez le programme Unitame sur Sourceforge et ouvrez le fichier unitame.dat dans un éditeur de texte. En face de chaque lettre figure la conversion automatique ou un espace.

Attention au piège. Même si le rapport contient “Unitame says all characters can be handled automatically” (Unitame indique que tous les caractères peuvent être convertis automatiquement), cela ne signifie pas que cela s'applique à votre projet particulier.

  • Si votre texte est un traité de linguistique, ces diacritiques sont peut-être essentiels pour la signification et ne peuvent être retirés.
  • Les guillemets hauts et bas „“ sont convertis automatiquement en guillets "dactylographiques". Cela convient parfaitement pour des langues comme le suédois qui utilise maintenant des guillemets à l'anglaise; mais pour d'autres langues il est préférable d'utiliser des guillemets français «ainsi» ou »inversés«.
  • Le Œ majuscule est toujours converti en Oe, ce qui donne des horreurs comme OeDIPE ou VOeUX.

Pensez à votre choix comme une comparaison de temps. Chaque fichier que vous soumettez aux whitewashers doit être vérifié indépendamment avec Gutcheck et je ne sais quels autres outils, donc la question est de savoir si cela leur prend plus de temps de faire les modifications à la main ou de faire une ou deux batteries de tests supplémentaires. Supposez que les modifications prendront plus de temps aux whitewashers qu'à vous, qui connaissez le texte.

Vous pouvez choisir de convertir en une forme similaire à la syntaxe des tours de relecture, par exemple avec des constructions entre crochets ( devenant [~e]), ou vous pouvez préférer remplacer en fonction du sens (par exemple devenant en ou em). Dans tous les cas, indiquez dans votre note du transcripteur les conventions de représentation adoptées.

... et ensuite vers l'ASCII

A cette étape, les accents restants disparaissent. Si la conversion est faite automatiquement, la plupart des accents sont purement et simplement retirés, seuls ä, ö, ü étant convertis en ae, oe, ue (selon l'usage allemand). Les fractions sont converties en caractères ASCII : ½ devient 1/2.

De même que pour la conversion Unicode vers Latin-1, considérez vos caractères non-ASCII et assurez-vous que la conversion automatique fait tout ce que vous voulez et uniquement ce que vous voulez.

La conversion des majuscules dépend du whitewasher. L'un des logiciels convertit en majuscule suivi d'une minuscule (Ä, Ö, Ü, Æ devenant Ae, Oe, Ue, et Ae), l'autre met tout en majuscules, donnant AE, OE and UE.

  • Si votre texte contient des mots comme “Saül” (tréma), ou “cañon” (tilde), la conversion automatique donnera “Sauel” et “canon”.
  • Vérifiez les majuscules. La conversion auto peut donner AeNEAS and UeBERRASCHUNG—ou alors AEneas et UEberraschung.
  • les fractions composées doivent être retouchées à la main, pour ne pas que 1½ (=1,5) devienne 11/2 (=5,5).

Méfiez-vous aussi des changements de longueur de lignes induits par la conversion automatique. Le changement le plus grand est peut-être le symbole des degrés ° qui devient par défaut “ deg.” (avec l'espace et le point) pour un total de 5 caractères. Il suffit de deux symboles degrés dans une ligne de 72 caractères pour atteindre les 80 caractères.

(TODO - mention also that autoconversion messes vertical alignments in tables. Offer a hint to take care of that semi-automatically, which is to add fake characters like ¤¤¤ the currency symbol, which are to be deleted when converting to one version, and converted to space in the other version.)

Que dire aux whitewashers?

C'est une bonne idée d'inclure une ligne en commentaire lorsqu'on envoie le fichier aux whitewashers pour expliquer pourquoi on soumet une version Latin-1 ou ASCII séparée. Les whitewashers sauront ainsi que le but est de leur épargner du travail de conversion, et pas d'accroître leur travail de vérification.

PG n'exige plus de versions en ASCII, donc si votre texte est particulièrement compliqué à convertir vous pouvez indiquer qu'une version ASCII-7 bits n'est pas souhaitée. Les textes en langue autre que l'anglais ne sont plus convertis en ASCII sauf demande expresse de votre part.

Comment lire vos fichiers

Votre fichier s'affiche en toute beauté sur votre propre ordinateur. Mais que se passe-t-il quand il part dans le vaste monde pour être lu par de parfaits étrangers avec un équipement inconnu?

Terminologie

Vous êtes le fournisseur. La personne qui essaie de lire votre fichier est utilisateur, qui utilise un agent utilisateur en jargon HTML, c'est-à-dire un afficheur de texte ou un navigateur. Vous êtes le premier utilisateur, et souvent le PPV est le deuxième.

Encodage de fichier

Texte brut

Les fichiers en texte brut ne contiennent pas d'information sur l'encodage. Il revient à l'agent utilisateur (l'éditeur de texte, le téléphone portable, le navigateur, le biduloïde qui reste à inventer) de décider quel encodage adopter. Si cet agent devine mal, chaque caractère non-ASCII sera affiché avec des caractères bizarres. Certains lecteurs de texte offrent la possibilité de réinterpréter le fichier avec un encodage différent; dans d'autres vous devrez fermer le fichier et changer un paramètre avant de le rouvrir. Vous n'y pouvez rien, tout ce que vous pouvez faire est de fournir l'information.

HTML

Le fichier HTML inclut une ligne indiquant l'encodage du fichier. Le plus souvent, ça suffit parfaitement. Seuls certains très vieux navigateurs (et peut-être certains dispositifs qui exploitent l'HTML) ne tiennent pas compte de cette information. C'est pour cela qu'il est parfois conseillé d'indiquer au lecteur dans une sorte d'avertissement que le fichier qu'il est en train de lire est en Unicode (UTF-8).

Polices de caractères

Les fichiers en texte brut ne contiennent pas d'information sur les polices de caractères. Ils s'affichent selon la police par défaut de l'utilisateur. Les fichiers HTML ont la possibilité technique de donner une information de police de caractères, mais vous connaissez les dangers de cette approche: une police de caractère présente par défaut sur les navigateurs de maintenant peut complètement disparaître de la circulation d'ici quelques années.

Dans certains cas il peut être utile de suggérer une police particulière. Mais en général, si un utilisateur est habitué à manipuler du grec, du vieil anglais, ou que sais-je encore, il saura sans doute parfaitement quelle police employer. Et s'il n'est pas habitué, il se précipitera sans doute directement sur la translitération.

Substitution de police

Si votre texte inclus des caractères inhabituels ou des écritures hors alphabet latin, la substitution de police de caractère permet d'afficher les caractères d'une police proche, si la police par défaut ne contient pas ces caractères. Malheureusement il n'est pas de votre ressort (vous le producteur) de faire en sorte que cette possibilité soit offerte à l'utilisateur (et parfois l'utilisateur n'y peut rien non plus). Certains logiciels et systèmes d'exploitation utilisent la substitution de police nativement, d'autres non. C'est pour cela que certains post-processeurs mentionnent dans leur avertissement la possibilité d'avoir à changer de police.

Charactères rares

Si possible, essayez de déterminer quels caractères sont largement supportés par les polices (le grec, par exemple, ou les voyelles avec barre horizontale) et lesquels n'existent que dans une poignée de polices spécialisées. Un caractère qui n'est apparu que dans des versions récentes d'Unicode (actuellement la version 5.0) sera probablement peu répandu. Dans ce cas il est particulièrement utile de fournir une translitération, ou une image. Pour les fichiers en texte brut, on peut même utiliser de l'ASCII art.

Si votre texte contient un nombre considérable de caractères rares, il peut être sage d'inclure une liste de ces caractères en note, en donnant pour chacun un nom descriptif, afin de permettre aux lecteurs de vérifier s'ils sont affichés correctement.