comment #12:

> I don't see much fragility in what you are using now,

True, there's not much, but pretty clearly more than solving the problem at its source and avoiding the need for the workarounds altogether.  The more moving parts there are, the more potential points of failure.

> Perhaps a general user who has a similar requirement, if they
> ask the best way to do it, we could point them to diffing
> the -Z output to avoid problems with diffing postscript output.

Certainly, that may work well for them.

Would an additional grops option or two that such users never use be an obstacle to your suggested workflow?

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.

comment #8:

> I think there was a message on here recently which highlighted
> how few letters were left for flags,

You're likely thinking of the discussion in bug #60571, which catalogued the remaining letters available for new in-document escapes.  I mentioned Unix command-line switches in passing as a related general concern, but a shortage related to groff in particular was never brought up as an issue.

It's true that the groff command itself has nearly used up its single-letter switch allotment, but grops and gropdf have plenty of available slots.

Still, no point in burning through them willy-nilly: maybe these two new filters under consideration could be clumped under the same option, taking a parameter (like grops' -b option does) specifying what to filter.  (For grops in particular, the existing -b option could even be extended to cover this, but that would alter its semantics, as the things it currently filters all have compatibility implications.)

Speaking as a general user, I periodically need to verify that some change I've made to some roff code that shouldn't change the PostScript output does not, in fact, change the PostScript output.  The most straightforward way to do this is *diff*ing the .ps files,* but the %%CreationDate is just noise that needs to be ignored for this.  I also sometimes compare output from a sandbox build of groff to that from a stock 1.22.4 build, which adds further noise (%%Creator, %%DocumentSuppliedResources, and %%BeginResource all embed groff version information) that I must also filter.

SOURCE_DATE_EPOCH (presumably the found solution to which you refer) does help with %%CreationDate, so I'm less concerned about the flag to suppress that.  But SOURCE_DATE_EPOCH affects the behavior of programs besides groff, and a user might want a groff-specific way to ignore this line without affecting other software.  And it just feels cleaner to be able to say "I don't care about the timestamp" rather than "Use this phony timestamp."

Do you oppose the addition of such flags, or just question their necessity?



* Yes, there are ways to compare the rendered page that the PostScript code generates, and sometimes I must resort to these.  But they are agonizingly slow for documents of any length.  diff is blindingly quick--even on my decrepit hardware, even on PostScript files that run hundreds of pages--so will always be the first tool I reach for.

comment #4:

> There is already a method for preventing "build artifacts" in grops and gropdf, what more would this add?

comment #3:

> You have not mentioned why you want to suppress CreationDate nor what are the other related comments.

Thanks, Deri.  I did file this in a hurry.  My main concern was grohtml.

I skimmed the grops(1) and gropdf(1) pages but didn't see what I was looking for.

I can't seem to get grops's -b option to suppress these kinds of comments.

$ for N in $(seq 0 31); do echo | groff -Tps -P-b$N | grep -q '%Creat' || echo %N works to suppress the comments; done

In gropdf(1), I see options to add more comments (-d, -s), but not to remove any.

$ echo | groff -Tpdf -P-d | grep -E '/(Creator|ModDate|Producer)'
/Creator (groff version 1.22.4)
/ModDate (D:20210523141122+00'00')
/Producer (gropdf version 1.22.4)

Can you offer me some clues?

You have not mentioned why you want to suppress CreationDate nor what are the other related comments.

Mmmm, how about -C for the CreationDate and -G for the Creator ("Groff") instead.  The functions are distinct and groff's release cycle is long enough to make a real difference.