Ideas of a new version of PostScript (called "Computer PostScript")
From
news@zzo38computer.org.invalid@21:1/5 to
All on Wed Mar 6 20:59:18 2024
I had ideas how to improve PostScript programming language, making a new version, which can be called "Computer PostScript" since it is meant for computers rather than printers. It is based on level 3 PostScript, and some
of the extensions provided by Ghostscript, and some of my own new stuff.
* Add append operator of NeWS, which concatenates two strings or arrays.
Also add arrayop operator of NeWS, which is receiving a procedure and two arrays (or strings) of equal length and produces a single array from
combining the corresponding elements of each one with the same index by
the specified procedure. (This could also be worked with dictionaries too,
I suppose; if the dictionaries have the same keys.)
* Add straccum and strfinish operators. (I have implemented these in
PostScript itself, but may be more efficient as native operators.) The
straccum operator will make a writable file object, which remembers
anything written to it; strfinish takes the file object from straccum on
the stack, and closes it and then the output is a new string object that contains all data that was written to the file before it was closed.
* Remove the /PageCount system parameter, which is only relevant for
printers and not for computers. However, the /PageCount page device
parameter of Ghostscript is included.
* The job server is also not needed so it can be removed, too.
* Possibility of having alpha transparency, in the current colour and in
raster images. There might also be operators for adding layers to a layer stack, and then you can combine modes when popping the layer stack. (Some
page devices might not support alpha transparency in the output, and some vector devices might not allow alpha transparency at all.)
* The ARGUMENTS array of Ghostscript is included. In "program mode" (which
is the default mode), this is always used for command-line arguments. (If
the system's character encoding is a superset of ASCII then they should be passed unchanged to the PostScript program. This is required to be the same character encoding used for file names, but is allowed to be any ASCII
based encoding as long as it satisfies this requirement.)
* Some operators that require an existing allocation can now automatically allocate a string or array if you pass null. For example: copy, readline,
cvs, and some others. Some, such as readstring, might accept a number in
place of a string to automatic allocation.
* Add a built-in procedure called #! which skips the rest of the current
line of the input file. (Store this is systemdict.)
* An option (perhaps a user parameter) to display error messages on stderr while not redirecting any other output (e.g. print = == etc) to stderr. (Perhaps it should be the default setting, or even the only setting.)
* Type 4 function dictionaries, like PDF.
* Possibility to set a font list and character encoding separately. (If
you use the existing way to set the font, it is set to a font list
containing a single font, and the encoding of that font.)
* Allow glyphshow to use numbers even for fonts that are not CID fonts
(names can still be used, too).
* Add a page device parameter that can be retrieved and used when setting
it to preserve the existing device state for that specific page device, including not erasing the page. This parameter is mutually exclusive with
some of the other parameters, though.
* Similarly than the above, you can save the graphics state with a page
device, enter a new one, and then when you go back, you can continue with
the existing page. (See below for why this is relevant.)
* Add a command to select a internal raster page device which stores the picture in a buffer which can then be read back after you pop that internal device off of the stack. This is similar than "makeimagedevice" command in Ghostscript, but I dislike some of the details of Ghostscript's working.
* Add a Environment resource category which allows reading and writing environment variables.
* Add the %pipe% device of Ghostscript, but without input buffering. (The
input buffering makes many things difficult. Ghostscript does not have this problem when reading from stdin, but %pipe% still has that problem.)
* The %pipe% device may also be opened in (r+) mode for two-way
communication with an external program, like in FreeBSD.
* Possibly some way to define animations.
* Make a C API for defining your own operators and for extending the
PostScript interpreter with dynamically linked C codes. This C API would
also be usable for defining page devices as well. For vector devices, you
can also access the glyph names and CIDs of text (or you can choose to
ignore text and just have the PostScript engine to convert them to the
shapes), and pdfmark can also be implemented by any page devices.
* A variant of Type 1 fonts but unencrypted.
* Make the "known" operator to work with strings and arrays as well as
with dictionaries. Also add "knownget" operator.
* Make the fileposition operator to work with non-positionable files
too in which case it tells the number of bytes read or written; with
seekable files it works like it already normally does.
* Add "kforall", "vforall", and "kvforall", usable with any types that
"forall" is usable with; they will give you only the keys, only values,
or both keys and values, respectively. (For dictionaries, forall is the
same as kvforall; for strings and arrays, forall is same as vforall.)
* Add a "unread" operator, similar than the "ungetc" function of C.
* I don't like the exception for storing local objects in systemdict,
so I would propose an alternative: You can store references to local
objects inside of global objects if those local objects were created
before the first time "save" is executed.
* The copypage operator works like level 2 PostScript, although it might
not be available for all devices on all implementations. (If it is not available, then it is an error when used in that way.)
* Colour management: Ghostscript uses colour management unless you set
the UseFastColor mode. I think it should not do that, and should just use direct colours normally. However, you can add a /ColorManagement page
device parameter; if 0 then there is no colour management, if 1 then there
is colour management if using managed colour spaces (such as ManagedRGB, ManagedCMYK, etc instead of DeviceRGB, etc) and you can set the rendering intent separately at different times, if 2 then the colour management is
done only during post processing, if 3 then it is like 1 but uses the
colour management in all colour spaces including Device colour spaces, and
4 means that colour management is applied afterward during postprocessing. (Some settings might be unavailable for some output devices. For most
output file formats, colour management should be disabled by default
(unlike Ghostscript), although it may be enabled by command-line argument
or within the PostScript program itself.) (The CIE-based colour spaces
remain available and are managed in the way that they are specified by
level 3 PostScript. Also, even if colour management is set to 0, such
things as transfer functions will still work (although they would normally
only be set for printer drivers and such things and not for most output
file formats); the /ColorManagement parameter only controls use of managed colour profiles, similar than /UseFastColor in Ghostscript.)
* Add a DeviceRaw colour space, allowing to access raw colour data of the specific output device (usually an integer or a string) (in some cases,
e.g. PDF, this might not be available).
* An extension of the PostScript binary object sequence format to support 64-bit integers, 64-bit floating point, and dictionaries.
* New filters: ExternalDecode and ExternalEncode, which use an external program. ExternalEncode will write anything written to the filter file to
the external program's stdin, and whatever the external program writes to
its stdout will be written to whatever the filter is writing to; the ExternalDecode is other way around.
* New filters named ByteTranslateEncode and ByteTranslateDecode, which
work like those in Ghostscript.
* Allow the dictionary for ASCII85Encode and ASCIIHexEncode to specify
where line breaking should occur (including none at all) and to be able
to suppress the final > or ~> when the filter is closed.
* Allow several encoding filters to specify values other than the default
that are permitted in decoding filters, such as UnitLength and LowBitFirst
for LZWEncode.
* Add a parameter for FlateDecode and FlateEncode to control whether or not
it should use a raw DEFLATE stream.
* New filters: Base64Decode and Base64Encode. You may specify the alphabet
to use, where line breaking should occur, and whether or not to add padding with equal signs.
* Allow defining new filters by adding resources.
* Some output file formats other than PDF might be able to use pdfmark too.
* The "run" operator should accept files as well as file names, like Ghostscript does; but, unlike Ghostscript, it should only interpret the
file as PostScript code. (Another operator could be made to load in a
separate execution context, and possibly to allow to specify other
document formats too.)
* Allow the alternative colour space of a Separation or DeviceN colour
space to be another special colour space (although only a single nesting
level is allowed in this way); therefore you can tell it to ignore an unavailable separation entirely (by specifying [/Separation /None] as the alternative colour space), or to simulate it with patterns.
* Add a "cvri" operator to read numbers according to a specified base,
without needing to prepend something like "16#".
* Add the arctangent function. Also, make trigonometry functions with
radians as well as with degrees.
* Built-in operators for dealing with strings and files as arrays of fixed-length integers (similar than typed arrays in JavaScript). (This
is useful for dealing with other file formats.)
* DSC is not used.
* Only the Courier font is mandatory; the others are optional. This font
will need to have the same metrics as the official Courier font, even if
it is actually a different font (as is the case in Ghostscript).
* Permissions to control parameters are no longer controlled by passwords.
Any input argument that needs a password is now ignored (and its type is
also ignored), and password entries in dictionaries are also ignored.
(There may be other restrictions on controlling them, e.g. the security features of the host system, but those are not controlled by PostScript.)
* The currentdevparams and setdevparams operators can be used on files
that are already open as well as on devices named by strings. (For example,
it might be used to control terminal settings, locking, etc.)
* An implementation may allow additional editing controls with %lineedit%
and %statementedit%.
* Add an operator to wait for multiple objects. This can be used in case
of connecting to multiple sockets or pipes at once, and with extensions
may be usable for other purposes too.
* A "cvop" operator to convert other objects (such as procedures) into
an operator that, when executed, will execute the other object.
* Idiom recognition is always disabled by default.
* A variant quit operator that allows specifying the exit code.
* Make a better way to access ligature/kerning data of fonts from within PostScript programs.
* You can use a UUID as a XUID by the first entry being 36#UUID and the
other four are each 32-bits of the UUID number.
* Add a font type which is metrics only and contains an identification of
the font for the output device. This is used for fonts that are built in
to the output device or that are not known at compile time. You cannot
use them with the image device, nor with PostScript operators such as
charpath. Only some devices will support this use. (For example, with a
X window output device, it can be used to represent X core fonts. It may
also be used with some printers that have built-in fonts.)
* Pen shapes, like in METAFONT.
* Allow circular and elliptical arcs to be stored directly in paths. This
is useful for some output formats, such as SVG.
Please tell me what are your opinions, and if you have other ideas too.
(I have many other ideas too, than only what I mentioned above. Maybe I
will write more, later, too.)
--
Don't laugh at the moon when it is day time in France.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)