diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /graphics/jpicedt/doc/parsing.html |
Initial commit
Diffstat (limited to 'graphics/jpicedt/doc/parsing.html')
-rw-r--r-- | graphics/jpicedt/doc/parsing.html | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/graphics/jpicedt/doc/parsing.html b/graphics/jpicedt/doc/parsing.html new file mode 100644 index 0000000000..169312198f --- /dev/null +++ b/graphics/jpicedt/doc/parsing.html @@ -0,0 +1,158 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"> + <META key="author" CONTENT="Sylvain Reynal"> + <TITLE>jPicEdt 1.3.2 Help Content </TITLE> + </HEAD> + + <BODY BGCOLOR="#ffffff"> + + <H2>Parsing input files</H2> + + <P>When parsing input files, jPicEdt can handle a variety of, say, + syntax <I>deviations</I>... I carved it fairly robust :-), and you + needn't worry too much about whether your syntax is perfectly + <I>LaTeX-, epic- or PsTricks- compliant</I> or not, since jPicEdt 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 :</P> + <UL> + <LI>jPicEdt expects to find a + <CODE>\unitlength</CODE> or a <CODE>\psset{unit=xxx}</CODE> (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. + </LI> + <LI>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. + <code>\multiput</code> (and its PsTricks equivalent) are not handled yet. + </LI> + <li> + It is perfectly possible to mix LaTeX, eepic and Pstricks commands in the same file. + PsTricks default parameters (those set by <code>\psset</code> commands) won't interfere + with LaTeX or eepic ones (e.g. <code>linethickness</code>). + </LI> + <li>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 + very commands related to the picture environment, see <i>LaTeX, a documentation preparation system, + Leslie Lamport, p.97 and p.108</i>). + </li> + <li>The parsing process ends if, either an End-of-file is encountered, or a + <code>\end{picture}</code> (or its equivalent for PsTricks) is found. + </UL> + +<P>In case you are still fathoming out what those weird comment lines that jPicEdt adds to your +file really mean, here are some hints. We rely on this trick for commands that cannot be put on a single line : using a +<i>%Begin</i> and <i>%End</i> blocks is a way of making jpicedt understand that every command that lies +inside the block belongs to the same graphical element, e.g. a circle, a line,.... Obviously, +for graphical elements whose +formatted string holds on a single line (which is always the case for PsTricks, so far), +there's no need to rely on this trick however. +</P> +<p><i>Note : this small grammar was designed at a time where only the LaTeX picture environment and the +epic/eepic package were handled by jPicEdt. +Don't expect to find parameters related to colours, shadows or textures ! (please use PsTricks in this case). +Only rules needed to properly represent a compound graphical object with the set of graphical attributes +offered by the eepic package are part of this grammar, no less, no more...</i> +<TABLE BORDER=3 CELLPADDING=2 CELLSPACING=2> + <TR> + <TD><P>Line</P></TD> + <TD><P>%Line 0 0 (x1,y1)(x2,y2)<BR>%End Line</P></TD> + </TR> + <TR> + <TD><P>Vector (arrow on first end)</P></TD> + <TD><P>%Line 1 0 (x1,y1)(x2,y2)<BR>%End Line</P></TD> + </TR> + <TR> + <TD><P>Vector (arrow on second end)</P></TD> + <TD><P>%Line 0 1 (x1,y1)(x2,y2)<BR>%End Line</P></TD> + </TR> + <TR> + <TD><P>Vector (two arrows)</P></TD> + <TD><P>%Line 1 1 (x1,y1)(x2,y2)<BR>%End Line</P></TD> + </TR> + <TR> + <TD><P>Dashed line (or vector) *</P></TD> + <TD><P>%Line 0 0 (x1,y1)(x2,y2) dash=value_in_mm<BR>%End Line</P></TD> + </TR> + <TR> + <TD><P>Ellipse (hollowed)</P></TD> + <TD><P>%Ellipse (x_centre,y_centre)(width)(height)<BR>%End Ellipse</P></TD> + </TR> + <TR> + <TD><P>Black-, gray- or white-filled ellipse *</P></TD> + <TD><P>%Ellipse (x_centre,y_centre)(width)(height) blacken|shade|whiten<BR>%End Ellipse</P> + </TD> + </TR> + <TR> + <TD><P>Dashed ellipse *</P></TD> + <TD><P>%Ellipse (x_centre,y_centre)(diameter)(diameter) dash=value_in_mm<BR>%End Ellipse</P> + </TD> + </TR> + <TR> + <TD><P>Arc</P></TD> + <TD><P>%Ellipse (x_centre,y_centre)(diameter)(diameter) arcStart=angle_in_degree arcExtent=angle_in_degree<BR>%End Ellipse</P> + </TD> + </TR> + <TR> + <TD><P>Rectangle (First point = bottom left corner ; second point = top right corner)</P></TD> + <TD><P>%Rectangle(x1,y1)(x2,y2)<BR>%End Rectangle</P></TD> + </TR> + <TR> + <TD><P>Black-, gray- or white-filled rectangle *</P></TD> + <TD><P>%Rectangle(x1,y1)(x2,y2) blacken|shade|whiten<BR>%End Rectangle</P></TD> + </TR> + <TR> + <TD><P>Dashed rectangle</P></TD> + <TD><P>%Rectangle(x1,y1)(x2,y2) dash=value_in_mm<BR>%End Rectangle</P></TD> + </TR> + <TR> + <TD><P>Bezier splines (quadratic)</P></TD> + <TD><P>%Bezier 0 0 (x1,y1)(x_control,y_control)(x2,y2)<BR>%End Bezier</P></TD> + </TR> + <TR> + <TD><P>Bezier splines (quadratic) with an arrow on the first point</P></TD> + <TD><P>%Bezier 1 0 (x1,y1)(x_control,y_control)(x2,y2)<BR>%End Bezier</P></TD> + </TR> + <TR> + <TD><P>Bezier splines (quadratic) with an arrow on the second point</P></TD> + <TD><P>%Bezier 0 1 (x1,y1)(x_control,y_control)(x2,y2)<BR>%End Bezier</P></TD> + </TR> + <TR> + <TD><P>Bezier splines (quadratic) with two arrows</P></TD> + <TD><P>%Bezier 1 1 (x1,y1)(x_control,y_control)(x2,y2)<BR>%End Bezier</P></TD> + </TR> + <TR> + <TD><P>Filled Polygons (possibly closed) *</P></TD> + <TD><P>%Polygon (x1,y1)...(xN,yN) blacken|shade|whiten closed<BR>%End Polygon</P></TD> + </TR> + <TR> + <TD><P>Dashed Polygons (possibly closed)</P></TD> + <TD><P>%Polygon (x1,y1)...(xN,yN) dash=value_in_mm closed<BR>%End Polygon</P></TD> + </TR> + <TR> + <TD><P>Begin group</P></TD> + <TD><P>%Begin group</P></TD> + </TR> + <TR> + <TD><P>End group</P></TD> + <TD><P>%End group</P></TD> + </TR> + <TR> + <TD><P>Text</P></TD> + <TD><P>See LaTeX and PsTricks documentation about using \makebox,\framebox, \dashbox, \psframebox,... commands.</P></TD> + </TR> +</TABLE> +<p>Please note : </p> +<ul> +<li>commands marked with an * are supported by eepic only.</li> +<li>Order of optional params (such as dash=..., fill-colour, etc...) is not significant.</li> +<li>Cubic splines, which are not + supported by the LaTeX picture environment, are converted to a pair of quad + splines before formatting (see "Numerical Recipes in Fortran" for the algorithm + used to convert a cubic to two quads).</li> +</ul> +</BODY> +</HTML> |