Discussion :

[Invité]

Puisque personne ne s'y colle, j'informe ceux qui ne le sauraient pas que TeXlive2010 est sortie. On peut télécharger la totalité du dvd ou le petit programme qui téléchargera ce qu'il faut et installera TL2010 sur votre système.

À vos modem donc !

À signaler cette nouveauté assez attendue : les images au format eps peuvent désormais être intégrées dans un document latex compilé en mode pdf.

[pulsar68]

Merci pour l'information.

Download en cours...

[c-top]

Pour cette année encore, on ne peut pas mettre à jour TL2009 vers TL2010. Il faudra donc télécharger 2010 et vérifier que votre installation fonctionne avant de pouvoir définitivement virer 2009. Au passage je précise que le tlmgr de 2009 n'est plus fonctionnel.
Mais on peut avoir un petit espoir pour la mise à jour de 2010 vers 2011, les développeurs de TeXlive ont pris en compte les nombreuses demades allant dans ce sens.
Bon courage à tous pour l'installation

[pulsar68]

Ayé, c'est installé. Ce n'est pas si terrible. Le truc un poil long, c'est de se taper les fichiers *.map de polices personnelles avec updmap. Et il ne faut pas oublier de mettre ses $PATH à jour...

À par ça, mes 1ers tests fonctionnent, mais je n'ai que recompilé mes documents du moment.

[lecteur1001]

Au passage je précise que le tlmgr de 2009 n'est plus fonctionnel.

Apparemment si. À confirmer car je n'ai pas encore testé chez moi.

[c-top]

Oui, mais les packages de ces dépots ne sont plus mis à jour

[pulsar68]

Tiens, la version de TikZ est la même que celle de TeXLive2009, c'est-à-dire non compatible avec la version actuelle de Gnuplot. M'en vais me remettre la version CVS...

[lecteur1001]

Oui, mais les packages de ces dépots ne sont plus mis à jour

Arf ! C'est du beau tiens !

[Invité]

Tiens, la version de TikZ est la même que celle de TeXLive2009

tikz ? Cette grosse machinerie de plus en plus pesante étant mise à jour toutes les années bissextiles (et encore, dans le meilleur des cas), il ne faut rien espérer de ce côté là. Je préfère attendre latex3 ou même luatex, c'est autrement plus excitant.

[pulsar68]

C'est bien possible que ce soit une "grosse machinerie". Quoiqu'il en soit, je trouve son usage assez facile à aborder pour mes besoins, et j'apprécie la possibilité de faire du pdflatex, voir même du dvipdfmx sans avoir à passer par des solutions de conversion qui sont à mon sens autant de grosses machineries.

Si j'ai bien compris, tu aurais tendance à préférer PStricks, j'ai bon ? Mais tu ne m'entraîneras pas plus loin dans ce débat du même ordre que windows/linux...

[Invité]

C'est bien possible que ce soit une "grosse machinerie". Quoiqu'il en soit, je trouve son usage assez facile à aborder pour mes besoins, et j'apprécie la possibilité de faire du pdflatex, voir même du dvipdfmx sans avoir à passer par des solutions de conversion qui sont à mon sens autant de grosses machineries.

Huhuhu, ça mord

Je ne suis pas d'accord. La grosse machinerie, c'est de faire faire les interminables calculs de positions graphiques à TeX. Car sais-tu que dans tikz, absolument tout les calculs sont faits par TeX ? J'espère que tu reconnaîtras avec moi que TeX est particulièrement mauvais dans les calculs et que donc, ce parti pris est assez discutable.

Avec pstricks, TeX ne fait pratiquement aucun calcul. Ils sont faits par postscript qui est un vrai langage de programmation autrement plus performant que TeX pour les calculs. D'ailleurs, il n'y a qu'à voir les temps de compilation avec tikz pour commencer à avoir peur et prendre conscience de le peine que TeX a en coulisses avec les maths calculatoires... Donc, je maintiens que la grosse machinerie est bien la couche pgf et non pas le langage postscript.

Si j'ai bien compris, tu aurais tendance à préférer PStricks, j'ai bon ?

De loin, pour les raisons que j'ai citées dont la principale est que via pstricks, on a accès à un vrai langage de programmation qui est postscript. De plus, et c'est un avis strictement personnel, la syntaxe de tikz m'est extrêmement difficile à retenir; je la trouve peu logique à cause des trop nombreuses possibilités syntaxiques qui sont offertes pour une même action . Quant au manuel, je trouve que c'est une honte. Il est d'une telle lourdeur que c'est plus une tare qu'une vraie aide : si tu savais le nombre d'heures que j'ai passées sur ce manuel à chercher un truc quasi-introuvable, tu comprendrais. Pourquoi ne pas faire comme pstricks et diviser le manuel en plein de manuels correspondant aux extensions pstricks, avec ces manuels qui vivraient leur vie propre ?

Ceci dit, tikz est extrêmement prometteur et devient capable de choses étonnantes. Je comprends tout à fait que l'on soit en admiration devant, mais il faut aussi savoir ce qui se passe en coulisse ! À titre de comparaison avec pstrick (que les utilisateurs de tikz n'aiment en général pas le décrivant comme "lourd"), le côté caché est bien plus clean...

[pulsar68]

Bon, je reviens tout de même sur ce sujet, non pas pour alimenter le troll, mais pour demander tes lumières sur 2 points PStricks.

Jamais opposé aux bonnes idées, j'ai décidé d'explorer un peu PStricks depuis ton intervention et regarder comment construire certains de mes schémas initialement créés avec TikZ. Chose amusante, les détracteurs de PStricks au profit de TikZ mettent souvent en avant la syntaxe plus simple de TikZ. Il est vrai que je lui trouve un côté "pratique", cependant, je trouve, après mes 1ers essais, celle de PStricks plus logique (bien que pas toujours pratique pour autant). Certains de mes schémas se sont révélés plus simples à coder avec PStricks (mais pas tous). Et aussi, si je ne suis pas particulièrement attaché à pdflatex, j'aime bien dvipdfmx, qui ne semble pas compatible avec PStricks, mais ce n'est pas forcément très grave.

2 questions pour lesquelles tu auras peut-être une réponse:

• il y a un aspect que j'aime bien avec TikZ, c'est le dimensionnement automatique de l'image finale. Avec PStricks, je dois donner une dimension de la fenêtre de dessin. Cette dimension peut être dépassée si je n'utilise pas pspicture* (donc sans l'astérisque), mais avec le problème que je perds les "espaces" automatiquement ajoutés par l'environnement figure par exemple. Ainsi, si je mets des axes respectant ma fenêtre PStricks et que j'y ajoute des labels aux flêches de ses axes, ces labels seront davantage collés au texte au dessus. Connais-tu une méthode pour éviter ce genre de problème et éviter de dimensionner de manière si précise la fenêtre de dessin ?
• existe-t-il une technique pour reproduire avec PSticks ce que permet de faire le \foreach de TikZ, notamment pour un liste de points sans pas fixe ? Le fin du fin, avec des points couplés x/y comme \foreach ?

Merci pour tes lumières.

Un gars pas borné qui prend l'habitude d'essayer comprendre tes interventions.

[c-top]

La christian ne va pas être content mais si tu es en phase de découverte et de recherche d'un outils efficace tu peux regarder du coté d'asymptote qui s'intègre parfaitement avec LaTeX, de même que pstricks et tikz.
Ceci n'est pas un troll c'est juste une info et chacun est libre de faire comme bon lui semble.
bon week-end à tous.

http://asymptote.sourceforge.net/

http://www.piprime.fr/asymptote/

[pulsar68]

Oui, dans le même ordre d'idée, il y a aussi TeXgraph que je trouve intéressant.

Mais j'espère malgré tout avoir des pistes pour les 2 points que je soulève plus haut.

[Invité]

Bon, je reviens tout de même sur ce sujet, non pas pour alimenter le troll, mais pour demander tes lumières sur 2 points PStricks.

Mince, tu laisses tomber le troll un vendredi ? C'est pas loyal ça.

Je tiens à mettre tout de suite les choses au point : je ne suis absolument pas un spécialiste de pstricks, juste un utilisateur habitué qui se cantonne à ses habitudes sans essayer d'en savoir plus. Je crois que je manque de curiosité pour ce genre de package (tikz et pstricks).

Pour la première question, je n'ai pas trop compris et je vais peut-être répondre à côté, mais si tu veux ajouter un peu d'espace avant un dessin pstricks (ou après), pourquoi ne pas utiliser \vspace{<dimension>}.

Pour la seconde question, les commandes \psforeach et \psForeach existent, même si je ne m'en suis jamais servi.

[pulsar68]

Oui, en effet mon 1er point est vraiment très mal expliqué. Version plus simple (j'espère) : TikZ gère automatiquement la taille maximale du dessin et a priori pas PStricks avec lequel je suis obligé de définir "à la main" les dimensions la fenêtre du dessin; Ces dimensions peuvent être dépassées pour placer des objets sur le dessin. Cependant ces dépassements ne seront pas pris en compte pour le placement de l'image dans le document. Y a-t-il un moyen de reproduire le comportement de TikZ pour cela sans avoir à faire les choses "à la main" avec \vspace ou au niveau de la dimension de pspicture ?

Point 2: effectivement avec \psforeach, je m'en sors. Merci.

[Invité]

Oui, en effet mon 1er point est vraiment très mal expliqué. Version plus simple (j'espère) : TikZ gère automatiquement la taille maximale du dessin et a priori pas PStricks avec lequel je suis obligé de définir "à la main" les dimensions la fenêtre du dessin; Ces dimensions peuvent être dépassées pour placer des objets sur le dessin. Cependant ces dépassements ne seront pas pris en compte pour le placement de l'image dans le document. Y a-t-il un moyen de reproduire le comportement de TikZ pour cela sans avoir à faire les choses "à la main" avec \vspace ou au niveau de la dimension de pspicture ?

Ayé, j'ai pigé.

Tu mets le doigt sur un point fondamental. Le dessin exécuté par \pstrricks est fait bien après que TeX ait fini son boulot et que la compilation du document entier soit faite. Par conséquent, TeX ne peut pas savoir quelle seront les dimensions de la boite englobante du dessin, c'est bien à toi de les spécifier.

La situation est très différente avec tikz puisque le dessin est fait alors que TeX fait son travail : en fait, TeX passe momentanément la main à tikz. Et donc, après avoir fini son dessin, pour les avoir calculées, tikz connait les dimensions de la boite englobante et peut les communiquer à TeX qui réserve la place adéquate dans le document et y place le dessin. Tu vois, tout n'est pas mauvais dans tikz . Disons que cette fonctionnalité qui est extrêmement intéressante est la contre partie des interminables calculs exécutés pendant la compilation du document.

Avec pstricks, si tu veux placer des objets en dehors de la boite englobante que tu as définie et que tu emploies l'environnement "pspicture*", il va falloir que tu modifies à la mano les dimensions de la boite englobante pour que les objets que tu as rajouté apparaissent.

Point 2: effectivement avec \psforeach, je m'en sors. Merci.

Justement, je me disais que la macro \foreach de tikz ou \psforeach de pstricks ont toute les deux une limitation. Je me limite à parler de \foreach, la seule que je connaisse. Avec \foreach donc, on peut dire :
\foreach \x/\y in {1/2,2/4,3/9}{<code à exécuter>}
Mais on ne peut pas donner le pattern que l'on veut dans le masque qui définit les variables. Par exemple, elle va planter (enfin je crois à 99%) si tu dis :
\foreach (x*y) in {(1*2),(2*4),(3*9)}{<code à exécuter>}

J'ai trouvé que c'était un très beau challenge que d'améliorer cette macro pour qu'elle admette le pattern que l'on veut pour le champ de déclaration de variables.

Cette macro est presque terminée, il me reste des gestion d'espaces dans les masque de pattern pour les variables (le truc pénible comme d'habitude quoi). Je posterai le résultat dans ce fil lorsqu'elle sera terminée.

[pulsar68]

Ayé, j'ai pigé.

Tu mets le doigt sur un point fondamental. Le dessin exécuté par \pstrricks est fait bien après que TeX ait fini son boulot et que la compilation du document entier soit faite. Par conséquent, TeX ne peut pas savoir quelle seront les dimensions de la boite englobante du dessin, c'est bien à toi de les spécifier.

La situation est très différente avec tikz puisque le dessin est fait alors que TeX fait son travail : en fait, TeX passe momentanément la main à tikz. Et donc, après avoir fini son dessin, pour les avoir calculées, tikz connait les dimensions de la boite englobante et peut les communiquer à TeX qui réserve la place adéquate dans le document et y place le dessin.

D'accord, je comprends mieux. Autant j'avais pigé qu'avec PStricks, on faisait bosser PostScript, autant je n'avais pas anticipé que cela se faisait à la fin... Je pensais que ça se faisait un peu comme l'appel de Gnuplot via l'option --shell-escape par TikZ.

Justement, je me disais que la macro \foreach de tikz ou \psforeach de pstricks ont toute les deux une limitation. Je me limite à parler de \foreach, la seule que je connaisse. Avec \foreach donc, on peut dire :
\foreach \x/\y in {1/2,2/4,3/9}{<code à exécuter>}
Mais on ne peut pas donner le pattern que l'on veut dans le masque qui définit les variables. Par exemple, elle va planter (enfin je crois à 99%) si tu dis :
\foreach (x*y) in {(1*2),(2*4),(3*9)}{<code à exécuter>}

J'ai trouvé que c'était un très beau challenge que d'améliorer cette macro pour qu'elle admette le pattern que l'on veut pour le champ de déclaration de variables.

Il est vrai que pour le moment l'écriture \foreach \x/\y in {1/a,2/b,3/c} me convient bien. Mais j'ai du mal à comprendre l'intérêt d'admettre un autre pattern. Dans l'état, l'idée est de pouvoir jouer avec les 2 éléments de chaque couple, le compteur étant le 1er élement du couple. As-tu un exemple qui pourrait nécessiter autre chose que \x/\y (qui dans l'état permet de dissocier l'usage de \x et de \y) ?

Mais je n'ai pas trouvé une fonctionnalité équivalente avec \psforeach.

Cette macro est presque terminée, il me reste des gestion d'espaces dans les masque de pattern pour les variables (le truc pénible comme d'habitude quoi). Je posterai le résultat dans ce fil lorsqu'elle sera terminée.

Je suis évidemment preneur, selon la réponse donnée au-dessus.

[Invité]

D'accord, je comprends mieux. Autant j'avais pigé qu'avec PStricks, on faisait bosser PostScript, autant je n'avais pas anticipé que cela se faisait à la fin... Je pensais que ça se faisait un peu comme l'appel de Gnuplot via l'option --shell-escape par TikZ.

J'y pensais aussi lorsque j'écrivais tout à l'heure.

On pourrait fort bien imaginer (et c'est déjà probablement fait par un package, d'ailleurs) que l'environnement \pspicture appelle via un shell escape un interpréteur postscript quelconque qui exécute le dessin et trouve donc les dimensions de la boite englobante de ce dessin postscript. Cette façon de faire serait encore plus légitime avec la TL2010 qui permet le shell escape pour des binaires appartenant à une liste prédéfinie.

Après que le dessin ait été fait par l'outil extérieur, l'environnement pspicture ainsi modifié ferait comme tikz : il réserverait la place automatiquement calculée pour le dessin.

Ne me demande surtout pas quel package pstricks fait ce genre de truc. J'ignore s'il existe (bien que je suppose fortement qu'il existe déjà), et comment il s'appelle.

Il est vrai que pour le moment l'écriture \foreach \x/\y in {1/a,2/b,3/c} me convient bien. Mais j'ai du mal à comprendre l'intérêt d'admettre un autre pattern. Dans l'état, l'idée est de pouvoir jouer avec les 2 éléments de chaque couple, le compteur étant le 1er élement du couple. As-tu un exemple qui pourrait nécessiter autre chose que \x/\y (qui dans l'état permet de dissocier l'usage de \x et de \y) ?

Et bien, si par une lubie soudaine, j'ai envie de spécifier un couple par "\x;\y", ce qui est au moins aussi légitime que "\x/\y" ? Ou alors "\x-\y" ou tout autre façon ?

Et si j'ai besoin de 3 variables ? Ou même plus ? Comme par exemple dans :
\foreach (\x;\y;\dotcolor) in {(1;2;red),(3;7;black),(4;8;green)}{<code à exécuter>}

[Invité]

Voici un ECM où vous verrez la macro \doforeach qui fonctionne comme \foreach de tikz sauf que le pattern de déclaration des variables est libre : on peut utiliser les caractères que l'on veut et autant de variables que l'on souhaite (dans la limite de 8 quand même !).

Pour la programmation de cet objet, c'est assez costaud, et j'ai eu la flemme de commenter le code. Il faut juste savoir que TeX construit lui-même une macro qu'il programme selon le pattern rencontré : la macro \read@item qui lit un item dans la liste.

Dernier truc : la macro n'est pas définie comme "\long", c'est fait exprès pour des raisons de débogage. On ne peut donc pas mettre un "\par" dans son argument. Il suffit, comme d'habitude, de remplacer le \par par un \endgraf.

Pour que cet ECM fonctionne, il faut compiler avec latex->dvi->ps->pdf puisqu'il contient du code pstricks.

Bon week-end...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
 
\documentclass[a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[frenchb]{babel}
\usepackage{tikz}
\usepackage{pstricks}
 
\makeatletter
 
\newtoks\arg@tok
\newtoks\def@tok
\newif\ifspace@found@
\newcount\cnt@variable
 
\def\add@to@tok#1#2{#1\expandafter{\the#1#2}}
\def\expadd@to@tok#1#2{%
	#1\expandafter\expandafter\expandafter
	{\expandafter\the\expandafter#1#2}}
 
\def\snif@next@tok{\futurelet\next@tok\analyse@variable@tok}
 
\def\parse@variables#1{%
	\cnt@variable\z@
	\arg@tok{}\def@tok{}%
	\space@found@false
	\snif@next@tok#1\relax}
 
\def\analyse@variable@tok{%
	\ifx\next@tok\relax
		\advance\cnt@variable\@ne
		\arg@tok\expandafter{\expandafter\def\expandafter\read@item\the\arg@tok,##}%
		\expadd@to@tok\arg@tok{\number\cnt@variable\relax}%
		\expadd@to@tok\def@tok{\expandafter\def\expandafter\list@item\expandafter{\expandafter##\number\cnt@variable\relax}}%
		\expandafter\the\expandafter\arg@tok\expandafter{\the\def@tok}% définit la macro \read@item
		\let\next@action\@gobble% mange le \relax
	\else
		\ifspace@found@
			\space@found@false
			\add@to@tok\arg@tok{ }% ajoute l'espace auparavant détecté
		\fi
		\ifx\@sptoken\next@tok
			\space@found@true% se rappeler qu'un espace a été trouvé
			\def\next@action{\let\next@tok= }% mange l'espace
			\afterassignment\snif@next@tok
		\else
			\let\next@action\eatnext@variable@tok
		\fi
	\fi
	\next@action
}
 
\def\eatnext@variable@tok#1{%
	\ifcat\relax\noexpand#1
		\advance\cnt@variable\@ne
		\expadd@to@tok\arg@tok{\expandafter##\number\cnt@variable}%
		\expadd@to@tok\def@tok{\expandafter\def\expandafter#1\expandafter{\expandafter##\number\cnt@variable}}%
	\else
		\add@to@tok\arg@tok{#1}%
	\fi
 \snif@next@tok
}
 
\def\doforeach#1in{%
	\parse@variables{#1}%
	\@ifnextchar\bgroup{\doforeach@i\iftrue}{\doforeach@i\iffalse}%
}
 
\def\doforeach@i#1#2{%
	#1% \iftrue ou \iffalse
		\def\list@item{#2,\relax}%
	\else
		\expandafter\def\expandafter\list@item\expandafter{#2,\relax}%
	\fi
	\afterassignment\parse@itemlist
	\def\loop@code
}
 
\def\parse@itemlist{%
	\if\relax\expandafter\noexpand\list@item
	\else
		\expandafter\read@item\list@item
		\loop@code
		\expandafter\parse@itemlist
	\fi
}
 
\makeatother
 
\begin{document}
\doforeach (\x:\y) in {(3:4),(7:9),(15:3),(1:8)}{$x$ vaut \x, $y$ vaut \y\ et leur somme est \number\numexpr\x+\y\relax\endgraf}
\bigskip
 
%même que ci dessus mais avec pattern différent
\doforeach \x;\y in {3;4,7;9,15;3,1;8}{$x$ vaut \x, $y$ vaut \y\ et leur somme est \number\numexpr\x+\y\relax\endgraf}
\bigskip
 
%on peut mettre la liste dans une séquence de contrôle
\def\mylist{1-4-8,2-6-7,3-9-4}
\doforeach \uu-\vv-\ww in \mylist {Le triplet est \uu, \vv, \ww.\endgraf}
\bigskip
 
Voici un dessin fait avec tikz :
\begin{tikzpicture}
	\draw[help lines] (0,0) grid (3,3);
	\doforeach \x;\y(\dotcolor) in {1;1(red),2;0(blue),3;2(green),2.5;2.5(yellow)}{\fill[\dotcolor] (\x,\y) circle (2pt);}
\end{tikzpicture}
\bigskip
 
% ATTENTION : compiler avec latex->dvi->ps->pdf pour le code ci dessous :
Voici  un dessin fait avec pstricks :
\psset{unit=1cm,gridlabels=0,subgriddiv=0,gridcolor=gray,gridwidth=0.6pt,dotstyle=*}
\begin{pspicture}(0,0)(3,3)
	\psgrid(0,0)(3,3)
	\doforeach \x;\y(\dotcolor) in {1;1(red),2;0(blue),3;2(green),2.5;2.5(yellow)}{\psdots[linecolor=\dotcolor](\x,\y)}%
\end{pspicture}
\end{document}