LuaLaTeX
Elie
juste pour dire que les gens intéressés peuvent tester ce que je
développe en ce moment : les paquetages LuaLaTeX :
http://github.com/eroux/lualatex/tree/master
Pour l'instant luatextra et luamcallbacks commencent à ressembler à
leur version finale, luamplib doit être légèrement adapté, et
luainputenc doit marcher à peu près mais est loin d'être stabilisé :
il va certainement être coupé en deux entre luainputenc et
fancyencodings...
Il n'est pas exclu non-plus que quelques texio.write_nl("prout") aient
échapé à ma vigilance...
En tous cas n'hésitez pas à faire des remarques, tester, contribuer,
etc.
--
Elie
Pruneau d'Agen
> Bonjour,
>
> juste pour dire que les gens intéressés peuvent tester ce que je
> développe en ce moment : les paquetages LuaLaTeX :
C'est vraiment bien de voir qu'enfin des packages latex sont développés
pour luatex. Tu devrais aussi en parler sur c.t.t.
Seb
Je vais tester aussi. Juste une chose : puisque tes packages ne sont pas
encore sur le CTAN, tiens nous au courant dès qu'il y a une mise à jour
ou si carrément tu changeais l'endroit où tu les déposes.
Merci et beau boulot, je reviendrai faire un tour mais là il faut
justement que je fasse quelques tests.
Seb
Damien Bonis
Ben ça tombe bien Elie, je viens de voir juste à l'instant que tu venais
de modifier tes packages.
-mplib.dtx doit être renommé en luamplib.dtx (en plus j'arrivais pas à
le compiler)
-tant que tu y es, est-ce que tu peux fournir les fichiers .sty
directement (à la place des .dtx) avec les documentations (en dvi
pourquoi pas), c'est plus rapide.
Merci Elie
Damien Bonis
Je n'arrive pas à compiler luamplib.dtx
Damien Bonis
Voici encore quelques messages d'erreur durant la compilation :
(c:/mytexmf/tex/lualatex/luainputenc/luainputenc.sty
! LuaTeX error c:/mytexmf/tex/lualatex/luainputenc/luainputenc.lua:233:
'<eof>'
expected near 'end'
stack traceback:
[C]: in function 'dofile'
<\directlua0>:1: in main chunk.
l.29 ...dofile(kpse.find_file("luainputenc.lua"))}
) (c:/mytexmf/tex/lualatex/luatextra/luatextra.sty
! Package luatextra Error: This package must be used with LuaTeX.
l.10 ...or: This package must be used with LuaTeX}
! Extra \else.
l.13 \else
(c:/mytexmf/tex/lualatex/ifluatex/ifluatex.sty)
(c:/Program Files/texlive/2008/texmf-dist/tex/latex/environ/environ.sty)
! LaTeX Error: Command \luaRequireModule already defined.
Or name \end... illegal, see p.192 of the manual.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.24 ...luatextra.require_module([[#2]], [[#1]])}}
! Extra \fi.
l.25 \fi
(c:/mytexmf/tex/lualatex/luatextra/luatextra.lua
(c:/mytexmf/tex/lualatex/luam
callbacks/luamcallbacks.lua))
Elie
Voilà qui est étrange... il faut le compiler avec tex en fait, pas
latex, c'est dû à des hacks moches pour docstrip pour faire un sty
acceptable par Plain... Cela marche-t-il mieux avec tex ?
--
Elie
mpg
> -tant que tu y es, est-ce que tu peux fournir les fichiers .sty
> directement (à la place des .dtx) avec les documentations (en dvi
> pourquoi pas), c'est plus rapide.
>
s/dvi/pdf/g ?
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Damien Bonis
Tu veux que je compile les fichiers .dtx avec tex au lieu de latex c'est
ça ? Ok, je teste mais encore un truc : tu devrais fournir directement
le .sty et la documentation sans avoir à faire la compilation.
Damien Bonis
non, ça ne marche pas mieux avec tex, j'ai les mêmes erreurs.
Un truc : lorsque tu dis : "faire un sty acceptable par Plain". Mais
Plain ne sait pas interpréter les .sty je crois.
> --
> Elie
Elie
> Un truc : lorsque tu dis : "faire un sty acceptable par Plain". Mais
> Plain ne sait pas interpréter les .sty je crois.
Sauf si on cache les macros spécifiques à LaTeX (comme
\ProvidesPackage) derrière des \iflatex (ou assimilé). Ça permet de
n'avoir qu'un seul fichier. Je vais essayer de finir luamplib (enfin
c'est toujours pareil, ça va réévoluer) ce soir...
--
Elie
Elie
marche toujours pas chez vous (alors que ça marche toujours très bien
chez moi même si le fichiers est isolé tout seul dans un répertoire),
les fichiers générés (dont le pdf) sont dispo sur http://norgz.guiling.fr/luamplib.zip
.
Le prochain sur la liste c'est luaminimalotf...
--
Elie
Damien Bonis
Une chose car je crois qu'il y a confusion : les messages d'erreur
ci-dessus ne proviennent pas de la compilation des fichiers .dtx : il
s'agit d'erreurs lors de la compilation d'un document latex personnel
avec pdflualatex.
En ce qui concerne les fichier .sty, je les ai c'est bon, maintenant, ce
qu'il y a au-dessus montre quelques problèmes que je ne peux pas
moi-même interpréter. (je me souviens avoir compilé ce même doc latex
avec lua-inputenc à l'époque et j'avais eu moins d'erreurs)
Ceci étant durant la compilation je fais [return] et la compilation se
termine me fournissant le pdf attendu, ce qui est rassurant.
Damien
Elie
> Une chose car je crois qu'il y a confusion : les messages d'erreur
> ci-dessus ne proviennent pas de la compilation des fichiers .dtx : il
> s'agit d'erreurs lors de la compilation d'un document latex personnel
> avec pdflualatex.
Je peux avoir ton document pour tester ? Mon adresse de réponse marche
(crois-je)...
--
Elie
Elie
> Je peux avoir ton document pour tester ? Mon adresse de réponse marche
> (crois-je)...
Après 10s de réflexion : utilises-tu TL2008 ? Dans ce cas je conseille
de mettre LuaTeX à jour, car celui de TL2008 est quand même pas mal
buggé, et luamplib ne marche pas...
--
Elie
Damien Bonis
Salut Elie,
En fait, mon fichier est très loin d'être autonome : il fait appel à une
dizaine de packages perso eux-même faisant appel à une dizaine de
package perso.
En fait, je vais essayer de décortiquer pour aller droit au but. Et puis
, il s'agit de te donner un coup de main et pour ça j te fournirai des
ECM qui montre le mieux possible les éventuels problèmes. Il faut que je
refasse des tests avec d'autres fichiers aussi.
Damien Bonis
J'ai une TL08 à jour avec un luatex en 0.35 tout frais, formats
fraîchement régénérés. Pour le moment je ne teste pas non plus luamplib
car je ne suis pas un adepte de metapost mais je pourrai tester plus
tard, ce n'est pas les bouts de codes metapost qui manquent.
Par contre ce qui me semble important, c'est aussi de se mettre d'accord
sur un préambule minimal (auquel viendront s'ajouter d'autres packages)
représentant un minimum vital pour faire tourner lualatex.
Mettons-nous enfin d'accord sur le pilote car cela me semble important
aussi. Moi je préfère sortir du pdf directement donc, je compile
systématiquement avec pdflualatex.
Voici le préambule minimal que je propose, es-tu d'accord avec :
\documentclass{article}
\usepackage{luainputenc}
\usepackage{luatextra}
%%%%%%%%%% FIN DU PREAMBULE MINIMAL %%%%%%%%%%%%
Tout ça pour ça ? Ok c'est court mais je me posais aussi la question de
l'opportunité de charger aussi le package pdftexcmds de oberdiek (encore
lui !) : peut-il aider pour le fonctionnement de certains packages sous
luatex ? Je ne l'ai pas encore testé.
Elie
> \documentclass{article}
> \usepackage{luainputenc}
> \usepackage{luatextra}
> %%%%%%%%%% FIN DU PREAMBULE MINIMAL %%%%%%%%%%%%
Je dirais même plus :
\documentclass{article}
\usepackage{luatextra}
%%%%%%%%%% FIN DU PREAMBULE MINIMAL %%%%%%%%%%%%
vu que je suis en train de faire luainputenc, donc tout en utf8... A
priori je finirai luainputenc demain.
--
Elie
Damien Bonis
ok, j'attends demain pour reprendre les tests.
Bonne journée.
Damien Bonis
> Elie a écrit :
>> On 8 mar, 22:06, Damien Bonis <damis@dantaboite> wrote:
>>
>>> Une chose car je crois qu'il y a confusion : les messages d'erreur
>>> ci-dessus ne proviennent pas de la compilation des fichiers .dtx : il
>>> s'agit d'erreurs lors de la compilation d'un document latex personnel
>>> avec pdflualatex.
>>
>> Je peux avoir ton document pour tester ? Mon adresse de réponse marche
>> (crois-je)...
>> --
>> Elie
>
> Salut Elie,
>
> En fait, mon fichier est très loin d'être autonome : il fait appel à une
> dizaine de packages perso eux-même faisant appel à une dizaine de
> package perso.
(courants)"
Elie
> ok, j'attends demain pour reprendre les tests.
Pas besoin : le comportement de luainputenc est de ne rien faire quand
il a l'option utf8... du coup \usepackage[utf8]{luainputenc} est
équivalent à rien du tout... donc pas de problème pour commencer les
tests !
--
Elie
Elie
> Pas besoin : le comportement de luainputenc est de ne rien faire quand
> il a l'option utf8... du coup \usepackage[utf8]{luainputenc} est
> équivalent à rien du tout... donc pas de problème pour commencer les
> tests !
Bon voilà, première version de luainputenc ici :
http://github.com/eroux/lualatex/blob/4ab5393f9932ffb54f4ce3a375f81e336baefa13/luainputenc/luainputenc.dtx
si des gens veulent tester... attention à bien lire la doc !
Quelques exemples de préambules qui marchent :
\usepackage[latin1]{luainputenc}
\usepackage[latin1]{inputenc}
\usepackage{utf8}{luainputenc}
et quelques exemples qui ne marchent pas :
\usepackage[latin1]{luainputenc}
\usepackage[utf8]{luainputenc}
\usepackage[utf8]{inputenc}
Bon, il se trouve que \usepackage[latin1]{luainputenc} doit marcher
parcequ'utf8 ressemble beaucoup à latin1, mais c'est purement
fortuit... Je ne suis pas contre un peu de tests!
--
Elie
Damien Bonis
> Bon voilà, première version de luainputenc ici :
> http://github.com/eroux/lualatex/blob/4ab5393f9932ffb54f4ce3a375f81e336baefa13/luainputenc/luainputenc.dtx
> si des gens veulent tester... attention à bien lire la doc !
>
> Quelques exemples de préambules qui marchent :
>
> \usepackage[latin1]{luainputenc}
> \usepackage[latin1]{inputenc}
>
> \usepackage{utf8}{luainputenc}
>
> et quelques exemples qui ne marchent pas :
>
> \usepackage[latin1]{luainputenc}
>
> \usepackage[utf8]{luainputenc}
> \usepackage[utf8]{inputenc}
>
> Bon, il se trouve que \usepackage[latin1]{luainputenc} doit marcher
> parcequ'utf8 ressemble beaucoup à latin1, mais c'est purement
> fortuit... Je ne suis pas contre un peu de tests!
> --
> Elie
Voici le code que j'ai compilé
\documentclass{article}
\usepackage[utf8]{luainputenc}
%\usepackage{luamcallbacks}
\begin{document}
Hello world !
\end{document}
Et voici le log (ça ne fonctionne pas, que luamcallbacks soit commenté
ou pas) :
This is LuaTeX, Version snapshot-0.35.0-2009022415 (Web2C 7.5.7)
(format=pdflualatex 2009.3.8) 10 MAR 2009 21:20
**exp1
(exp1.tex
LaTeX2e <2005/12/01>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax,
dumylang, noh
yphenation, german-x-2008-06-18, ngerman-x-2008-06-18, ancientgreek,
ibycus, ar
abic, basque, bulgarian, catalan, pinyin, coptic, croatian, czech,
danish, dutc
h, esperanto, estonian, farsi, finnish, french, galician, german,
ngerman, mono
greek, greek, hungarian, icelandic, indonesian, interlingua, irish,
italian, la
tin, lithuanian, mongolian, mongolian2a, bokmal, nynorsk, polish,
portuguese, r
omanian, russian, sanskrit, serbian, slovak, slovenian, spanish,
swedish, turki
sh, ukenglish, ukrainian, uppersorbian, welsh, loaded.
(c:/Program Files/texlive/2008/texmf-dist/tex/latex/base/article.cls
Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
(c:/Program Files/texlive/2008/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size option)
)
\c@part=\count79
\c@section=\count80
\c@subsection=\count81
\c@subsubsection=\count82
\c@paragraph=\count83
\c@subparagraph=\count84
\c@figure=\count85
\c@table=\count86
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
(c:/mytexmf/tex/lualatex/luainputenc/luainputenc.sty
Package: luainputenc 2009/03/10 v0.92 inputenc package for LuaTeX
(c:/mytexmf/tex/lualatex/luatextra/luatextra.sty
(c:/Program Files/texlive/2008/texmf-dist/tex/generic/oberdiek/ifluatex.sty
Package: ifluatex 2007/12/12 v1.0 Provides the ifluatex switch (HO)
Package ifluatex Info: LuaTeX detected.
)
Package: luatextra 2009/02/26 v0.9 LuaTeX extra low-level macros
(c:/Program Files/texlive/2008/texmf-dist/tex/latex/environ/environ.sty
Package: environ 2008/06/18 v0.2 A new way to define environments
\@emptytoks=\toks14
\@envbody=\toks15
) (c:/mytexmf/tex/lualatex/luatextra/luatextra.lua
! LuaTeXtra error: unable to find lua module luamcallbacks
.
l.1 ...ble to find lua module luamcallbacks^^J^^J}
l.66 \luaUseModule{luamcallbacks}
?
! Emergency stop.
l.1 ...ble to find lua module luamcallbacks^^J^^J}
l.66 \luaUseModule{luamcallbacks}
End of file on the terminal!
Here is how much of TeX's memory you used:
299 strings out of 257049
3954 string characters out of 1164402
100000,552014 words of node,token memory allocated
node memory in use: 239 words out of 100000
rapidly available: 2:12, 3:1, 4:2, 6:2, 9:3 nodes
current usage: 1 hlist, 1 rule, 38 glue_spec, 1 write, 2 dir nodes
3903 multiletter control sequences out of 65536+50000
15 fonts using 148973 bytes
28i,0n,18p,169b,36s stack positions out of 5000i,500n,6000p,200000b,50000s
! ==> Fatal error occurred, no output PDF file produced!
Elie
> ! LuaTeXtra error: unable to find lua module luamcallbacks
Hmm... petit indice : http://github.com/eroux/lualatex/tree/404c353679cbe0ad50d3ad6f92b4180b930455bd/luamcallbacks
--
Elie
mpg
> Bon, il se trouve que \usepackage[latin1]{luainputenc} doit marcher
> parcequ'utf8 ressemble beaucoup à latin1, mais c'est purement
> fortuit... Je ne suis pas contre un peu de tests!
C'est même un peu plus qu'une grosse ressemblance. Tous les caractères
existant en latin1 on le même point de code Unicode que leur index dans
latin1. C'est une décision tout à fait intentionelle d'Unicode.
D'ailleurs il faut bien penser en testant à essayer d'autres encodages
pour cette raison.
Damien Bonis
je ne comprends pas, c'est pareil chez moi.
Elie
> C'est même un peu plus qu'une grosse ressemblance. Tous les caractères
> existant en latin1 on le même point de code Unicode que leur index dans
> latin1. C'est une décision tout à fait intentionelle d'Unicode.
Toutafé. C'est ce qui a guidé certaines personnes sur de fausses
pistes dans luainputenc...
--
Elie
Ulrike Fischer
>> Bon, il se trouve que \usepackage[latin1]{luainputenc} doit marcher
>> parcequ'utf8 ressemble beaucoup à latin1, mais c'est purement
>> fortuit... Je ne suis pas contre un peu de tests!
>
> C'est même un peu plus qu'une grosse ressemblance. Tous les caractères
> existant en latin1 on le même point de code Unicode que leur index dans
> latin1. C'est une décision tout à fait intentionelle d'Unicode.
Le euro € (autre position dans unicode) et le ß (autre position dans
T1) sont bien pour tester.
--
Ulrike Fischer
Elie
> je ne comprends pas, c'est pareil chez moi.
As-tu luamcallbacks.lua dans ton répertoire courant ?
--
Elie
Damien Bonis
Bonsoir,
Bon hier soir je n'avais pas les yeux en face des trous (mon préambule
n'était pas le bon et je n'ai même pas fait attention, bref).
Ce soir, j'ai pu faire des tests pour le moins satisfaisants mais
d'abord, je voudrais revenir sur cette affaire luamcallbacks.lua :
-non je n'avais pas le fichier luamcallbacks.lua dans mon dossier
courant et je ne sais pas pourquoi. Aurait-il dû être généré lorsque
j'ai compilé docstrip avec tex (comme je le fais pour les autres
packages) ? En tous cas, j'ai dû aller le trouvé sur le net ici :
http://ftp.math.purdue.edu/mirrors/ctan.org/macros/luatex/generic/luamcallbacks/luamcallbacks.lua
J'ai dû louper un truc quelque part mais ce fichier n'est pas fourni
avec le package, je me trompe ?
-après l'avoir récupéré et mis dans le répertoire courant, j'ai pu
débuter mes tests. En fait, je l'ai mis par la suite dans le dossier
luamcallbacks de ma texmf et tout marchait bien.
Bien, passons au test : j'ai effectué à nouveau le test sur mon fichier
qui fait appel à beaucoup de packages persos ...:
-la compilation est assez longue (beaucoup plus longue) qu'avec pdflatex
: comment l'expliquer ?
-la compilation se termine sans erreur, quelques warning dont :
LuaTeXtra Warning: You have requested module `luamcallbacks',
but the file luamcallbacks.lua does not provide it.
-du point de vue de la composition du document, le pdf obtenu semble
être le même que celui obtenu par compilation avec pdflatex,
-la taille du fichier obtenu semble être un peu plus faible,
-pas de caractère oublié ou remplacé a priori,
Deux bémols :
-le pdf obtenu peut être ouvert avec n'importe lequel de mes readers
(SumatraPDF, Foxit Reader, Adobe Reader 9.0, Pdf-XChange viewer) *sauf
avec* adobe acrobat reader 5.0 : avez-vous déjà rencontré le même problème ?
-j'ai essayé de changer la fonte (j'utilisais lmodern pour le test
précédent) : fourier : OK, kpfonts et mathpazo : les caractère accentués
sont supprimés.
Voilà pour ce soir.
Elie
> -non je n'avais pas le fichier luamcallbacks.lua dans mon dossier
> courant et je ne sais pas pourquoi. Aurait-il dû être généré lorsque
> j'ai compilé docstrip avec tex (comme je le fais pour les autres
> packages) ? En tous cas, j'ai dû aller le trouvé sur le net ici :
En fait il est généré par luamcallbacks.dtx, c'est un autre package
que luatextra, mais qui est appelé par lui quand même... C'est vrai
que c'est assez contestable, mais bon, je changerai plus tard...
> -la compilation est assez longue (beaucoup plus longue) qu'avec pdflatex
> : comment l'expliquer ?
Disons que tout est checké et converti en fake utf8, ce qui prend un
temps non-négligeable, proportionnel au nombre de caractères...
> LuaTeXtra Warning: You have requested module `luamcallbacks',
> but the file luamcallbacks.lua does not provide it.
Ça devrait être corrigé avec le dernier luamcallbacks (toujours ici :
http://github.com/eroux/lualatex/blob/0d14348279d30ee2f624f6b8582dc33c3f695666/luamcallbacks/luamcallbacks.dtx)
> -du point de vue de la composition du document, le pdf obtenu semble
> être le même que celui obtenu par compilation avec pdflatex,
Bonne nouvelle !
> -la taille du fichier obtenu semble être un peu plus faible,
C'est peut-être dû à LuaTeX...
> -le pdf obtenu peut être ouvert avec n'importe lequel de mes readers
> (SumatraPDF, Foxit Reader, Adobe Reader 9.0, Pdf-XChange viewer) *sauf
> avec* adobe acrobat reader 5.0 : avez-vous déjà rencontré le même problème ?
Ça m'a déjà fait ça avec des pdf obtenus avec LuaTeX (avec ou sans
luainputenc)... à mon avis ce n'est pas vraiment corrigeable.
> -j'ai essayé de changer la fonte (j'utilisais lmodern pour le test
> précédent) : fourier : OK, kpfonts et mathpazo : les caractère accentués
> sont supprimés.
Étrange... ça n'est pas normal... tu peux m'envoyer un fichier exemple
minimal stp ? Il est possible que ça vienne de fontenc, qui a
potentiellement besoin d'une adaptation à LuaLaTeX...
--
Elie
mpg
>> -la compilation est assez longue (beaucoup plus longue) qu'avec pdflatex
>> : comment l'expliquer ?
>
> Disons que tout est checké et converti en fake utf8, ce qui prend un
> temps non-négligeable, proportionnel au nombre de caractères...
>
Euh, à mon avis le temps pris par le callback pour le conversion est
loin d'être aussi grand, et ne suis même pas sûr qu'il soit sensible.
La première cause que j'invoquerais est que LuaTeX est intrinsèquement
plus lent que pdfTeX : c'est une machinerie bien plus grosse. Exemple.
mpg@roth:~% time pdflatex sample2e >/dev/null
pdflatex sample2e > /dev/null 0,16s user 0,02s system 99% cpu 0,184 total
mpg@roth:~% time pdflualatex sample2e >/dev/null
pdflualatex sample2e > /dev/null 2,03s user 0,05s system 99% cpu 2,087 total
mpg@roth:~%
C'est surtout le temps de démarrage de la bestiole qui est sensible. Le
temps de compilation en lui-même est sans doute comparable, et pourra à
terme être plus rapide si des trucs lourds codés en macros TeX finissent
par être ré-implémentés en Lua.
>> -le pdf obtenu peut être ouvert avec n'importe lequel de mes readers
>> (SumatraPDF, Foxit Reader, Adobe Reader 9.0, Pdf-XChange viewer) *sauf
>> avec* adobe acrobat reader 5.0 : avez-vous déjà rencontré le même problème ?
>
> Ça m'a déjà fait ça avec des pdf obtenus avec LuaTeX (avec ou sans
> luainputenc)... à mon avis ce n'est pas vraiment corrigeable.
>
pdfTeX produit du pdf version 1.4, qui est lisible par Adobe Reader
version 6 ou plus. Je ne sais pas si c'est réglable ou pas. Au pire, on
doit pouvoir post-traiter le fichier pour abaisser la version, en
passant par gs ou un autre outil (et en perdant potentiellement des
infos au passage). Je n'ai heureusement jamais eu à m'en soucier.
Damien Bonis
>> -j'ai essayé de changer la fonte (j'utilisais lmodern pour le test
>> précédent) : fourier : OK, kpfonts et mathpazo : les caractère accentués
>> sont supprimés.
>
> Étrange... ça n'est pas normal... tu peux m'envoyer un fichier exemple
> minimal stp ? Il est possible que ça vienne de fontenc, qui a
> potentiellement besoin d'une adaptation à LuaLaTeX...
> --
> Elie
\documentclass{article}
\usepackage{luatextra}
\usepackage{kpfonts}
\begin{document}
abécédé !
\end{document}
Damien Bonis
> Elie scripsit:
>
>>> -la compilation est assez longue (beaucoup plus longue) qu'avec pdflatex
>>> : comment l'expliquer ?
>> Disons que tout est checké et converti en fake utf8, ce qui prend un
>> temps non-négligeable, proportionnel au nombre de caractères...
>>
> Euh, à mon avis le temps pris par le callback pour le conversion est
> loin d'être aussi grand, et ne suis même pas sûr qu'il soit sensible.
>
> La première cause que j'invoquerais est que LuaTeX est intrinsèquement
> plus lent que pdfTeX : c'est une machinerie bien plus grosse. Exemple.
>
> mpg@roth:~% time pdflatex sample2e >/dev/null
> pdflatex sample2e > /dev/null 0,16s user 0,02s system 99% cpu 0,184 total
> mpg@roth:~% time pdflualatex sample2e >/dev/null
> pdflualatex sample2e > /dev/null 2,03s user 0,05s system 99% cpu 2,087 total
> mpg@roth:~%
>
> C'est surtout le temps de démarrage de la bestiole qui est sensible.
C'est vrai que c'est au début que c'est long.
Est-ce que ça peut aussi venir de mon installation de luatex qui est une
installation manuelle (en tous cas par rapport à l'installation de la
texlive originale) ?
> Le
> temps de compilation en lui-même est sans doute comparable, et pourra à
> terme être plus rapide si des trucs lourds codés en macros TeX finissent
> par être ré-implémentés en Lua.
espérons
>>> -le pdf obtenu peut être ouvert avec n'importe lequel de mes readers
>>> (SumatraPDF, Foxit Reader, Adobe Reader 9.0, Pdf-XChange viewer) *sauf
>>> avec* adobe acrobat reader 5.0 : avez-vous déjà rencontré le même problème ?
>> Ça m'a déjà fait ça avec des pdf obtenus avec LuaTeX (avec ou sans
>> luainputenc)... à mon avis ce n'est pas vraiment corrigeable.
>>
> pdfTeX produit du pdf version 1.4, qui est lisible par Adobe Reader
> version 6 ou plus. Je ne sais pas si c'est réglable ou pas.
il faudrait le demander sur ma ml de dev-luatex
> Au pire, on
> doit pouvoir post-traiter le fichier pour abaisser la version, en
> passant par gs ou un autre outil (et en perdant potentiellement des
> infos au passage).
c'est casse-pied.
Elie
> C'est surtout le temps de démarrage de la bestiole qui est sensible. Le
> temps de compilation en lui-même est sans doute comparable, et pourra à
> terme être plus rapide si des trucs lourds codés en macros TeX finissent
> par être ré-implémentés en Lua.
Hmm... je pense que ça va plutôt ralentir qu'accélérer... non ?
Sinon merci Damien pour le fichier test, je m'occupe de ça dés que
j'ai fini de m'amuser avec la syntaxe \font de XeTeX.
--
Elie
Pétiard François
> Elie scripsit:
<couic>
>>> -le pdf obtenu peut être ouvert avec n'importe lequel de mes readers
>>> (SumatraPDF, Foxit Reader, Adobe Reader 9.0, Pdf-XChange viewer) *sauf
>>> avec* adobe acrobat reader 5.0 : avez-vous déjà rencontré le même problème ?
>> Ça m'a déjà fait ça avec des pdf obtenus avec LuaTeX (avec ou sans
>> luainputenc)... à mon avis ce n'est pas vraiment corrigeable.
>>
> pdfTeX produit du pdf version 1.4, qui est lisible par Adobe Reader
> version 6 ou plus. Je ne sais pas si c'est réglable ou pas. Au pire, on
> doit pouvoir post-traiter le fichier pour abaisser la version, en
> passant par gs ou un autre outil (et en perdant potentiellement des
> infos au passage). Je n'ai heureusement jamais eu à m'en soucier.
>
Heu, non, pdf version 1.4 est lisible par Adobe Reader version 5.x
(regarder les propriétés du document dans Adobe Reader, onglet Description).
Cela se règle au coup par coup en mettant :
\pdfminorversion=4
dans le fichier .tex, ou globalement, en mettant :
pdf_minorversion 4
dans pdftex.cfg
François
--
<Jose> Je n'ose pas trop contredire Jean-Côme,
<Jean-Côme> Mais tout le monde a le droit de contredire Jean-Côme. Et
toi encore plus que certains :-) Il va falloir que je relise à
tête reposée pour comprendre ce que tu racontes et pour voir
si nous ne sommes pas d'accord également (je commence à me
méfier dans ce fil).
-+- in fr.comp.text.tex -+-
Damien Bonis
Je vais faire d'autres tests ces prochains jours et je te tiendrai au
courant au cas où je verrai d'autres choses anormales.
Sinon, tu bosses sur une fontec/fontespec ?
Elie
> Je vais faire d'autres tests ces prochains jours et je te tiendrai au
> courant au cas où je verrai d'autres choses anormales.
>
> Sinon, tu bosses sur une fontec/fontespec ?
En fait là je m'amuse à faire comprendre à LuaTeX la syntaxe du \font
de XeTeX... ça servira au moins pour fontspec si ce n'est plus. Ça me
permet aussi de faire joujou avec le fontes, et de découvrir des
choses qui me seront utiles pour fontenc, que je vais essayer de faire
ensuite.
--
Elie
mpg
> C'est vrai que c'est au début que c'est long.
> Est-ce que ça peut aussi venir de mon installation de luatex qui est une
> installation manuelle (en tous cas par rapport à l'installation de la
> texlive originale) ?
>
Non, je ne pense pas. LuaTeX est juste intrinsèquement plus lent (au
moins au démarrage) que pdfTeX. Il consomme aussi notablement plus de
mémoire. Et il restera plus lent, juste parce qu'il fait *beaucoup* plus
de choses : on n'a rien sans rien.
>> Le
>> temps de compilation en lui-même est sans doute comparable, et pourra à
>> terme être plus rapide si des trucs lourds codés en macros TeX finissent
>> par être ré-implémentés en Lua.
>
> espérons
>
Je parlais du temps, après le lancement, hein.
>> pdfTeX produit du pdf version 1.4, qui est lisible par Adobe Reader
>> version 6 ou plus. Je ne sais pas si c'est réglable ou pas.
>
> il faudrait le demander sur ma ml de dev-luatex
>
J'aurais plutôt dit sur la ml utilisateurs de pdftex :-) La question est
commune aux deux. Et en fait, encore avant, on va lire le manuel pdfTeX
(texdoc pdftex-ref sur une TL'08). Où l'on entend parler de
\pdfminorversion qui résout notre problème ainsi.
\pdfminorversion=3\relax
\documentclass{...}
% ...
mpg
> Hmm... je pense que ça va plutôt ralentir qu'accélérer... non ?
>
Étant donné que Lua est un des langages de scripts les plus rapides à
l'heure actuelle, et que TeX est un des langages les moins optimisés
pour certaines tâches... ça va plutôt accélérer.
Ce qui ne veut pas dire que le temps global d'exécution de LuaTeX sera
inférieur à celui de pdfTeX. Si on dit que le temps est de la forme aX +
b où X représente la « taille » du document, le a de LuaTeX a des
chances d'être plus petit à terme (ça dépendra surtout des jeux de
macros en fait) alors que le b restera toujours notablement plus grand.
Je crois que Hans (Hagen) est assez préoccupé par les questions de
vitesse, et qu'il mesure assez précisément pas mal de paramètres. Depuis
qu'il a réécrit en Lua une bonne partie de ConTeXt MkIV, tous les
paramètres qui rentrent dans mon a ci-dessus ont diminué.
mpg
> Heu, non, pdf version 1.4 est lisible par Adobe Reader version 5.x
> (regarder les propriétés du document dans Adobe Reader, onglet Description).
>
Oups, j'avions trompé.
> Cela se règle au coup par coup en mettant :
>
> \pdfminorversion=4
>
Oups, j'avions pas lu la fin du fil avant de répondre...
Damien Bonis
> Bonjour,
>
> juste pour dire que les gens intéressés peuvent tester ce que je
> développe en ce moment : les paquetages LuaLaTeX :
>
> http://github.com/eroux/lualatex/tree/master
>
> Pour l'instant luatextra et luamcallbacks commencent à ressembler à
> leur version finale, luamplib doit être légèrement adapté, et
> luainputenc doit marcher à peu près mais est loin d'être stabilisé :
> il va certainement être coupé en deux entre luainputenc et
> fancyencodings...
>
> Il n'est pas exclu non-plus que quelques texio.write_nl("prout") aient
> échapé à ma vigilance...
>
> En tous cas n'hésitez pas à faire des remarques, tester, contribuer,
> etc.
> --
> Elie
un nouvel ECM qui ne marche pas :
\documentclass{article}
\usepackage{luatextra}
%\usepackage{lmodern}
\begin{document}
\section{abécédé}
\end{document}
par contre, si on charge lmodern ça passe
Elie
> \documentclass{article}
> \usepackage{luatextra}
> %\usepackage{lmodern}
> \begin{document}
> \section{abécédé}
> \end{document}
Ça c'est typiquement un des problèmes de fonte que je vais essayer de
régler en faisant un fontenc... mais j'en suis encore aux
balbutiements...
--
Elie
Sandy Kilo
Encore un mais celui-ci doit te sembler moins étonnant
\documentclass{article}
\usepackage{luatextra}
\usepackage{lmodern}
\usepackage[draft=false]{hyperref}
Elie
En rajoutant
\usepackage[EU1]{fontenc}
ça passe tout aussi bien... je crois que c'est l'option à utiliser en
utf8... C'est du XeTeX, mais ça m'a l'air de pas mal marcher...
--
Elie
Michel Dujardin
> On 9 mar, 21:38, Damien Bonis <damis@dantaboite> wrote:
>
>> \documentclass{article}
>> \usepackage{luatextra}
>> %%%%%%%%%% FIN DU PREAMBULE MINIMAL %%%%%%%%%%%%
>
> Je dirais même plus :
>
> \documentclass{article}
> \usepackage{luatextra}
> %%%%%%%%%% FIN DU PREAMBULE MINIMAL %%%%%%%%%%%%
>
> vu que je suis en train de faire luainputenc, donc tout en utf8... A
> priori je finirai luainputenc demain.
> --
> Elie
Bonjour,
Je voudrais tester ces packages et leur nombre a grandi depuis ...
Est-ce que le préambule proposé ci-dessus est toujours valable ou est-ce
qu'il faut rajouter le chargement d'autres packages maintenant qu'il y
en a d'autres ?
Merci
Damien Bonis
> Bonjour,
>
> juste pour dire que les gens intéressés peuvent tester ce que je
> développe en ce moment : les paquetages LuaLaTeX :
>
> http://github.com/eroux/lualatex/tree/master
>
> Pour l'instant luatextra et luamcallbacks commencent à ressembler à
> leur version finale, luamplib doit être légèrement adapté, et
> luainputenc doit marcher à peu près mais est loin d'être stabilisé :
> il va certainement être coupé en deux entre luainputenc et
> fancyencodings...
>
> Il n'est pas exclu non-plus que quelques texio.write_nl("prout") aient
> échapé à ma vigilance...
>
> En tous cas n'hésitez pas à faire des remarques, tester, contribuer,
> etc.
> --
> Elie
Bonjour Elie,
Je refais mon test avec le même fichier et avec la dernière version de
packages. J'obtiens ceci :
LuaTeXtra Warning: You have requested module `luamcallbacks',
but the file luamcallbacks.lua does not provide it.
)
! LuaTeX error c:/mytexmf/tex/lualatex/luatextra/luatextra.lua:341:
attempt to
call field 'create' (a nil value)
stack traceback:
c:/mytexmf/tex/lualatex/luatextra/luatextra.lua:341: in main chunk
[C]: in function 'dofile'
<\directlua0>:1: in main chunk.
l.55 ...t{dofile(kpse.find_file("luatextra.lua"))}
The lua interpreter ran into a problem, so the
remainder of this lua chunk will be ignored.
Pour le warning, c'est pas nouveau je crois par contre il y a cette erreur.
Damien
Elie
> The lua interpreter ran into a problem, so the
> remainder of this lua chunk will be ignored.
>
> Pour le warning, c'est pas nouveau je crois par contre il y a cette erreur.
Ah, je vois que les gens suivent github ;-)
Sinon le préambule précédent est toujours bon, il ne le sera plus
bientôt (demain ?). Un de tes messages d'erreur est dû à une version
de luamcallbacks trop ancienne, mais je crois que je me suis un peu
planté dans mon dernier commit, ce sera arrangé demain aussi.
Sinon j'ai un version de inputenc+fontencT1 qui marche bien là, en
rendant moulte caractères actifs, et je suis en train de préparer un
encodage EU2 qui désactive les caractères pour utiliser directement
les fontes unicode... La bonne nouvelle c'est que fontenc n'aura pas
besoin d'être changé, par contre la mauvaise c'est que l'équipe LaTeX
n'a pas réagi *du tout* à une proposition de modification d'inputenc
pour l'utilisation avec LuaTeX... on verra bien...
--
Elie
Damien Bonis
> On 22 mar, 19:08, Damien Bonis <damis@dantaboite> wrote:
>
>> The lua interpreter ran into a problem, so the
>> remainder of this lua chunk will be ignored.
>>
>> Pour le warning, c'est pas nouveau je crois par contre il y a cette erreur.
>
> Ah, je vois que les gens suivent github ;-)
>
> Sinon le préambule précédent est toujours bon, il ne le sera plus
> bientôt (demain ?).
Dès qu'il y a du nouveau, donne nous un bon préambule.
> Un de tes messages d'erreur est dû à une version
> de luamcallbacks trop ancienne, mais je crois que je me suis un peu
> planté dans mon dernier commit, ce sera arrangé demain aussi.
en ce qui concerne le fichier luamcallbacks.lua, pourras-tu le mettre
directement dans le dossier luamcallbacks à côté du fichier .dtx : c'est
quand même mieux que d'aller le chercher ailleurs.
> Sinon j'ai un version de inputenc+fontencT1 qui marche bien là, en
> rendant moulte caractères actifs, et je suis en train de préparer un
> encodage EU2 qui désactive les caractères pour utiliser directement
> les fontes unicode... La bonne nouvelle c'est que fontenc n'aura pas
> besoin d'être changé, par contre la mauvaise c'est que l'équipe LaTeX
> n'a pas réagi *du tout* à une proposition de modification d'inputenc
> pour l'utilisation avec LuaTeX... on verra bien...
Quelle conséquence cela a-t-il pour ton travail ? Je sais que tu abats
déjà un boulot énorme mais ne peux-tu pas modifier le inputenc comme tu
l'entends (l'appeler inputencx si par hasard c'était une extension de
inputenc ou encore luainputencx si c'est une extension qui utilise du lua)
> --
> Elie
mpg
> Quelle conséquence cela a-t-il pour ton travail ? Je sais que tu abats
> déjà un boulot énorme mais ne peux-tu pas modifier le inputenc comme tu
> l'entends (l'appeler inputencx si par hasard c'était une extension de
> inputenc ou encore luainputencx si c'est une extension qui utilise du lua)
>
Le point est justement que si Élie (ou qui que ce soit d'autre que
l'équipe LaTeX) veut modifier inputenc, il doit l'appeler autrement,
alors que pour l'utilisateur ça serait plus naturel que le nom ne change
pas. D'où l'appel à l'équipe LaTeX.
mpg
> Sinon j'ai un version de inputenc+fontencT1 qui marche bien là, en
> rendant moulte caractères actifs, et je suis en train de préparer un
> encodage EU2 qui désactive les caractères pour utiliser directement
> les fontes unicode...
Et avec les fontes pas-unicode, qu'en est-il ?
> La bonne nouvelle c'est que fontenc n'aura pas
> besoin d'être changé, par contre la mauvaise c'est que l'équipe LaTeX
> n'a pas réagi *du tout* à une proposition de modification d'inputenc
> pour l'utilisation avec LuaTeX... on verra bien...
J'avoue que je ne suis pas du tout sûr que ça soit la meilleure chose à
faire, de modifier inputenc pour qu'il fasse appel à luainputenc, du
moins dans l'état actuel des choses. Avec cette histoire des fichiers
auxiliaires (entre autres), on est quand même relativement loin de la
compatibilité absolue, et je n'aime pas trop l'idée de laisser
l'illusion à l'utilisateur que tout est pareil alors que ce n'est pas le
cas.
Par ailleurs, si quelque chose était décidé à ce sujet maintenant, il
est probable que ça finirait gravé dans la pierre et c'est sans doute un
peut tôt pour ça.
À mon avis, il n'est pas déraisonnable de demander aux gens qui veulent
bêta-tester LuaTeX maintenant d'encoder leur source en UTF-8 et de ne
pas utiliser inputenc (après tout, c'est bien ce qu'on demande aux
utilisateurs de XeLaTeX et personne ne s'en plaint, alors que c'est même
pas pour du bêta-test). Et de prendre son temps pour tester puis
développer les solutions de rétro-compatibilité (comme luainputenc et
peut-être son utilisation automatique par le vrai inputenc), vu que
c'est par définition un domaine où il faut être conservateur.
Damien Bonis
Exact
Elie
> Dès qu'il y a du nouveau, donne nous un bon préambule.
le bon préambule sera le préambule classique LaTeX en utf8:
\usepackage[utf8]{inputenc}
\usepackage[T1]{inputenc}
Ça marchera bien (pour répondre à Manuel) pour les fontes T1, ça fera
pile la même chose que l'ancien LaTeX, à la macro LICR près. Par
contre j'ai juste un petit problème légal : est-ce que je peux piquer
du code d'inputenc.sty et le mettre dans mon luainputenc.sty (pareil
pour utf8.def -> lutf8.def) sans que ça gêne la lppl ?
> en ce qui concerne le fichier luamcallbacks.lua, pourras-tu le mettre
> directement dans le dossier luamcallbacks à côté du fichier .dtx : c'est
> quand même mieux que d'aller le chercher ailleurs.
Hmmm... je suis suffisament bordélique pour que ce genre de choses
dégénère et que les deux ne soient pas synchronisés... un petit
pdflatex luamcallbacks.dtx te donnera le bon luamcallbacks.lua. Si
l'erreur persiste, envoie-moi par mail ta version de
luamcallbacks.lua, ce n'est vraiment pas normal que ça ne marche pas.
> Quelle conséquence cela a-t-il pour ton travail ? Je sais que tu abats
> déjà un boulot énorme mais ne peux-tu pas modifier le inputenc comme tu
> l'entends (l'appeler inputencx si par hasard c'était une extension de
> inputenc ou encore luainputencx si c'est une extension qui utilise du lua)
Le but c'est de faire en sorte que LuaLaTeX puisse compiler des vieux
documents LaTeX.. mais plus de détails dans un prochain post.
--
Elie
Elie
> Et avec les fontes pas-unicode, qu'en est-il ?
Ça marche (mais c'est pas encore commité) !
> J'avoue que je ne suis pas du tout sûr que ça soit la meilleure chose à
> faire, de modifier inputenc pour qu'il fasse appel à luainputenc, du
> moins dans l'état actuel des choses. Avec cette histoire des fichiers
> auxiliaires (entre autres), on est quand même relativement loin de la
> compatibilité absolue, et je n'aime pas trop l'idée de laisser
> l'illusion à l'utilisateur que tout est pareil alors que ce n'est pas le
> cas.
>
> Par ailleurs, si quelque chose était décidé à ce sujet maintenant, il
> est probable que ça finirait gravé dans la pierre et c'est sans doute un
> peut tôt pour ça.
>
> À mon avis, il n'est pas déraisonnable de demander aux gens qui veulent
> bêta-tester LuaTeX maintenant d'encoder leur source en UTF-8 et de ne
> pas utiliser inputenc (après tout, c'est bien ce qu'on demande aux
> utilisateurs de XeLaTeX et personne ne s'en plaint, alors que c'est même
> pas pour du bêta-test). Et de prendre son temps pour tester puis
> développer les solutions de rétro-compatibilité (comme luainputenc et
> peut-être son utilisation automatique par le vrai inputenc), vu que
> c'est par définition un domaine où il faut être conservateur.
En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
les anciennes fontes (en fait toutes les fontes quasiment). La
proposition de Will est la suivante : inputenc.sty appelle
luainputenc.sty si appelé avec luatex, et inputenclegacy.sty si appelé
avec pdftex. Ça permet de faire en sorte que luainputenc soit encore
modifiable sans que l'équipe LaTeX n'ait vraiment à s'en occuper, et
donc de pouvoir s'adapter à des nouveautés du moteur, comme par
exemple (soyons optimistes), la possibilité d'écrire autre chose que
de l'utf8. C'est de toute façon le seul miracle qui permettrait une
rétro-compatibilité de 100%, et donc d'être vraiment conservateur...
autrement de toute façon on peut améliorer les euristiques, mais ça ne
sera jamais du 100%...
En attendant de toute façon, je pense que permettre aux gens de
compiler leurs vieux documents LaTeX avec LuaTeX, même si ce n'est pas
parfait, c'est quelquechose d'intéressant...
--
Elie
mpg
>> Et avec les fontes pas-unicode, qu'en est-il ?
>
> Ça marche (mais c'est pas encore commité) !
>
Cool :-)
> En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
> les anciennes fontes (en fait toutes les fontes quasiment).
On peut envisager d'autres solutions techniques qui n'auraient pas cet
inconvénient.
> En attendant de toute façon, je pense que permettre aux gens de
> compiler leurs vieux documents LaTeX avec LuaTeX, même si ce n'est pas
> parfait, c'est quelquechose d'intéressant...
Bien sûr que c'est intéressant. Mais on en a pas besoin tout de suite.
Et ce dont on a surtout pas besoin tout de suite, c'est de laisser
croire que ça marche alors qu'il existe des cas où ça ne peut pas encore
marcher et que ces cas ne sont pas clairement identifiés et documentés.
On a pas besoin non plus de créer une confusion entre ce qui est supposé
stable (inputenc) et ce qui est encore beaucoup trop récent pour l'être
(luainputenc).
Ceci dit, bien sûr que luainputenc est très intéressant, et qu'il est
intéressant d'envisager de le faire appeler par inputenc comme mesure de
rétro-compatibilité. Je pense juste qu'actuellement c'est le moment d'y
réfléchir, de tester, d'améliorer et de documenter, et que le reste (le
renommage en lui-même) ne devrait venir que quand ça sera prêt.
mpg
> contre j'ai juste un petit problème légal : est-ce que je peux piquer
> du code d'inputenc.sty et le mettre dans mon luainputenc.sty (pareil
> pour utf8.def -> lutf8.def) sans que ça gêne la lppl ?
>
Tu peux tout à fait, la LPPL ne serait pas vraiment une licence libre
sinon. Par contre la section 6 de la LPPL impose certaines
resctrictions sur les modifications en elle-mêmes (essentiellement le
façon de les signaler), et la section section 10 sur la licence à
choisir pour une œuvre dérivée (essentiellement, préserver pour l'œuvre
dérivées les conditions de la section 6 de la LPPL).
Maintenant, il faut voir combien de code tu vas piquer, ce n'est
peut-être pas assez pour qu'on puisse considérer luainputenc comme une
œuvre dérivée de inputenc (je ne sais pas s'il existe de critère précis
à ce sujet), auquel cas tu est parfaitement libre.
Au passage, si on lit attentivement la section 6 de la LPPL 1.3c, je ne
crois pas qu'il te soit interdit de distribuer un paquet s'appelant
inputenc.sty, du moment qu'il est clairement identifié comme n'étant pas
le inputenc.sty de l'équipe LaTeX, que les différences sont mentionnées,
etc etc. Ceci dit, je ne t'encourage pas à le faire. (Toute notion de
licence mise à part, TeX Live n'aime pas avoir dans les chemins d'entrée
de TeX deux fichiers ayant le même nom.)
> Hmmm... je suis suffisament bordélique pour que ce genre de choses
> dégénère et que les deux ne soient pas synchronisés...
Je me demande si un petit hook pre-commit ne réglerait pas l'affaire.
Elie
> > En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
> > les anciennes fontes (en fait toutes les fontes quasiment).
>
> On peut envisager d'autres solutions techniques qui n'auraient pas cet
> inconvénient.
Disons que pour utiliser les anciennes fontes avec utf8 ce n'est pas
spécialement un inconvénient vu que LaTeX fait pareil...
Pour utiliser des fontes unicode par contre, pas besoin d'inputenc,
mais il faudra quand même dire à fontenc d'utiliser EU2, histoire
qu'il n'utilise pas OT1. Par contre cette utilisation n'est pas encore
vraiment très répandue étant donné que LuaTeX ne sait pas lire les
OTF... du coup pour EU2 j'ai même carrément du mal à trouver une fonte
par défaut ; ce que je pense faire c'est loader luaminimalotf et
mettre une lmodern par défaut...
--
Elie
Elie
> Pour utiliser des fontes unicode par contre, pas besoin d'inputenc,
> mais il faudra quand même dire à fontenc d'utiliser EU2, histoire
> qu'il n'utilise pas OT1.
En fait le problème est plus la fonte par défaut que le codage OT1,
qui dans ce cas-là aurait le même effet qu'EU2, c'est à dire aucun...
--
Elie
Jean-Marc Bourguet
> En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
> les anciennes fontes (en fait toutes les fontes quasiment).
Je suis de beaucoup trop loin, et je m'excuse si le sujet a deja ete
aborde, mais ca semble tres bizarre de devoir specifier inputenc pour gerer
ce qui me semble relever de fontenc.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Elie
> Je suis de beaucoup trop loin, et je m'excuse si le sujet a deja ete
> aborde, mais ca semble tres bizarre de devoir specifier inputenc pour gerer
> ce qui me semble relever de fontenc.
Tout simplement parceque c'est fait comme ça dans LaTeX : les fichiers
*enc.dfu sont chargés par DefineFontEncoding (si je me rappelle bien),
commande qui dans le cas d'utf8 est définie dans utf8.enc appelé par
inputenc... je vais déjà voir ce que disent les devs LaTeX sur le fait
de changer inputenc... s'ils ne s'y opposent pas, je pourrais
éventuellement changer fontenc pour faire en sorte que
DefineFontEncoding soit définie par défaut à son comportement actuel
en utf8, et qu'elle ait son comportement actuel avec les encodages 8-
bit, ce qui serait, il est vrai, plus logique. Cependant je ne suis
pas partisan de mettre des préfixes lua dans tous les packages de base
(luainputenc, luafontenc), donc si les devs LaTeX ne veulent pas
changer inputenc, je crois que je vais garder fontenc tel qu'il est,
et que donc inputenc sera nécessaire même en utf8... Le troll est en
cours sur la liste latex-l, on verra ce que ça donnera...
--
Elie
Ulrike Fischer
>> En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
>> les anciennes fontes (en fait toutes les fontes quasiment).
> Je suis de beaucoup trop loin, et je m'excuse si le sujet a deja ete
> aborde, mais ca semble tres bizarre de devoir specifier inputenc pour gerer
> ce qui me semble relever de fontenc.
C'est parceque le caractere a la fin depend de ton input ;-)
fontenc decrit la connection entre des commandes et les positions
dans la fonte. inputenc fait la connection entre des caracteres
non-ascii et des commandes.
inputenc fontenc
ß -------------> \ss ----------------> position XYZ
--
Ulrike Fischer
Jean-Marc Bourguet
Il doit y avoir qqch de propre a luatex que j'ai saute (comme je l'ai
ecrit, je suis de tres loin et j'ai peut-etre comble trop de trous dans ma
connaissance avec mon imagination). Parce que ce que tu decris ici est
justement ma comprehension: inputenc transforme ce qui n'est pas ASCII en
commande, fontenc definit les commande pour qu'elles designent la bonne
position dans la fonte, et dans ce cadre, l'utilisation de fonte ne releve
que du fontenc.
J'imaginais qu'avec que luatex fonctionne en interne en Unicode -- donc
supprimant peut-etre la necessite d'un codage en commande pour utiliser
simplement le code Unicode, peut-etre completer dans les zones privees pour
avoir un codet pour les caracteres precomposes non existant dans unicode.
Un inputenc pour luatex utiliserait pour moi simplement les mecanismes
herites d'omega (ca je suis quasiment certain qu'omega avec des choses pour
ca) pour transcoder vers unicode.
Ulrike Fischer
> Ulrike Fischer <ne...@nililand.de> writes:
>
>> Am 24 Mar 2009 15:11:32 +0100 schrieb Jean-Marc Bourguet:
>>
>>>> En fait il faudra de toute façon utiliser (lua)inputenc pour utiliser
>>>> les anciennes fontes (en fait toutes les fontes quasiment).
>>
>>> Je suis de beaucoup trop loin, et je m'excuse si le sujet a deja ete
>>> aborde, mais ca semble tres bizarre de devoir specifier inputenc pour gerer
>>> ce qui me semble relever de fontenc.
>>
>> C'est parceque le caractere a la fin depend de ton input ;-)
>> fontenc decrit la connection entre des commandes et les positions
>> dans la fonte. inputenc fait la connection entre des caracteres
>> non-ascii et des commandes.
>>
>> inputenc fontenc
>> ß -------------> \ss ----------------> position XYZ
>
> Il doit y avoir qqch de propre a luatex que j'ai saute (comme je l'ai
> ecrit, je suis de tres loin et j'ai peut-etre comble trop de trous dans ma
> connaissance avec mon imagination). Parce que ce que tu decris ici est
> justement ma comprehension: inputenc transforme ce qui n'est pas ASCII en
> commande, fontenc definit les commande pour qu'elles designent la bonne
> position dans la fonte, et dans ce cadre, l'utilisation de fonte ne releve
> que du fontenc.
Oui. Mais si inputenc manque, latex ne sait plus que "ß" veut dire
"\ss".
>
> J'imaginais qu'avec que luatex fonctionne en interne en Unicode -- donc
> supprimant peut-etre la necessite d'un codage en commande pour utiliser
> simplement le code Unicode, peut-etre completer dans les zones privees pour
> avoir un codet pour les caracteres precomposes non existant dans unicode.
>
> Un inputenc pour luatex utiliserait pour moi simplement les mecanismes
> herites d'omega (ca je suis quasiment certain qu'omega avec des choses pour
> ca) pour transcoder vers unicode.
Que gagnes-tu si luatex "sait" que l'input "ß" veut dire que tu veux
le caractere Unicode-je-ne-sais-quoi? Il lui manque encore
l'information ou il peut trouver le glyph "ß" dans la fonte. Si la
fonte elle-meme comprend aussi l'unicode, c'est simple. Mais pour
les autres (les vieilles) fontes il faut quelque part l'information
"prends la position XX".
--
Ulrike Fischer
Elie
> Il doit y avoir qqch de propre a luatex que j'ai saute (comme je l'ai
> ecrit, je suis de tres loin et j'ai peut-etre comble trop de trous dans ma
> connaissance avec mon imagination). Parce que ce que tu decris ici est
> justement ma comprehension: inputenc transforme ce qui n'est pas ASCII en
> commande, fontenc definit les commande pour qu'elles designent la bonne
> position dans la fonte, et dans ce cadre, l'utilisation de fonte ne releve
> que du fontenc.
Hmm non pas tout à fait... comme l'a dit Ulrike, fontenc fait le lien
entre les commandes et la position... mais cela nécessite d'avoir des
commandes, et pour avoir des commandes il faut appeler inputenc. Une
autre solution serait de faire ça en lua, c'est à dire à passer
l'input à la moulinette pour le transformer en quelquechose mangeable
par T1, mais c'est une solution vraiment beaucoup plus complexe et qui
génèrera potentiellement des incompatibilités, alors que celle-ci va
assez vite à développer et est vraiment rétro-compatible. Évidemment
dans les lendemains ensoleillés de LuaLaTeX tout le monde utilisera
fontspec et des fontes unicode, donc il n'y aura plus besoin ni
d'inputenc ni de fontenc.
> J'imaginais qu'avec que luatex fonctionne en interne en Unicode -- donc
> supprimant peut-etre la necessite d'un codage en commande pour utiliser
> simplement le code Unicode, peut-etre completer dans les zones privees pour
> avoir un codet pour les caracteres precomposes non existant dans unicode.
Des caractères non-présents dans unicode... tu penses à quoi ?
> Un inputenc pour luatex utiliserait pour moi simplement les mecanismes
> herites d'omega (ca je suis quasiment certain qu'omega avec des choses pour
> ca) pour transcoder vers unicode.
LuaTeX peut utiliser les fontes Omega (ofm, ovf, etc.), mais
malheureusement il n'y en a pas des masses (corrigez-moi si je me
fourvoie), et les gens voudront de toute façon utiliser leur bon vieux
times.
--
Elie
Jean-Marc Bourguet
> Que gagnes-tu si luatex "sait" que l'input "ß" veut dire que tu veux
> le caractere Unicode-je-ne-sais-quoi? Il lui manque encore
> l'information ou il peut trouver le glyph "ß" dans la fonte. Si la
> fonte elle-meme comprend aussi l'unicode, c'est simple. Mais pour
> les autres (les vieilles) fontes il faut quelque part l'information
> "prends la position XX".
C'est le boulot de fontenc pas de inputenc, non?
Il y a deux parametres qui sont raisonnablement independant. Il est sense
de les specifier separement.
mpg
>> On peut envisager d'autres solutions techniques qui n'auraient pas cet
>> inconvénient.
>
> Disons que pour utiliser les anciennes fontes avec utf8 ce n'est pas
> spécialement un inconvénient vu que LaTeX fait pareil...
>
J'ai oublié de préciser que j'estime que devoir rendre actif 128
caractères fait partie àmha des inconvénients du LaTeX actuel :-) Donc
je persiste à appeler ça un inconvénient, même si tu as raison de
souligner que ça ne serait pas pire que maintenant.
Ulrike Fischer
> Ulrike Fischer <ne...@nililand.de> writes:
>
>> Que gagnes-tu si luatex "sait" que l'input "ß" veut dire que tu veux
>> le caractere Unicode-je-ne-sais-quoi? Il lui manque encore
>> l'information ou il peut trouver le glyph "ß" dans la fonte. Si la
>> fonte elle-meme comprend aussi l'unicode, c'est simple. Mais pour
>> les autres (les vieilles) fontes il faut quelque part l'information
>> "prends la position XX".
>
> C'est le boulot de fontenc pas de inputenc, non?
Cela depend un peu comment tu le fais.
Si tu fais
\catcode`\ß=\active
et ensuite
\def ß {\ss} c'est plutôt comparable à inputenc
\def ß {\char XY} c'est plutôt fontenc.
Du point pratique je pense que c'est plus simple de faire le
premier, parce que tout le code qui map \ss au fonte existe dans les
fichier de fontenc.
--
Ulrike Fischer
mpg
> (luainputenc, luafontenc), donc si les devs LaTeX ne veulent pas
> changer inputenc, je crois que je vais garder fontenc tel qu'il est,
> et que donc inputenc sera nécessaire même en utf8... Le troll est en
> cours sur la liste latex-l, on verra ce que ça donnera...
Qu'on m'accuse de jouer sur le mots si on veut, mais j'appele ça une
discussion plutôt qu'un troll (même si ce n'est pas une discussion aussi
posée et calme qu'on l'imaginerait au pays des bisounours), dans le sens
où à la fin une décision non-triviale doit être prise, qui peut avoir une
influence sur un grand nombre d'utilisateurs (en gros, la plupart de ceux
qui voudront essayer LaTeX avec LuaTeX sur leur TeX Live 2009).
Et je voudrais souligner un truc, c'est que le rôle des mainteneurs de
LaTeX, qui privilégient la stabilité, est assez ingrat, mais que la
stabilité a aussi ses avantages (quand elle laisse la place au
développement de se produire par ailleurs, ce qui est le cas
actuellement), dont on bénéficie tous souvent sans même le remarquer.
Bref, on aura compris que je plaide pour attendre (lire : continuer à
réfléchir, développer et surtout tester) avant de modifier inputenc et
fontenc pour éventuellement appeler luainputenc. Élie a déjà mentionné
qu'il y a une discussion en cours sur latex-l [1], où je pense avoir dit
ce que j'avais à dire, j'ai la flemme de le répéter en français ici,
surtout si ça doit être considéré comme un troll.
[1]: ah bah non, on dirait qu'il n'y a pas d'archive publiques :-(
Jean-Marc Bourguet
> Am 24 Mar 2009 16:40:19 +0100 schrieb Jean-Marc Bourguet:
>
> > Ulrike Fischer <ne...@nililand.de> writes:
> >
> >> Que gagnes-tu si luatex "sait" que l'input "ß" veut dire que tu veux
> >> le caractere Unicode-je-ne-sais-quoi? Il lui manque encore
> >> l'information ou il peut trouver le glyph "ß" dans la fonte. Si la
> >> fonte elle-meme comprend aussi l'unicode, c'est simple. Mais pour
> >> les autres (les vieilles) fontes il faut quelque part l'information
> >> "prends la position XX".
> >
> > C'est le boulot de fontenc pas de inputenc, non?
>
> Cela depend un peu comment tu le fais.
>
> Si tu fais
> \catcode`\ß=\active
> et ensuite
>
> \def ß {\ss} c'est plutôt comparable à inputenc
Nous sommes d'accord la dessus.
> \def ß {\char XY} c'est plutôt fontenc.
Ca me semble plutot etre une confusion des deux, parce que ca ne marche
qu'en supposant connaitre le codage d'entree et celui des fontes (et ca
suppose en prime que les fontes aient toutes le meme codage).
mpg
> Ulrike Fischer <ne...@nililand.de> writes:
>
>> Que gagnes-tu si luatex "sait" que l'input "ß" veut dire que tu veux
>> le caractere Unicode-je-ne-sais-quoi? Il lui manque encore
>> l'information ou il peut trouver le glyph "ß" dans la fonte. Si la
>> fonte elle-meme comprend aussi l'unicode, c'est simple. Mais pour
>> les autres (les vieilles) fontes il faut quelque part l'information
>> "prends la position XX".
>
> C'est le boulot de fontenc pas de inputenc, non?
>
Il y a trois encodages en jeu : l'encodage du source, celui de la fonte,
et entre les deux l'encodage interne. Le job de fontenc est de convertir
de l'encodage interne vers l'encodage de la fonte. Celui d'inputenc est
de convertir de l'encodage du source vers l'encodage interne.
> Il y a deux parametres qui sont raisonnablement independant. Il est sense
> de les specifier separement.
>
Pas entièrement, parce que les deux doivent être d'accord sur ce qu'est
l'encodage interne. Si inputenc convertit de l'encodage du source vers
utf-8, et que fontenc convertit de LICR vers l'encodage de sortie, ça
marche pas.
Pour résoudre ce problème, deux approches sont théoriquement possibles :
1. Modifier inputenc pour qu'il continue à convertir en LICR ;
2. Modifier fontenc pour qu'il puisse convertir depuis l'utf-8.
Pour l'instant, c'est la première approche dont parle Élie (si j'ai bien
compris). Ça peut paraître bizarre à première vue, mais c'est en effet
une approche censée car elle apporte pas mal de bonus pour d'autres
problèmes, par exemple les fichiers intermédiaires.
Puisque j'en parle, autant compléter le tableau ci-dessus : parmi les
trois encodages cités (ou plus), il faut choisir celui des fichiers
intermédiaires (fichiers .aux par exemple) : qui vont être écrits (on
est donc plus vers la sortie) puis relus (là c'est de l'entrée).
La solution retenue par LaTeX est de les écrire en LICR, à savoir son
encodage interne, en se reposant sur la propriété fondamentale suivant :
LICR est un sous-encodage de tous les encodages d'entrées possibles (il
n'utilise que de l'ascii). Du coup, quand on lit un fichier, on peut
toujours supposer qu'il est écrit dans l'encodage d'entrée.
Si on remplace l'encodage interne par utf-8, il n'est plus inclus dans
tous les encodages d'entrée, donc la question se pose quand on ouvre un
fichier de savoir dans quel encodage il est, contrairement à ce qui se
passe si on garde LICR comme codage intermédiaire.
Le tableau ci-dessus est un peu simplificateur en ce qui concerne
l'enocdage des fichiers intermédiaires : en vrai, c'est potentiellement
un mix entre du LICR et un encodage indéterminé mais qu'on peut souvent
supposer être l'encodage d'entrée [1]. En LuaTeX, ça serait un mix entre
du LICR et de l'utf-8 dans ce cas, et c'est donc susceptible de ne pas
marcher comme avant.
[1] Un cas où on a un caractère non-ascii écrit dans le fichier
intermédiaire ave l'encodage d'entrée est si on y écrit par exemple
'\string«'. Un cas où il n'est pas écrit dans l'encodage d'entrée, cas
qui s'est présenté il n'y a pas si longtemps ici même, est si on essaie
d'écrire un fichier avec VerbatimOut : là, les caractères non-ascii
seront convertis en T1 à l'écriture, ce qui pose potentiellement des
sales problèmes à la relecture.
mpg
>> J'imaginais qu'avec que luatex fonctionne en interne en Unicode -- donc
>> supprimant peut-etre la necessite d'un codage en commande pour utiliser
>> simplement le code Unicode, peut-etre completer dans les zones privees pour
>> avoir un codet pour les caracteres precomposes non existant dans unicode.
>
> Des caractères non-présents dans unicode... tu penses à quoi ?
>
Pas forcément des vrais caractères, mais des combinaisons
caractères-accent pour lesquelles il n'existe pas de caractère Unicode
correspondant. Si on regarde les tableaux de commandes d'accents dans
symbols-a4, on trouve plein de trucs qui n'existent en Unicode (enfin,
j'entends, pas en caractère unique, il faut passer par des caractères
combinants).
D'ailleurs, j'ai eu des gros problèmes quand j'ai voulu reproduire des
analogues de ces tableuaux en utilisant XeTeX.
> LuaTeX peut utiliser les fontes Omega (ofm, ovf, etc.), mais
> malheureusement il n'y en a pas des masses (corrigez-moi si je me
> fourvoie), et les gens voudront de toute façon utiliser leur bon vieux
> times.
Je ne sais pas si « le bon vieux times » exprime bien ta pensée, car il
existe très certainement des version Unicode de Times. Mais je suis
d'accord sur le fond : quoi qu'on en dise, les gens voudront pouvoir
continuer à utiliser leures bonnes vieilles fontes en vieux encodages
tout moins bien qu'Unicode, mais qui existent.
Damien Bonis
Chépas ici http://news.gmane.org/group/gmane.comp.tex.latex.latex3 ?
(désolé de mettre mon grain de sel)
mpg
>> [1]: ah bah non, on dirait qu'il n'y a pas d'archive publiques :-( [2]
>
> Chépas ici http://news.gmane.org/group/gmane.comp.tex.latex.latex3 ?
Ah oui, bien vu. (C'est marrant parce que sur le gestionnaire de la
liste, les archives sont reservées aux abonnés.)
> (désolé de mettre mon grain de sel)
Bah faut pas être désolé, au contraire, tu fournis une réponse utile :-)
Damien Bonis
> Damien Bonis scripsit:
>
>>> [1]: ah bah non, on dirait qu'il n'y a pas d'archive publiques :-( [2]
>> Chépas ici http://news.gmane.org/group/gmane.comp.tex.latex.latex3 ?
>
> Ah oui, bien vu. (C'est marrant parce que sur le gestionnaire de la
> liste, les archives sont reservées aux abonnés.)
>
>> (désolé de mettre mon grain de sel)
>
> Bah faut pas être désolé, au contraire, tu fournis une réponse utile :-)
D'ailleurs, c'est pas du tout pour faire de la pub pour gmane (mais pour
faire connaître un moyen pour discuter et s'informer) mais on peut se
connecter à son serveur gratuitement et s'abonner à n'importe quel
groupe sachant que l'intérêt de ce serveur de news (news.gmane.org)
c'est que les groupes qu'il propose reflètent exactement les messages
qui sont postés sur les listes de diffusion (context, pgf, luatex,
latex3, xetex, ... tout ce qui nous intéresse de près ou de loin ici) :
on peut lire les messages et même y répondre.
Le très gros avantage, c'est que comme ça, plus besoin de s'inscrire
pour recevoir les listes. Cool, n'est-ce pas ?
Damien Bonis
> D'ailleurs, c'est pas du tout pour faire de la pub pour gmane (mais pour
> faire connaître un moyen pour discuter et s'informer) mais on peut se
> connecter à son serveur gratuitement et s'abonner à n'importe quel
> groupe sachant que l'intérêt de ce serveur de news (news.gmane.org)
> c'est que les groupes qu'il propose reflètent exactement les messages
> qui sont postés sur les listes de diffusion (context, pgf, luatex,
> latex3, xetex, ... tout ce qui nous intéresse de près ou de loin ici) :
> on peut lire les messages et même y répondre.
"et même y répondre" : là je m'emballe, je crois pas en fait.
Jean-Marc Bourguet
> Elie scripsit:
>
> >> J'imaginais qu'avec que luatex fonctionne en interne en Unicode -- donc
> >> supprimant peut-etre la necessite d'un codage en commande pour utiliser
> >> simplement le code Unicode, peut-etre completer dans les zones privees pour
> >> avoir un codet pour les caracteres precomposes non existant dans unicode.
> >
> > Des caractères non-présents dans unicode... tu penses à quoi ?
> >
> Pas forcément des vrais caractères, mais des combinaisons
> caractères-accent pour lesquelles il n'existe pas de caractère Unicode
> correspondant.
C'est bien a ca que je pensais.
Ulrike Fischer
>> \def ß {\char XY} c'est plutôt fontenc.
> Ca me semble plutot etre une confusion des deux, parce que ca ne marche
> qu'en supposant connaitre le codage d'entree
Avec xetex/luatex le codage d'entree est connu (ou plus exactement
le codage interne), c'est "unicode". Les engines connaissent le "ß"
de la meme facon qu'ils connaissent un "a" ou un "b".
> et celui des fontes (et ca
> suppose en prime que les fontes aient toutes le meme codage).
Il faut naturellement plusieurs definitions de ce type. Comme avec
\ss:
\DeclareTextSymbol{\ss}{T1}{255} (t1enc.def)
\DeclareTextSymbol{\ss}{OT1}{25} (ot1enc.def)
\DeclareUTFcharacter[\UTFencname]{x00DF}{\ss} (xunicode.sty)
etc
C'est pour ca qu'une solution du type "inputenc" (\def ß {\ss}) est
plus simple: c'est seulement une definition et toutes les
definitions de \ss pour les differents codages de fontes existent
deja.
--
Ulrike Fischer
Elie
tester dans tous les sens. Je n'ai pas encore intégré le support de
l'encodage EU2, qui sera le futur encodage unicode, donc ne testez que
des choses anciennes. Notamment évidement les fontes otf seront
encodées n'importecomment, donc n'utilisez que des bonnes vieilles
fontes.
En gros pour les tests, prenez vos vieux documents, et remplacez
inputenc par luainputenc. C'est la seule modification nécessaire
normalement. Je vous demande de tester avant d'avoir fini le support
de EU2 car je serai absent pendant les 4 prochains jours, et si je
peux avoir déjà des retours sur ce que j'ai fait ce sera bien !
Si y'a un gros bug énorme au premier test, c'est peut-être parceque
j'ai fait mon boulet en commitant, mais normalement ça devrait être
bon...
Merci d'avance !
--
Elie
Jaunty
> Bonjour,
>
> juste pour dire que les gens intéressés peuvent tester ce que je
> développe en ce moment : les paquetages LuaLaTeX :
>
> http://github.com/eroux/lualatex/tree/master
>
> Pour l'instant luatextra et luamcallbacks commencent à ressembler à
> leur version finale, luamplib doit être légèrement adapté, et
> luainputenc doit marcher à peu près mais est loin d'être stabilisé :
> il va certainement être coupé en deux entre luainputenc et
> fancyencodings...
>
> Il n'est pas exclu non-plus que quelques texio.write_nl("prout") aient
> échapé à ma vigilance...
>
> En tous cas n'hésitez pas à faire des remarques, tester, contribuer,
> etc.
> --
> Elie
Bravo pour ces packages, beau travail. Cependant, quelle différence
fait-on entre luaminimalotf et luaotfload ? Il me semble que ces deux
packages font plus ou moins la même chose et sont donc concurrents ?
L'un d'entre eux va-t-il disparaître à la longue ou sera-t-il absorbé
par l'autre à moins que les deux ne soient absorbés par une version de
fontspec pour luatex ?
Elie
> Bravo pour ces packages, beau travail. Cependant, quelle différence
> fait-on entre luaminimalotf et luaotfload ? Il me semble que ces deux
> packages font plus ou moins la même chose et sont donc concurrents ?
> L'un d'entre eux va-t-il disparaître à la longue ou sera-t-il absorbé
> par l'autre à moins que les deux ne soient absorbés par une version de
> fontspec pour luatex ?
luaminimalotf est une implémentation maison, par Arthur
principalement, qui a un petit code compréhensible, mais est loin de
faire tout ce que l'on voudrait qu'il fasse (il faut l'oublier pour
l'arabe par exemple). luaotfload est une grosse usine à gaz (il est
extrêmement difficile de se plonger dans le code) prise de ConTeXt qui
fait déjà beaucoup plus de choses, comme l'arabe.
Je bosse en ce moment sur luafontspec, mais cela n'entre pas du tout
en concurrence, en fait luafontspec (comme fontspec) prend juste des
arguments "human readable", par exemple "Ligatures = historical" et
les transforme en arguments de \font avec la syntaxe XeTeX, dans ce
cas "+hlig" puis appelle \font avec tous les arguments. Ensuite c'est
luaotfload qui va vraiment ouvrir l'otf. Évidemment il y a quelques
trucs en plus, mais globalement c'est le principe.
--
Elie
Damien Bonis
> Bonjour,
>
> juste pour dire que les gens intéressés peuvent tester ce que je
> développe en ce moment : les paquetages LuaLaTeX :
>
> http://github.com/eroux/lualatex/tree/master
>
> Pour l'instant luatextra et luamcallbacks commencent à ressembler à
> leur version finale, luamplib doit être légèrement adapté, et
> luainputenc doit marcher à peu près mais est loin d'être stabilisé :
> il va certainement être coupé en deux entre luainputenc et
> fancyencodings...
>
> Il n'est pas exclu non-plus que quelques texio.write_nl("prout") aient
> échapé à ma vigilance...
>
> En tous cas n'hésitez pas à faire des remarques, tester, contribuer,
> etc.
> --
> Elie
Je suis en luatex 0.40 et je viens de mettre à jour avec tes packages.
J'obtiens ça :
! I can't find file `luatextra-latex.tex'.
l.52 \input luatextra-latex.tex
Please type another input file name
! Emergency stop.
l.52 \input luatextra-latex.tex
*** (job aborted, file error in nonstop mode)
J'ai l'impression qu'il manque un fichier non ?
Damien Bonis
Au fait en passant les fichiers .dtx à pdflatex, je n'obtiens jamais le
.sty (sauf pour luainputenc). Je suis obligé de compiler docstrip pour
les avoirs. C'est normal ?
Elie
> > J'ai l'impression qu'il manque un fichier non ?
Oui, il manque luatextra-latex.tex... qui est généré par luatextra.dtx
normalement... tu confirmes que tex luatextra.dtx ne le produit pas
(chez moi si, mais il y a peut-être une boulette quelque part) ?
> Au fait en passant les fichiers .dtx à pdflatex, je n'obtiens jamais le
> .sty (sauf pour luainputenc). Je suis obligé de compiler docstrip pour
> les avoirs. C'est normal ?
Oui, j'avoue que ce n'est pas forcément très cohérent... La commande
pour avoir les fichiers est soit tex soit pdftex suivant les hacks
qu'il y a dedans. Pour trouver la commande il suffit de regarder le
premier bloc de commentaire du fichier .dtx.
--
Elie
Damien Bonis
> On 23 avr, 23:47, Damien Bonis <damis@dantaboite> wrote:
>
>>> J'ai l'impression qu'il manque un fichier non ?
>
> Oui, il manque luatextra-latex.tex... qui est généré par luatextra.dtx
> normalement... tu confirmes que tex luatextra.dtx ne le produit pas
> (chez moi si, mais il y a peut-être une boulette quelque part) ?
c'est bon je l'ai.
>> Au fait en passant les fichiers .dtx à pdflatex, je n'obtiens jamais le
>> .sty (sauf pour luainputenc). Je suis obligé de compiler docstrip pour
>> les avoirs. C'est normal ?
>
> Oui, j'avoue que ce n'est pas forcément très cohérent... La commande
> pour avoir les fichiers est soit tex soit pdftex suivant les hacks
> qu'il y a dedans. Pour trouver la commande il suffit de regarder le
> premier bloc de commentaire du fichier .dtx.
> --
> Elie
Bon ce n'est pas trop grave.
J'ai compilé un document et j'obtiens ça :
! LuaTeX error
...egardes/mytexmf/tex/lualatex/luatextra/luatextra.lua:219: att
empt to call field 'find_module' (a nil value)
stack traceback:
...egardes/mytexmf/tex/lualatex/luatextra/luatextra.lua:219: in
function <...e
gardes/mytexmf/tex/lualatex/luatextra/luatextra.lua:218>
[C]: in function 'require'
<\directlua >:1: in main chunk.
l.213 }
The lua interpreter ran into a problem, so the
remainder of this lua chunk will be ignored.
Aussi, j'ai essayé de testé luamplib mais ça ne passe pas, c'est normal ?
Est-ce que tes packages font usage de pdftexcmds ?
Elie
> [...]The lua interpreter ran into a problem, so the
> remainder of this lua chunk will be ignored.
Ça ce n'est pas très normal... tu peux m'envoyer ton luatextra.lua
(mon adresse de réponse est bonne) stp ?
> Aussi, j'ai essayé de testé luamplib mais ça ne passe pas, c'est normal ?
Oui. Pour utiliser luamplib il faut avoir un fichier luatex-plain.mem
accessible par TeX généré par la version de LuaTeX avec laquelle tu
utilises mplib ! Pour créer un tel mem, il faut utiliser le script
luamplib-create-format.lua (de mémoire). Je ne me rappelle plus
exactement avec quelles options... Dans ces cas-là luamplib.pdf est
toujours d'un grand secours !
> Est-ce que tes packages font usage de pdftexcmds ?
Pas du tout. Je pourrais, mais j'avoue que je préfèrerais l'adapter à
luatextra... En fait c'est comme tous les packages d'Heiko (luacolor
aussi par exemple), ils ont été faits il y a fort longtemps et ce
serait mieux de les adapter à luatextra. Mais je pense que Heiko ne
voudra pas le faire tout de suite et qu'il attend de voir si luatextra
va être vraiment utilisé ou pas... seul l'avenir nous le dira...
J'avoue que je crois aussi qu'il n'aimerais pas trop dépendre d'un
truc qu'il ne contrôle pas, ce qui peut se comprendre. C'est le gros
problème de luatextra : ce n'est pas intégré à LaTeX, donc des
systèmes concurrents peuvent être développés (luatextra est déjà plus
ou moins un fork très amélioré du luatex d'Heiko), du coup ce n'est
pas 100% fiable, contrairement à quelquechose qui serait intégré dans
le format directement. Enfin j'espère qu'avec un peu de pub (c'est
prévu) luatextra sera un minimum adopté...
--
Elie
Damien Bonis
>> Aussi, j'ai essayé de testé luamplib mais ça ne passe pas, c'est normal ?
>
> Oui. Pour utiliser luamplib il faut avoir un fichier luatex-plain.mem
> accessible par TeX généré par la version de LuaTeX avec laquelle tu
> utilises mplib ! Pour créer un tel mem, il faut utiliser le script
> luamplib-create-format.lua (de mémoire). Je ne me rappelle plus
> exactement avec quelles options... Dans ces cas-là luamplib.pdf est
> toujours d'un grand secours !
J'ai généré le luatex-plain.mem en faisant "texlua
luamplib-createmem.lua". J'ai généré le luatex-latex.mem en suivant la
doc mais j'obtiens :
! Module luamplib error: Mem file unloadable. Maybe generated with a
different
version of mplib ?
Pourtant mon texlua et mon luatex sont tous les deux en 0.40.
Peut-être que mes fichiers ne sont pas au bon endroit pour être
accessibles par tex (c'est ce qui est demandé dans la doc)
De plus, je n'ai pas généré le luatex-mpfun.mem
>> Est-ce que tes packages font usage de pdftexcmds ?
Je dis ça simplement car à la suite du message d'erreur dans mon
précédent message, il y avait :
\pdftexcmds@toks=\toks22
Elie
> J'ai généré le luatex-plain.mem en faisant "texlua
> luamplib-createmem.lua".
Jusque-là tout va bien.
> J'ai généré le luatex-latex.mem en suivant la
> doc
Attention, ça n'a pas vraiment de sens... luatex-plain c'est pour le
format plain de metapost, pas de TeX. L'autre format c'est mpfun, pas
LaTeX donc.
> mais j'obtiens :
>
> ! Module luamplib error: Mem file unloadable. Maybe generated with a
> different
> version of mplib ?
>
> Pourtant mon texlua et mon luatex sont tous les deux en 0.40.
Ce n'est pas normal ça par contre...
> Peut-être que mes fichiers ne sont pas au bon endroit pour être
> accessibles par tex (c'est ce qui est demandé dans la doc)
Si luatex-plain.mem est dans le répertoire courant, ça devrait marcher
pourtant... tu peux m'envoyer un tgz avec ton luatex-plain.mem, ton
luamplib.lua et ton luamplib.sty stp?
> De plus, je n'ai pas généré le luatex-mpfun.mem
Ce n'est pas grave, ça devrait marcher quand même.
> Je dis ça simplement car à la suite du message d'erreur dans mon
> précédent message, il y avait :
>
> \pdftexcmds@toks=\toks22
Étrange, ça ne vient pas de luatextra en tous cas.
--
Elie
Damien Bonis
> On 24 avr, 23:35, Damien Bonis <damis@dantaboite> wrote:
>
>> J'ai généré le luatex-plain.mem en faisant "texlua
>> luamplib-createmem.lua".
>
> Jusque-là tout va bien.
>
>> J'ai généré le luatex-latex.mem en suivant la
>> doc
>
> Attention, ça n'a pas vraiment de sens... luatex-plain c'est pour le
> format plain de metapost, pas de TeX. L'autre format c'est mpfun, pas
> LaTeX donc.
ok, j'ai essayé de générer luatex-mpfun.mem en suivant la doc mais rien.
>> mais j'obtiens :
>>
>> ! Module luamplib error: Mem file unloadable. Maybe generated with a
>> different
>> version of mplib ?
>>
>> Pourtant mon texlua et mon luatex sont tous les deux en 0.40.
>
> Ce n'est pas normal ça par contre...
Euh mea culpa : j'ai oublié de dire une chose importante : c'est le
message d'erreur que j'obtiens quand je compile un document latex avec
pdflualatex qui fait usage de luamplib. Ce n'est pas un message d'erreur
que j'obtiens en faisant texlua luamplib-createmem.lua (en remplaçant
plain par latex à la fin pour créer luatex-latex.mem que je n'obtenais
de toutes façons pas). Hier soir j'étais fatigué... fausse alerte.
>> Peut-être que mes fichiers ne sont pas au bon endroit pour être
>> accessibles par tex (c'est ce qui est demandé dans la doc)
>
> Si luatex-plain.mem est dans le répertoire courant, ça devrait marcher
> pourtant... tu peux m'envoyer un tgz avec ton luatex-plain.mem, ton
> luamplib.lua et ton luamplib.sty stp?
C'est bon j'ai refait les opérations et la compilation se termine
normalement (ouf). Par contre, je n'ai pas l'image metapost intégrée
dans mon pdf.
>> De plus, je n'ai pas généré le luatex-mpfun.mem
>
> Ce n'est pas grave, ça devrait marcher quand même.
oui et de toutes façons je n'y arrive toujours pas.
>> Je dis ça simplement car à la suite du message d'erreur dans mon
>> précédent message, il y avait :
>>
>> \pdftexcmds@toks=\toks22
>
> Étrange, ça ne vient pas de luatextra en tous cas.
Bon, pdftexcmds est bien chargé et ça ne vient pas de tes packages mais
c'est l'un des miens qui le charge et je ne sais pas lequel ni pourquoi
(au début je l'ai vu apparaître en compilant avec pdflualatex + tous mes
packages puis il apparaissait même en compilant avec pdflatex,
c'est-à-dire sans que j'utilise tes packages).
Quand je fais un \listfiles, que signifient les (HO), (HH), (RS), ... :
(...)
fancyhdr.sty
hyperref.sty 2009/04/04 v6.78q Hypertext links for LaTeX
hycolor.sty 2008/09/08 v1.4 Code for color options of
hyperref/bookmark (HO
)
xcolor-patch.sty 2008/09/08 xcolor patch
pd1enc.def 2009/04/04 v6.78q Hyperref: PDFDocEncoding definition (HO)
etexcmds.sty 2007/12/12 v1.2 Prefix for e-TeX command names (HO)
hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive
kvoptions.sty 2009/04/10 v3.1 Keyval support for LaTeX options (HO)
url.sty 2006/04/12 ver 3.3 Verb mode for urls, etc.
bitset.sty 2007/09/28 v1.0 Data type bit set (HO)
intcalc.sty 2007/09/27 v1.1 Expandable integer calculations (HO)
bigintcalc.sty 2007/11/11 v1.1 Expandable big integer calculations (HO)
pdftexcmds.sty 2009/04/10 v0.4 LuaTeX support for pdfTeX utility
functions (
HO)
(...)
mpg
> Quand je fais un \listfiles, que signifient les (HO), (HH), (RS), ... :
>
Souvent, les auteurs mettent leurs initiales après la description du
package. Par exemple, HO c'est le très prolifique Heiko Oberdiek.
Damien Bonis
> Damien Bonis scripsit:
>
>> Quand je fais un \listfiles, que signifient les (HO), (HH), (RS), ... :
>>
> Souvent, les auteurs mettent leurs initiales après la description du
> package. Par exemple, HO c'est le très prolifique Heiko Oberdiek.
tanx
Elie
> C'est bon j'ai refait les opérations et la compilation se termine
> normalement (ouf). Par contre, je n'ai pas l'image metapost intégrée
> dans mon pdf.
Ce n'est pas normal, tu peux m'envoyer un .tgz avec ton .mem, ton
luamplib.sty, ton luamplib.lua, et un ECM que tu essayes de compiler
stp ?
--
Elie
Elie
> > [...]The lua interpreter ran into a problem, so the
> > remainder of this lua chunk will be ignored.
>
> Ça ce n'est pas très normal... tu peux m'envoyer ton luatextra.lua
> (mon adresse de réponse est bonne) stp ?
C'était un bug dans luatextra, je l'ai corrigé dans le dépôt github,
tu peux réessayer stp ?
--
Elie
Damien Bonis
Ok, j'ai essayé : c'est bon, ma figure metapost passer maintenant, c'est
cool !
Damien Bonis
-j'ai compilé un de mes documents qui ne compilait plus ces derniers
temps et qui fonctionne à nouveau,
-j'ai compilé un autre document et là il y a un problème : "le nom du
fichier".aux s'affiche plusieurs fois dans l'en-tête de mon document pdf
(mais le reste du pdf est bon cependant). Dans le log, il me dit qu'il
ne trouve pas \begin{document}. Je vais tenter de trouver d'où vient le
problème et faire un ECM mais là je n'ai pas le temps. J'essaierai
demain, à moins que tu n'ai trouvé la solution d'ici là.
Bonne soirée.
Damien
Elie
> Ok, j'ai essayé : c'est bon, ma figure metapost passe maintenant, c'est
> cool !
C'est bizarre, normalement ce n'est pas du tout corrélé ! Tu peux
m'envoyer un fichier qui ne marchait pas avant qui marche maintenant
stp ? Il y a un truc que je ne comprend pas...
> -j'ai compilé un autre document et là il y a un problème : "le nom du
> fichier".aux s'affiche plusieurs fois dans l'en-tête de mon document pdf
> (mais le reste du pdf est bon cependant). Dans le log, il me dit qu'il
> ne trouve pas \begin{document}. Je vais tenter de trouver d'où vient le
> problème et faire un ECM mais là je n'ai pas le temps. J'essaierai
> demain
Voilà qui est étrange... j'attend ton ECM !
> à moins que tu n'ai trouvé la solution d'ici là.
C'est bien la première fois que j'entends parler d'un tel bug...
--
Elie
Damien Bonis
> On 26 avr, 21:04, Damien Bonis <damis@dantaboite> wrote:
>
>> cool !
>
> C'est bizarre, normalement ce n'est pas du tout corr�l� ! Tu peux
> m'envoyer un fichier qui ne marchait pas avant qui marche maintenant
> stp ? Il y a un truc que je ne comprend pas...
J'ai �cras� ce fichier en faisant des tests avec un autre code metapost.
Comme ce n'�tait pas un code perso (je l'ai piqu� un peu au hasard sur
melusine/syracuse), j'aurais du mal � le retrouver.
>> -j'ai compil� un autre document et l� il y a un probl�me : "le nom du
>> fichier".aux s'affiche plusieurs fois dans l'en-t�te de mon document pdf
>> (mais le reste du pdf est bon cependant). Dans le log, il me dit qu'il
>> ne trouve pas \begin{document}. Je vais tenter de trouver d'o� vient le
>> probl�me et faire un ECM mais l� je n'ai pas le temps. J'essaierai
>> demain
>
> Voil� qui est �trange... j'attend ton ECM !
>
>> � moins que tu n'ai trouv� la solution d'ici l�.
>
> C'est bien la premi�re fois que j'entends parler d'un tel bug...
Voil� j'ai trouv�, cela ne vient pas de tes packages mais de lualatex,
je m'explique :
Voici le contenu du fichier a.tex :
\documentclass{article}
\begin{document}
Hello world
\end{document}
Quand je compile ce fichier avec lualatex, impec. Si je le renomme
en a b.tex (a "espace" b.tex), �a ne va plus. Pourtant, si je le compile
avec latex ou pdflatex �a passe.
Pourtant, si je compile le fichier a b.tex contenant Hello world\bye
avec luatex ou pdfluatex, �a passe nickel.
Alors on dira qu'il faut se m�fier des noms de fichiers contenant des
espaces mais jusque l� je n'ai jamais rencontr� de probl�me avec
pdflatex et �a marche aussi luatex mais �a marche mal avec
lualatex/pdflualatex. C'est un peu dommage car c'est assez confortable
de pouvoir mettre des esapce comme on veut. Maintenant, c'est sous
windows, est-ce que sous nux ou mac on observe des commortements
diff�rents ?
Elie
> Maintenant, c'est sous
> windows, est-ce que sous nux ou mac on observe des commortements
J'ai la même chose sous linux, c'est assez inexpliquable... Je n'ai
malheureusement probablement pas le temps de regarder ça plus en
détail, mais si quelqu'un peut confirmer ça sur un luatex récent ce
serait bien. La derniere version svn par exemple, ou le tag 0.40 qui
sera sans doute intégré à TeXLive. Je pense qu'un bug comme ça sera
corrigé...
--
Elie
Damien Bonis
> On 27 avr, 19:52, Damien Bonis <damis@dantaboite> wrote:
>> Maintenant, c'est sous
>> windows, est-ce que sous nux ou mac on observe des commortements
>
> J'ai la m�me chose sous linux, c'est assez inexpliquable... Je n'ai
> malheureusement probablement pas le temps de regarder �a plus en
> d�tail, mais si quelqu'un peut confirmer �a sur un luatex r�cent ce
> serait bien. La derniere version svn par exemple, ou le tag 0.40 qui
> corrig�...
> --
> Elie
Encore faut-il faire remonter sur dev-luatex d�s que quelqu'un aura
confirm�. Mes tests sont faits avec la 0.40. Manu donnera sans doute son
point de vue.
Sinon, merci encore Elie et � tr�s bient�t.
Damien
mpg
> Quand je compile ce fichier avec lualatex, impec. Si je le renomme
> en a b.tex (a "espace" b.tex), �a ne va plus. Pourtant, si je le compile
> avec latex ou pdflatex �a passe.
>
> Pourtant, si je compile le fichier a b.tex contenant Hello world\bye
> avec luatex ou pdfluatex, �a passe nickel.
>
La premi�re diff�rence qui me passe par la t�te entre latex et plain est
l'utilisation d'un fichier aux.
/me va tester...
OK, l'exemple minimal est le suivant (en Plain ou LaTeX).
\edef\x{\jobname}
\show\x
Avec pdftex, on a ��"a b"��, avec luatex � a b��. Du coup coup quand LaTeX fait
un \@@input\jobname, c'est le drame.
Comme tu le dis deux messages plus bas, je pense que c'est un bug que les
d�veloppeurs voudront fixer avant la version de TeX Live 2009 (ce n'est pas par
hasard que dans la 2008 la version est 0.25.4 et pas 0.25.0, hein).
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
mpg
> un \@@input\jobname, c'est le drame.
>
Pouf-pouf, lire \@@input\jobname.aux, bien s�r.