next up previous contents
Next: 7. Compiling and Porting Up: Toolkit for Conceptual Modeling Previous: 5. TCM Class Hierarchy

Subsections

6. Output Files

6.1 PostScript output

This is a short description of the structure of the PostScript files that is generated by the current version of TCM. This is not a lesson in programming PostScript nor a detailed explanation of each possible PostScript expression that could be generated by TCM. Instead, you are referred to the official documentation like [6,5].

6.1.1 Plain PostScript

The PostScript output files for a TCM document have the following structure.

6.1.1.1 Header

The first part of the plain PostScript output consists of the following header:
%!PS-Adobe-1.0
%%Title: <name of document>
%%Creator: <tool+version>
%%CreationDate: <current date>
%%For: <login>
%%DocumentFonts: (atend)
%%Pages: (atend)
%%BoundingBox: (atend)
%%EndComments
/ISOLatin1Encoding[
      ...
] def
EndProlog

Lines that start with %% or %! are PostScript structuring commands. The generated files conform to the PS-Adobe 1.0 file structuring conventions. (atend) means that the value is determined in the rest of the program. The ISOLatin1Encoding definition (whose body is not printed here to save space) is necessary to make sure that the entire ISO Latin-1 character set can be displayed.

6.1.1.2 Pages

Each page starts with a page setup followed by the page contents. Example page setup:

%%Page: 1 2
12.8976 9.49604 translate
0.867470 0.867470 scale
0 948.736111 translate
1 -1 scale
1.000000 1.000000 scale
0.750000 setlinewidth
%%BeginPageSetup
gsave
-0.000000 -0.000000 translate
%%EndPageSetup
The first line gives the current page label (1 in this example) and the total number of pages (2). The next translate line moves the coordinate system to the drawable paper area. Then the scale line scales X coordinates to PostScript points. The other translate and scale lines change from X to the PostScript coordinate system (in portrait mode and with scale factor 1.0). When the page would be written in LandScape and with scale factor 1.5, those three lines would be:
90 rotate
1 -1 scale
1.5 1.5 scale

The setlinewidth line sets the width of the line a bit smaller than the default, which is a bit too fat in comparison with the Xlib lines. The lines between BeginPageSetup and EndPageSetup move the page (like it is visible in the X window) that is going be written to the position of the first page (in this case the translation is zero because the example shows the first page).

After that, the lines of the current page are written in rather ordinary PostScript prose (with newpath, moveto, rlineto, closepath and stroke commands).

Strings are drawn in the following fashion: First the font is loaded when that is not already done, e.g.:

dup length dict begin
   {1 index /FID ne {def} {pop pop} ifelse} forall
   /Encoding ISOLatin1Encoding def
   currentdict
end
/Helvetica-ISOLatin1Encoding exch definefont pop
This loads the font family (in our case Helvetica ISO Latin1). Then the string is positioned and drawn, e.g:
/Helvetica-ISOLatin1Encoding findfont
10 scalefont setfont
(foobar) stringwidth
pop 2 div neg
120 add 144 moveto
gsave
1 -1 scale
(foobar) show
grestore
The above lines draw the string foobar in the just loaded font, centered at position (120,144) with point size 10. Each PostScript output page ends with:
grestore
showpage
%%PageTrailer

End finally the PostScript output ends with:

%%Trailer
%%EOF

6.1.2 Encapsulated PostScript

The first part of the EPS output consists of the following header.

%!PS-Adobe-3.0 EPSF-3.0
%%Title: <document name>
%%Creator: <tool+version>
%%CreationDate: <current date>
%%For: <login>
%%DocumentFonts: (atend)
%%Pages: 0
%%BoundingBox: llx lly urx ury
%%EndComments
/ISOLatin1Encoding[
] def
The four numbers (llx lly urx ury) are the top left and bottom right coordinates of the bounding box, i.e. the square area occupied by the drawing. After the header the font is loaded, in the same way as in plain PostScript. EPS does not have separate pages and hence does not need page setup lines. The following lines are generated to change from X coordinates to EPS coordinates:

0.867470 0.867470 scale
0 85 2 mul 117 add 0.867470 div translate
1 -1 scale
%%EndProlog

0.867470 is the (fixed) factor of X coordinates/PS coordinates. As a remark, I forgot the exact meaning of the second line, but is works in any case. After that the entire drawing is written as PostScript, the same way as it is done with plain PostScript (but without page setups). The output ends with the same two lines as plain PostScript.

6.1.3 PSGrafport

All PostScript generation is hidden in the PSGrafport class. It contains the functions that write headers and page setup lines to the PostScript output file and for each Grafport function it contains a counterpart that writes a piece of PostScript. For example Grafport has a virtual function DrawRectangle(int x, int y, int width, int height) that draws a rectangle to the Grafport. XGrafport implements this function as:

 
XDrawRectangle(display, window, xorGC, x, y, wd, ht);
I.e. it draws a rectangle on an X window. Whereas PSGrafport implements this function with:
 
fprintf(fd, "newpath\n");
fprintf(fd, "%d %d moveto\n", x, y);
fprintf(fd, "%d 0  rlineto\n", wd);
fprintf(fd, "0 %d  rlineto\n", ht);
fprintf(fd, "-%d 0 rlineto\n", wd);
fprintf(fd, "closepath\n");
fprintf(fd, "stroke\n");
I.e. it writes a PostScript fragment to the file that would result into the printing of a rectangle.

To add another output format to TCM, you probably need only to make another specialization of Grafport and implement each Grafport function in that class to write a piece of output in that format. For instance, for writing the Fig output (Produced by Xfig) we implemented a FigGrafport that writes for every Draw-functions a part of Fig-format to file.

6.2 TCM file format

The TCM file format of the current version is described in full detail in appendix B of the User's guide.


next up previous contents
Next: 7. Compiling and Porting Up: Toolkit for Conceptual Modeling Previous: 5. TCM Class Hierarchy
Henk van de Zandschulp
2003-01-07