## Parsing input files

When you save a drawing to disk, jPicEdt writes the drawing content twice,

- first in a special format called JPIC-XML (JPIC-XML is a an XML format specially tailored for jPicEdt ; it strongly mimicks the well-known SVG format, yet has extra tags dedicated to jPicEdt's own graphic primitives, which SVG obviously doesn't know of),
- then again in the LaTeX format of your choice (i.e. picture env, eepic or PSTricks).

Since both the XML code and the LaTeX code reside in the same file, the whole block of XML code is commented out by a percent symbol so that the file can be properly compiled by LaTeX. The XML code allows jPicEdt to reload the drawing without losing even the tiniest piece of information, a feature which the PSTricks format alone (not to speak about the eepic format) would not guarantee.

Therefore, when parsing input files, jPicEdt first tries to look for a JPIC-XML preamble. If it's there, then the drawing is rebuilt solely by parsing the XML code (this means that any changes made to other parts of the file have no effect). Otherwise (which is the case if you're loading a picture written by hand or by another LaTeX-capable software like GnuPlot, or if you deleted the XML code), jPicEdt delegates to an embedded LaTeX parser which currently supports three LaTeX formats, namely the standard picture environment, the eepic package, and the PSTricks package (all three can be combined into a single file, for that matter, except that only the first begin{(ps)picture}...end{(ps)picture} declaration is considered). The LaTeX parser can handle a variety of, say, syntax deviations, and you needn't worry too much about whether your syntax is perfectly LaTeX-, eepic- or PSTricks- compliant or not, since the parser will issue a pretty informative message as soon as it finds a syntax error, an incorrect format number, etc... However, we strongly encourage you to follow these rules :

- jPicEdt expects to find a `\unitlength` or a `\psset{unit=xxx}` (or xunit, yunit, runit) command at the very beginning of your file, or at least before the first command you want to be processed ; it not, default unitlength will be assumed, e.g. 1cm for PSTricks until one of these commands are found.
- jPicEdt accepts almost every command of the LaTeX picture environment, the epic/eepic packages, and the PSTricks base-package, though for the later add-ons packages are not supported yet, e.g. pst-nodes.sty or pst-coils.sty. `\multiput` (and its PSTricks equivalent) are not handled yet. I know there's been steady pressure toward supporting add-ons, but it's tricky, i tell you...
- It is perfectly possible to mix LaTeX, eepic and Pstricks commands in the same file. PSTricks default parameters (those set by `\psset` commands) won't interfere with LaTeX or eepic ones (e.g. `linethickness`).
- As of LaTeX boxes (e.g. framebox,...), don't expect true WYSIWYG behaviour ! JPicEdt doesn't embed any TeX compiler, hence only a limited set of LR-commands is handled (specifically : only those very commands related to the picture environment, see LaTeX, a documentation preparation system, Leslie Lamport, p.97 and p.108).
- The parsing process ends if, either an End-of-file is encountered, or an `\end{picture}` (or its equivalent for PSTricks) is found.
- Sure, the old-style format from jPicEdt 1.3.2 (that is, with tons of special comments) is still understood !