• PostScript to SVG

    From jdaw1@21:1/5 to All on Sat Jul 4 05:53:19 2020
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From news@zzo38computer.org.invalid@21:1/5 to jdawiseman@gmail.com on Sat Jul 4 14:07:26 2020
    jdaw1 <jdawiseman@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?)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ken@21:1/5 to All on Mon Jul 6 15:26:40 2020
    In article <1593895164.bystand@zzo38computer.org>, news@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From news@zzo38computer.org.invalid@21:1/5 to ken on Mon Jul 6 15:56:55 2020
    ken <ken@spamcop.net> wrote:
    In article <1593895164.bystand@zzo38computer.org>, news@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.)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ken@21:1/5 to All on Tue Jul 7 08:03:30 2020
    In article <1594070675.bystand@zzo38computer.org>, news@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jean-Francois Moine@21:1/5 to jdawiseman@gmail.com on Sat Jul 11 16:36:58 2020
    On Sat, 4 Jul 2020 05:53:19 -0700 (PDT)
    jdaw1 <jdawiseman@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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdaw1@21:1/5 to ne...@zzo38computer.org.invalid on Sun Jul 12 03:19:23 2020
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to All on Wed Jul 29 00:22:18 2020
    On Saturday, July 4, 2020 at 7:53:21 AM UTC-5, jdaw1 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.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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to luser droog on Fri Aug 27 19:47:17 2021
    On Wednesday, July 29, 2020 at 2:22:19 AM UTC-5, luser droog wrote:
    On Saturday, July 4, 2020 at 7:53:21 AM UTC-5, jdaw1 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.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?
    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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdaw1@21:1/5 to All on Sun Oct 10 11:46:34 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)