lp-l10n-fr team mailing list archive

[verdy_p <verdy_p@xxxxxxxxxx>]

"Nicolas Delvaux" 
> > Bonne lecture !
> 
> Tu devrais écrire des livres tu sais ^^
> 
> Bien, je pense avoir compris.
> À priori il faudrait donc employer des nnbsp partout et remonter les
> bugs de rendu éventuels vers le moteur de rendu incriminé.
> 
> Comme tu l'as peut-être vu, j'ai soumis un patch pour rajouter un tag
> « [thinsp] » et, en guise de nnbsp, un tag « [nbthin] » (oui, j'ai pensé
> qu'il y aurait trop de risques de confusions entre « [nbsp] » et
> « [nnbsp] »).
> Après réflexion, même si « [fine] » aurait été mieux pour nous, il faut
> être cohérent : Launchpad est intégralement en anglais (et ce n'est pas
> près de changer à priori) donc bon, notre « [fine] » aurait été un peu
> hors sujet.
> Déjà que les mots anglais que l'on emploi au milieu d'une conversation
> française sont un peu destroy... Et bien idem dans l'autre sens
> (AMHA). ;-)
> 
> Et sinon, concernant l'emploi de nnbsp, j'ai trouvé plusieurs versions
> différentes.
> Par exemple, regarde les références de cette page :
> http://traduc.org/gnomefr/Typographie
> 
> Certains veulent des espaces insécables « simple » entre les guillemets,
> d'autres ne veulent une nnbsp que devant un point-virgule...
> En pratique j'ai l'impression qu'il n'y a pas vraiment de règle ferme et
> définitive.
> Mais on pourrait par exemple décréter que, dans le groupe lp-l10n-fr, on
> utilise exclusivement des nnbsp (donc, peut-être, des [nbthin] ;-)) sous
> le prétexte que c'est plus simple... et que je trouve ça plus joli. 
> 
> Ça vous va tous le monde ?
> (bien entendu il faudra attendre que le tag nécessaire arrive dans
> Launchpad)

J'ai travaillé pour la presse française dans un éditeur de logiciels spécialisés dans ce domaine (toute sorte de 
presse : quotidienne nationale, régionale ou internationale, magazines, guides, dictionnaires, annuaires), et pas 
qu'en France !

On y faisait des solutions d'éditique, de gestion des annonces, de gestion de la publicité, un moteur de rendu 
SGML/XML (et la typographie fine était bien plus avancée que ce qu'on trouve encore sur le web) ; nos clients, 
c'était la TOTALITÉ des groupes de presse français (TOUTE LA PRESSE régionale y compris Le Parisien, et une grande 
partie des nationaux, dont Le Monde, Libé...), l'imprimerie nationale, divers éditeurs aussi connus que Hachette, 
Bayard, Larousse, Pags Jaunes, et d'autres du même ordre au Royaume-Uni, au Canada, en Belgique, en Italie, en 
Espagne, dans le Moyen-Orient et le Maghreb, quelques éditeurs aux USA et même au Japon...

Et ABSOLUMENT TOUS étaient d'accord sur le fait que la fine (française ou anglaise, la française étant seulement 
légèrement plus grande dans la typographie traditionelle, ce qui n'et plus vrai maintenant qu'on s'est habité aux 
polices numériques, et qu'on ne monte plus les pages avec du plomb fondu, et « à la ficelle » sur les chemin de fer) 
s'imposait ABSOLUMENT PARTOUT où une espace insécable était demandée à côté d'une ponctuation ou comme séparateur de 
groupes de chiffres (donc aussi avec nos guillemets doubles) et c'était vrai MÊME dans les ouvrages en anglais, 
allemand, espagnol, italien, arabe, néerlandais, et pas uniquement pour des raisons de place (dans les colonnes d'un 
journal d'annonces), mais bien pour des raisons esthétiques.

D'ailleurs si j'ai connu la FINE française, c'est bien grâce à eux qui la voulaient ABSOLUMENT ! D'ailleurs on 
l'affichait dans les interfaces de saisie de texte comme [fine] (dans la version francophone de nos produits) en 
petit caractères rouges, alors que le reste était composé en caractères noirs.

Les anglophones eux voyaient [thin], et notre moteur de compo (capable de traiter des chemins de fer aussi complexes 
que des journaux, guides, dictionnaires, avec des milliers de pages en quelques minutes, avec des tas d'autres 
contraintes de placement que le HTML ou CSS ne sait toujours pas gérer correctement, hormi le CSS version Adobe qui 
est bien encore le seul à prendre en compte un certin nombre de détails...) leur retournait la fine anglaise (1/8e 
em) au lieu de la fine française (1/6e em). Et dans ce cas, même les anglophones utilisaient ces « superfines » 
autour des deux-points, des points-virgules, des points d'exclamation et d'interrogation, et même autour de leurs 
“guillemets” !

Il faut voir et lire des traités de typographie avancée anciens pour voir que les anglophones n'ont JAMAIS abandonné 
leur fine (au moins chez les éditeurs de presse et de livres), même si la dactylographie, puis les débuts de 
l'informatique ont fait bien des ravages et propagé de fausses idées ! En effet ils n'utilisent pas nos polices 
informatiques usuelles (Times New Roman ou Arial par exemple) mais bien des polices beaucoup plus précises (et plus 
chères).

Avant qu'Adobe commence à s'intéresser sérieusement au sujet (aux USA) pour le démocratiser, c'était l'allemand 
Monotype (racheté ensuite par Agfa) qui maitrisait le mieux la typographie demandée par les éditeurs et imprimeurs. 
Monotype avait aussi acquis une expertise dans la typographie arabo-persanne et indienne, ainsi que la caligraphie 
sino-japonaise.

D'ailleurs ce n'est qu'aujourd'hui, grâce aux progrès du support d'Unicode dans les logiciels usuels, qu'on commence 
à retrouver l'intérêt de la typographie fine traditionelle, qui commence à se démocratiser.

Franchement je ne sais pas qui a eu l'idée de recommander des espaces insécables larges autour des guillemets, à mon 
avis il n'ont JAMAIS travaillé avec des éditeurs ou avec la presse et ont inventé cette règle eux-mêmes.

Mais si jamais il y en a qui préfèrent une espace normale et non une fine à côté des guillements, c'est bien plus 
simple pour eux d'effectuer la subsitution de «+FINE et FINE+» en «+NBSP et NBSP+», plutôt que l'inverse, par des 
options de leur moteur de rendu (sachant aussi qu’une police peut ajuster les approches de ces paires 
spécifiquement, par les tables de "kerning").

Pour moi la fine (NNBSP) est universelle et on n'a pas besoin de coder autre chose.