2 Importieren, Exportieren und Speichern

2.1 Allgemeines

2.1.1 Dateiformate

Wenn Sie eine Zeichnung auf einen Datenträger speichern, speichert jPicEdt die Zeichnung gleich zweimal ab,

• einmal in einem besonderem Format namens JPIC-XML (JPIC-XML ist ein speziell auf jPicEdt zugeschnittenes XML Format; es ist sehr ähnlich zum weitverbreiteten SVG Format, kennt aber zusätzlich noch speziell an jPicEdt angepasste graphische Primitive, welche in SVG nicht bekannt sind),
• und zum anderem in ein LaTeX Format ihrer Wahl (z.B. picture env, eepic or PSTricks).

Da sich sowohl der XML Code als auch der LaTeX Code in der selben Datei befinden, wird der komplette XML Block mit Prozentzeichen auskommentiert, damit die Datei auch richtig von LaTeX kompiliert werden kann. Der XML Code erlaubt es jPicEdt die Zeichnung neuzuladen ohne auch nur eine winzige Information zu verlieren, ein Feature welches das PSTricks Format nicht garantieren kann (das eepic Format schon gar nicht).

2.1.2 Speicherformate und Inhaltstypen

2.1.3 Öffnen einer Datei

2.1.4 Inhaltstypen und WYSIWYG-Verhalten

Daher sucht jPicEdt, wenn man eine Eingabedatei analysiert, zuerst nach einer JPIC-XML Präambel. Ist diese vorhanden, wird die Zeichnung auf Basis des XML-Codes neu aufgebaut (was bedeutet, dass sämtliche sonstige Änderungen an anderen Stellen der Datei zu keinem Effekt führen). Andernfalls (dies ist der Fall wenn Sie ein Bild öffnen welches per Hand oder in einer LaTeX-kompatiblen Software wie zum Beispiel GnuPlot geschrieben wurde, oder wenn der XML-Code gelöscht wurde), beauftragt jPicEdt einen integrierten LaTeX-Parser, welcher zur Zeit folgende drei Formate unterstützt: die Standard picture Umgebung, das eepic-Paket und das PSTricks Paket (alle drei können in einer einzelnen Datei kombiniert werden, in diesem Falle wird nur die erste \begin{[ps]picture} … \end{[ps]picture} Deklaration betrachtet). Der LaTeX-Parser kann mit einer Vielzahl von Syntax-Abweichungen umgehen, sie brauchen sich also keine großen Sorgen darüber machen, ob Ihre Syntax nun perfekt LaTeX-, eepic- oder PSTricks-kompatibel ist oder nicht, denn der Parser wird eine recht informative Meldung ausgeben, falls er einen Syntaxfehler, eine falsch formatierte Zahl, usw. findet. Trotzdem empfehlen wir folgende Regeln zu beachten:

• jPicEdt erwartet, dass ein \unitlength oder \psset{unit=xxx} (oder xunit, yunit, runit) Kommando ganz am Anfang ihrer Datei oder zumindest vor dem ersten Kommando steht, welches verarbeitet werden soll; ist dies nicht der Fall, wird die Standard \unitlength angenommen, z.B. 1cm für PSTricks, bis ein solches Kommando gefunden wird.
• jPicEdt akzeptiert so gut wie alle Kommandos der LaTeX picture-Umgebung, des epic/eepic-Pakets und des PSTricks Basispaktes, wobei neuere Zusatzpakete noch nicht unterstützt werden, wie zum Beispiel pst-nodes.sty oder pst-coils.sty. \multiput (und sein PSTricks Gegenstück) werden auch noch nicht verarbeitet. Ich weiß, dass es einen sehr großen Druck gibt bzgl. der Unterstützung von Addons, aber das ist ein wenig knifflig, das sag ich ihnen …
• Es ist absolut zulässig und möglich LaTeX-, eepic- and PSTricks-Kommandos in der selben Datei zu vermischen. Die Standard Parameter von PSTricks (welche mit \psset gesetzt werden) stören nicht die Benutzung von LaTeX- oder eepic Parametern (z.B. linethickness).
• Anders als bei LaTeX-Boxen (z.B. framebox, …) können sie hier kein wahres WYSIWYG Verhalten erwarten! JPicEdt verfügt nicht über einen integrierten TeX Compiler, daher werden auch nur eine begrenzte Menge an LR-Kommandos verarbeitet (genauer gesagt: nur Kommandos, die sich auf die Bildumgebung beziehen, siehe LaTeX, a documentation preparation system, Leslie Lamport, S.97 und S.108).
• Der Parsingprozess endet entweder, wenn das Ende der Datei erreicht ist, oder falls ein \end{picture} (oder das Gegenstück für PSTricks) gefunden wird.
• Natürlich wird der alte Formattyp von jPicEdt 1.3.2 (mit einer Unzahl von besonderen Kommentaren) weiterhin unterstützt !

2.2 Besonderheiten der verschiedenen Formate

2.2.1 Analyse einer Datei im LaTeX-Format

2.3 Benutzer-Präambel und -Postambel im Speicherformat

Although basically a drawing save file can be directly included into a LaTeX file with a \input{nom_du_fichier_jpicedt} command, it is also possible to insert into it a user preamble and postamble, so that to make a master LaTeX file out of it.

The use preamble and postamble are not interpreted by jPicEdt, so they can be any text. In particular the user preamble can be a classical LaTeX document preamble, that is to say the code section that goes from \documentclass up-to \begin{document}, and a classical LaTeX postamble, that is to say the code section that comprises \end{document}. This way, the save file can be compiled directly with LaTeX like any master file.

Anhand der folgenden Abbildung wird beispielhaft gezeigt, aus welchen Teilen eine jPicEdt besteht:

Der Inhalt der jPicEdt Datei, die zu dieser Abbildung gehört, kann hier heruntergeladen werden: help.RedStar.jpe.pstricks.

Hier ist er dargestellt:

Die Datei besteht aus sieben aufeinanderfolgenden Teilen:

1. First of all a user preamble. This pramble is empty by default, and the only way to fill it is to edit the save file with a text editer software, like EMACS for instance. You can place whatever valid LaTeX code into this preamble, jPicEdt anyway does not interprete it. However, the two typical usage are these ones hereinafter :
   • Add a comment with a key that a file version control system can interprete and update to tag the file by its archive version. In the example this comment is as follows:

     % Version: $Id: help.RedStar.jpe.pstricks,v 1.1 2013/02/26 22:16:59 vincentb1 Exp $
     

   • Add a classical LaTeX preamble, so as to allow direct compilation of the file to produce a picture this way:

     latex -jobname=RedStar help.RedStar.jpe.pstricks
     dvips -E RedStar.dvi -o RedStar.eps
     

     Please note that:

     • The -jobname=RedStar option passed to the latex command is necessary only for renaming the file basename, there would be no use for it if the file was directly named RedStar.tex, which jPicEdt does not prevent.
     • The LaTeX preamble is encapsulated into:

       \ifx\JPicIsIncluded\undefined
          …    …    …    …   …
       \fi
       

       so that the file can be not only directly compiled as a master file, but also included through a \input{…} command into another master file, provided that its preamble contains this declaration:

       \newcommand*\JPicIsIncluded{}
       

   • The second part is a mark-up that allows jPicEdt to detect the file format and and the beginning of the embedded JPIC-XML code this way:

     %%Created by jPicEdt 1.6-pre1: mixed JPIC-XML/LaTeX format
     %%Mon Feb 25 21:15:38 CET 2013
     %%Begin JPIC-XML
     

   • The third part is the embedded JPIC-XML code itself.
   • The fourth part is a mark-up that separate the embedded JPIC-XML from the exported LaTeX code this way:

     %%End JPIC-XML
     

   • The fifth part is the exported LaTeX code, this part is waht LaTeX will compile to produce the picture corresponding to your drawing.
   • The sixth and seventh part are optional, the sixth part is a mark-up that separates the exported LaTeX code from the user postamble like this:

     %%User Data
     

   • The seventh part is the use postamble, you need that the markup that is the sixth part be present for jPicEdt to keep this postamble. The typical usage of the user preabmle is for instance:
     • A LaTeX classical postamble that matches the LaTeX preamble within the first part if any. In this example that is the following:

       \ifx\JPicIsIncluded\undefined
       \end{preview}
       \end{document}
       \fi
       

       Please note that — for the sake of consistency — we used the same \ifx\JPicIsIncluded\undefined … \fi encapsulation trick for this LaTeX postamble as in the LaTeX preamble.

     • Special comments that can be interpreted by your text editor software, in this example these are EMACS “File Varaibles”:

       %%% Local Variables:
       %%% mode: latex
       %%% eval: (TeX-PDF-mode 0)
       %%% End:
       

2.3.1 Formatierung im DXF-Format