2.3 Particularités des différents formats
2.3.1 Analyse d’un fichier au format LaTeX
Les trois variantes (picture de base, epic, ou pstricks) du format LaTeX peuvent
combinées dans un même fichier convertible au moment de l’analyse, à ceci près
que seul la première
begin{(ps)picture}…end{(ps)picture} déclaration est prise en
compte. L’analyseur syntaxique LaTeX est capable de s’accommoder d’un
certain nombrre de, disons, déviations syntaxiques, et vous n’avez
donc pas à vous souciez de savoir si votre syntaxe est parfaitement conforme
à LaTeX, eepic ou PSTricks ou non, pusique l’analyseur syntaxique
produira un message ne vous laissant pas dans le doute dès qu’il tombe sur
une erreur de syntaxe, un numéro incorrect de format, etc. …
Néanmoins, vous être fortement encouragé à respecter les règles
suivantes :
- jPicEdt s’attend à trouver une commande
\unitlength
ou
\psset{unit=xxx}
(ou xunit
, yunit
, runit
)
au tout début de votre fichier, ou tout du moins avant la première
commande que vous voulez traiter ; dans le cas contraire, un
\unitlength
par défaut sera prise pour hypothèse, c’est à dire
1cm pour PSTricks jusqu’à que ce que l’une de ces commandes soit
trouvée.
- jPicEdt accepte pratiquement toutes les commandes de l’environnement
picture de LaTeX, des paquetages epic/eepic, et du paquatage de base de
PSTricks, bien que pour ce dernier les paquetages compagnons ne sont pas
encore supportés, par ex. pst-nodes.sty ou pst-coils.sty.
\multiput
(est ses équivalents en PSTricks) ne sont pas
encore gérés. Je sais qu’il y a une demande régulière de supporter ces
compagnon, mais ça ne coule pas de source, croyez moi…
- Il est tout à fait possible de mélanger des commandes LaTeX, eepic et
Pstricks dans le même fichier. Les paramètres par défaut de PSTricks
(ceux définis pas les commandes
\psset
) n’interféreront pas avec
ceux de LaTeX picture de base ou ceux d’eepic (par
ex. linethickness
).
- Quant aux boîtes LaTeX (par ex. framebox, …), ne vous
attendez pas à un comportement vraiment WYSIWYG ! jPicEdt ne
comprend aucun compilateur TeX, ainsi donc seulement un nombre limité de
commandes LR-commands est géré (en particulier : seulement ces
commandes-là qui sont liées à l’environnemnt picture, voir
LaTeX, a documentation preparation system, Leslie Lamport, p.97
and p.108).
- Le processus d’analyse s’arrête si, soit une fin-de-fichier est
rencontrée, soit un
\end{picture}
(ou son équivalent pour PSTricks) est
trouvé.
- Bien sûr, l’ancien format à la jPicEdt 1.3.2 (celui avec des tas de
commentaires spéciaux) est toujours intelligible pour jPicEdt !
2.3.2 Formatage en DXF
Les points suivants sont à noter :
- aucun attribut de couleur, d’épaisseur, de flèche n’est transféré en DXF
- le texte dans les objets de type texte est formatté comme du text brut
(non comme du meta-texte), c’est à dire que toute commande LaTeX comprise
dans ce texte y apparaîtra en clair sans être interprétée
- si dans les préférences vous sélectionner de n’utiliser que des lignes et
des arcs de cercle pour coder les courbes extensible de Bézier alors il est
possible que chaque sauvegarde prenne un temps significatif, en effet,
jPicEdt doit se livrer à des calculs un peu compliqué pour approximer des
courbes de Bézier par des arcs de cercle.
- La WYSIWYG-ité du type de contenu DXF n’est pas aboutie, c’est à dire que
la façon dont le dessin est présenté à l’écran est en général beaucoup plus
riche que la façon dont il apparaîtra dans le dessin DXF final.