Comment soigner les orphelins de fin de paragraphe
January 14, 2010 | Extras | fr
Pour des raisons que j'aurais du mal à appuyer sur des bases orthotypographiques solides, j'éprouve de l'empathie pour les mots isolés. Quand InDesign décide — fût-ce avec les meilleurs arguments du monde — de rejeter à la ligne le dernier terme d'un paragraphe, une sorte de frisson communautaire me saisit. Par des moyens pas toujours avouables, je tente alors de raccrocher le wagon à son prédécesseur, quitte à lui antéposer manuellement une espace insécable justifiante. Beurk ! Et si l'on appelait les « Styles Grep » à la rescousse...
La capture ci-dessus fixe la situation initiale de cet exercice. On aperçoit en rouge les mots orphelins de la composition courante. (En vérité, ce ne sont pas des orphelins au sens strict, il faudrait plutôt les appeler « orphelins de paragraphe ».) Dans un premier réflexe, on se verrait bien appliquer une espace insécable justifiante avant chacun de ces mots, ou bien user de l'option « Sans retour automatique » pour solidariser les termes à la fin du paragraphe.
L'espace insécable est une mauvaise option, car cela consisterait à ajouter un caractère que le texte ne requiert pas sur un plan strictement typographique. Après tout, le traitement des orphelins de paragraphe n'est qu'un choix esthétique — un choix humanitaire — dont on ne saurait faire peser la subjectivité sur nos confrères.
Ainsi, le maquettiste responsable doit rechercher une issue par stylisation (des paragraphes et/ou des caractères). Comme chacun sait, InDesign propose parmi ses « Options d'enchaînement » (niveau paragraphe) tous les outils pour conjurer les lignes veuves et orphelines. Accessoirement, les « Paramètres de la césure » permettent de proscrire la division d'un mot entre deux colonnes (« Césure sur la colonne ») ainsi que la division du dernier mot d'un paragraphe (« Couper le dernier mot »). Toutefois, aucun paramètre n'est offert pour augmenter la solidarité des mots à la fin d'un paragraphe.
Le style NO_WRAP
C'est le paramètre « Sans retour automatique », évoqué plus haut, qui va nous tirer d'affaire. Comme il s'agit d'un attribut de caractère, il peut intervenir isolément dans la formation d'un style de caractère. Par ailleurs, tout caractère porteur de cet attribut interdit le retour à la ligne à son emplacement. Ainsi, un simple caractère d'espace se comportera comme insécable si nous l'étiquetons « Sans retour automatique ».
Voyons où cela nous mène. Créons sans plus tarder un style de caractère, NO_WRAP, dont la seule fonction sera d'activer l'attribut « Sans retour automatique » :
A priori, NO_WRAP ne sert pas à grand-chose, mais supposez juste une seconde que nous parvenions à l'appliquer automatiquement à tout espace précédant un mot orphelin...
Appliquer NO_WRAP par un Style Grep
Pour voir, considérons maintenant le style de paragraphe utilisé dans notre composition principale (chez moi, il s'appelle LABEUR). Afin de bien décomposer les mouvements, dupliquons-le (sélection + « Créer un nouveau style »), puis nommons son duplicata LABEUR_SansOrphelin.
Éditons LABEUR_SansOrphelin (double-clic). La seule spécialisation que nous allons lui apporter par rapport à LABEUR est une règle de « Style Grep ». (Si votre style de travail comporte déjà d'autres instructions Grep, je vous laisse juge de la priorité à appliquer vis-à-vis des autres règles.)
L'expression régulière que nous utilisons ci-dessus — " (?=[^ ]+$)"
(sans les guillemets) — fait appel au lookahead positif, elle sélectionne un caractère d'espace sous réserve qu'il soit suivi d'une séquence de la forme "[^ ]+$"
, c'est-à-dire d'une suite de caractères sans espace concluant un paragraphe ou un article. En clair, notre regex met en joue toute espace située avant le dernier mot. Le mécanisme des Styles Grep permet alors de lui affecter le style NO_WRAP, ce qui rend artificiellement cette espace insécable.
À noter que j'ai délibérément ignoré dans ce traitement les espaces spéciales (fines, ultra-fines, etc.), lesquelles seront donc considérées comme des caractères déjà rattachés et ne devant être pris en compte dans la détection des mots orphelins. Ainsi, l'espace fine située avant un point d'interrogation final ne vaudra pas comme caractère de séparation.
Il n'y a plus qu'à appliquer à notre texte le style LABEUR_SansOrphelin, à la place de LABEUR. Le résultat est immédiat et ne nécessitera plus aucun retraitement manuel :
NB. — Klaus Nordby m'a invité à réfléchir à un problème similaire portant sur les caractères singletons isolés en fin de ligne. Faut-il parler de « veufs de ligne » ? Quoi qu'il en soit, une solution analogue peut être mise en œuvre pour les rattacher à la ligne à suivre. On appliquera par exemple le style NO_WRAP sur la regex :
"\<\w "
(sans les guillemets).
Comments
Bonjour Marc,
Approche originale pour ces problèmes de mots seuls en fin de paragraphe qui trouvera partisans et détracteurs (cf. débat sur le forum Adobe : Orphans Words, http://forums.adobe.com/message/228...). Comme il est aussi suggéré, une autre approche peut être de privilégier un nombre de caractères avec, par exemple, .{15}$
J'ai fait quelques essais avec les deux approches, et selon les réglages de justif et autres, le mot seul peut parfois "remonter" à la ligne précédente et non pas être précédé d'un autre mot sur la dernière ligne.
Amitiés
Merci Laurent pour ton message et pour le lien du forum Adobe.
> Comme il est aussi suggéré, une autre approche peut être de privilégier
> un nombre de caractères avec, par exemple, .{15}$
Excellente piste. On peut par exemple décider d'empêcher les mots orphelins très courts, genre moins de 6 lettres, qui sont visuellement les plus disgracieux. Dans ce cas, ma regex devient:
" (?=[^ ]{1,5}$)"
(sans les guillemets)
Quoi qu'il en soit, je suis bien d'accord que n'est pas de la « pure » typographie ; on est plutôt dans le registre du nettoyage esthétique, de plus ou moins bon aloi. Mais l'expérience est plutôt amusante, et j'avoue que j'utilise assez souvent cette astuce en composition sur les grandes justifs.
@+
Marc
(Sorry to write in english)
Orphans are nor at all a problem. They are intrinsic to text. And necessary: adds wonderful white space... Some publishers destroy books avoiding orphans (in Spain Pretextos, the marvelous publishing house use to change the leading in some pages to avoid these...: with a semitransparent paper the backing-up is lost)
We have more interesting problems:how to visualize widows and how to fix them with scripting? (distinguished newspapers and magazines do not care about widows and perhaps this tendency will gain while we won't provide them with automated tools. It is no time to wasting time looking for widows... It has to be a mechanical process.
Or how to avoid (ugly) hyphenated word at the last line in a page, specially if this page is odd? Of course the manual and tedious shortcut command+shift+hyphen before the word is just enough. How to script these to visualize and check one second before the last pdf for print is going to be processed?
Hi Mariana,
Thank you for your comment.
> Some publishers destroy books avoiding orphans [...]
You are absolutely right. A text layout needs white space to breathe. My purpose here is not to ‘pack’ end lines exaggeratedly, but to give a generic way to limit (short) orphan words at the paragraph level.
> We have more interesting problems: how to visualize
> widows and how to fix them with scripting? [...]
InDesign allows you to prevent both ‘orphan and widowed lines’ (using The Chicago Manual of Style definitions). You just need to display the paragraph ‘Keep Options’ and to enable ‘Keep Lines together’ selecting the ‘At Start/End of Paragraph’ option with the values ‘Start: 2 lines’ and ‘End: 2 lines’.
> Or how to avoid (ugly) hyphenated word at the last
> line in a page [...]
Here again InDesign can fix this without scripting. Open the paragraph ‘Hyphenation Settings’ dialog and uncheck ‘Hyphenate Across Column’ and/or ‘Hyphenate Last Word’.
@+
Marc
Indesign Keep options usually substracts one line at the end of the culprit page. Although this practise is generally acepted
—J. Tschichold wrote about this idea but repeating the same in both pages: visually the pages are now similar and book will show the lack of the last line in both endings of page, something not to much noticeable for the silent reader—
through this option, ID offers the half solution: only one page is afected and the other one gets longer. But is not enough.
Repairing these paragraphs is tricky: sometimes it is enough to track from 1 to 4 lines; sometimes the whole paragraph. It is like adjusting a motor without tools... Like in the middle age, artisan changing the spaces between words to obatin justification with differents cuadratin formulaes...
What about script this? For the beginning something as powerful as your orphan macro that expand-collapses a little the paragraph. Or something that shows (or list) the widows. In long documents is always a tragedy the step before printing; by astrological reasons (or author's last time decision) it appears the terrible widow. Checking hundred pages again and again is a lost of time and temper.
E-books are not needing design for the moment. Sizes are choosed by the readers and also fonts. Perhaps the invisible bridge between author and autor ( B. Warde) will not need more than this solution in the Kindles and designers will have to make clear and simple menus, to allow the big publishers convert text to e-format inmediately. Scripting and design seem one way to preserve territories.
I will check that hyphenated last word to see which parameters use to avoid the paragraph gets damaged. Thank you!
M.