ResToImage in Java
There is an alternative implementation of RES 0.3, called
ResToImage, written in Java, as part of
There are a few differences between the
options of res2image and
those of ResToImage, summarized below.
For superimposed glyphs, and for shading across glyphs,
res2image takes the minima of the
RGB values of the pixels (i.e. maximally dark). However, ResToImage
lets the last written glyph or stroke dominate the color of a pixel. (This is
preferable for generation of, e.g., Postscript and PDF, when glyphs and curves
are stored rather than pixels.)
- A new experimental option is -chunks. This is
mutually exclusive with -basic, -repeat,
-multi and -echo.
The first line of the output consists of the maximum number of groups
in which the hieroglyphic can be broken up. Then follows for each
such group the image name followed by the four sizes of the margins,
followed by the distance between the current group and the next
(0 if there is no next group).
The last line contains a header and/or switch for values that
hold at the end of the encoding and that differ from the defaults.
An image name is the base name, followed by a number starting from 1.
With -chunks, the option -length is ignored.
- Not implemented in ResToImage are
-bilevel and -palette.
- Not implemented in ResToImage is -ps.
Option -eps leads to output without pixelization. Regrettably
this also leads to increased storage demands.
Additional formats implemented in ResToImage are JPEG and PNG, with the
options -jpg and -png.
These options lead to file extensions
.jpg and .png, respectively.
For none of the formats is it checked whether colors actually
occur within the encoding.
That is, with option -color,
images are always written as color images rather than grayscale,
even if no colors are used within the encoding.
Not implemented in ResToImage is -dpi device_resolution.
Instead there is the option -dpp device_resolution.
This specifies the device resolution, in dots per point;
device_resolution is a positive integer.
The default is 1.
- For option -f fonts_file, the default is the file
fonts.txt in the directory where the fonts are stored
./nederhof/fonts relative to the root directory where the Java code is stored).
The possibilities offered by -pipe command
are more restricted, and especially the operators |,
> and < cannot be used. The best solution seems to
let the command be a call of
a one-argument script that reads an image from standard input.
For example, to produce a (pixelized) image in
Postscript, create an executable script myconversion containing just one
pnmtops <&0 -noturn > $1.ps
java nederhof.res.ResToImage -pnm -pipe "./myconversion %s"
making use of external program pnmtops to convert
PNM to Postscript.
ResToImage can only handle encoding_unicode, not