J'ai passé beaucoup, beaucoup de jours à lutter contre les problèmes d'espacement dans les scripts d'Asie du Sud-Est. Je n'ai JAMAIS vu d'environnement de publication dans lequel des espaces de largeur fixe telles que THIN SPACE \u2009 ou EM SPACE \u2003 produisent une sortie correcte lorsqu'elles sont utilisées entre des mots ou des phrases. Voici quelques problèmes spécifiques que j'ai observés :
- Alors qu'un espace normal SPACE \u0020 disparaît à la fin d'une ligne lorsque le mot précédent atteint complètement la marge, un espace de largeur fixe exigera soit un espace suffisant pour apparaître sur la ligne avant la marge droite, soit la largeur de l'espace tirera le mot précédent vers la ligne suivante, soit l'espace de largeur fixe passera seul à la ligne suivante, indentant efficacement la ligne de texte suivante.
- Les algorithmes de retour à la ligne privilégient la coupure à un SPACE plutôt qu'à des espaces de largeur fixe, produisant des paragraphes moches avec des demi-lignes de texte.
- Un espace de largeur fixe ne peut pas être étiré ou rétréci afin d'obtenir des marges entièrement justifiées ou des paragraphes bien équilibrés. Seul un caractère SPACE normal fonctionne pour ces choses.
- Un espace de largeur fixe peut apparaître de manière étrange lorsque l'utilisateur copie-colle depuis une application vers un messager, etc.
- Les claviers de téléphone ne peuvent pas taper un espace de largeur fixe, donc une recherche multi-mots dans une application de téléphone échouera.
La solution que j'ai trouvée est d'utiliser des caractères SPACE \u0020 normaux pour les espaces étroites et larges. Dans PTXprint, j'utilise SPACE+ZWSP+SPACE pour obtenir un double (ou triple) espace aux pauses de phrase. Dans SAB, j'utilise deux ou trois caractères d'espace, avec un style contenant CSS white-space: pre-wrap; pour empêcher le moteur HTML de fusionner plusieurs espaces en une seule espace. Dans PTXprint, SAB ou Indesign, je peux appliquer des styles personnalisés à l'espace pour le rendre plus large ou plus étroit.
L'utilisation d'espaces de largeur fixe dans Paratext fonctionne principalement correctement, bien que l'inventaire de ponctuation soit confus. Cependant, ma préférence est d'éviter d'utiliser des espaces de largeur fixe dans Paratext également, car elles sont difficiles à voir. Il est mieux d'utiliser un caractère visible (par exemple, une virgule aux pauses de phrase) et de changer ensuite le caractère en un espace plus large ou plus étroit au moment de la publication.
Comme l'a indiqué mnjames, SAB est presque aussi flexible que PTXprint lorsqu'il s'agit de mettre en œuvre des règles de modification, donc vous devriez pouvoir obtenir une sortie parfaite dans l'un ou l'autre programme, si vous avez une police fonctionnelle.
I've spent many, many days wrestling with space issues in Southeast Asian scripts. I have NEVER seen a publishing environment in which fixed width spaces such as THIN SPACE \u2009 or EM SPACE \u2003 produce correct output when used between words or phrases. Here are a few specific problems I have observed:
- Whereas a normal SPACE \u0020 will disappear at the end of a line when the preceding word reaches all the way to the margin, a fixed width space will either require sufficient space to appear on the line before the right margin, or the width of the space will pull the preceding word down to the next line, or the fixed width space will wrap to the next line alone, effectively indenting the next line of text.
- Line break algorithms prioritize breaking at a SPACE higher than at fixed width spaces, producing ugly paragraphs with half-lines of text.
- A fixed width space cannot be stretched or shrunk in order to achieve fully justified margins or nicely balanced paragraphs. Only a normal SPACE character works for these things.
- A fixed width space may appear strangely when the user copy-pastes from an app into a messenger, etc.
- Phone keyboards can't type a fixed width space so a multi-word search in a phone app will fail.
The solution that I have found is to use normal SPACE \u0020 characters for both narrow and wide spaces. In PTXprint I use SPACE+ZWSP+SPACE to get a double (or triple) space at phrase breaks. In SAB I use two or three space characters, with a style containing CSS white-space: pre-wrap; to prevent the HTML engine from collapsing multiple spaces into a single space. In either PTXprint, SAB, or Indesign I can apply custom styles to the space to make it either wider or narrower.
Using fixed-width spaces within Paratext works mostly OK, though the punctuation inventory gets confused. My preference, however, is to avoid using fixed-width spaces in Paratext too because they're difficult to see. It's better to use a visible character (e.g. a comma at phrase breaks) and then change the character to a wider or narrower space at publication time.
As mnjames indicated, SAB is almost as flexible as PTXprint when it comes to implementing change rules, so you should be able to get perfect output in either program, if you have a working font.
Traduit automatiquement depuis English
