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.