Again, as with the graphs, we separate those parser commands that manipulate the data in a set from the commands that determine parameters---elements that are saved in a project file. Commands

Operations for set I/O are summarized in table . (Note that this is incomplete and only lists input commands at the moment.) Statement | Description | Types | Example @ READ "file" | Reads file as a single set | sexpr file | READ "foo.dat" @ READ settype "file" | Reads file into a single set of type settype | xytype settype, sexpr file | READ xydy "bar.dat" @ READ NXY "file" | Reads file as NXY data | sexpr file | READ NXY "gad.dat" @ READ BLOCK "file" | Reads file as block data | sexpr file | READ BLOCK "zooks.dat" @ KILL BLOCK | Kills the current block data and frees the associated memory |   | KILL BLOCK @ BLOCK settype columns | Forms a data set of type settype using columns from current block data file. | xytype settype, sexpr columns | BLOCK xydxdy "0:2:1:3" @ WRITE set | writes set to stdout| setsel set | WRITE G0.S1 @ WRITE set FORMAT "formatstring" | writes set to stdout using format specification formatstring | setsel set sexpr formatstring | WRITE G0.S1 FORMAT "%18.8g" @ WRITE set FILE "file" | writes set to file | setsel set sexpr file | WRITE G0.S1 FILE "data.dat" @ WRITE set FILE "file" FORMAT "formatstring" | writes set to file using format specification formatstring | setsel set sexpr file sexpr formatstring | WRITE G0.S1 FILE "data.dat" FORMAT "%18.8g" @

Set input, output, and creation

The parser commands analogous to the Data|Data set operations dialogue can be found in table . Statement | Description | Types | Example @ COPY src TO dest | Copies src to dest| setsel src,dest | COPY S0 TO S1 @ MOVE src TO dest | Moves src to dest | setsel src,dest | MOVE G0.S0 TO G1.S0 @ SWAP src AND dest | Interchanges src and dest | setsel src,dest | SWAP G0.S0 AND G0.S1 @ KILL set | Kills set | setsel set | KILL G0.S0 @

Set operations

Not Finished yet... Parameter settings

Not written yet... Advanced topics

Fonts

For all devices, Grace uses Type1 fonts. Both PFA (ASCII) and PFB (binary) formats can be used.

Font configuration

The file responsible for the font configurations of Grace is fonts/FontDataBase. The first line contains a positive integer specifying the number of fonts declared in that file. All remaining lines contain declarations of one font each, composed out of three fields: Font name. The name will appear in the font selector controls. Also, backend devices that has built-in fonts, will be given the name as a font identifier. Font fall-back. Grace will try to use this in case the real font is not found. Font filename. The file with the font outline data.

Here is the default FontDataBase file: 14 Times-Roman Times-Roman n021003l.pfb Times-Italic Times-Italic n021023l.pfb Times-Bold Times-Bold n021004l.pfb Times-BoldItalic Times-BoldItalic n021024l.pfb Helvetica Helvetica n019003l.pfb Helvetica-Oblique Helvetica-Oblique n019023l.pfb Helvetica-Bold Helvetica-Bold n019004l.pfb Helvetica-BoldOblique Helvetica-BoldOblique n019024l.pfb Courier Courier n022003l.pfb Courier-Oblique Courier-Oblique n022023l.pfb Courier-Bold Courier-Bold n022004l.pfb Courier-BoldOblique Courier-BoldOblique n022024l.pfb Symbol Symbol s050000l.pfb ZapfDingbats ZapfDingbats d050000l.pfb

Font data files

For text rastering, three types of files are used. .pfa-/.pfb-files: These contain the character outline descriptions. The files are assumed to be in the fonts/type1 directory; these are the filenames specified in the FontDataBase configuration file. .afm-files: These contain high-precision font metric descriptions as well as some extra information, such as kerning and ligature information for a particular font. It is assumed that the filename of a font metric file has same basename as the respective font outline file, but with the .afm extension; the metric files are expected to be found in the fonts/type1 directory, too. .enc-files: These contain encoding arrays in a special but simple form. They are only needed if someone wants to load a special encoding to re-encode a font. Their place is fonts/enc Custom fonts

It is possible to use custom fonts with Grace. One mostly needs to use extra fonts for the purpose of localization. For many European languages, the standard fonts supplied with Grace should contain all the characters needed, but encoding may have to be adjusted. This is done by putting a Default.enc file with proper encoding scheme into the fonts/enc directory. Grace comes with a few encoding files in the directory; more can be easily found on the Internet. (If the Default.enc file doesn't exist, the IsoLatin1 encoding will be used). Notice that for fonts having an encoding scheme in themselves (such as the Symbol font, and many nationalized fonts) the default encoding is ignored.

If you do need to use extra fonts, you should modify the FontDataBase file accordingly, obeying its format. However, if you are going to exchange Grace project files with other people who do not have the extra fonts configured, an important thing is to define reasonable fall-back font names.

For example, let us assume I use Hebrew fonts, and the configuration file has lines like these: ... Courier-Hebrew Courier courh___.pfa Courier-Hebrew-Oblique Courier-Oblique courho__.pfa ... My colleague, who lives in Russia, uses Cyrillic fonts with Grace configured like this: ... Cronix-Courier Courier croxc.pfb Cronix-Courier-Oblique Courier-Oblique croxco.pfb ... The font mapping information (Font name <-> Font fall-back) is stored in the Grace project files. Provided that all the localized fonts have English characters in the lower part of the ASCII table unmodified, I can send my friend files (with no Hebrew characters, of course) and be sure they render correctly on his computer.

Thus, with properly configured national fonts, you can make localized annotations for plots intended for internal use of your institution, while being able to exchange files with colleagues from abroad. People who ever tried to do this with MS Office applications should appreciate the flexibility :-). Interaction with other applications

Using pipes

Using grace_np library

The grace_np library is a set of compiled functions that allows you to launch and drive a Grace subprocess from your C or Fortran application. Functions are provided to start the subprocess, to send it commands or data, to stop it or detach from it. Function | Arguments | Description @ int GraceOpenVA | (char *exe, int buf_size, ...) | launch a Grace executable exe and open a communication channel with it using buf_size bytes for data buffering. The remaining NULL-terminated list of options is command line arguments passed to the Grace process @ int GraceOpen | (int buf_size) | equivalent to GraceOpenVA("xmgrace", buf_size, "-nosafe", "-noask", NULL) @ int GraceIsOpen | (void) | test if a Grace subprocess is currently connected @ int GraceClose | (void) | close the communication channel and exit the Grace subprocess @ int GraceClosePipe | (void) | close the communication channel and leave the Grace subprocess alone @ int GraceFlush | (void) | flush all the data remaining in the buffer @ int GracePrintf | (const char* format, ...) | format a command and send it to the Grace subprocess @ int GraceCommand | (const char* cmd) | send an already formated command to the Grace subprocess @ GraceErrorFunctionType GraceRegisterErrorFunction | (GraceErrorFunctionType f) | register a user function f to display library errors @

grace_np library C functions.

Function | Arguments | Description @ integer GraceOpenF | (integer buf_size) | launch a Grace subprocess and open a communication channel with it @ integer GraceIsOpenF | (void) | test if a Grace subprocess is currently connected @ integer GraceCloseF | (void) | close the communication channel and exit the Grace subprocess @ integer GraceClosePipeF | (void) | close the communication channel and leave the Grace subprocess alone @ integer GraceFlushF | (void) | flush all the data remaining in the buffer @ integer GraceCommandF | (character*(*) cmd) | send an already formatted command to the Grace subprocess @ GraceFortranFunctionType GraceRegisterErrorFunctionF | (GraceFortranFunctionType f) | register a user function f to display library errors @

grace_np library F77 functions.

There is no Fortran equivalent for the GracePrintf function, you should format all the data and commands yourself before sending them with GraceCommandF. The Grace subprocess listens for the commands you send and interprets them as if they were given in a batch file. You can send any command you like (redraw, autoscale, ...). If you want to send data, you should include them in a command like "g0.s0 point 3.5, 4.2". Apart from the fact it monitors the data sent via an anonymous pipe, the Grace subprocess is a normal process. You can interact with it through the GUI. Note that no error can be sent back to the parent process. If your application send erroneous commands, an error popup will be displayed by the subprocess. If you exit the subprocess while the parent process is still using it, the broken pipe will be detected. An error code will be returned to every further call to the library (but you can still start a new process if you want to manage this situation). Here is an example use of the library, you will find this program in the distribution. #include #include #include #include #ifndef EXIT_SUCCESS # define EXIT_SUCCESS 0 #endif #ifndef EXIT_FAILURE # define EXIT_FAILURE -1 #endif void my_error_function(const char *msg) { fprintf(stderr, "library message: \"%s\"\n", msg); } int main(int argc, char* argv[]) { int i; GraceRegisterErrorFunction(my_error_function); /* Start Grace with a buffer size of 2048 and open the pipe */ if (GraceOpen(2048) == -1) { fprintf(stderr, "Can't run Grace. \n"); exit(EXIT_FAILURE); } /* Send some initialization commands to Grace */ GracePrintf("world xmax 100"); GracePrintf("world ymax 10000"); GracePrintf("xaxis tick major 20"); GracePrintf("xaxis tick minor 10"); GracePrintf("yaxis tick major 2000"); GracePrintf("yaxis tick minor 1000"); GracePrintf("s0 on"); GracePrintf("s0 symbol 1"); GracePrintf("s0 symbol size 0.3"); GracePrintf("s0 symbol fill pattern 1"); GracePrintf("s1 on"); GracePrintf("s1 symbol 1"); GracePrintf("s1 symbol size 0.3"); GracePrintf("s1 symbol fill pattern 1"); /* Display sample data */ for (i = 1; i <= 100 && GraceIsOpen(); i++) { GracePrintf("g0.s0 point %d, %d", i, i); GracePrintf("g0.s1 point %d, %d", i, i * i); /* Update the Grace display after every ten steps */ if (i % 10 == 0) { GracePrintf("redraw"); /* Wait a second, just to simulate some time needed for calculations. Your real application shouldn't wait. */ sleep(1); } } if (GraceIsOpen()) { /* Tell Grace to save the data */ GracePrintf("saveall \"sample.agr\""); /* Flush the output buffer and close Grace */ GraceClose(); /* We are done */ exit(EXIT_SUCCESS); } else { exit(EXIT_FAILURE); } }

To compile this program, type cc example.c -lgrace_np If Grace wasn't properly installed, you may need to instruct the compiler about include and library paths explicitly, e.g. cc -I/usr/local/grace/include example.c -L/usr/local/grace/lib -lgrace_np FFTW tuning

When the FFTW capabilities are compiled in, Grace looks at two environment variables to decide what to do with the FFTW 'wisdom' capabilities. First, a quick summary of what this is. The FFTW package is capable of adaptively determining the most efficient factorization of a set to give the fastest computation. It can store these factorizations as 'wisdom', so that if a transform of a given size is to be repeated, it is does not have to re-adapt. The good news is that this seems to work very well. The bad news is that, the first time a transform of a given size is computed, if it is not a sub-multiple of one already known, it takes a LONG time (seconds to minutes).

The first environment variable is GRACE_FFTW_WISDOM_FILE. If this is set to the name of a file which can be read and written (e.g., $HOME/.grace_fftw_wisdom) then Grace will automatically create this file (if needed) and maintain it. If the file is read-only, it will be read, but not updated with new wisdom. If the symbol GRACE_FFTW_WISDOM_FILE either doesn't exist, or evaluates to an empty string, Grace will drop the use of wisdom, and will use the fftw estimator (FFTW_ESTIMATE flag sent to the planner) to guess a good factorization, instead of adaptively determining it.

The second variable is GRACE_FFTW_RAM_WISDOM. If this variable is defined to be non-zero, and GRACE_FFTW_WISDOM_FILE variable is not defined (or is an empty string), Grace will use wisdom internally, but maintain no persistent cache of it. This will result in very slow execution times the first time a transform is executed after Grace is started, but very fast repeats. I am not sure why anyone would want to use wisdom without writing it to disk, but if you do, you can use this flag to enable it.

DL modules

Grace can access external functions present in either system or third-party shared libraries or modules specially compiled for use with Grace. Function types

One must make sure, however, that the external function is of one of supported by Grace types: Grace type | Description @ f_of_i | a function of 1

Grace types for external functions

The return values of functions are assumed to be of the Examples

Caution: the examples provided below (paths and compiler flags) are valid for Linux/ELF with gcc. On other operating systems, you may need to refer to compiler/linker manuals or ask a guru. Example 1

Suppose I want to use function USE "pow" TYPE f_of_dd FROM "/usr/lib/libm.so" Try to plot y = pow(x,2) and y = x^2 graphs (using, for example, "create new -> Formula" from any ) and compare. Example 2

Now, let us try to write a function ourselves. We will define function double my_function (int n, double x) { double retval; retval = (double) n * x; return (retval); } OK, now compile it: $gcc -c -fPIC my_func.c $gcc -shared my_func.o -o /tmp/my_func.so (You may strip it to save some disk space): $strip /tmp/my_func.so That's all! Ready to make it visible to Grace as "myf" - we are too lazy to type the very long string "my_function" many times. USE "my_function" TYPE f_of_nd FROM "/tmp/my_func.so" ALIAS "myf" Example 3

A more serious example. There is a special third-party library available on your system which includes a very important for you yet very difficult-to-program from the scratch function that you want to use with Grace. But, the function prototype is NOT one of any predefined . The solution is to write a simple function wrapper. Here is how: Suppose, the name of the library is "special_lib" and the function you are interested in is called "special_func" and according to the library manual, should be accessed as double my_wrapper(int n, double x) { extern void special_func(double *x, double *y, int n); double retval; (void) special_func(&x, &retval, n); return (retval); } Compile it: $gcc -c -fPIC my_wrap.c $gcc -shared my_wrap.o -o /tmp/my_wrap.so -lspecial_lib -lblas $strip /tmp/my_wrap.so Note that I added all libraries which your module depends on (and all libraries those libraries rely upon etc.), as if you wanted to compile a plain executable. Fine, make Grace aware of the new function USE "my_wrapper" TYPE f_of_nd FROM "/tmp/my_wrap.so" ALIAS "special_func" so we can use it with its original name. Example 4

An example of using Fortran modules. Here we will try to achieve the same functionality as in Example 2, but with the help of F77. DOUBLE PRECISION FUNCTION MYFUNC (N, X) IMPLICIT NONE INTEGER N DOUBLE PRECISION X C MYFUNC = N * X C RETURN END As opposite to C, there is no way to call such a function from Grace directly - the problem is that in Fortran all arguments to a function (or subroutine) are passed by reference. So, we need a wrapper: double myfunc_wrapper(int n, double x) { extern double myfunc_(int *, double *); double retval; retval = myfunc_(&n, &x); return (retval); } Note that most of f77 compilers by default add underscore to the function names and convert all names to the lower case, hence I refer to the Fortran function $g77 -c -fPIC myfunc.f $gcc -c -fPIC myfunc_wrap.c $gcc -shared myfunc.o myfunc_wrap.o -o /tmp/myfunc.so -lf2c -lm $strip /tmp/myfunc.so And finally, inform Grace about this new function: USE "myfunc_wrapper" TYPE f_of_nd FROM "/tmp/myfunc.so" ALIAS "myfunc" Operating system issues

OS/2

In general the method outlined in the examples above can be used on OS/2, too. However you have to create a DLL (Dynamic Link Library) which is a bit more tricky on OS/2 than on most Un*x systems. Since Grace was ported by using EMX we also use it to create the examples; however other development environments should work as well (ensure to use the _System calling convention!). We refer to Example 2 only. Example 1 might demonstrate that DLLs can have their entry points (i.e. exported functions) callable via ordinals only, so you might not know how to access a specific function without some research. First compile the source from Example 2 to "my_func.obj" gcc -Zomf -Zmt -c my_func.c -o my_func.obj Then you need to create a linker definition file "my_func.def" which contains some basic info about the DLL and declares the exported functions. LIBRARY my_func INITINSTANCE TERMINSTANCE CODE LOADONCALL DATA LOADONCALL MULTIPLE NONSHARED DESCRIPTION 'This is a test DLL: my_func.dll' EXPORTS my_function (don't forget about the 8 characters limit on the DLL name!). Finally link the DLL: gcc my_func.obj my_func.def -o my_func.dll -Zdll -Zno-rte -Zmt -Zomf (check out the EMX documentation about the compiler/linker flags used here!) To use this new library function within Grace you may either put the DLL in the LIBPATH and use the short form: USE "my_function" TYPE f_of_nd FROM "my_func" ALIAS "myf" or put it in an arbitrary path which you need to specify explicitly then: USE "my_function" TYPE f_of_nd FROM "e:/foo/my_func.dll" ALIAS "myf" (as for most system-APIs you may use the Un*x-like forward slashs within the path!) References

Typesetting

Grace permits quite complex typesetting on a per string basis. Any string displayed (titles, legends, tick marks,...) may contain special control codes to display subscripts, change fonts within the string etc.

Control code | Description @ \f{x} | switch to font named "x" @ \f{n} | switch to font number n @ \f{} | return to original font @ \R{x} | switch to color named "x" @ \R{n} | switch to color number n @ \R{} | return to original color @ \#{x} | treat "x" (must be of even length) as list of hexadecimal char codes @ \t{xx xy yx yy} | apply transformation matrix @ \t{} | reset transformation matrix @ \z{x} | zoom x times @ \z{} | return to original zoom @ \r{x} | rotate by x degrees @ \l{x} | slant by factor x @ \v{x} | shift vertically by x @ \v{} | return to unshifted baseline @ \V{x} | shift baseline by x @ \V{} | reset baseline @ \h{x} | horizontal shift by x @ \n | new line @ \u | begin underline @ \U | stop underline @ \o | begin overline @ \O | stop overline @ \Fk | enable kerning @ \FK | disable kerning @ \Fl | enable ligatures @ \FL | disable ligatures @ \m{n} | mark current position as n @ \M{n} | return to saved position n @ \dl | LtoR substring direction @ \dr | RtoL substring direction @ \dL | LtoR text advancing @ \dR | RtoL text advancing @ \x | switch to Symbol font (same as \f{Symbol}) @ \+ | increase size (same as \z{1.19} ; 1.19 = sqrt(sqrt(2))) @ \- | decrease size (same as \z{0.84} ; 0.84 = 1/sqrt(sqrt(2))) @ \s | begin subscripting (same as \v{-0.4}\z{0.71}) @ \S | begin superscripting (same as \v{0.6}\z{0.71}) @ \T{xx xy yx yy} | same as \t{}\t{xx xy yx yy} @ \Z{x} | absolute zoom x times (same as \z{}\z{x}) @ \q | make font oblique (same as \l{0.25}) @ \Q | undo oblique (same as \l{-0.25}) @ \N | return to normal style (same as \v{}\t{}) @ \\ | print \ @ \n | switch to font number n (0-9) (deprecated) @ \c | begin using upper 128 characters of set (deprecated) @ \C | stop using upper 128 characters of set (deprecated) @

Control codes.

Example:

F\sX\N(\xe\f{}) = sin(\xe\f{})\#{b7}e\S-X\N\#{b7}cos(\xe\f{})

prints roughly -x F (e) = sin(e)·e ·cos(e) x

using string's initial font and e prints as epsilon from the Symbol font.

NOTE: Characters from the upper half of the char table can be entered directly from the keyboard, using appropriate xmodmap(1) settings, or with the help of the font tool ("Window/Font tool").

Device-specific limitations

Grace can output plots using several device backends. The list of available devices can be seen (among other stuff) by specifying the "-version" command line switch. X11, PostScript and EPS are full-featured devices Raster drivers (PNM/JPEG/PNG): only even-odd fill rule is supported patterned lines are not implemented PDF driver: bitmapped text strings are not transparent MIF driver: some of patterned fills not implemented bitmapped text strings not implemented SVG driver: bitmapped text strings not implemented

Device-specific settings

Some of the output devices accept several configuration options. You can set the options by passing a respective string to the interpreter using the "DEVICE "devname" OP "options"" command (see ). A few options can be passed in one command, separated by commas.

Command | Description @ grayscale | set grayscale output @ color | set color output @ level1 | use only PS Level 1 subset of commands @ level2 | use also PS Level 2 commands if needed @ docdata:7bit | the document data is 7bit clean @ docdata:8bit | the document data is 8bit clean @ docdata:binary | the document data may be binary @ xoffset:x | set page offset in X direction x pp @ yoffset:y | set page offset in Y direction y pp @ mediafeed:auto | default input tray @ mediafeed:match | select input with media matching page dimensions @ mediafeed:manual | manual media feed @ hwresolution:on | set hardware resolution @ hwresolution:off | do not set hardware resolution @

PostScript driver options

Command | Description @ grayscale | set grayscale output @ color | set color output @ level1 | use only PS Level 1 subset of commands @ level2 | use also PS Level 2 commands if needed @ bbox:tight | enable "tight" bounding box @ bbox:page | bounding box coincides with page dimensions @

EPS driver options

Command | Description @ PDF1.3 | set compatibility mode to PDF-1.3 @ PDF1.4 | set compatibility mode to PDF-1.4 @ compression:value | set compression level (0 - 9) @ patterns:on | enable use of patterns @ patterns:off | disable use of patterns @

PDF driver options

Command | Description @ format:pbm | output in PBM format @ format:pgm | output in PGM format @ format:ppm | output in PPM format @ rawbits:on | "rawbits" (binary) output @ rawbits:off | ASCII output @

PNM driver options

Command | Description @ grayscale | set grayscale output @ color | set color output @ optimize:on/off | enable/disable optimization @ quality:value | set compression quality (0 - 100) @ smoothing:value | set smoothing (0 - 100) @ baseline:on/off | do/don't force baseline output @ progressive:on/off | do/don't output in progressive format @ dct:ifast | use fast integer DCT method @ dct:islow | use slow integer DCT method @ dct:float | use floating-point DCT method @

JPEG driver options

Command | Description @ interlaced:on | make interlaced image @ interlaced:off | don't make interlaced image @ transparent:on | produce transparent image @ transparent:off | don't produce transparent image @ compression:value | set compression level (0 - 9) @

PNG driver options

Dates in Grace

We use two calendars in Grace: the one that was established in 532 by Denys and lasted until 1582, and the one that was created by Luigi Lilio (Alyosius Lilius) and Christoph Klau (Christophorus Clavius) for pope Gregorius XIII. Both use the same months (they were introduced under emperor Augustus, a few years after Julian calendar introduction, both Julius and Augustus were honored by a month being named after each one). The leap years occurred regularly in Denys's calendar: once every four years, there is no year 0 in this calendar (the leap year -1 was just before year 1). This calendar was not compliant with earth motion and the dates were slowly shifting with regard to astronomical events. This was corrected in 1582 by introducing Gregorian calendar. First a ten days shift was introduced to reset correct dates (Thursday October the 4th was followed by Friday October the 15th). The rules for leap years were also changed: three leap years are removed every four centuries. These years are those that are multiple of 100 but not multiple of 400: 1700, 1800, and 1900 were not leap years, but 1600 and 2000 were (will be) leap years. We still use Gregorian calendar today, but we now have several time scales for increased accuracy. The International Atomic Time (TAI) is a linear scale: the best scale to use for scientific reference. The Coordinated Universal Time (UTC, often confused with Greenwich Mean Time) is a legal time that is almost synchronized with earth motion. However, since the earth is slightly slowing down, leap seconds are introduced from time to time in UTC (about one second every 18 months). UTC is not a continuous scale ! When a leap second is introduced by International Earth Rotation Service, this is published in advance and the legal time sequence is as follows: 23:59:59 followed one second later by 23:59:60 followed one second later by 00:00:00. At the time of this writing (1999-01-05) the difference between TAI and UTC was 32 seconds, and the last leap second was introduced in 1998-12-31. These calendars allow to represent any date from the mist of the past to the fog of the future, but they are not convenient for computation. Another time scale is possible: counting only the days from a reference. Such a time scale was introduced by Joseph-Juste Scaliger (Josephus Justus Scaliger) in 1583. He decided to use "-4713-01-01T12:00:00" as a reference date because it was at the same time a Monday, first of January of a leap year, there was an exact number of 19 years Meton cycle between this date and year 1 (for Easter computation), and it was at the beginning of a 15 years Roman indiction cycle. The day number counted from this reference is traditionally called Julian day, but it has really nothing to do with the Julian calendar. Grace stores dates internally as reals numbers counted from a reference date. The default reference date is the one chosen by Scaliger, it is a classical reference for astronomical events. It can modified for a single session using the popup of the GUI. If you often work with a specific reference date you can set it for every sessions with a REFERENCE DATE command in your configuration file (see ). The following date formats are supported (hour, minutes and seconds are always optional): iso8601 : 1999-12-31T23:59:59.999 european : 31/12/1999 23:59:59.999 or 31/12/99 23:59:59.999 us : 12/31/1999 23:59:59.999 or 12/31/99 23:59:59.999 Julian : 123456.789 One should be aware that Grace does not allow to put a space in one data column as spaces are used to separate fields. You should always use another separator (:/.- or better T) between date and time in data files. The GUI, the batch language and the command line flags do not have this limitation, you can use spaces there without any problem. The T separator comes from the ISO8601 standard. Grace support its use also in european and us formats. You can also provide a hint about the format ("ISO8601", "european", "us") using the -datehint command line flag or the ref name="Edit->Preferences" id="preferences"> popup of the GUI. The formats are tried in the following order: first the hint given by the user, then iso, european and us (there is no ambiguity between calendar formats and numerical formats and therefore no order is specified for them). The separators between various fields can be any characters in the set: " :/.-T" (one or more spaces act as one separator, other characters can not be repeated, the T separator is allowed only between date and time, mainly for iso8601), so the string "1999-12 31:23/59" is allowed (but not recommended). The '-' character is used both as a separator (it is traditionally used in iso8601 format) and as the unary minus (for dates in the far past or for numerical dates). By default years are left untouched, so 99 is a date far away in the past. This behavior can be changed with the popup, or with the DATE WRAP on and DATE WRAP YEAR year commands. Suppose for example that the wrap year is chosen as 1950, if the year is between 0 and 99 and is written with two or less digits, it is mapped to the present era as follows: range [00 ; 49] is mapped to [2000 ; 2049] range [50 ; 99] is mapped to [1950 ; 1999] with a wrap year set to 1970, the mapping would have been: range [00 ; 69] is mapped to [2000 ; 2069] range [70 ; 99] is mapped to [1970 ; 1999] this is reasonably Y2K compliant and is consistent with current use. Specifying year 1 is still possible using more than two digits as follows: "0001-03-04" is unambiguously March the 4th, year 1. The inverse transform is applied for dates written by Grace, for example as tick labels. Using two digits only for years is not recommended, we introduce a wrap year + 100 bug here so this feature should be removed at some point in the future ... The date scanner can be used either for Denys's and Gregorian calendars. Inexistent dates are detected, they include year 0, dates between 1582-10-05 and 1582-10-14, February 29th of non leap years, months below 1 or above 12, ... the scanner does not take into account leap seconds: you can think it works only in International Atomic Time (TAI) and not in Coordinated Unified Time (UTC). If you find yourself in a situation were you need UTC, a very precise scale, and should take into account leap seconds ... you should convert your data yourself (for example using International Atomic Time). But if you bother with that you probably already know what to do. Xmgr to Grace migration guide

This is a very brief guide describing problems and workarounds for reading in project files saved with Xmgr. You should read the docs or just play with Grace to test new features and controls. Grace must be explicitly told the version number of the software used to create a file. You can manually put "@version VERSIONID" string at the beginning of the file. The VERSIONID is built as MAJOR_REV*10000 + MINOR_REV*100 + PATCHLEVEL; so 40101 corresponds to xmgr-4.1.1. Projects saved with Xmgr-4.1.2 do NOT need the above, since they already have the version string in them. If you have no idea what version of Xmgr your file was created with, try some. In most cases, 40102 would do the trick. The above relates to the ASCII projects only. The old binary projects (saved with xmgr-4.0.*) are not automatically converted anymore. An input filter must be defined to make the conversion work on-the-fly. Add the following line to ~/.gracerc or the system-wide $GRACE_HOME/gracerc resource file: DEFINE IFILTER "grconvert %s -" MAGIC "00000031" See docs for more info on the I/O filters. Documentation on the script language is severely lacking still. Grace is WYSIWYG. Xmgr was not. Many changes required to achieve the WYSIWYG'ness led to the situation when graphs with objects carefully aligned under Xmgr may not look so under Grace. Grace tries its best to compensate for the differences, but sometimes you may have to adjust such graphs manually. A lot of symbol types (all except *real* symbols) are removed. "Location *" types can be replaced (with much higher comfort) by A(nnotating)values. "Impulse *", "Histogram *" and "Stair steps *" effects can be achieved using the connecting line parameters (Type, Drop lines). "Dot" symbol is removed as well; use the filled circle symbol of the zero size with no outline to get the same effect. Default page layout switched from free (allowing to resize canvas with mouse) to fixed. For the old behavior, put "PAGE LAYOUT FREE" in the Grace resource file or use the "-free" command line switch. The use of the "free" page layout is in general deprecated, though. System (shell) variables GR_* renamed to GRACE_* Smith plots don't work now. They'll be put back soon.