All operations in PROforma need some kind of entry point, just to let PROforma know which device has to be used, what parameters are currently valid, how big the drawing board is etc. To prevent the client (that is the user, or the application which wants to use PROforma) from having to pass these details with every command, with all possibilities of mistakes, these parameters are combined into a general, internal structure for PROforma. This structure is a 'graphics state' or 'Gstate'. A gstate contains information about :
A driver is a set of characteristics and routines which describe the behaviour of a certain output device (like a printer, or the screen). This usually includes details as size, resolution, available colours... On the other hand you can probably attache your printer both to a serial port, or a parallel port, or maybe you just want your image to to output to a file. Therefore, you always have to specify the driver (how to draw), and a device (where to draw) when you allocate a gstate.
PROforma acually works with three kinds of drivers, and one of these has two variants. The most important kind is a printer driver, which is used to actually make everything visible (create the output). A variant of this is a screen driver. This similar to a printer driver with as only difference that the output is produced by your monitor instead of your printer. (In this manual the term printer driver always includes the screen drivers, and the word page can be replaced by screen when a screen driver is used).
Another type of driver is a bitmap driver, which is used by PROforma to draw in a buffer which is later copied to the actual output device.
Picture drivers are the third and last kind of drivers. They are used to display bitmapped pictures in PROforma. They are a separate kind of driver because there are so many graphics formats in the world.
In this manual, when the general term driver is used, without specifying which kind of driver, it normally means a printer driver.
On devices : we strongly recommend the use of the parallel printer port and not the serial port. Serial ports are extremely slow and the amount of data which has to be sent to a printer can be huge. Of course we try to send as little data as possible, but not too many printers can handle compressed data. You should also be aware that serial to parallel converters do NOT speed the transfer of data up. The serial port can handle a certain speed and not more. For instance try sending an A4 page of 300 dpi data on a 9600 baud serial port (standard). This A4 page would need about 966k of data and this would take at least 13 minutes without control bits or correction of control bits (and without handshaking). In short, it will take MORE than 13 minutes to send this data. Luckily, PROforma will normally send less than 966k.
There are actually two meanings for this term, a device interpretation and a graphical interpretation.
A move (to define the origin of the subpath) followed by a sequence of path segments. A subpath can be open, or closed.
A path segment is either a line or a bezier curve. Circular arcs are converted to bezier path segments.
Bƒzier is a French mathematician who works for Renault and who "invented" a description/display method for curves based on Bernstein polynomials.
In PROforma we only use cubic bezier curves. That is curves which
consist of four points: the two endpoints (which are on the curve), and
two controlpoints (which are off the curve).
A clipping path is a special path which is not actually drawn, but
which is used as a mask for all drawing operation (except text when
the cache is used, see later). So the path itself is not drawn, but
instead only the places which would be coloured by drawing the path are
candidates for all future drawings until the clipping path is cleared.
This is a structure (actually a matrix), which explains how the
coordinates which are passed to PROforma will be transformed to default
user space.
User space is the coordinate system which is used to tell PROforma where and how to display path or text objects. The user space is converted into default user space by PROforma. This user space divides an inch in 72 equal parts, the axisses are horizontal (x) and vertical (y). The origin is at the top left, and the axisses extend right and down. The unit of 1/72 inch is called a point (pt). Note that a point can be defined slightly different depending on the source: some say there are 72.27 points in an inch, others say 72.307 points per inch.
Please note that PROforma allows to scale the default user space. This would allow the user to specify all coordinates in inches, or centimetres,...
Internally, PROforma transforms all coordinates from user space to device space. This resembles the position of the picture elements (pixels) of the device. Thus PROforma can decide which pixels to turn on or off.
The current point is very important when building a path. All path construction commands start at the current point, and set the current point to their endpoint.
It is also the start position on the baseline for text, and set to the end of the text. And it is also the position where a bitmap can be placed.
However, the current point is not always stable. For instance, the current point can not handle changes in the CTM. To avoid this kind of problems, see "PROforma sessions."
PROforma has a special view on how things have to be visualised on the chosen device. For starters there is the "page." This entity contains all path and text objects which have to be drawn. The actual image of the object depends on the CTM.
On the other hand, the page has to be visualised on the chosen device. Two things are important for this, the PageBbox which gives the origin and size (on the device) where the page (or part of) will be visualised. Which part of the page will be shown is determined by the PageOrigin, which is the coordinate (in default user space) of the point in the top-left corner of the PageBbox.
Especially for writing such things as window manager which uses
PROforma, the concept of a subwindow is introduced. The concept is
quite similar to a pagebbox except that a pagebbox is used to redraw
part of something bigger (e.g. in interactive applications), and a
subwindow is used to draw an independent part of the screen. If the
concept of a subwindow would not exist in PROforma, you would have to
open a Gstate for each part of the window where you need to draw.
Subwindows allow you to reduce a lot of the overhead by using one
Gstate for lots of smaller parts in a window.
Collection of graphical shapes, which can usually be combined to give readable text. The font files currently have a lot of similarity with the Adobe Type I font format (slightly adopted for easier access, which also makes them a bit shorter). However this may change in future if we choose to add a different hinting scheme (as the hinting used in type I files is quite obscure, and our current implementation quite unsatisfactory).
Fonts are handled quite efficiently. Each font will only be in memory once. Clients have to state which font they want to use (load), or no longer want to use (unload). Fonts are always referenced by their name. The name of the font and where to find it are stored in the "fontmap." The fontmap is read when PROforma is loaded. If a font is not in the fontmap, then it can't be used.
PROforma automatically releases a font when there are no gstates which have loaded it. Special routines are included to make sure this is always true (even when a job is force removed). When a font is loaded it is placed in the "fontlist" for that gstate.
Normally, fonts are loaded when they are first requested to be usable
by a gstate, and they will be discarded when the font is no longer in
use by any gstate.
However, PROforma also contains the concept of a resident font. A
resident font remains loaded from when it is specified until PROforma
is removed (or a reset). A resident font is always available by all
gstates, they don't have to say that they are going to use that font.
It is most practical when a user often uses the same fonts. They are
then always immediately accessible.
PROforma always needs at least one resident font, which is called the builtin font (the first resident font). This font has a special purpose as it will alwys be used when no ther font is selected. It is also intended that you should use a complete font for the builtin. When PROforma displays a character, it will get the shape from the current font. However, it is quite possible that the current font does not contain a shape for the requested character. In that case, PROforma will try to get the shape from the builtin font.
PROforma always keeps a table of all known fonts. This table is used to map a fontname to a fontfile. If a client tries to access a font which is not in the fontmap, then an error is returned.
The fontmap can not change after PROforma has been loaded (except by removing the PROforma job and loading it again, alas this also removes all clients of PROforma).
Naturally, the fontmap can be examined to find out which fonts can be loaded (if the fontfile is available or fonts is already loaded of course).
Each gstate also keeps a list of the fonts which it can already access. A gstate can only access fonts which are actually loaded. Therefore, when the client request to load a font, it is added to the fontlist of the gstate. The fontlist can be examined to find out which fonts can already be used by a gstate.
To increase the drawing speed of text, often used characters are also kept in an internal format which can be displayed much faster than the standard representation on the font. This is called the font cache. There are two limitations imposed by the font cache. The font cache is not capable to display fonts with clipping. Only characters which are not slanted or rotated (so only scaled) can be handled by the font cache. This actually means that some fonts can never be cached (fonts which are internally slanted or rotated). The font cache is also not used for the characters which are partly invisible.
Because the font cache has a limited size, a replacement algorithm must be used. In the case of PROforma, we make sure that only the least recently used characters are removed from the font cache. PROforma makes sure that the capacity of the font cache is not reduced because of fragmentation.
Unfortunately, the font cache doesn't use a magic trick. Although a cached characters draw at least four times faster than a character which was not cached, you can only gain speed if the character which is cached is used again before it is removed. So if you now in advance that a certain character will only be displayed once, switch off the cache ! This should be done because actually placing a character in the font cache can be hard work !
Because typography uses many characters, PROforma uses a special extended character set, which contains much more characters then the standard character set which is supported by the operating system.
All character strings which are used to display text use an extended
character set, unicode. In unicode all characters are a word long (two
bytes instead of one).
Actually unicode is a character encoding, while PROforma needs a glyph
encoding.This means that some things are not supported by unicode which
PROforma needs and vice versa (e.g. ligatures). So PROforma uses only
a subset with some extra characters (the ff and fi ligatures). The
characters which PROforma considers as "supported" all have a proper
character name (which can be found in the PFCharNameTable).
To increase the cohesion of a combination of characters, it is often
not enough to position all characters side by side, put some character
combinations have to be put closer together (or further apart) to make
sure that they are visually equally spaced (same amount of whitespace
between characters). This process is called kerning. A typical example
is the word "AWAY."
Another typesetting feature is that some characters sequences like "ff",
"fi", "fl", "ffi", "ffl" should be replaced by special characters which
look better. Ligatures are supported in the Extended Character Set
and can therefore be used by the client.
Sometimes it may be interesting to add some extra space between all characters. This is called tracking, and can be particularly useful for logo's.
PROforma does all drawing inside a buffer. Only when the PFPageShow command is called, is the buffer actually displayed to the user.
However, for interactive use, this is not an ideal situation. In fact, users find it very annoying to wait for the drawing to complete, and time only passes very slowly when you are waiting. Therefore, PROforma (and specifically the screen driver) allows you to change the display mode from the default behaviour, to an update mode where the screen is continually refreshed with the current state of the drawing buffer. This refreshing is cancelled when the PFPageShow command is called.