|
|
|
[rs]X’ps: exec code’ |
| |
This executes the arbitrary PostScript commands in
code.
The PostScript currentpoint will be set to the position of the
[rs]X command before executing
code.
The origin will be at the top left corner of the page,
and y~coordinates will increase down the page.
A procedure~
u will be defined that converts groff units
to the coordinate system in effect.
For example,
|
|
|
|
.nr x 1i
[rs]X’ps: exec [rs]nx u 0 rlineto stroke’
|
|
|
|
|
will draw a horizontal line one inch long.
code may make changes to the graphics state,
but any changes will persist only to the
end of the page.
A dictionary containing the definitions specified by the
def and
mdef will be on top of the dictionary stack.
If your code adds definitions to this dictionary,
you should allocate space for them using
[rs]X’ps mdef n’.
Any definitions will persist only until the end of the page.
If you use the
[rs]Y escape sequence with an argument that names a macro,
code can extend over multiple lines.
For example,
|
|
|
|
.nr x 1i
.de y
ps: exec
[rs]nx u 0 rlineto
stroke
..
[rs]Yy
|
|
is another way to draw a horizontal line one inch long.
|
|
[rs]X’ps: file name’ |
| |
This is the same as the
exec command except that the PostScript code is read from file
name.
|
|
[rs]X’ps: def code’ |
| |
Place a PostScript definition contained in
code in the prologue.
There should be at most one definition per
[rs]X command.
Long definitions can be split over several
[rs]X commands;
all the
code arguments are simply joined together separated by newlines.
The definitions are placed in a dictionary which is automatically
pushed on the dictionary stack when an
exec command is executed.
If you use the
[rs]Y escape sequence with an argument that names a macro,
code can extend over multiple lines.
|
|
[rs]X’ps: mdef n code’ |
| |
Like
def, except that
code may contain up to
n~ definitions.
grops needs to know how many definitions
code contains
so that it can create an appropriately sized PostScript dictionary
to contain them.
|
|
[rs]X’ps: import file llx lly urx ury width [ height ]’ |
| |
Import a PostScript graphic from
file.
The arguments
llx,
lly,
urx, and
ury give the bounding box of the graphic in the default PostScript
coordinate system; they should all be integers;
llx and
lly are the x and y~coordinates of the lower left
corner of the graphic;
urx and
ury are the x and y~coordinates of the upper right corner of the graphic;
width and
height are integers that give the desired width and height in groff
units of the graphic.
The graphic will be scaled so that it has this width and height
and translated so that the lower left corner of the graphic is
located at the position associated with
[rs]X command.
If the height argument is omitted it will be scaled uniformly in the
x and y~directions so that it has the specified width.
Note that the contents of the
[rs]X command are not interpreted by
troff; so vertical space for the graphic is not automatically added,
and the
width and
height arguments are not allowed to have attached scaling indicators.
If the PostScript file complies with the Adobe Document Structuring
Conventions and contains a
%%BoundingBox comment, then the bounding box can be automatically
extracted from within groff by using the
psbb request.
The
-mps macros (which are automatically loaded when
grops is run by the groff command) include a
PSPIC macro which allows a picture to be easily imported.
This has the format
|
|
|
|
.PSPIC [-L|-R|-I n] file [width [height]]
|
|
file is the name of the file containing the illustration;
width and
height give the desired width and height of the graphic.
The
width and
height arguments may have scaling indicators attached;
the default scaling indicator is~
i.
This macro will scale the graphic uniformly
in the x and y~directions so that it is no more than
width wide
and
height high.
By default, the graphic will be horizontally centered.
The
-L and
-R cause the graphic to be left-aligned and right-aligned
respectively.
The
-I option causes the graphic to be indented by~
n.
|
|
[rs]X’ps: invis’ |
| |
|
|
[rs]X’ps: endinvis’ |
| |
No output will be generated for text and drawing commands
that are bracketed with these
[rs]X commands.
These commands are intended for use when output from
troff will be previewed before being processed with
grops; if the previewer is unable to display certain characters
or other constructs, then other substitute characters or constructs
can be used for previewing by bracketing them with these
[rs]X commands.
For example,
gxditview is not able to display a proper
[rs](em character because the standard X11 fonts do not provide it;
this problem can be overcome by executing the following
request
|
|
|
|
.char [rs](em [rs]X’ps: invis’[rs]
[rs]Z’[rs]v’-.25m’[rs]h’.05m’[rs]D’l .9m 0’[rs]h’.05m’’[rs]
[rs]X’ps: endinvis’[rs](em
|
|
In this case,
gxditview will be unable to display the
[rs](em character and will draw the line,
whereas
grops will print the
[rs](em character
and ignore the line.
|
|
The input to
grops must be in the format output by
troff(1).
This is described in
groff_out(5).
In addition the device and font description files for the device used
must meet certain requirements.
The device and font description files supplied for
ps device meet all these requirements.
afmtodit(1)
can be used to create font files from AFM files.
The resolution must be an integer multiple of~72 times the
sizescale.
The
ps device uses a resolution of 72000 and a sizescale of 1000.
The device description file should contain a command
|
|
|
paperlength n
|
|
which says that output should be generated which is suitable for
printing on a page whose length is
n~ machine units.
Common values are 792000 for letter paper and 841890 for paper in A4 format.
Alternatively, it can contain
|
|
|
papersize string
|
|
to specify a paper size; see
groff_font(5)
for more information.
Each font description file must contain a command
|
|
|
internalname psname
|
|
which says that the PostScript name of the font is
psname.
It may also contain a command
|
|
|
encoding enc_file
|
|
which says that
the PostScript font should be reencoded using the encoding described in
enc_file; this file should consist of a sequence of lines of the form:
|
|
|
pschar code
|
|
where
pschar is the PostScript name of the character,
and
code is its position in the encoding expressed as a decimal integer.
Lines starting with
# and blank lines are ignored.
The code for each character given in the font file must correspond
to the code for the character in encoding file, or to the code in the default
encoding for the font if the PostScript font is not to be reencoded.
This code can be used with the
[rs]N escape sequence in
troff to select the character,
even if the character does not have a groff name.
Every character in the font file must exist in the PostScript font, and
the widths given in the font file must match the widths used
in the PostScript font.
grops will assume that a character with a groff name of
space is blank (makes no marks on the page);
it can make use of such a character to generate more efficient and
compact PostScript output.
|
|
grops can automatically include the downloadable fonts necessary
to print the document.
Any downloadable fonts which should, when required, be included by
grops must be listed in the file
/usr/share/groff/1.18.1.1/font/devps/download; this should consist of lines of the form
|
|
|
font filename
|
|
where
font is the PostScript name of the font,
and
filename is the name of the file containing the font;
lines beginning with
# and blank lines are ignored;
fields may be separated by tabs or spaces;
filename will be searched for using the same mechanism that is used
for groff font metric files.
The
download file itself will also be searched for using this mechanism;
currently, only the first found file in the font path is used.
|
|
If the file containing a downloadable font or imported document
conforms to the Adobe Document Structuring Conventions,
then
grops will interpret any comments in the files sufficiently to ensure that its
own output is conforming.
It will also supply any needed font resources that are listed in the
download file
as well as any needed file resources.
It is also able to handle inter-resource dependencies.
For example, suppose that you have a downloadable font called Garamond,
and also a downloadable font called Garamond-Outline
which depends on Garamond
(typically it would be defined to copy Garamond’s font dictionary,
and change the PaintType),
then it is necessary for Garamond to be appear before Garamond-Outline
in the PostScript document.
grops will handle this automatically
provided that the downloadable font file for Garamond-Outline
indicates its dependence on Garamond by means of
the Document Structuring Conventions,
for example by beginning with the following lines
|
|
|
%!PS-Adobe-3.0 Resource-Font
%%DocumentNeededResources: font Garamond
%%EndComments
%%IncludeResource: font Garamond
|
|
In this case both Garamond and Garamond-Outline would need to be listed
in the