> Plus sérieusement, compiler vers du TeX a l'avantage de rester dans un monde homogène et tres stable.
Oui, mais ça rajoute une couche qui n'est pas forcément stable.
Ben voilà!
L'avantage principal de LuaTeX c'est de pouvoir utiliser des polices OpenType, ce qui est quand même un minimum pour faire de la typographie aujourd'hui.
En fait (je crois) que l'avantage ne réside pas tellement dans la possibilité d'utiliser ces polices — c'est déjà possible avec pdfTeX — mais de faciliter (idéalement automatiser) l'utilisation des fontes «installées» sur le système dans TeX. En principe les fontes de TeX et les fontes du système sont deux mondes à part.
TeX a quelques défauts de conception, par exemple, l'algorithme de coupure des pages travaille à l'aveugle et ne considère pas les coupures sur plusieurs pages pour prendre sa décision, mais je ne pense pas que LuaTeX y change quelque chose! Les algorithmes de placement des flottants ou de succession des modèles de page seront probablement plus faciles à écrire en Lua qu'en TeX — quoique :)
Un gros problème de TeX est la difficulté qu'il y a à créer de nouveaux modèles de documents. LuaTeX devrait permettre d'écrire plus facilement des modèles très généraux, plus facilement personnalisables. À mon avis la personnalisation sera un vrai cauchemar à cause des dépendances entres les paramètres que l'auteur du modèle n'aura pas forcément pu intégrer dans son modèle.
Mais c'est surtout une question de goûts j'imagine.
Pas du tout. Les systèmes de types qu'il y a en Lua (Perl, Python) sont tout pourris et n'aident pas du tout le programmeur à éviter de faire des fautes. Toutes les fautes de frappe dans les noms des méthodes, interversion dans l'ordre des paramètres, ne sont détectés qu'à l'éxécution — si le code en question est exécuté. Par exemple si tu fais un calcul qui dure 3h et que tu fais une faute de frappe dans le code qui sauvegarde le résultat, c'est reparti pour un tour. Heureusement, on a des centrales nucléaires.
Dans les langages fortement typés à la ML, le compilateur est capable de détecter un grand nombre d'erreurs, celles qui restent sont essentiellement les erreurs:
— de protocole, il faut relire la description du protocole!
— d'algorithme, si la méthode est mauvaise, il faut la changer!
— de système, mais qui c'est qui essaie d'écrire dans un fd ferme, mh?
autrement dit les vrais erreurs.
[^] # Re: Limitations sérieuses
Posté par Michaël (site web personnel) . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 3.
Ben voilà!
En fait (je crois) que l'avantage ne réside pas tellement dans la possibilité d'utiliser ces polices — c'est déjà possible avec pdfTeX — mais de faciliter (idéalement automatiser) l'utilisation des fontes «installées» sur le système dans TeX. En principe les fontes de TeX et les fontes du système sont deux mondes à part.
TeX a quelques défauts de conception, par exemple, l'algorithme de coupure des pages travaille à l'aveugle et ne considère pas les coupures sur plusieurs pages pour prendre sa décision, mais je ne pense pas que LuaTeX y change quelque chose! Les algorithmes de placement des flottants ou de succession des modèles de page seront probablement plus faciles à écrire en Lua qu'en TeX — quoique :)
Un gros problème de TeX est la difficulté qu'il y a à créer de nouveaux modèles de documents. LuaTeX devrait permettre d'écrire plus facilement des modèles très généraux, plus facilement personnalisables. À mon avis la personnalisation sera un vrai cauchemar à cause des dépendances entres les paramètres que l'auteur du modèle n'aura pas forcément pu intégrer dans son modèle.
Pas du tout. Les systèmes de types qu'il y a en Lua (Perl, Python) sont tout pourris et n'aident pas du tout le programmeur à éviter de faire des fautes. Toutes les fautes de frappe dans les noms des méthodes, interversion dans l'ordre des paramètres, ne sont détectés qu'à l'éxécution — si le code en question est exécuté. Par exemple si tu fais un calcul qui dure 3h et que tu fais une faute de frappe dans le code qui sauvegarde le résultat, c'est reparti pour un tour. Heureusement, on a des centrales nucléaires.
Dans les langages fortement typés à la ML, le compilateur est capable de détecter un grand nombre d'erreurs, celles qui restent sont essentiellement les erreurs:
— de protocole, il faut relire la description du protocole!
— d'algorithme, si la méthode est mauvaise, il faut la changer!
— de système, mais qui c'est qui essaie d'écrire dans un fd ferme, mh?
autrement dit les vrais erreurs.