Re: [K2] & sci

[Thierry Bouche <Thierry.Bouche@xxxxxxxxxxxxxxx>]

Sur les problèmes de codage, il y a trois initiatives en cours,
Unicode qui contient déjà beaucoup de symboles mathématiques,
« unicode glyph registry » qui devrait contenir tous ceux constatés
dans des documents publiés (y compris quand c'est seulement les
approches qui changent : deux signes identiques munis d'approches
différentes sont des glyphes distincts -> corriger mes précédentes
remarques à ce sujet). 

MathML devrait s'appuyer là-dessus, mais va probablement devoir
introduire de nouvelles « entités ».

La « communauté » TeX travaille à de nouveaux codages sur 8 bits (dans la
fonte principale, on a un alphabet latin italique dont les glyphes sont
corrigés pour un usage mathématique, et deux alphabets grecs (droit et
italique). Pour une fois, ça ne se fait pas dans une tour d'ivoire :
un autre projet mené par les principaux éditeurs scientifiques et
quelques éditeurs de logiciels (du genre mathematica) devrait
converger si bien que ces codages devraient aboutir à un standard de
fait, donc tentant pour les fondeurs. Par exemple, ces codages
contiennent un e, un i, un d pour (respectivement) noter la base de
l'exponentielle, la racine carrée de moins un, et les éléments
différentiels. Si j'ai bien compris, les américains les utilisent
italiques, les français utilisent les deux premiers droits
(constantes !) tandis que les allemands ou les physiciens (quelle
différence entre les deux ?) les utilisent tous droits. Une norme
Afnor rénégate tente d'entériner en France une vieille norme ISO qui
met tout en italiques (y compris les constantes !) : supprimons
l'Afnor !

________________________________________

Une autre info, c'est que des gens qui travaillent à un successeur de
tex se disent prêts à lui donner une architecture de type bibliothèque
avec fonctions de typo mathématiques appelables par un tiers (la façon
selon laquelle hz était supposé fonctionner). Une bibliothèque de
fonctions de typo plus paramétrable que tex, et _gratuite_ ! ça
pourrait motiver les bâtisseurs de logiciels du côté de la plus-value
pas cher payée ?
________________________________________

Je crois comme Alain qu'il n'est pas nécessaire d'inventer des
codages, de mettre à plat tout ce que doit faire un logiciel de compo
scientifique. C'est le boulot des implémenteurs ! Notre boulot est de
leur demander de ne pas faire de grosse sottise rendant impossible une
surcouche aussi finement paramétrable que nécessaire. Si la typo est
uniquement conçue pour le texte, on sera condamné à un fonctionnement
« image » genre EPS importé. Si la typo permet de placer n'importe
quoi n'importe où (essentiellement, comme dans la recension d'Olivier,
on doit pouvoir affubler un bloc (qui sera en général un signe, mais
peut aussi bien être une formule entre parenthèses) de modificateurs
placés au nord, nord est, est, sud est, sud, sud ouest, ouest, nord
ouest, ces modificateurs pouvant eux-mêmes être des objets complexes
(affublés eux-mêmes de ...). C'est le premier point important. Le
second, c'est la capacité à enjamber des lignes ou des colonnes. Le
troisième, c'est la possibilité de _bien_ placer les caractères (du
genre paires d'approches corrigées différentes en exposant, en indice,
etc.) et bien les _espacer_. Le quatrième, c'est que les polices
doivent rester cohérentes avec celles du texte, mais les attributs
comme gras ou italiques doivent rester fixes.

______________________________________

la morale de cette histoire ?

« Même si Adobe décide d'intégrer un super éditeur de formules, il sera de
peu d'usage au typographe qui travaille Marie-Claire »

   Thierry Bouche.       -----       thierry.bouche@xxxxxxxxxxxxxxx
          http://www-fourier.ujf-grenoble.fr/~bouche/