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.

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.