Revisiter les espaces insécables à l'ère de la publication incrémentale

Question

Bonjour à tous, j'aimerais discuter des espaces insécables (U+00A0) à l'ère de la publication numérique.

Je travaille dans un pays officiellement bilingue entre le français et l'anglais. Dans les pays anglophones, les espaces insécables et demi-espaces sont rares. Vous pourriez trouver un espace insécable entre les parties de 1·Chroniques.

En revanche, la plupart de nos traducteurs des régions francophones souhaitent suivre les règles d'espacement françaises. Dans le monde francophone, des espaces sont requis avant/autour de la ponctuation à 2 signes (; ! : ? « »). Les espaces insécables sont souvent utilisés comme séparateur de milliers dans les grands nombres, comme 1·000 (Paramètres des nombres - Séparateur de milliers se réinitialise - #3 par jeffh). Les normes de publication varient, mais les candidats idéaux pour ce cas sont l'espace insécable commun (U+00A0) et l'espace insécable étroit (U202F). Cela empêche un signe de ponctuation de fermeture d'être repoussé à la ligne suivante, en particulier dans les mises en page à plusieurs colonnes. Ces espaces permettent au texte de couler sur les ordinateurs du monde entier. L'espace standard (U+0020), l'espace fin (U+2009) et l'espace capillaire (U+022A) ont des largeurs variables, mais ne fournissent pas la protection nécessaire contre les orphelins.

Certains outils choisissent de représenter visuellement les espaces insécables par un point pâle ou une boîte grise. Paratext remplace automatiquement l'espace insécable (U+00A0) par un tilde gigantesque (~, U+007E). Dans les versions actuelles, la saisie de 00A0 et l'appui sur ALT-X remplacent ce qui devrait être un espace insécable par des espaces simples (0020), ce qui est tout simplement faux. Ce tilde géant est très distrayant pour nos traducteurs, et donc, la plupart du temps, les traducteurs francophones ont été instruits d'utiliser soit des espaces simples, soit de ne pas utiliser d'espaces avant la ponctuation, avec la compréhension que le typographe standardisera les espaces à la dernière minute selon leurs décisions avant l'impression. Je suis pleinement conscient que les tildes gigantesques sont remplacés par des espaces insécables en mode aperçu, et peuvent être remplacés via les modifications de Print Draft ou ptxPrint. Un technicien créatif pourrait configurer PTX print pour insérer des espaces avant de tels caractères, mais alors ils ne seraient pas du tout vus dans Paratext.

De la documentation de Paratext :

En raison de cela, Paratext ne prend plus en charge l'utilisation de l'espace insécable. Si vous souhaitez utiliser des espaces insécables dans votre texte, vous devez saisir un tilde à la place de l'espace insécable. Ceux-ci peuvent être convertis en espaces insécables lors de la composition. Les tildes saisis dans le texte sont affichés comme des espaces insécables dans la vue Aperçu.

Si c'était quelque chose de rare (comme en anglais), je ne m'en soucierais pas, mais cela se produit presque dans chaque paragraphe d'un texte francophone. Ma préoccupation est que 1) les tildes sont distrayants pour les traducteurs qui passent leur temps en vue standard, et pour ceux qui lisent par-dessus leur épaule, et 2) que cette restriction ne tient pas la route à cette ère de publication et de partage numériques.

Techniquement,~on~peut~se~passer~de~cela~et~publier~via~les~tildes~intermédiaires. La réponse du personnel de terrain aux tildes, à savoir d'ignorer les espaces insécables jusqu'à la composition, n'est plus viable, car les textes ne sont pas seulement préparés pour l'impression par des typographes. Des livres individuels sont publiés localement, des versions numériques sont mises dans le DBL et rendues disponibles, et des applications bibliques sont créées. Cela signifie que l'espacement « final » dans la version Paratext est de plus en plus important, et Paratext ne prend toujours pas « vraiment » en charge cela. (Je viens de découvrir aujourd'hui que l'espace insécable étroit (U202F) n'a pas d'indicateur visuel, mais heureusement qu'il ne devient pas un tilde.) L'affichage/gestion incohérent de U+202F, qui devrait être plus étroit, est discuté ici (Suppression de l'Unicode 202F ("espace insécable étroit") dans le projet)

LibreOffice utilise une boîte grise pour distinguer les espaces insécables des espaces normaux. La fonction Afficher/Masquer de Word utilise un cercle ouvert pour les espaces non insécables et un point centré pour les espaces normaux.

Les développeurs de Paratext considéreraient-ils d'abandonner le tilde dans l'interface et d'utiliser quelque chose de plus lisible et moins distrayant ? Cela nécessiterait-il un changement dans USFM, ou seulement dans Paratext ? Les traducteurs sont déjà habitués aux métadonnées grisâtres dans leur texte comme les marqueurs USFM. Un point gris pâle · en vue standard serait utile pour distinguer les espaces spéciaux et les espaces normaux, n'est-ce pas ? Opter pour les carrés gris au lieu de cela montrerait à la fois le caractère non insécable et la longueur, ce qui, je suppose, est la raison pour laquelle LibreOffice les a choisis. Ce serait une grande victoire pour la compatibilité interculturelle, j'espère que quelqu'un d'autre travaillant dans le monde francophone pourra donner son avis. @jeffh @dhigby @anon023887 ?

Je comprends de ce message (Problèmes d'espaces insécables) que la transformation en tilde a été introduite pour combattre un problème d'alternance d'Internet Explorer. Même maintenant, deux espaces consécutifs dans une page Web exigent qu'au moins l'un soit transformé en NBSP. Oui, il est difficile de distinguer visuellement les espaces, mais les équipes doivent encore les standardiser.
~ Matthew_Lee
Consultant en technologie des langues
SIL Cameroun

Pour aggraver les choses, l'aide de Paratext traite les espaces insécables comme un fléau à éradiquer (voir ci-dessous).

Pourquoi vois-je des tildes à la place des espaces dans mon texte ?
Les espaces insécables sont des caractères qui ressemblent à un espace mais qui ne allo…
Les espaces insécables sont des caractères qui ressemblent à un espace mais qui ne permettent pas de casser la ligne à cet endroit. À l'ouverture d'un texte avec des espaces insécables, si vous constatez que ces espaces semblent avoir été remplacés par des caractères tilde (~), c'est intentionnel. Paratext rend les espaces insécables visibles en les affichant sous forme de tildes.
Qu'est-ce que je dois savoir au minimum à ce sujet ?
Les versions antérieures de Paratext inséraient occasionnellement et à tort des espaces insécables là où un espace normal était nécessaire. Par conséquent, si vous voyez un tilde occasionnel à un endroit du texte où vous êtes tout à fait sûr qu'un espace insécable n'est pas requis, vous pouvez simplement remplacer le tilde par un espace.
Que faire si je souhaite résoudre le problème d'un coup ?
Si vous n'avez PAS inséré intentionnellement d'espaces insécables ou de tildes dans votre texte et que vous souhaitez donc supprimer tous les espaces insécables et tildes, suivez les instructions de l'Option 1. Si vous n'êtes pas absolument sûr que les tildes ou les espaces insécables ont été insérés intentionnellement, consultez votre personne de support CAP avant de les supprimer tous, sinon vous devrez peut-être les ressaisir manuellement.

             Option 1 (To get rid of all no-break spaces and tildes):
             
                Click the tab of your project to make it the active tab.
                From the Tools menu, point to Advanced and then select Replace No-Break Spaces With Normal Spaces.
                Read the warning message and click Yes if you are sure you wish to continue.

        If your project has been following the USFM manual and so has been manually inserting tildes either to represent no-break spaces or for some other function, follow the instructions in Option 2. Doing this sooner rather than later prevents Paratext from inserting any more occasional unwanted tildes.

             Option 2 (To get rid of no-break spaces, but keep all tildes):
             
                Click the tab of your project to make it the active tab.
                From the Tools menu, point to Advanced and then select Replace No-Break Spaces With Normal Spaces But Keep Tildes.
                Read the warning message and click Yes if you are sure you wish to continue.
        
         See also:
        
          Important information about no-break spaces and tildes

Traduit automatiquement depuis English Afficher l'original

Answer 1

Oui, je suis d'accord avec Matthew_Lee pour dire qu'il s'agit d'une question importante, en particulier dans le monde francophone. Il y a plusieurs points que je souhaite mentionner dans mon analyse, mais j'essaierai de résumer (TLDR) en bas de ce message.

Un peu de recherche en ligne révèle des choses intéressantes, qui ne sont pas vraiment « hors sujet » :

Et quelques échecs humoristiques (où ils utilisaient manifestement une espace normale - ce qui a cassé dans ce cas) :

C'est exactement ce que nous voulons éviter - des éléments de ponctuation non connectés à leur texte associé. Donc, si nous allons utiliser un certain type de caractère d'espace pour isoler la ponctuation, nous devons TOUJOURS utiliser une espace insécable d'une sorte ou d'une autre.

Les deux principales options sont l'Espace insécable (NBSP, U+00A0) ou l'Espace insécable étroite (NNBSP, U+202F), dont les définitions peuvent être trouvées dans la norme Unicode, aux adresses https://unicode.org/charts/PDF/U0090.pdf et https://unicode.org/charts/PDF/U2000.pdf, respectivement :

Comme vous pouvez le voir, la définition de la NNBSP indique qu'elle a typiquement la largeur d'une espace fine, qui est définie dans ce même graphique comme :

Ainsi, une NNBSP serait typiquement un cinquième d'un em (0.2em). Quelle est la taille d'une espace normale ou d'une NBSP ? Ces métriques dépendent de la police, mais un calcul approximatif avec la police Charis SIL montre que les caractères espace et NBSP sont d'environ 0.34em. La NNBSP est d'environ 0.22em. C'est une différence significative, et si vous utilisez une NBSP (ou, à titre de mesure temporaire, une espace normale, qui a l'inconvénient de casser à la ligne) autour de la ponctuation, les typographes que je connais diront que cet espace est trop grand. L'utilisation de la NNBSP aide considérablement et peut être faite assez facilement dans PTXprint avec des modifications comme les lignes suivantes dans PrintDraftChanges.txt :

' *:'  >    '\u202f:'     # Place non-breaking thin space before colon
'« *' >    '«\u202f'     # Place non-breaking thin space after opening guillemets
' *»' >    '\u202f»'     # Place non-breaking thin space before closing guillemets
'‹ *' >    '‹\u202f'     # Place non-breaking thin space after opening guillemets
' *›' >    '\u202f›'     # Place non-breaking thin space before closing guillemets

Cela place une NNBSP avant ou après (selon le besoin) la ponctuation, et supprime également les espaces qui y figurent (s'il y en a). Cela signifie que, que l'équipe mette des espaces ou non, ils seront normalisés en caractères NNBSP. Par exemple, dans ce projet, l'équipe est incohérente et utilise des (espaces) normales autour des points d'interrogation et des deux-points, mais pas autour des guillemets :

image945×67 35 KB

Notez que vous pouvez voir qu'il s'agit simplement d'espaces normales si vous ajustez le zoom et/ou la taille du panneau juste à point, car elles autoriseront une cassure de ligne, comme ceci :

image755×114 48.8 KB

Mais les modifications ci-dessus devraient pouvoir gérer correctement ces deux cas et insérer la NNBSP pour la composition typographique.

De manière similaire, vous voudriez mettre en place des règles de modification dans vos projets SAB, pour vous assurer que vos applications bibliques gèrent correctement les espaces. Consultez ce message pour des exemples de règles : https://community.scripture.software.sil.org/t/suggestions-for-changes-gallery/590/3.

Notez que les règles de ce message ne gèrent pas l'espace ou l'absence d'espace aussi élégamment que les règles ci-dessus, mais vous pouvez les ajuster avec des astuces comme " *" utilisées ci-dessus.

Et un dernier point avant d'aborder Paratext… Dans des travaux de composition typographique récents, nous avons en fait utilisé un dixième d'un em (0.1em) comme espace autour de la ponctuation, c'est-à-dire plus petit que la NNBSP. Voici la définition de la ponctuation que nous avons utilisée :

\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon

Note : cela a été fait dans XeTeX, mais la même chose pourrait être faite avec PTXprint. Je pense que vous voudriez que cela soit défini dans le fichier de configuration ptxprint-mods.tex disponible sur l'onglet Outils avancés. Cela donne un espace assez minimal autour de la ponctuation, comme on peut le voir dans cet exemple :

image752×102 11.5 KB

Mais les équipes ont estimé que c'était un espace suffisant pour répondre à leur besoin perçu d'espace autour de la ponctuation, qui est requis en français. (Bien sûr, les francophones peuvent ne pas être d'accord, mais ce n'est pas leur langue !)

Conclusion (TLDR) : Que signifie cela pour Paratext ?

Si l'équipe utilise des espaces normales dans le texte pour espacer sa ponctuation, alors parfois cela apparaîtra incorrectement sur leur écran dans Paratext (c'est-à-dire avec une ponctuation non correctement attachée à son texte, comme montré ci-dessus), ce qui est distrayant mais pas la fin du monde. Dans ce cas, la responsabilité incombe au typographe ou au créateur d'application de modifier ces espaces normales de manière appropriée. Malheureusement, si c'est la forme qui est mise dans le DBL (très probable), alors des applications comme YouVersion auront des problèmes, car elles ne gèrent pas ces espaces de manière appropriée, notoirement.

Compte tenu de cette tendance vers des espaces insécables de plus en plus petites pour isoler la ponctuation (d'abord la NNBSP à 0.2em, puis la composition manuelle à 0.1em avec PTXprint) que j'ai observée dans mes projets de composition typographique, je recommande presque toujours aux équipes de ne pas mettre d'espaces autour de leur ponctuation dans Paratext, et de simplement faire confiance à la composition typographique ou à la création d'applications pour faire la bonne chose autour de ces signes de ponctuation. Cela signifie que lorsque le texte est mis dans le DBL, YouVersion n'aura pas de ponctuation flottante. (Il n'y aura pas non plus d'espaces autour de la ponctuation, mais c'est un problème moindre à mon avis.)

Ainsi, avec ce plan d'action spécifique, aucune modification n'est requise dans Paratext. Si vous vouliez, comme l'a suggéré Matthew_Lee, un moyen d'afficher les caractères NNBSP ou NBSP, je pense que ce serait une bonne idée, mais nos claviers auraient aussi besoin d'un moyen de taper ces caractères (ce qu'ils ne font pas toujours), et Paratext devrait savoir de ne pas manipuler ces caractères. (Et les inventaires de ponctuation devraient afficher toutes les combinaisons avec ces espaces, pour s'assurer qu'ils étaient utilisés de manière cohérente, par exemple toujours avec une NNBSP.)

Ce message propose moins des solutions que de fournir plus de contexte et d'informations. Je n'aime vraiment pas la façon dont cette affaire de tilde / NBSP fonctionne dans Paratext actuellement, et je suis d'accord pour dire qu'elle devrait changer. Il semble que Paratext devrait supposer qu'il doit prendre chaque caractère du texte à la lettre, qu'il s'agisse d'un tilde, d'une NBSP ou d'une NNBSP. Et un moyen de les voir (subtilement) serait agréable. Deux espaces ou plus devraient-ils être automatiquement combinés (en réponse à @anon942452) ? Peut-être s'ils sont des caractères identiques ? Cela permettrait toujours la correction automatique des espaces de Paratext, mais fournirait aussi des options pour y échapper. Et il faudrait aussi trouver un moyen de gérer tous les projets anciens qui ont des tildes pour les espaces insécables, peut-être juste une conversion, pour les convertir tous en NBSP, une fois que cela sera géré correctement dans Paratext.

Bon, encore un peu de matière à réflexion…

Traduit automatiquement depuis English Afficher l'original

Comments

Certaines langues nationales d'Asie du Sud-Est utilisent un espace entre les phrases et non entre les mots. Certaines langues minoritaires utilisant ces écritures ont choisi d'utiliser un espace normal entre chaque mot et un espace plus large aux ruptures de phrase. Si un ESPACE EM (\u2003) est utilisé pour ces ruptures de phrase à espace large dans Paratext, alors les inventaires de caractères et de ponctuation traitent l'ESPACE EM comme un caractère formant mot plutôt que comme de la ponctuation, rendant impossible de vérifier les séquences correctes. J'ai signalé cela comme PTXS-31753.

Lorsque jeffh recommande aux traducteurs de laisser les espaces français hors de Paratext, il aide à s'assurer que le texte dans Paratext marque sans ambiguïté la structure/le sens au prix d'une présentation moins esthétique. Je fais de même lorsque je recommande l'utilisation de la virgule au lieu de l'ESPACE EM dans Paratext. Mais les utilisateurs ont raison de s'opposer aux deux suggestions ; je préfère moi-même grandement le WYSIWYG de Microsoft Word aux commandes à points de WordStar que j'utilisais sur mon premier ordinateur.

J'aimerais voir Paratext ajouter une option « Afficher les caractères invisibles » qui, par exemple, afficherait les caractères d'espace comme une boîte grise. Cet « Afficher les caractères invisibles » serait extrêmement bénéfique pour les langues qui tapent un Espace de largeur nulle (\u0200b) entre chaque mot. Actuellement, Paratext recommande de taper une barre oblique (/) entre chaque mot. Cette barre oblique est alors (hideusement) visible dans toutes les vues sauf l'Aperçu.

Je me demande si les zones francophones pourraient trouver une police qui soit soit (1) rend ~ beaucoup moins intrusif ou (2) ajuste automatiquement l'espace autour de la ponctuation selon le contexte.

Bénédiction,
LivingField

Traduit automatiquement depuis English Afficher l'original

---

Il peut parfois être préjudiciable pour Paratext d'accommoder les demandes de personnalisation. C'est particulièrement vrai lorsque la personnalisation n'est pas prise en charge par d'autres logiciels ou lorsqu'elle permet des choix qui vont à l'encontre de la direction dans laquelle le logiciel commercial se dirige. Les communautés linguistiques font alors des choix qui sont des impasses pour leur développement futur en dehors de Paratext. (Bien sûr, cela a aussi été très utile dans d'autres situations, les problèmes sont simplement complexes et nécessitent une réflexion attentive.)

Mais dans cette conversation, nous parlons d'accommoder des choix actuellement disponibles dans les logiciels commerciaux ainsi que d'un outil déjà couramment disponible. Si présenté ainsi dans une demande de fonctionnalité, je pense que nous pourrions avancer. Peut-être que ceux qui en savent le plus pourraient avoir une conversation séparée hors liste sur la meilleure façon de présenter la demande de fonctionnalité et ce qui est réellement le plus nécessaire.

Bénédiction,

Traduit automatiquement depuis English Afficher l'original

Answer 2

Merci Matthew_Lee, pour votre e-mail utile et informatif. Je n'ai pas de solutions à offrir, mais je suis très intéressé par le sujet et j'ai appris davantage grâce à votre rigueur. J'ai surtout du mal avec les caractères invisibles RTL et LTR qui affectent nos scripts complexes. S'il y avait un moyen de rendre tous les caractères invisibles légèrement visibles (ou d'activer/désactiver la visibilité avec une touche ctrl, par exemple), cela pourrait aider à résoudre plus facilement certains problèmes épineux auxquels nous sommes confrontés. Cette approche pourrait également rendre l'espace non insécable normal viable pour une utilisation dans Paratext, bien que je n'aie aucune idée des autres obstacles possibles à son utilisation du côté de la programmation.

Bénédiction,

Traduit automatiquement depuis English Afficher l'original

Answer 3

Cher Matthew_Lee, merci d'avoir soulevé cette question. Je travaille sur des langues des Premières Nations d'Amérique du Nord qui utilisent un script non romain (syllabaire canadien) et plusieurs orthographies majeures qui utilisent ce script font usage de diverses largeurs (trois largeurs) d'espace blanc pour indiquer les limites de morphèmes et de mots. L'espace de mot normal 0020 est considérablement plus large dans la police syllabique préférée, qui fonctionne bien dans Paratext. Mais l'espace insécable étroit (U+202F) est 1/3 de la largeur de l'espace de mot normal. L'utilisation de cet espace est critique dans notre langue également – il doit être utilisé à l'intérieur des mots comme limite de morphème et aussi (comme c'est fait en français) pour séparer la ponctuation de la fin des phrases. Enfin, dans de nombreuses situations, une troisième largeur d'espace insécable est nécessaire. Depuis des années, les communautés linguistiques avec lesquelles nous travaillons utilisent deux espaces insécables étroits (U+202F U+202F) consécutifs pour fournir un espace insécable entre les préfixes et les radicaux des mots, empêchant les orphelins en fin de ligne et fournissant un indice visuel du début du radical. La largeur de ceux-ci équivaut à 2/3 d'un espace de mot standard.

Malheureusement, depuis Paratext 7, il existe un algorithme Paratext qui supprime tout deux caractères d'espace blancs identiques consécutifs et les remplace par un seul. Nous avons dû trouver une solution de contournement hasardeuse en créant un clavier Keyman qui insère un espace insécable de largeur nulle (U+200D) pour empêcher Paratext de remplacer notre double espace fin intentionnel (U+202F U+202F) par un seul.

Lors de l'exportation de notre Bible vers le DBL, cette séquence était inacceptable, nous devons donc d'abord exécuter un programme de conversion qui remplace toutes les séquences (U+202F U+200D U+202F) par un espace insécable « standard » (dans Paratext, « tilde », qui devient U+00A0).

Bref, tout cela pour dire que je soutiens votre sujet de réexamen du tilde comme espace insécable, pour les raisons que vous donnez, et je voulais donner mon avis avec un script qui utilise trois largeurs distinctes d'espace blanc.

Cordialement, anon942452 J

Traduit automatiquement depuis English Afficher l'original

Comments

Les technologies web modernes ont tendance à compresser les espaces dupliqués sans demander, mais permettent GÉNÉRALEMENT l'alternance entre plusieurs types d'espacement. Pour cette raison, les concepteurs web ont longtemps abusé de l'espacement en alternant espace et nbsp au lieu de définir des retraits. @anon942452 a trouvé une méthode qui fonctionne pour outrepasser le nettoyage automatique des déchets de la même manière.

Si j'ai bien compris, je rejoins @Shegnada sur le fait que permettre aux utilisateurs de faire dans Paratext des choses qui fonctionnent déjà dans les outils d'entreprise devrait présenter un faible risque, mais créer de nouveaux flux de travail personnalisés qui ne fonctionneront que dans Paratext prépare la communauté à des défis de littératie et de publication plus tard. J'ai vu cela avec des personnes qui s'enferment dans des polices modifiées et d'anciennes macros.

J'espère que Paratext pourra apprendre à prendre en charge tous les espaces, afin que le projet Paratext puisse être la référence (gold standard).

Le premier défi est d'accepter les espaces et de permettre leur passage vers DBL et l'édition numérique/imprimée. Peut-être suis-je un optimiste, mais les applications mobiles, inDesign et HTML ne devraient pas poser de problème, car il s'agit de glyphes Unicode dans les polices suggérées. TeX (PTXPrint) nécessitera un peu de prétraitement, mais des outils existent dans TeX pour gérer cela. Si les outils en aval comme YouVersion doivent apprendre à utiliser des espaces/casse-lignes avancés, c'est une discussion qui vaut la peine d'être menée.

Le deuxième défi est de faciliter le travail avec l'espacement avancé dans Paratext. J'AIMERAIS VOIR des carrés gris pour les espaces insécables. L'outil de ponctuation pourrait simplement fonctionner, car il affiche déjà les valeurs Unicode pour les combinaisons.

Traduit automatiquement depuis English Afficher l'original

Answer 4

Je pense qu'en tant que proposition initiale, nous pourrions demander à Paratext d'ajouter dans le menu Project View une option « Afficher la mise en forme cachée ». Lorsque vous faites cela dans Word, vous obtenez le suivant pour une série de trois espaces, trois NBSP et trois NNBSP (202F) :

Dans LibreOffice Writer, vous obtenez :

LO Writer n'affiche pas les NBSP, et aucun des deux n'affiche les NNBSP. Pour être la référence, nous voudrions le faire. Mais vous ne voulez pas non plus avoir un symbole différent pour chaque mise en forme cachée possible, alors passerions-nous à l'affichage du code du caractère, à l'exception de quelques caractères majeurs comme l'espace et le NBSP (qui auraient un symbole), peut-être dans un motif diagonal petit ? Que diriez-vous de quelque chose comme ceci :

image772×660 19.4 KB

Je pense qu'il est utile d'afficher la mise en forme cachée dans une couleur différente. Matthew_Lee suggère le gris, LO Writer utilise le bleu, Word continue simplement d'utiliser le noir. J'aime aussi l'idée du gris, mais l'astuce sera de trouver la bonne nuance de gris, pour qu'elle soit visible mais subtile.

Évidemment, si nous affichons un code de caractère, alors toutes les mises sont perdues pour la largeur réelle du caractère. C'est aussi le cas pour la mise en forme cachée affichée dans Word ou LO Writer.

Quant à la « simplification » des espaces par Paratext, je proposerais que Paratext continue de condenser plusieurs espaces en un seul espace, mais UNIQUEMENT pour les espaces réels U+0020. Tout autre espace ou caractère de mise en forme cachée serait maintenu.

Éventuellement, nous voudrions probablement avoir des raccourcis pour TAPER ces caractères de mise en forme cachée directement dans Paratext également, mais pour l'instant, nous pouvons compter sur AUTOCORRECT.TXT et/ou les claviers Keyman pour taper ces caractères.

OK, donc c'est une idée, lancée dans l'arène… Quels sont les avantages et les inconvénients ? Quelles autres idées avez-vous ?

Traduit automatiquement depuis English Afficher l'original

Comments

C'est ce que je voulais dire par LibreOffice (6) affichant les NBSP comme je m'en souvenais : ce n'est même pas le mode d'affichage de tous les caractères, juste une vue normale. Je crois que c'est le paramètre par défaut. Ce n'est pas la même chose dans LO 7 ?

Vous avez raison de dire qu'il n'affiche pas les NNBSP (même en mode afficher tout, mais nous obtenons des points comptables pratiques pour le NBSP et l'espace.

La proposition diagonale de jeffh est élégante, mais nous aurions besoin d'une police avec ces lettres. Il existe des polices existantes qui utilisent un carré alphanumérique pour afficher les valeurs Unicode des polices.

J'ai peur que permettre des espaces non normaux dupliqués entraîne un retrait multi-espaces, tout comme les gens abusent déjà de cette possibilité dans Word, mais cela s'alignerait avec les autres normes web de flux de texte.

J'ai le NBSP sur mon clavier depuis des années, mais j'ai aussi des choses comme le trait d'astérisque, le copyright et le cercle vide.

Traduit automatiquement depuis English Afficher l'original

---

Il y avait une option désactivée dans ma configuration de LO Writer 7 dans Outils - Options - LibreOffice Writer - Aides à la mise en forme, l'option Espaces insécables était désactivée. En l'activant, j'obtiens bien le carré gris dont vous parliez :

Mais pas un point…

Traduit automatiquement depuis English Afficher l'original

Answer 5

C'est une conversation très encourageante. C'est formidable d'entendre parler des besoins et des solutions potentielles dans le contexte de Paratext et d'autres outils. J'imagine que c'est quelque chose qui serait « utile pour beaucoup » et qui sera donc probablement considéré avant certaines fonctionnalités moins utiles.

(En passant - parce que je pense avoir vu quelques mentions de la façon de taper certains caractères qui n'apparaissent pas sur les claviers standards … Pour ceux qui ne le savent pas déjà, la saisie de caractères inhabituels sans application tierce peut être facilitée en utilisant l'application Character Map dans Windows. Lorsque vous cliquez sur un caractère dans la carte des caractères, il affiche un raccourci « Keystroke » en bas à droite de l'application pour de nombreux caractères. Ce raccourci peut être saisi en maintenant Alt et en tapant quatre chiffres du pavé numérique (pas les chiffres au-dessus des lettres). Par exemple : Alt+0160 tape un espace insécable (U+00A0), Alt+0169 génère le symbole ©, le tiret demi-cadratin est Alt+0150 –, tandis que le tiret cadratin est Alt+0151 —.)

Traduit automatiquement depuis English Afficher l'original

Answer 6

Juste un commentaire concernant la publication numérique via le DBL. Le téléverseur Paratext supprime les espaces insécables lors de la création du bundle USX que nous partageons avec l'éditeur. Malheureusement, lorsqu'un texte est partagé numériquement, les espaces insécables ont historiquement causé des problèmes.

Traduit automatiquement depuis English Afficher l'original

Comments

anon175865:

Malheureusement, lorsqu'un texte est partagé numériquement, les espaces insécables ont historiquement causé des problèmes.

Et que dire de NE PAS utiliser d'espaces insécables ?! Voici une page aléatoire de la Parole de Vie, une traduction française bien respectée, telle qu'elle est vue dans YouVersion, une application biblique bien respectée :

image360×760 123 KB

Notez les coupures de ponctuation cassées (problème) qui sont surlignées. Je fronce les sourcils chaque fois que je vois cela, et je le vois BEAUCOUP sur les textes extraits du DBL précisément (j'imagine) parce que les espaces insécables valides ont été convertis en espaces réguliers.

Si nous gérons bien les espaces insécables dans Paratext, alors je pense que le téléverseur ne devrait pas les supprimer lors du téléversement vers le DBL. Alors faisons-le !

Traduit automatiquement depuis English Afficher l'original

---

Je suis d'accord pour dire qu'ils « ont historiquement » causé des problèmes. Cela aurait été vrai dans l'ensemble avant Unicode, mais si les créateurs de contenu et les éditeurs en aval n'ont toujours pas appris à prendre en charge les espaces spéciaux, il est temps qu'ils le fassent.

Supprimer les NBSP aujourd'hui est une erreur, car les technologies d'affichage que nous utilisons ont toutes un processus pour gérer les espaces correctement encodés (HTML, XML, TeX, inDesign), et ces espaces font partie des guides de style de nombreuses langues majoritaires et minoritaires du monde. Tout le code sous Paratext a la possibilité d'être modifié, y compris l'affichage interne et l'exportation USX. TeX et SAB gèrent déjà tous ces espaces, sinon le hack print-draft-changes ne fonctionnerait pas dans print draft ou ptxPrint (peut-être que quelqu'un de PTXPrint peut donner son avis). Si les normes USFM et USX interdisent actuellement les espaces insécables, elles devront être modifiées.

Je savais que ce changement devrait être apporté à toute la chaîne, mais cela ne le rend pas moins important. Paratext, Chorus, USFM, USX et d'autres devront cesser de les supprimer et commencer à les prendre en charge et à les afficher. Je soupçonne que les cas limites principaux seront si quelqu'un choisit de remplacer CHAQUE espace par un NBSP et a débordé d'une ligne.

Ici au Cameroun, je parle encore des caractères IPA de la langue comme de « caractères spéciaux », mais avec le large soutien que nous avons, l'un des linguistes ici m'a récemment rappelé que nous devrions simplement les appeler « caractères ». Les outils qui ne peuvent pas prendre en charge une grande variété de caractères dans le texte deviennent de plus en plus rares. La dernière frontière semble être la prise en charge des caractères spéciaux dans les noms de dossiers pour les logiciels en ligne de commande Windows. Windows prend cela en charge depuis des années, mais les choses sont encore déformées.

~Matthew_Lee

Traduit automatiquement depuis English Afficher l'original

---

Bonjour jeffh,

J'ai transmis votre préoccupation à nos amis de YouVersion… bien que je pense que le processus de conversion des espaces insécables en espaces réguliers est effectué dans le téléverseur Paratext, et non du côté de YouVersion (ou de tout autre éditeur).

Traduit automatiquement depuis English Afficher l'original

---

Merci d'avoir fait le lien avec les gens de YouVersion @anon175865. Oui, comme vous l'avez mentionné, j'imagine que tous les espaces insécables ont déjà disparu dans le DBL, supprimés par le téléverseur Paratext. Donc, ce n'est pas leur faute. Ce que @Matthew_Lee et moi disons, c'est que nous devons réparer notre chaîne, afin que Paratext soit à l'aise avec ces espaces spéciaux et puisse les gérer facilement, et que le téléverseur ne les supprime pas. Alors ils seront là dans le DBL, et lorsque YouVersion utilise ces textes, ils s'afficheront correctement à l'écran.

Traduit automatiquement depuis English Afficher l'original

Answer 7

WSTech a discuté de certains des problèmes dans ce fil, et je voulais envoyer un résumé :

• Je soupçonne que la très grande tilde qui est affichée (pour le NBSP) provient de la police Charis SIL. Si une autre police de script latin est utilisée, la taille de la tilde change-t-elle ?
• Il existe des polices qui ajustent automatiquement l'espacement autour des signes de ponctuation (comme nécessaire dans les zones francophones), mais semblent être rares. Donc, mettre les espaces nécessaires semble être la meilleure approche.
• L'utilisation d'une police séparée pour afficher les valeurs Unicode des espaces (c'est-à-dire, pas la police principale utilisée pour le texte) devrait fonctionner.
• PTXprint peut gérer tous les différents caractères d'espace.

Traduit automatiquement depuis English Afficher l'original

Comments

WSTech a également récemment ajusté la largeur des espaces dans nos polices. Pour la rétrocompatibilité, les polices de script latin (et peut-être d'autres) ne suivent pas nos nouvelles recommandations pour tous les espaces, seulement pour certains espaces.

Traduit automatiquement depuis English Afficher l'original

---

Je suis encouragé d’avoir reçu des nouvelles de tant de personnes, y compris de WSTech et de Paratext. Comment faire avancer les choses ? Faut-il rédiger une demande de fonctionnalité et la soumettre au processus normal de priorisation ?

Les grands problèmes (qui peuvent être traités séparément) sont les suivants :

1. Permettre aux caractères NBSP et similaires mentionnés dans ce fil de coexister dans toute la chaîne PTX/USFM/USX/DBL (et de gérer les problèmes d’affichage qui en découlent au besoin). C’est le premier et le plus important obstacle. Ensuite, nous pourrons « corriger » l’espacement dans les projets individuels à l’avenir.

• Ces caractères doivent s’afficher correctement dans PTX standard et dans les aperçus.
• Ils doivent être reconnus individuellement dans les vérifications de ponctuation et de caractères.
• Ils doivent être acceptés dans les paramètres de citation et de numéros (notez que FLEx utilise des points pour afficher les espaces dans Configurer le dictionnaire).

2. Fournir un moyen dans Paratext de visualiser ces caractères.

• Des polices temporaires spéciales ont été proposées comme possibilité.
• Des carrés gris permanents ont été suggérés.
• Une fonction d’affichage de tous les caractères similaire à celle de Word/LibreOffice.
  • L’un de mes utilisateurs a suggéré que la fonction Afficher/Masquer ouvre une boîte de dialogue (similaire à la boîte de dialogue Basic Checks) permettant de spécifier quels caractères spéciaux afficher (espaces normales, espaces insécables, connecteurs, traits d’union insécables, marqueurs bidirectionnels, retours à la ligne doux et durs). Je peux imaginer des cas où un technicien souhaite que tous les marqueurs soient surlignés (ce que je fais souvent dans des outils externes), ainsi que des situations où l’équipe n’a besoin que des marqueurs « spéciaux » surlignés.
  • 

~Matthew_Lee

Traduit automatiquement depuis English Afficher l'original

---

Matthew_Lee:

Comment faire avancer les choses ? Faut-il rédiger une demande de fonctionnalité et la soumettre au processus normal de priorisation ?

Oui, ce serait la meilleure option. Il serait également utile de lier ce fil à toute demande de fonctionnalité.

Pour ceux qui ne connaissent pas le processus de création d’une demande de fonctionnalité – il est disponible pour tous les utilisateurs de Paratext. Depuis le menu principal de Paratext, sélectionnez Help > Give feedback et choisissez l’option Make a suggestion... dans le formulaire qui s’affiche.

Si quelqu’un estime qu’une demande de fonctionnalité est particulièrement importante ou utile, il vaut la peine d’en informer votre représentant régional ou organisationnel pour Paratext. Ils peuvent choisir de la présenter lors des réunions trimestrielles de priorisation de Paratext.

Traduit automatiquement depuis English Afficher l'original

Answer 8

Cela a maintenant été soumis en tant que demande de fonctionnalité. Ce fil a été référencé dans le rapport.

Rapports pertinents :
https://paratext.myjetbrains.com/youtrack/issue/PTX-22626
https://paratext.myjetbrains.com/youtrack/issue/PTUX-1318
https://paratext.myjetbrains.com/youtrack/issue/PTX-22623

Traduit automatiquement depuis English Afficher l'original

Comments

Un autre commentaire que j’ai ajouté dans YouTrack :

Les caractères invisibles doivent être répertoriés dans les inventaires de caractères et de ponctuation, ce qui sera notre meilleure indication qu’ils existent et dans quels contextils ils existent. Ils doivent également être autorisés comme séparateurs valides dans les paramètres de citation ([NBSP]»), les paramètres de références bibliques (1[NBSP]Rois) et les paramètres de numéros (10[NBSP]000). Cela couvrirait de nombreux cas d’utilisation.

Traduit automatiquement depuis English Afficher l'original

Answer 9

Je suis en retard ici, je viens de découvrir le sujet.

Je donne mon +1, ou plutôt mon +100000, pour ces fonctionnalités proposées. Je travaille pour une autre langue, où, pour des raisons historiques et de coexistence, l’orthographe essaie d’être aussi proche que possible du français.

Je rappellerai à tous de se documenter sur le français avant d’apporter des modifications techniques. La typographie française est encore plus complexe que ce que les profanes ne le savent. Oui, il y a des espaces autour de certains caractères de ponctuation, mais ils ne sont pas les mêmes. L’espace avant (à gauche) d’un deux-points doit être de taille pleine, par exemple.

J’ai un document, compilé à partir de plusieurs sources, et la source principale n’est malheureusement plus en ligne.

grafik1237×800 71 KB

Il existe également des livres papier utiles, comme « Lexique des règles typographiques » en usage à l’imprimerie nationale » de l’imprimerie nationale (de France) et « Règles de l’écriture typographique du français à l’usage des personnes qui exercent une activité sur MAC ou PC » de Yves Perrousseaux.

Traduit automatiquement depuis English Afficher l'original

Answer 10

Jusqu’à présent, nous utilisons pleinement et embrassons la tilde dans PT, comme d’autres gèrent XeTeX et ont mon admiration – mais pas mon désir d’être comme eux.

La logique de publication fréquente par application et par portion d’Écriture est également pertinente pour notre contexte. Et la tilde doit disparaître bientôt.

Aussi, plus de polices doivent fournir le non-insécable étroit. Il semble que même toutes les polices SIL ne le fassent pas. Criez-moi dessus si elles le font ; ce serait une bonne nouvelle pour moi, bien méritée d’un cri.

Pour saisir la tilde maintenant (NNBSP bientôt, j’espère), j’ai inventé une fonctionnalité ingénieuse pour PT, où j’utilise la fonctionnalité intégrée autocorrect.txt. Par exemple, pour obtenir une tilde plus un point d’exclamation, je tape trois fois le point d’exclamation et PT fait le reste de la bonne manière. J’ai ce paramétrage pour toutes ces ponctuations qui nécessitent un soin particulier.

(Et j’utilise aussi cela pour saisir des mots fréquents comme Abraham, Jésus ou Jérusalem.)

Traduit automatiquement depuis English Afficher l'original