Discussion:
Ideas of a new version of PostScript (called "Computer PostScript")
(too old to reply)
n***@zzo38computer.org.invalid
2024-03-07 04:59:18 UTC
Permalink
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.
Lawrence D'Oliveiro
2024-03-07 05:29:18 UTC
Permalink
Post by n***@zzo38computer.org.invalid
It is based on level 3 PostScript, and
some of the extensions provided by Ghostscript, and some of my own new
stuff.
Get rid of the whole graphics API. It doesn’t serve any useful purpose any
more.

NeWS was obsoleted by Display PostScript, and even Display PostScript
isn’t worth using now.
n***@zzo38computer.org.invalid
2024-03-07 23:05:07 UTC
Permalink
Get rid of the whole graphics API. It doesn't serve any useful purpose any
more.
I still use it sometimes, although I also write programs in PostScript that do
not use the graphics, too (PostScript is useful for programs with and without
graphics). I still think it is good, although some improvements could be made,
which I mentioned in my message.

If you do not use the graphics API, how do you think would be improvement, if
you want to use graphics, then?
NeWS was obsoleted by Display PostScript, and even Display PostScript
isn't worth using now.
There are a few good ideas, though, which is why I have mentioned some of them.
--
Don't laugh at the moon when it is day time in France.
Lawrence D'Oliveiro
2024-03-07 23:38:47 UTC
Permalink
Post by n***@zzo38computer.org.invalid
(PostScript is useful for programs
with and without graphics). I still think it is good, although some
improvements could be made, which I mentioned in my message.
I mentioned some other improvements in mine.
Post by n***@zzo38computer.org.invalid
If you do not use the graphics API, how do you think would be
improvement, if you want to use graphics, then?
Use something more modern, like Cairo. While that was clearly inspired by
PostScript, it has gone beyond it to include features good for interactive
graphics and Unicode-based text rendering, like operators, alpha channels
and glyphs.

Cairo has been quite popular: the Web folks used Cairo as the basis for
their “Canvas 2D” API, and even the C++ folks have been looking at
incorporating some form of it as a standard graphics API for their run-
time library.
n***@zzo38computer.org.invalid
2024-03-08 20:00:11 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by n***@zzo38computer.org.invalid
If you do not use the graphics API, how do you think would be
improvement, if you want to use graphics, then?
Use something more modern, like Cairo. While that was clearly inspired by
PostScript, it has gone beyond it to include features good for interactive
graphics and Unicode-based text rendering, like operators, alpha channels
and glyphs.
There does seem some features of PostScript not implemented in Cairo, such
as separations, and CMYK, and some other features. (As far as I can tell,
the only colours implemented in Cairo are RGBA.)

(I also wanted compatibility with most existing PostScript graphics code,
including non-Unicode text; but also to add some new features such as alpha
transparency, combining modes, etc. Some of these things could be done in
ways similar than Cairo e.g. adding the operators like Cairo has.)

(So, I think that enhancing the existing PostScript graphics API would be
superior than using Cairo, in my opinion.)
--
Don't laugh at the moon when it is day time in France.
Lawrence D'Oliveiro
2024-03-08 20:53:00 UTC
Permalink
Post by n***@zzo38computer.org.invalid
There does seem some features of PostScript not implemented in Cairo,
such as separations, and CMYK, and some other features. (As far as I can
tell, the only colours implemented in Cairo are RGBA.)
That’s because CMYK is something specific to offset printers. Let the
offset printer operators worry about its quirks: they are the ones paid to
do it.

There are non-RGB colour spaces that are worth supporting, like HSV and
HLS. My Python wrapper for Cairo <https://gitlab.com/ldo/qahirah> lets you
freely interconvert between these spaces, even though the underlying Cairo
API only ever sees RGBA. I even let you use X11 colour names.
Post by n***@zzo38computer.org.invalid
(I also wanted compatibility with most existing PostScript graphics
code ...
Ah. Waste of time. Leave that in the museum, too. By all means extract the
algorithms, just leave the actual code behind.
David Newall
2024-03-26 05:20:51 UTC
Permalink
Post by Lawrence D'Oliveiro
Get rid of the whole graphics API. It doesn’t serve any useful purpose any
more.
PS is a great language but has no obvious use-case that doesn't include
rendering text and graphics.
n***@zzo38computer.org.invalid
2024-03-26 06:10:37 UTC
Permalink
Post by David Newall
PS is a great language but has no obvious use-case that doesn't include
rendering text and graphics.
I think it is good whether or not you are rendering text and graphics.

Half of the programs I write in PostScript don't use graphical output.
(And one (a Z-machine interpreter) which does produce graphical output
but is not its primary use.)

(Note that by "graphical output" I am including rendering text on a page,
as well as graphics on a page. Some programs don't render anything on a
page, such as those that only deal with files or standard I/O.)
--
Don't laugh at the moon when it is day time in France.
Lawrence D'Oliveiro
2024-03-26 06:20:37 UTC
Permalink
Post by David Newall
Post by Lawrence D'Oliveiro
Get rid of the whole graphics API. It doesn’t serve any useful purpose
any more.
PS is a great language but has no obvious use-case that doesn't include
rendering text and graphics.
There are better graphics APIs now, better suited to, for example,
interactive on-screen graphics. PostScript, even Display PostScript, never
progressed beyond the marks-on-paper model.
Richard L. Hamilton
2024-05-25 16:07:45 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by David Newall
Post by Lawrence D'Oliveiro
Get rid of the whole graphics API. It doesn’t serve any useful purpose
any more.
PS is a great language but has no obvious use-case that doesn't include
rendering text and graphics.
There are better graphics APIs now, better suited to, for example,
interactive on-screen graphics. PostScript, even Display PostScript, never
progressed beyond the marks-on-paper model.
Back in the '80s, Sun had a Postscript based windowing system called NeWS.
NOT Display Postscript, but a program could send Postscript code to the
display server that would not only render something but allow interacting.
The entire GUI could run on the server and just send the results back to the
program.

Performance wasn't great, but what was a problem then probably wouldn't be
now unless you wanted to do high-end gaming on it.
Lawrence D'Oliveiro
2024-05-25 22:31:14 UTC
Permalink
Post by Richard L. Hamilton
Back in the '80s, Sun had a Postscript based windowing system called
NeWS. NOT Display Postscript ...
Display PostScript did come out shortly afterwards, with entirely
different extensions for interactive use.

Also X11 came out and was almost unanimously adopted as the standard GUI
engine by the Unix community. Including Sun. It ran a hybrid X11-NeWS
server for a while, before giving up on NeWS altogether. (NeWS fans were
not happy.)
Post by Richard L. Hamilton
... but a program could send Postscript code
to the display server that would not only render something but allow
interacting. The entire GUI could run on the server and just send the
results back to the program.
Performance wasn't great, but what was a problem then probably wouldn't
be now unless you wanted to do high-end gaming on it.
It wasn’t just a performance issue, it would also have been the trickiness
of synchronizing concurrent processes in the CPU versus the GUI server
while avoiding problems like deadlocks etc.

Mulithreading was being used for just about everything in the 1990s, until
it was realized that multithreaded GUIs were more trouble than they were
worth.

Lawrence D'Oliveiro
2024-03-21 07:31:57 UTC
Permalink
To give an example of something that can ease the pains of stack-oriented
programming, let me propose something I’ve been calling “</” and “/>”, or
“stackbegin” and “stackend”, to support the use of multiple nested operand
stacks.

Stackbegin pops a single integer off the stack:

n </

It then pops the next n operands off the stack, and transfers them as the
initial contents of a new operand stack. This becomes the current operand
stack, and the previous operand stack is no longer accessible.

Stackend reverses the process:

n />

It pops n off the stack, and asserts that there are exactly n operands
remaining on the stack; these get transferred to the previous operand
stack, which becomes the current operand stack while this one (now empty)
is discarded.

This allows you to constrain sections of code to operating on a more
restricted set of operands, without accidentally interfering with other
operands that might be underneath, or leaving junk behind.

I also propose that “;” be an operator that asserts that the (current)
operand stack is empty. E.g.

8 8 mul = ;

pops two operands, multiplies them, prints the answer, and then verifies
that the stack is now empty.
Bozo User
2024-03-24 20:45:37 UTC
Permalink
Post by n***@zzo38computer.org.invalid
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.)
Unicode today should be almost mandatory.
David Newall
2024-03-26 05:19:14 UTC
Permalink
Post by Bozo User
Unicode today should be almost mandatory.
See https://davidnewall.com/software/utf8show/ for my work on UTF8
for PS.
Loading...