Externalisation d'Asymptote
Christophe Jorssen
Je regarde un peu asymptote en ce moment. D'après ce que j'ai compris, si
on veut intégrer du code asy directement dans le document LaTeX, on est
obligé, avec l'environnement asy, d'avoir recours à 3 compilations, soit
dans l'ordre
(pdf)latex
asy
(pdf)latex
On peut modifier légèrement l'environnement asy pour que la compilation
asy se fasse à la volée en utilisant un \write18. Voilà par exemple ce
que j'ai trouvé sur le forum mathematex (bon, à adapter pour ne pas que
l'utilisateur voit verbatimwrite, mais l'idée est là).
%%%%%%%%%%%%%
\documentclass[12pt]{article}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[french]{babel}
\usepackage{moreverb}
\usepackage{graphics}
\newcommand{\ExecuteAsymptote}[1]{
\immediate\write18{asy #1}
}
\begin{verbatimwrite}{figI.asy}
unitsize(1inch);
path T,ct,tt;
T=(0,0)--(1,0)--(1/2,sqrt(3)/2)--cycle;
ct=(0,0)..(1,0)--(1/2,sqrt(3)/2)..cycle;
tt=shift(sqrt(3)/6*dir(30))*(scale(1/2)*T);
draw(T);
draw(shift(2*right)*ct);
fill(reverse(shift(4*right)*tt)^^(shift(4*right)*T),blue);
\end{verbatimwrite}
\begin{document}
\ExecuteAsymptote{figI.asy}
\begin{center}
\begin{figure}[h]
\includegraphics{figI.eps}
\caption{Mes premiers pas avec asymptote }
\end{figure}
\end{center}
\end{document}
%%%%%%%%%%%%%%%%%%
Mais, le problème est que la compilation se lance même si la figure asy
n'a pas été modifiée, ce qui peut être pénible (enfin surtout long) s'il
y en a beaucoup. D'où ma question : existe-t-il quelque chose comme la
bibliothèque d'externalisation de tikz ou d'utiliser la même procédure
que tikz avec gnuplot ?
Sinon, est-ce compliqué (je n'y connais rien en gestion de fichier par
TeX) de faire quelque chose de simple satisfaisant ce cahier des charges.
J'avoue avoir regardé le code de tikzexternalize et ça fait très très
très peur...
Merci d'avance
--
Christophe
Elie
<christophe.jors...@libre.fr.invalid> wrote:
>
> Mais, le problème est que la compilation se lance même si la figure asy
> n'a pas été modifiée, ce qui peut être pénible (enfin surtout long) s'il
> y en a beaucoup.
En faisant un tout petit script qui détecte si le fichier a besoin
d'être recompilé ou pas et le recompile (ou pas) en conséquence et en
appelant ce script au lieu d'asy directement ça résoud le problème.
Sinon dans gregorio je fais ça directement en Lua, ça évite d'avoir à
écrire un script externe.
--
Elie
Christophe Jorssen
Le Fri, 06 Nov 2009 04:59:05 -0800, Elie a écrit/wrote :
> On 6 nov, 13:29, Christophe Jorssen
> <christophe.jors...@libre.fr.invalid> wrote:
>>
>> Mais, le problème est que la compilation se lance même si la figure asy
>> n'a pas été modifiée, ce qui peut être pénible (enfin surtout long)
>> s'il y en a beaucoup.
>
> En faisant un tout petit script qui détecte si le fichier a besoin
> d'être recompilé ou pas et le recompile (ou pas) en conséquence et en
> appelant ce script au lieu d'asy directement ça résoud le problème.
Ok. Mais comment savoir ça ?
> Sinon dans gregorio je fais ça directement en Lua, ça évite d'avoir à
> écrire un script externe.
En effet. Ça sera vraiment bien quand luatex sera le standard !
--
Christophe
Thomas vO
� (at) 06 Nov 2009 13:29:54 GMT,
Christophe Jorssen <christoph...@libre.fr.invalid> nous disait (told us):
>> En faisant un tout petit script qui d�tecte si le fichier a besoin
>> d'�tre recompil� ou pas et le recompile (ou pas) en cons�quence et
>> en appelant ce script au lieu d'asy directement �a r�soud le
>> probl�me.
>
> Ok. Mais comment savoir �a ?
si la date de la sortie est inf�rieure � la date de l'entr�e, faut
recompiler...
ou tout simplement, un Makefile...
--
\newcommand*{\logo}{\textcolor{orng}{orange}}
%NB c'est juste un ECM, rien � voir avec les voleurs du t�l�phone
-+- draxar in fr.comp.text.tex -+-
Dominique MICOLLET
> Le Fri, 06 Nov 2009 04:59:05 -0800, Elie a ￜcrit/wroteￜ:
>> On 6 nov, 13:29, Christophe Jorssen <christophe.jors...@libre.fr.invalid>
wrote:
>>> n'a pas ￜtￜ modifiￜe, ce qui peut ￜtre pￜnible (enfin surtout long)
>>> s'il y en a beaucoup.
>>
>> d'ￜtre recompilￜ ou pas et le recompile (ou pas) en consￜquence et en
>> appelant ce script au lieu d'asy directement ï¿œa rï¿œsoud le problï¿œme.
>
> Ok. Mais comment savoir ï¿œa ?
Sous unix, il y a make qui est fait pour ï¿œa.
Sous Windows, il surement quelque chose d'ï¿œquivalent mais je ne connais pas.
--
Dominique MICOLLET
Adresse email : enlever deux francs
Elie
<christophe.jors...@libre.fr.invalid> wrote:
>
> Ok. Mais comment savoir ça ?
le filesystem se rappelle de la date de la dernière modification d'un
fichier. On peut y accéder avec quasiment tous les langages, en lua
c'est par exemple
lfs.attributes(monfichier).modification
en faisant un petit if sur les dates de modification, on en déduit
s'il faut recompiler ou pas.
--
Elie
Christophe Jorssen
> À (at) 06 Nov 2009 13:29:54 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> nous disait
> (told us):
>>> En faisant un tout petit script qui détecte si le fichier a besoin
>>> d'être recompilé ou pas et le recompile (ou pas) en conséquence et en
>>> appelant ce script au lieu d'asy directement ça résoud le problème.
>>
>> Ok. Mais comment savoir ça ?
>
> si la date de la sortie est inférieure à la date de l'entrée, faut
> recompiler...
Oui, en effet... Merci.
--
Christophe
Manuel Pégourié-Gonnard
> le filesystem se rappelle de la date de la derni�re modification d'un
> fichier. On peut y acc�der avec quasiment tous les langages, en lua
> c'est par exemple
>
> lfs.attributes(monfichier).modification
>
En fait, m�me pas besoin de LuaTeX pour �a. pdfTeX fournit
\pdffilemoddate
qui marche tr�s bien (c'est utilis� par exemple dans epstopdf.sty). Dans
la s�rie � savoir si un fichier a �t� modifi� � \pdfmdfivesum peut sans
doute �tre utile aussi. (On a souvent tendance � sous-estimer les
possibilit�s de pdfTeX.)
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Christophe Jorssen
wrote
:
> En fait, même pas besoin de LuaTeX pour ça. pdfTeX fournit
>
> \pdffilemoddate
>
> qui marche très bien (c'est utilisé par exemple dans epstopdf.sty). Dans
> la série « savoir si un fichier a été modifié » \pdfmdfivesum peut sans
> doute être utile aussi. (On a souvent tendance à sous-estimer les
> possibilités de pdfTeX.)
Merci, je ne connaissais pas et j'avoue être plus à l'aise en restant
dans le monde de TeX.
--
Christophe
Christophe Jorssen
Voilà un premier essai en utilisant mdfive. Ce n'est certainement pas ce
qu'il y a de mieux ni de plus optimisé, mais bon...
Mais il y a un truc que je ne comprends pas : deux fichiers identiques
<nom>.asy et <nom>.asy.tmp n'ont pas le même md5. C'est pas normal ça ?
Merci d'avance.
\documentclass{article}
\usepackage{moreverb}
\usepackage{graphicx}
\makeatletter
\def\asymptote@fig@count{\z@}
\newenvironment{asymptotealt}{}{}
\def\asymptotealt{%
\@tempcnta=\asymptote@fig@count\relax
\advance\@tempcnta\@ne
\xdef\asymptote@fig@count{\the\@tempcnta}%
\edef\asymptote@fig@filename{\jobname-asy-fig-\asymptote@fig@count.asy}%
\IfFileExists{\jobname-asy-fig-\asymptote@fig@count.asy}%
{% Asy file already exists: need to see if a newer version exists
\edef\asymptote@fig@filename@tmp{%
\jobname-asy-fig-\asymptote@fig@count.asy.tmp}%
\def\asymptote@next{\verbatimwrite{\asymptote@fig@filename@tmp}}}
{% Asy file does not exist: no problem
\let\asymptote@fig@filename@tmp\relax
\def\asymptote@next{\verbatimwrite{\asymptote@fig@filename}}}%
\asymptote@next}
\def\endasymptotealt{%
\endverbatimwrite%
\ifx\asymptote@fig@filename@tmp\relax
\else
\edef\asymptote@fig@filename@mdfive{%
\pdfmdfivesum{\asymptote@fig@filename}}%
\edef\asymptote@fig@filename@tmp@mdfive{%
\pdfmdfivesum{\asymptote@fig@filename@tmp}}%
\asymptote@fig@filename@mdfive -- \asymptote@fig@filename@tmp@mdfive
\fi}
\begin{document}
\begin{asymptotealt}
unitsize(1inch);
path T,ct,tt;
T=(0,0)--(1,0)--(1/2,sqrt(3)/2)--cycle;
ct=(0,0)..(1,0)--(1/2,sqrt(3)/2)..cycle;
tt=shift(sqrt(3)/6*dir(30))*(scale(1/2)*T);
draw(T);
draw(shift(2*right)*ct);
fill(reverse(shift(4*right)*tt)^^(shift(4*right)*T),blue);
\end{asymptotealt}
\end{document}
--
Christophe
Paul Gaborit
� (at) Fri, 06 Nov 2009 14:35:27 +0100,
Thomas vO <vanoud...@rf.esuoluot-vinu.invalid> �crivait (wrote):
> � (at) 06 Nov 2009 13:29:54 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> nous disait (told us):
>>> En faisant un tout petit script qui d�tecte si le fichier a besoin
>>> d'�tre recompil� ou pas et le recompile (ou pas) en cons�quence et
>>> en appelant ce script au lieu d'asy directement �a r�soud le
>>> probl�me.
>>
>> Ok. Mais comment savoir �a ?
>
> si la date de la sortie est inf�rieure � la date de l'entr�e, faut
> recompiler...
>
> ou tout simplement, un Makefile...
Sauf que comme le fichier asy provient du document LaTeX, il n'y a
plus de date valable : on a pu changer un tout petit truc dans LaTeX
sans toucher � la partie asy et pourtant le fichier asy g�n�r� sera
plus r�cent que tout autre fichier...
Le meilleur moyen de faire cela, c'est � chaque compilation asy
demand�e, de comparer le fichier fourni � une copie d'une version
pr�alable (si elle existe). Si il n'y a pas de version pr�alable ou si
la version pr�alable est diff�rente du fichier actuel, on compile et
le fichier a compiler devient la nouvelle version pr�alable (pour les
compilations suivantes).
Cette m�thode n'est pas sp�cifique � asy. Il faudrait utiliser une
technique similaire pour automatiser les recompilations avec TikZ et
son mode externalis� (dans la version CVS actuelle, on d�cide � la
main ce qui doit �tre recompil� ou non).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
� (at) 06 Nov 2009 15:04:03 GMT,
Christophe Jorssen <christoph...@libre.fr.invalid> �crivait (wrote):
> Voil� un premier essai en utilisant mdfive. Ce n'est certainement pas ce
> qu'il y a de mieux ni de plus optimis�, mais bon...
>
> Mais il y a un truc que je ne comprends pas : deux fichiers identiques
> <nom>.asy et <nom>.asy.tmp n'ont pas le m�me md5. C'est pas normal �a ?
Tr�s joli et super int�ressant (pas que asy mais pour plein d'autres
choses).
Pour l'appel � \pdfmdfive qui donne un r�sultat bizarre, c'est
normal. L�, il calcule le somme md5 des cha�nes constituant le nom des
deux fichiers. Il faut utiliser :
\pdfmdfivesum file {\asymptote@fig@filename}}
et
\pdfmdfivesum file {\asymptote@fig@filename@tmp}}%
et l� �a marche ! ;-)
Ne reste plus qu'� compl�ter pour renommer le fichier temporaire comme
il faut en cas de diff�rence...
Christophe Jorssen
> À (at) 06 Nov 2009 15:04:03 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> écrivait
> (wrote):
>
>> Voilà un premier essai en utilisant mdfive. Ce n'est certainement pas
>> ce qu'il y a de mieux ni de plus optimisé, mais bon...
>>
>> Mais il y a un truc que je ne comprends pas : deux fichiers identiques
>> <nom>.asy et <nom>.asy.tmp n'ont pas le même md5. C'est pas normal ça ?
>
> Très joli et super intéressant (pas que asy mais pour plein d'autres
> choses).
>
Tu penses à quoi d'autre ?
> Pour l'appel à \pdfmdfive qui donne un résultat bizarre, c'est normal.
> Là, il calcule le somme md5 des chaînes constituant le nom des deux
> fichiers. Il faut utiliser :
>
> \pdfmdfivesum file {\asymptote@fig@filename}}
Ok. Le fait que dans la doc de pdftex le "file" n'était pas en tt m'a
enduit d'erreur. Merci.
> Ne reste plus qu'à compléter pour renommer le fichier temporaire comme
> il faut en cas de différence...
Je m'y attèle.
--
Christophe
Christophe Jorssen
>
> Cette méthode n'est pas spécifique à asy. Il faudrait utiliser une
> technique similaire pour automatiser les recompilations avec TikZ et son
> qui doit être recompilé ou non).
C'est vrai ça. C'est manuel. Tu vois, je trouve cette bibliothèque
tellement bien que j'en avais oublié qu'elle ne faisait pas ce que je
cherchais à faire :-)
En revanche, ce qu'elle fait, c'est que les fichiers externalisés se
retrouvent avec toutes les macros du document (disons dans le préambule),
des packages et de la classe d'origine et c'est certainement ça qui fait
que le code est monstrueux ? L'adapter à cette extraction d'asymptote
pour que tout se retrouve à l'intérieur d'un environnement asydef du type
(extrait de la doc)
\begin{asydef}
usepackage("bm");
texpreamble("\def\V#1{\bm{#1}}");
\end{asydef}
me semble ambitieux. Enfin, peut-être me trompe-je ?
--
Christophe
Paul Gaborit
� (at) 06 Nov 2009 17:04:59 GMT,
Christophe Jorssen <christoph...@libre.fr.invalid> �crivait (wrote):
>
En premier lieu � TikZ qui dans sa nouvelle version permet
d'externaliser les figures pour �viter de les recompiler � chaque
fois.
Puis, j'ai d'autres applications plus personnelles en t�te. Par
exemple un support de cours o� je g�n�re des fichiers C au vol depuis
le document LaTeX et dont je pourrais d�clencher la compilation
uniquement s'ils ont �t� modifi�es...
On pourrait m�me imaginer une utilisation dans beamer lorsqu'on veut
g�rer une version pr�sentation combin�e � une version article qui
int�gre des slides de la version pr�sentation.
Plein de trucs, quoi !
>> Ne reste plus qu'� compl�ter pour renommer le fichier temporaire comme
>> il faut en cas de diff�rence...
>
> Je m'y att�le.
Super car �a je ne sais pas faire et j'ai la flemme de chercher ! ;-)
Paul Gaborit
� (at) 06 Nov 2009 17:10:38 GMT,
Christophe Jorssen <christoph...@libre.fr.invalid> �crivait (wrote):
> Le Fri, 06 Nov 2009 16:53:18 +0100, Paul Gaborit a �crit/wrote�:
>>
>> Cette m�thode n'est pas sp�cifique � asy. Il faudrait utiliser une
>> technique similaire pour automatiser les recompilations avec TikZ et son
>> mode externalis� (dans la version CVS actuelle, on d�cide � la main ce
>> qui doit �tre recompil� ou non).
>
> C'est vrai �a. C'est manuel. Tu vois, je trouve cette biblioth�que
> tellement bien que j'en avais oubli� qu'elle ne faisait pas ce que je
> cherchais � faire :-)
Mais avec le code que tu as produit en utilisant \pdfmdfive on n'est
pas loin d'une solution qui te et me conviendrait.
> En revanche, ce qu'elle fait, c'est que les fichiers externalis�s se
> retrouvent avec toutes les macros du document (disons dans le pr�ambule),
> des packages et de la classe d'origine et c'est certainement �a qui fait
> que le code est monstrueux ? L'adapter � cette extraction d'asymptote
> pour que tout se retrouve � l'int�rieur d'un environnement asydef du type
> (extrait de la doc)
>
> \begin{asydef}
> usepackage("bm");
> texpreamble("\def\V#1{\bm{#1}}");
> \end{asydef}
>
> me semble ambitieux. Enfin, peut-�tre me trompe-je ?
Si la figure asymptote est simple et ne repose pas sur du contenu
LaTeX, �a ne sert � rien.
Dans le cas contraire, je pense qu'il va falloir �tre ambitieux ou se
passer d'asymptote ou continuer � faire manuellement.
Moi, pour l'instant, j'ai choisi. Mais comme on est vendredi, je
pr�f�re me taire. ;-)
Christophe Jorssen
> À (at) 06 Nov 2009 17:10:38 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> écrivait
> (wrote):
>> C'est vrai ça. C'est manuel. Tu vois, je trouve cette bibliothèque
>> tellement bien que j'en avais oublié qu'elle ne faisait pas ce que je
>> cherchais à faire :-)
>
> Mais avec le code que tu as produit en utilisant \pdfmdfive on n'est pas
> loin d'une solution qui te et me conviendrait.
Oui, d'ailleurs, je vais en parler à Christian Feuersänger.
>> En revanche, ce qu'elle fait, c'est que les fichiers externalisés se
>> retrouvent avec toutes les macros du document (disons dans le
>> préambule), des packages et de la classe d'origine et c'est
>> certainement ça qui fait que le code est monstrueux ? L'adapter à cette
>> extraction d'asymptote pour que tout se retrouve à l'intérieur d'un
>> environnement asydef du type (extrait de la doc)
>>
>> \begin{asydef}
>> usepackage("bm");
>> texpreamble("\def\V#1{\bm{#1}}");
>> \end{asydef}
>>
>> me semble ambitieux. Enfin, peut-être me trompe-je ?
>
> Si la figure asymptote est simple et ne repose pas sur du contenu LaTeX,
> ça ne sert à rien.
>
> Dans le cas contraire, je pense qu'il va falloir être ambitieux ou se
> passer d'asymptote ou continuer à faire manuellement.
Ambitieux, en général oui, mais là bof (manque cruel de temps). Se passer
d'asymptote d'accord, mais il faudrait que tikz fasse bien de la 3D.
Faire manuellement : beurk.
>
> Moi, pour l'instant, j'ai choisi. Mais comme on est vendredi, je préfère
> me taire. ;-)
Bon allez, on est vendredi ! Que les choses soient claires. Je fais du
asymptote car j'ai essayé de faire de la 3D avec tikz, mais c'est quand
même pas encore ça. Je n'ai pas le temps d'approfondir, mais je suis
certain qu'il est possible de rendre tikz aussi puissant dans ce domaine
que dans le reste. Yapluka :-)
--
Christophe
Manuel Pégourié-Gonnard
> Tr�s joli et super int�ressant (pas que asy mais pour plein d'autres
> choses).
>
Je trouve aussi. �a vaudrait le coup d'avoir un package g�n�rique pour
faire �a. Je pense aussi � tout un tas d'applications personnelles.
> Pour l'appel � \pdfmdfive qui donne un r�sultat bizarre, c'est
> normal. L�, il calcule le somme md5 des cha�nes constituant le nom des
> deux fichiers. Il faut utiliser :
>
> \pdfmdfivesum file {\asymptote@fig@filename}}
>
Marrant, tout � l'heure j'avais lu trop en diagonale la doc et j'avais
cru comprendre qu'on ne pouvait calculer que des md5 de fichiers, pas de
cha�nes. Visiblement si. Cool :-)
> Ne reste plus qu'� compl�ter pour renommer le fichier temporaire comme
> il faut en cas de diff�rence...
>
Il me semble que c'est impossible de renommer le fichier si \write18
n'est pas activ�. Mais l�, vu qu'on veut lancer asy, j'imagine qu'on
peut supposer qu'il l'est.
Si on veut un truc qui marche aussi sous windows, on peut peut-�tre se
tourner vers ifplatform.sty de Will Robertson pour d�tecter la
plateforme courante (jamais test� personnellement).
Christophe Jorssen
> Je m'y attèle.
Voilà le résultat. S'il y a un volontaire pour optimiser, mettre des
options, rendre générique (au sens pas seulement externalisation
d'asymptote) et multiplateforme (avec ifplatform) et/ou packager, feel
free (je suis pour ma part malheureusement pris par le temps).
Bonne soirée
\documentclass{article}
\usepackage{moreverb}
\usepackage{graphicx}
\usepackage{ifpdf}
\makeatletter
\def\asy@fig@count{\z@}
\newenvironment{asyalt}{}{}
\newif\ifasy@mdfive
\let\asy@end@first\relax
\let\asy@end@second\relax
\def\asy@compare@two@mdfive#1#2{%
\asy@compare@two@mdfive@i#1\asy@end@first\asy@nil#2\asy@end@second
\asy@nil}
\def\asy@compare@two@mdfive@i#1#2\asy@nil#3#4\asy@nil{%
\if#1#3
\ifx\relax#2
\def\asy@next{\asy@mdfivetrue}%
\else
\def\asy@next{\asy@compare@two@mdfive@i#2\asy@nil#4\asy@nil}%
\fi
\else
\def\asy@next{\asy@mdfivefalse}%
\fi
\asy@next}
\def\asy@compile{%
\ifpdf
\immediate\write18{asy -f pdf \asy@fig@filename}
\else
\immediate\write18{asy \asy@fig@filename}
\fi}
\def\asyalt{%
\@tempcnta=\asy@fig@count\relax
\advance\@tempcnta\@ne
\xdef\asy@fig@count{\the\@tempcnta}%
\edef\asy@fig@filename{\jobname-asy-fig-\asy@fig@count.asy}%
\IfFileExists{\jobname-asy-fig-\asy@fig@count.asy}%
{% Asy file already exists: need to see if a newer version exists
\edef\asy@fig@filename@tmp{%
\jobname-asy-fig-\asy@fig@count.asy.tmp}%
\def\asy@next{\verbatimwrite{\asy@fig@filename@tmp}}}
{% Asy file does not exist: no problem
\let\asy@fig@filename@tmp\relax
\def\asy@next{\verbatimwrite{\asy@fig@filename}}}%
\asy@next}
\def\endasyalt{%
\endverbatimwrite%
\ifx\asy@fig@filename@tmp\relax
\asy@compile
\else
\edef\asy@temp{%
\noexpand\asy@compare@two@mdfive{%
\pdfmdfivesum file{\asy@fig@filename}}{%
\pdfmdfivesum file{\asy@fig@filename@tmp}}}
\asy@temp%
\ifasy@mdfive
\immediate\write18{rm -f \asy@fig@filename@tmp}
\else
\immediate\write18{mv \asy@fig@filename@tmp\space\asy@fig@filename}
\asy@compile
\fi
\fi
\includegraphics{\jobname-asy-fig-\asy@fig@count}}
\begin{document}
\begin{asyalt}
unitsize(1inch);
path T,ct,tt;
T=(0,0)--(1,0)--(1/2,sqrt(3)/2)--cycle;
ct=(0,0)..(1,0)--(1/2,sqrt(3)/2)..cycle;
tt=shift(sqrt(3)/6*dir(30))*(scale(1/2)*T);
draw(T);
draw(shift(2*right)*ct);
fill(reverse(shift(4*right)*tt)^^(shift(4*right)*T),blue);
\end{asyalt}
\end{document}
--
Christophe
as
Christophe Jorssen <christoph...@libre.fr.invalid> a écrit :
Hello,
> Voilà le résultat. S'il y a un volontaire pour optimiser, mettre des
> options, rendre générique (au sens pas seulement externalisation
> d'asymptote) et multiplateforme (avec ifplatform) et/ou packager,
> feel free (je suis pour ma part malheureusement pris par le temps).
"Il suffit"©® de s'inspirer de asyfig.sty du même auteur pour finir le
boulot.
AS
Sébastien
> Cette m�thode n'est pas sp�cifique � asy. Il faudrait utiliser une
> technique similaire pour automatiser les recompilations avec TikZ et
> son mode externalis� (dans la version CVS actuelle, on d�cide � la
> main ce qui doit �tre recompil� ou non).
Paul, tu abordes un sujet qui m'int�resse et que je ne connais pas.
Qu'entends-tu par "son mode externalis�".
Merci
Sébastien
> En fait, m�me pas besoin de LuaTeX pour �a. pdfTeX fournit
>
> \pdffilemoddate
>
> qui marche tr�s bien (c'est utilis� par exemple dans epstopdf.sty). Dans
> la s�rie � savoir si un fichier a �t� modifi� � \pdfmdfivesum peut sans
> doute �tre utile aussi. (On a souvent tendance � sous-estimer les
> possibilit�s de pdfTeX.)
A propos de ces deux commandes \pdffilemoddate et \pdfmdfivesum, je
pense qu'on les retrouvera dans LuaTeX, mais sous le m�me nom (ma
question semble peut-�tre stupide) ?
Sébastien
Bonsoir Christophe,
Je pense à une chose. Imaginons que je crée un document latex qui
comporte 10 figures asymptote. Après compilation avec (pdf)latex de mon
fichier file.tex, j'obtiens le fichier file.asy qui contient le code
asymptote de mes 10 figures asymptote et que je compile avec asy. La
compilation avec asy me donne autant de fichiers images que de figures
asymptote (ici 10). Enfin, je recompile file.tex avec (pdf)latex pour
avoir le document final. Imaginons je ne modifie qu'une seule des 10
figures asymptote, est-ce que les 10 seront être recompilées (ce qui
peut être lourd) ?
Paul Gaborit
� (at) Sun, 08 Nov 2009 18:21:36 +0100,
S�bastien <s...@free.fr> �crivait (wrote):
C'est une fonctionnalit� qui va appara�tre dans tikz/pgf (c'est dans
d�j� la version CVS). Cela permet de compiler certaines figures
tikz/pgf s�par�ment du document principal pour �viter de les
recompiler tout le temps. En fait, lors de la compilation du document
principal, le code de chaque figure tikz/pgf est enregistr� dans un
document .tex externe et le r�sultat de la compilation du fichier
externe vient remplacer cette figure. Cela n�cessite �videmment
plusieurs compilations pour obtenir le r�sultat final. Par contre, par
la suite, on n'est pas oblig� de tout recompiler � chaque fois.
Mais le choix du moment de recompilation n'est pas automatique. C'est
automatisable via un makefile mais en comparant les fichiers non pas
via leur date mais plut�t via leur contenu.
Christophe Jorssen
>
> Je pense à une chose. Imaginons que je crée un document latex qui
> comporte 10 figures asymptote. Après compilation avec (pdf)latex de mon
> fichier file.tex, j'obtiens le fichier file.asy qui contient le code
> asymptote de mes 10 figures asymptote et que je compile avec asy. La
> compilation avec asy me donne autant de fichiers images que de figures
> asymptote (ici 10). Enfin, je recompile file.tex avec (pdf)latex pour
> avoir le document final. Imaginons je ne modifie qu'une seule des 10
> figures asymptote, est-ce que les 10 seront être recompilées (ce qui
> peut être lourd) ?
Avec le code que j'ai fait, je ne crois pas. En revanche, si on insère
une 11ème figure avant les 10 autres, tout devra être recompilé.
--
Christophe
Christophe Jorssen
>
> A propos de ces deux commandes \pdffilemoddate et \pdfmdfivesum, je
> pense qu'on les retrouvera dans LuaTeX, mais sous le même nom (ma
> question semble peut-être stupide) ?
On les trouvera dans LuaTeX, c'est sûr. En revanche, je ne sais pas si le
nom a été tranché. Je sais que pendant tout un temps ça a fait débat sur
la liste LuaTeX (garder le préfixe pdf ou en changer pour luatex ou lua).
Elie ? Manuel ?
--
Christophe
Paul Gaborit
� (at) 08 Nov 2009 22:42:19 GMT,
Christophe Jorssen <christoph...@libre.fr.invalid> �crivait (wrote):
> Avec le code que j'ai fait, je ne crois pas. En revanche, si on ins�re
> une 11�me figure avant les 10 autres, tout devra �tre recompil�.
Parce que le num�ro �volue et le nom de fichier aussi ? Pourquoi ne
pas demander � l'utilisateur de fournir un nom de r�f�rence � chacune
de ses figures, nom qui servira pour nommer les fichiers externes pour
�viter les recompilations inutiles ?
Sébastien
> � (at) 08 Nov 2009 22:42:19 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> �crivait (wrote):
>
>> Avec le code que j'ai fait, je ne crois pas. En revanche, si on ins�re
>> une 11�me figure avant les 10 autres, tout devra �tre recompil�.
>
> Parce que le num�ro �volue et le nom de fichier aussi ? Pourquoi ne
> pas demander � l'utilisateur de fournir un nom de r�f�rence � chacune
> de ses figures, nom qui servira pour nommer les fichiers externes pour
> �viter les recompilations inutiles ?
Tiens je pense � un truc : quand (pdf)latex compile un fichier contenant
des figures asymptote, il cr�e le fichier .asy contenant tout le code
asymptote. Mais quand est-ce qu'il cr�e ce fichier ? A la fin de la
compilation juste avant (ou juste apr�s) avoir cr�� le fichier dvi (ou
pdf) ou au fur et � mesure de la compilation d�s qu'il rencontre le
premier environnement asy ? Ensuite, quand (pdf)latex �crit-il dans le
fichier .asy ? L� encore, au fur et � mesure ou � la fin ?
Manuel Pégourié-Gonnard
> Le Sun, 08 Nov 2009 18:28:47 +0100, S�bastien a �crit/wrote�:
>
>>
>> A propos de ces deux commandes \pdffilemoddate et \pdfmdfivesum, je
>> pense qu'on les retrouvera dans LuaTeX, mais sous le m�me nom (ma
>> question semble peut-�tre stupide) ?
>
> On les trouvera dans LuaTeX, c'est s�r. En revanche, je ne sais pas si le
> nom a �t� tranch�. Je sais que pendant tout un temps �a a fait d�bat sur
> la liste LuaTeX (garder le pr�fixe pdf ou en changer pour luatex ou lua).
> Elie ? Manuel ?
>
C'est compliqu�. D�j�, LuaTeX reprend en principe toutes les primitives
pdfTeX, avec le m�me nom, mais il y a des exceptions :
- certaines primitives utilitaires ne sont pas reprises, il se trouve
que \pdffilemoddate et \pdfmdfivesum en font partie. La raison est
simple : on a tout �a en Lua, et c'est sans doute plus naturel.
- certaines primitives sont �galement fournies avec un nom plus simple
en plus du nom originel : \primitive est un alias de \pdfprimitive par
exemple.
Pour �a, voir la secton 9.3 du manuel LuaTeX (version 0.40.6).
Ensuite, il y a le fait que dans TeX Live, sous LaTeX, les primitives
sp�cifiques � LuaTeX sont pr�fix�es avec 'luatex', dans l'espoir de
limiter les conflits de noms. Ainsi, ce que le manuel d�crit comme
\scantextokens est en fait disponible en tant que \luatexscantextokens,
\luatexversion reste \luatexversion, \primitive devient \luatexprimitive
(et \pdfprimitive reste inchang�). Seule \directlua garde son nom
original.
Ph. Ivaldi
> Tiens je pense � un truc : quand (pdf)latex compile un fichier
> contenant des figures asymptote, il cr�e le fichier .asy contenant
> tout le code asymptote. Mais quand est-ce qu'il cr�e ce fichier ? A la
> fin de la compilation juste avant (ou juste apr�s) avoir cr�� le
> fichier dvi (ou pdf) ou au fur et � mesure de la compilation
Oui, au fur et � mesure.
> d�s qu'il
> rencontre le premier environnement asy ?
�a m�me, s'il n'y a pas d'environnement asy il n'y a pas de .asy
g�n�r�.
--
Philippe Ivaldi.
http://www.piprime.fr/
Christophe Jorssen
> À (at) 08 Nov 2009 22:42:19 GMT,
> Christophe Jorssen <christoph...@libre.fr.invalid> écrivait
> (wrote):
>
>> Avec le code que j'ai fait, je ne crois pas. En revanche, si on insère
>> une 11ème figure avant les 10 autres, tout devra être recompilé.
>
> Parce que le numéro évolue et le nom de fichier aussi ? Pourquoi ne pas
> demander à l'utilisateur de fournir un nom de référence à chacune de ses
> figures, nom qui servira pour nommer les fichiers externes pour éviter
> les recompilations inutiles ?
Pourquoi pas. J'aime bien aussi l'approche automatique. Bref, il faudrait
quelques options bien pensées à ces environnement asyalt :-)
Il faudrait aussi tester l'existence de figure en .eps et pas en .pdf si
on compile avec pdflatex (sinon, ça plante).
<je passe mes nerfs>
Et prévoir une option qui permette de compiler à distance, via ssh, avec
asy des figures 3D sur une machine qui supporte bien opengl (pas comme ma
p*t*i* de carte graphique Intel Corporation Mobile 945GM/GMS/GME). Notez
que c'est quand même pour pouvoir avoir des figures comme ça que j'ai
fait tout ça et que ça ne fonctionne même pas sur ma bécane. Arg.
Y'aurait pas un service web qui ferait ça :-) ???
</je passe mes nerfs>
A+
--
Christophe