PostScript to SVG

[jdaw1]

Wanted: some very tight SVG, brutally short and efficient, from PostScript. It can be done by Distilling to PDF, and then using the likes of www.cloudconvert.com/pdf-to-svg to change that to SVG.

It’s not bad. But it could be much tighter. E.g., via PDF changes arcs to Bézier, and so the SVG isn’t as tight as it could be. Going direct from PS also does this, so it might be internally transforming via PDF.

The natural way to proceed is to go back to native PostScript. Perhaps as follows:

• SvgCommandsDict begin
Necessary. Obviously an ‘end’ later ends.

• width height SvgSetViewBox
Sets bounding box.

• matrix SvgSetMatrix
All SVG commands will be output in this space. If currentmatrix element-wise-equals this, no transformations will be done. If not, points will be reverse transformed back to this.

• filename SvgFinish
Output accumulated SVG to named file.

SvgCommandsDict needs redefinitions of moveto, lineto, rlineto, curveto, rcurveto, closepath, arc, arcn, arct, arcto, clip, clipsave, cliprestore, gsave, grestore, fill, stroke, setlinewidth, setlinejoin, setlinecap, setdash, stroke, setrgbcolor, setgray, and maybe others. What these do is: their usual; store state data to a data object; sometimes grow an SVG text string.

Text is harder: are fonts set with the PS, or inherited from the CSS? But my diagrams have no text, so that isn’t needed here.

Have readers ever implemented SVG in raw PostScript? Have you working code, or advice?

[ne...@zzo38computer.org.invalid]

jdaw1 <jdawi...@gmail.com> wrote:
> Wanted: some very tight SVG, brutally short and efficient, from PostScript.=
> It can be done by Distilling to PDF, and then using the likes of www.cloud=

> convert.com/pdf-to-svg to change that to SVG.

I first produced PDF output, and then used a program called "pdf2svg",
although better might be making a SVG output driver for Ghostscript. (I
think there might be one but doesn't fully work, or something like that.
I don't know if it supports pdfmarks, or what device parameters it has.)

> The natural way to proceed is to go back to native PostScript. Perhaps as

> follows: [...]

That is a interesting idea, I suppose. I have not done that though.

I also don't know what would be the policies on Wikipedia if you are using
PostScript code to draw the diagram and are then uploading a SVG file and
want to include the PostScript source codes in case someone else will edit
the diagram in this way.

--
This signature intentionally left blank.
(But if it has these words, then actually it isn't blank, isn't it?)

[ken]

In article <159389516...@zzo38computer.org>,
ne...@zzo38computer.org.invalid says...

> I first produced PDF output, and then used a program called "pdf2svg",
> although better might be making a SVG output driver for Ghostscript. (I
> think there might be one but doesn't fully work, or something like that.

There *was* an SVG output device and at one time an SVG interpreter,
both were declared defunct and removed from the source tree on the 9th
March 2014.

Essentially the problem was that fonts are not well supported in SVG and
many SVG consumers (at least back then) didn't really support fonts in
SVG at all.

I expect the device still works so you could probably get the source for
Ghostscript 9.10, take the gdevsvg.c file from ghostpdl/devices/vector,
and then modify the makefile of the current code to build and include
the device.

> I don't know if it supports pdfmarks, or what device parameters it has.)

The pdfmark PostScript operator is only supported by the pdfwrite
device.


Ken

[ne...@zzo38computer.org.invalid]

ken <k...@spamcop.net> wrote:
> In article <159389516...@zzo38computer.org>,
> ne...@zzo38computer.org.invalid says...
>
> > I first produced PDF output, and then used a program called "pdf2svg",
> > although better might be making a SVG output driver for Ghostscript. (I
> > think there might be one but doesn't fully work, or something like that.
>
> There *was* an SVG output device and at one time an SVG interpreter,
> both were declared defunct and removed from the source tree on the 9th
> March 2014.

OK, the SVG output device is discussed below, but the SVG interpreter, I
did also think of the possibility to write a SVG reader in PostScript, if
there is a XML parser in PostScript.

(I also don't like how the "run" operator reads PDF and EPS files as well
as PostScript programs; I would think that it would be better to have a
separate operator, perhaps called "rundoc", to do such thing (it would
still interpret it as a normal PostScript file if it is not recognized as
PDF or EPS, though). I think a EPS file is a PostScript program, anyways.
An alternative would be for the PostScript only run operator to be called
".run" and to leave "run" like it is; if you use -dWRITESYSTEMDICT then
you can write "/run /.run load def" if you want to disable PDF.)

> Essentially the problem was that fonts are not well supported in SVG and
> many SVG consumers (at least back then) didn't really support fonts in
> SVG at all.

You could have the option to output text as paths, perhaps (either for
some fonts or for all fonts, I suppose).

> I expect the device still works so you could probably get the source for
> Ghostscript 9.10, take the gdevsvg.c file from ghostpdl/devices/vector,
> and then modify the makefile of the current code to build and include
> the device.

There is the possibility of dynamically loading drivers, at least on
Linux. Unfortunately this seems to be undocumented except for the option
for the configure script. On my computer, it expects the dynamic driver
files in the directory called "/usr/local/lib/ghostscript/9.52"; if a
dynamic driver is compiled and put in that directory, it will be loaded.
(I have used this feature and intend to use some more, such as to
implement a driver for my "separations output format", although users who
don't have this feature can just recompile Ghostscript if they want to
add drivers, I suppose.)

I have not looked at the SVG output driver, although I will do so, to see
if it is suitable for my uses, at least. Then, someone else can see
whether or not it is suitable for their uses (and, I suppose, correct any
problems in that driver if they can do so).

> The pdfmark PostScript operator is only supported by the pdfwrite
> device.

While that may be the only included device which does, it would seem that
it is implemented as a device parameter, so it is possible to implement
other drivers that do that by checking for the /pdfmark device parameter.
(A test I have made seems to confirm that.)

Also, I think I read the DjVu output driver supports some pdfmarks too.
(Although I suppose that there may be possibility that some output formats
may support some pdfmarks that PDF doesn't, although probably not.)

[ken]

In article <159407067...@zzo38computer.org>,
ne...@zzo38computer.org.invalid says...

> OK, the SVG output device is discussed below, but the SVG interpreter,
I
> did also think of the possibility to write a SVG reader in PostScript, if
> there is a XML parser in PostScript.

I don't know of one, clearly one could be written.

> (I also don't like how the "run" operator reads PDF and EPS files as well
> as PostScript programs; I would think that it would be better to have a
> separate operator, perhaps called "rundoc", to do such thing (it would
> still interpret it as a normal PostScript file if it is not recognized as
> PDF or EPS, though). I think a EPS file is a PostScript program, anyways.

EPS files are valid PostScript programs, so there's no reason why run
shouldn't work with them.

When built with the PDF interpreter Ghostscript does patch the run
operator so that it handles PDF files, but then the PDF interpreter in
Ghostscript is itself a PostScript program. This is at least in part to
avoid code duplication between the PDF and PostScript paths.

Is it the way I would have done it ? No, but that train left the station
decades ago.

> An alternative would be for the PostScript only run operator to be called
> ".run" and to leave "run" like it is; if you use -dWRITESYSTEMDICT then
> you can write "/run /.run load def" if you want to disable PDF.)

I don't see any advantage to that. But if you want to do something like
that then you can use .runps, which is defined in exactly that way and
is used to run PostScript, and runpdf which is used to run PDF files.

> > Essentially the problem was that fonts are not well supported in SVG and
> > many SVG consumers (at least back then) didn't really support fonts in
> > SVG at all.
>
> You could have the option to output text as paths, perhaps (either for
> some fonts or for all fonts, I suppose).

It would have to be for all, but that was by no means the only problem,
there are other aspects of both PDF and PostScript which can't (or
couldn't at the time) be translated into SVG, and there was essentially
no interest in the device anyway,.

> > The pdfmark PostScript operator is only supported by the pdfwrite
> > device.
>
> While that may be the only included device which does, it would seem that
> it is implemented as a device parameter, so it is possible to implement
> other drivers that do that by checking for the /pdfmark device parameter.
> (A test I have made seems to confirm that.)

The underlying framework is handled as device parameters, but the
pdfmark operator itself is not handled by any other device than the
pdfwrite family (which includes eps2write and ps2write).

Obviously when I say its the only devcie which supports pdfmark I'm
clearly limiting myself to the devices included with Ghostscript.
Naturally its possible to write another device which can exploit any of
the capabilities of an existing device, this is after all open source
software.

> Also, I think I read the DjVu output driver supports some pdfmarks too.

Yes, but we don't own, support, or distribute that.


Ken

[Jean-Francois Moine]

On Sat, 4 Jul 2020 05:53:19 -0700 (PDT)
jdaw1 <jdawi...@gmail.com> wrote:

> Wanted: some very tight SVG, brutally short and efficient, from PostScript.

Do you know 'wps'? (http://logand.com/sw/wps/log.html)
It converts PostScriptto HTML5 canvas, but it is easy to let it
generate SVG.

I am using it in abc2svg, a program that displays/plays music written
in the ABC nmusic notation. My version of the PostScript to SVG converter
may be found in the abc2svg fossil repository at

https://chiselapp.com/user/moinejf/repository/abc2svg/

The file modules/wps.js

https://chiselapp.com/user/moinejf/repository/abc2svg/artifact/efd8214ba88870ef

is quite the original wps.js I found 11 years ago.

The file modules/psvg.js

https://chiselapp.com/user/moinejf/repository/abc2svg/artifact/5b786cba36add724

is the glue I use to convert the PostScript code defined in ABC to SVG.

Indeed, this is javascript code. If you want to do a batch/CLI program,
I recommend QuickJS

https://bellard.org/quickjs/

Otherwise, if you better like the C language, I put a small PostScript to
SVG converter in abcm2ps (svg.c). But it does not handle 'dict'.

--
Jean-Francois Moine http://moinejf.free.fr/

[jdaw1]

On Saturday, 4 July 2020 22:07:29 UTC+1, ne...@zzo38computer.org.invalid wrote:
> I first produced PDF output, and then used a program called "pdf2svg",

PostScript and SVG have arc commands. But the PS arc product Bézier curves. So going via PDF loses the circular intent of the arc. Such SVG would not be optimal.

On Monday, 6 July 2020 15:26:41 UTC+1, ken wrote:
> There *was* an SVG output device and at one time an SVG interpreter,
> both were declared defunct and removed from the source tree on the 9th
> March 2014.

Mixing up a partly-new partly-old version of GhostScript is beyond my skills.

> Essentially the problem was that fonts are not well supported in SVG and
> many SVG consumers (at least back then) didn't really support fonts in
> SVG at all.

That is messy. Happily my task is all vector and no text.

On Monday, 6 July 2020 23:57:04 UTC+1, ne...@zzo38computer.org.invalid wrote:
> OK, the SVG output device is discussed below, but the SVG interpreter, I
> did also think of the possibility to write a SVG reader in PostScript, if
> there is a XML parser in PostScript.

I’m definitely going in the direction PostScript → SVG.

On Saturday, 11 July 2020 15:36:59 UTC+1, Jean-Francois Moine wrote:
> Otherwise, if you better like the C language, I put a small PostScript to
> SVG converter in abcm2ps (svg.c). But it does not handle 'dict'.

The advantage of doing it by redefining PostScript commands is that all the PostScript structure comes for free. Surely a good thing?

[luser droog]

I posted an early draft of a pdf writer in PostScript that could probably
be modified to produce SVG. Not needing a xref table means a lot of the
code could disappear in the rewrite.

Capturing arcs as arcs is trickier tho. Yeah you can capture the call,
but then you'd have to take over a lot more operators and manage the
path. Not impossible -- You could store it easily enough. If a path is
an array of subpaths, a subpath is an array of elements, and an element
is a 2-element array (moveto or lineto) or a 6-element array (curveto)
then you could use a 5-element array for an arc. So arcs might be
"the other 90%" of the work.

https://stackoverflow.com/q/48535765/733077

[luser droog]

I think I put in all the caveats but forgot all the features. If anyone's still
interested,...

My pdf writer converts PostScript drawings to PDF by capturing calls
to stroke and fill. Inside the override functions for these operators,
it does a pathforall to get the path data and then dumps all the
points and calls to graphics operators in PDF's shorthand format.

It certainly has the "problem" with arcs that the output only contains
"curves". But, but, but, isn't that really ... "good" enough? They look
and quack the same, don't they?

The interfacing or overriding of the operators I think is pretty clever.
But the idea is all right there in the code on SO. If anybody has questions
about it, I'd love to boast further.

[jdaw1]

I’m not sure to what extent there is an answer. Given PS, can I generate something like idiomatic concise SVG?

Indeed, since asking this I’ve also acquired a need for the opposite: from SVG to concise idiomatic PostScript.