Follow-up Comment #11, bug #60655 (project groff):
Hi Deri,
I'm trying to keep the focus on what general users might find useful. For my
own part, I already have filters to massage .ps code, so the new options would
be a very small gain for me, allowing me to replace what are now shell
functions with simple command-line options. That seems less fragile overall,
and more likely to keep working going forward, but makes little practical
difference today, since my current needs are met by what I have.
Therein lies my problem with addressing your -Z suggestion: I don't feel
qualified to speak for the general user here. It's not helpful _to me_
because I already have the aforementioned filters, and I've gained modest
competency at reading groff-generated PostScript, whereas I'd have to learn -Z
output from scratch. I sometimes find it useful to read the code side by side
with the final rendering it generates, which is a direct path with a .ps file
and an indirect one with -Z output.
But I'm not in a position to speak for users without my experience and tool
set.
I will note, though, that a user might reasonably have old PostScript output
from a groff run they did years ago with a different version of the tool
chain; they probably don't have any such -Z output or any easy way to
regenerate it. .ps files might be retained over time; -Z output, in the
normal course of things, never even makes it into a file. So as general
solutions go, making it easier to work with the usual output seems like a
better approach.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?60655>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
