|
La solution que j'ai mise en œuvre consiste à assigner une combinaison de touches clavier au caractère unicode U+202f dans mon éditeur et les saisir manuellement. Mais dans le .pdf résultant de la compilation XeLaTeX, je constate que si l'insécabilité semble avoir été respectée — je n'ai pas vu de signes de ponctuation («»!?;:) orphelins (renvoyés à la ligne par exemple)… je constate que de visu les guillemets, points d'exclamation, d'interrogation, etc. sont séparés du texte qui précède ou qui suit par un espace que rien ne différencie a priori d'un espace de largeur normale. Pire, j'ai même l'impression que dans certains cas latex/xelatex étire (stretch) ces espaces comme il le ferait dans un souci d'esthétique pour des espaces standard/sécables. J'ai constaté par ailleurs que j'obtiens le résultat identique quand j'utilise '\,' (soit solidus inverse + virgule) qui j'avais cru le comprendre est la représentation canonique de l'espace mince/étroit insécable en syntaxe LaTeX (?) Je n'ai aucun problème côté saisie (ou les regex pour les insérer dans les textes scannés et OCR-isés) mais par contre je souhaiterais que mes espaces minces/étroits soient mieux respectés avec juste un espace tout juste visible, ce qui, pour moi (à tort ou à raison), est un des aspects les plus attrayants de la typographie française notamment quand on compare avec l'espagnol, l'allemand, l'italien, ou le portugais (et bien sûr l'anglais moderne), où des signes de ponctuation comme les guillemets doivent être directement collés à ce qui suit/précède. Avis personnel : je trouve ce choix d'absence d'espace à la fois pas très joli et peu lisible — un comble quand il s'agit par exemple d'un point d'exclamation censé attirer l'attention du lecteur notamment quand il est précédé d'une lettre tel que le 't', le 'l' etc. : suivant la police utilisée cela peut les rendre quasiment invisibles. Comme je ne sais des règles de la typographie du français que ce que j'ai pu glaner ici et là sur internet et vu que l'utilisation de cet espace mince/étroit est beaucoup plus fréquente que dans les autres langues que je pratique, j'ai pensé qu'il serait intéressant de poster sur ce forum où j'imagine que j'aurai plus de chances de rencontrer des utilisateurs qui sont quotidiennement confrontés au problème. En résumé… est-ce que je m'y prends mal ou y a-t-il un problème avec mon environnement LaTeX prévu initialement pour la publication de textes en langue anglaise ? |
|
J'utilise effectivement le package microtype. Quant à l'ECM cela ne sera pas nécessaire. Explication : En amont de la compilation xelatex, j'utilise un utilitaire nommé pandoc qui m'évite la mise au format latex de mon document ; en fait je travaille sur des fichiers de type .txt agrémentés d'un marquage rudimentaire de type markdown qui a en outre l'avantage que les fichiers source demeurent très lisibles. L'utilitaire pandoc se charge de générer le fichier latex que je convertis ensuite grâce à xelatex au format pdf. Suite à vos remarques ci-dessus, j'ai d'abord créé un ECM de trois lignes avec, qui un point d'exclamation… qui un point d'interrogation… en prime un dialogue très court entre guillemets, etc. toutes ponctuations bien sûr séparées du texte par des espaces minces. Hélas le fichier latex créé par pandoc contient une floppée de packages latex dont la plupart n'ont aucun rapport avec le problème qui nous concerne. Pas vraiment ravi par la taille et l'aspect de mon ECM, je m'apprêtais à procéder à lélagage de tout ce superflu afin de pouvoir présenter quelque chose qui se rapprocherait de l'ECM que vous me demandiez. C'est alors que j'ai eu l'excellente idée de jeter un œil à un document que j'avais créé en latex natif il y a environ un an… également en français. Or il s'avère que dans le .pdf que j'avais créé à cette époque les espaces minces sont minces à souhait ! Je n'ai bien entendu pas identifié à ce stade la cause exacte du problème mais il est évident qu'elle doit se trouver quelque part parmi les 40-50 lignes du préambule généré par pandoc. Donc à moins que vous ne soyiez vous-même utilisateur de pandoc et à ce titre que la résolution du problème vous intéresse suffisamment pour y consacrer un peu de temps… c'est bien vers les développeurs de pandoc des gens au demeurant fort sympathiques et qui se sont montrés très réactifs par le passé en ce qui me concerne que je dois à présent me tourner. Bien entendu, au cas où vous souhaiteriez jeter un œil au fichier latex généré par pandoc lors de mon test, je suis à votre disposition. @Chris Jones XL : formidable ! La rédaction d'un ECM permet souvent d'avancer vers la solution du problème. N'hésitez pas à « accepter » votre propre réponse en cliquant sur la boîte à cocher, en haut à gauche de votre réponse. |
|
Hum… disons que l'ECM sert avant tout à fesser les fâcheux qui créent un ticket auprès du support technique sans se donner le mal de faire une recherche préalable et qui comptent sur les âmes charitables pour résoudre leur problème sans effort de leur part. :-) Il est vrai néanmoins que certaines personnes (parfois parce qu'ils sont contraints à décrire leur problème dans une langue qui n'est pas la leur… mais pas que…) ont les pires difficultés dès qui s'agit d'expliquer ce qui les amène et que tout le monde n'a pas le goût des devinettes. Dans le cas qui nous occupe, c'est malheureusement la couche de complexité rajoutée par Vous pouvez voir des exemples de PDF que j'ai générés en utilisant Ce n'est certes pas du niveau du travail d'un professionnel de la typographie ou d'un spécialiste LaTeX, mais cela montre qu'un dilettante peut, sans bagage technique et avec un minimum d'efforts, obtenir grâce à |
|
Pour info… en remplaçant : \ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex \usepackage[shorthands=off,main=french]{babel} \else \usepackage{polyglossia} \setmainlanguage[]{french} \fi dans le généré \usepackage[french]{babel} … la typographie des espaces minces est corrigée. Je n'en sais pas plus à l'heure actuelle mais le problème semble être causé par les packages Nul doute que cette information sera précieuse pour des utilisateurs de pandoc, qui vous sauront gré de l'avoir partagée. |
|
Ayant jeté un œil à la documentation du package polyglossia… j'y ai appris que pour le français les espaces minces liés à la ponctuation sont gérés automatiquement. J'en déduis — sans en avoir la preuve pour le moment, que dans la mesure où mon fichier source contient déjà des espaces minces partout où les règles de la typographie française l'exigent, polyglossia ajoute un deuxième espace mince…? et au final j'ai donc un double espace mince dans mon PDF… ce qui ressemble furieusement à un espace standard. Pour l'éviter il existe heureusement une option |
|
Remarque typo, pour commencer : en typographie, le mot « espace » est féminin. L’espace dont tu parles, Chris, est appelée « espace fine ». Sa chasse (sa largeur) est égale approximativement à la moitié d’une espace ordinaire, soit à peu près un huitième de cadratin (0,125 em). La présence d’espaces fines dans le source Tex interfère effectivement avec le fonctionnement de Babel (et de Polyglossia, je suppose, mais je ne l’utilise pas). Le plus simple, dans ton fichier Markdown est de supprimer les fines avant les signes de ponctuation haute et avant/après les guillemets, pour laisser ensuite faire Babel French ou Polyglossia. C’est rapide avec les expressions rationelles : — chercher : s([:;?!»›]) — remplacer par: 1 — chercher : ([«‹])s — remplacer par: 1 |
|
@Thomas_Savary : Merci de corriger mon français souvent défaillant pour les aspects genre (gender) et je ne vous parle même pas des doubles consonnes…! Par contre, il ne saurait être question de modifier ma méthode de travail en ce qui concerne les espaces fines. J'ai choisi de les saisir manuellement dans la mesure où je n'utilise latex que rarement (et jamais les processeurs de textes). Et comme je ne souhaite pas avoir à changer mon méthod travail suivant le contexte je trouve beaucoup plus simple de m'en occuper moi-même que de faire confiance au logiciel. J'avais cru comprendre que c'est à l'ordinateur de s'adapter à l'utilisateur et non l'inverse. Je n'ai pas bien compris votre explication the la marche à suivre concernant les « expressions rationelles » (regular expressions, j'imagine… avec le sexe supposé des espaces typographiques, j'apprend beaucoup de choses avec vous). La méthode que j'utilise (notamment pour les textes OCR-isés) est la suivante : — rechercher les [:;?!»] précédés d'une (ou plus) espace quand elles existent et les supprimer, — rechercher les caractères suivis d'un [:;?!»] en prenant soin de les mémoriser, — substituer le caractère mémorisé (CM) suivi d'un des signes de ponctuation (P) par CM+°+P Sous vim cela donne quelque chose comme: " j'élimine les séquences de 1 à n espaces {1,}) précédant les ponctuations cible [!?;:»] :%s/ {1,}([!?;:»])/1/g " j'insère des espaces fines entre le caractère précédent et le signe de ponctuation :%s/(.)([!?:;])/1°2/g " où '°' représente U+202f l'espace fine insécable Bien entendu ces commandes sont mémorisées dans l'historique des commandes vim ce qui me permet de ne pas avoir à les saisir à chaque occasion (je tape le début et un petit coup the CTR+P pour les faire réapparaître). Et au cas où il s'agirait de traiter les 30-40 fichiers correspondant aux chapîtres d'un gros livre de 1200 pages… il me suffit de faire précéder mes :s (substitute) par ':bufdo' pour faire tout en une seule passe… cinq secondes chronos¹… que demande le « people » ! Le jour où les logiciels ergonomiques de qui vous savez pourront faire ce genre de chose… les secrétaires et les comptables seront computer scientists. Cordialement CJ ¹ j'exaggère à peine… il me faut bien sûr une seconde passe pour les guillemots ouvrants… |
|
Il s'avère que dans mon message précédent, l'éditeur a mangé mes barres obliques inversées !… Correction : :%s/ \{1,\}\([!?;:»]\)/\1/g :%s/\(.\)\([!?:;]\)/\1°\2/g |
Pourriez-vous poster un ECM illustrant votre souci ?
Utilisez-vous le package microtype ?