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.)

On Wed, 06 Mar 2024 20:59:18 -0800, news wrote:

> 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.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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.

On Thu, 07 Mar 2024 15:05:07 -0800, news wrote:

> (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.

> 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.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> > 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.

On Fri, 08 Mar 2024 12:00:11 -0800, news wrote:

> 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.

> (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.

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.

On 2024-03-07, news@zzo38computer.org.invalid <news@zzo38computer.org.invalid> wrote:
> 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.)
>

On 25/3/24 07:45, Bozo User wrote:
> Unicode today should be almost mandatory.

See https://davidnewall.com/software/utf8show/ for my work on UTF8
for PS.

On 7/3/24 16:29, Lawrence D'Oliveiro wrote:
> 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.

David Newall <ghostscript@davidnewall.com> wrote:
> 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.

On Tue, 26 Mar 2024 16:20:51 +1100, David Newall wrote:

> On 7/3/24 16:29, Lawrence D'Oliveiro wrote:
>
>> 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.