bugGNU roff - Bugs: bug #60655, want option for output drivers to...

 
 

bug #60655: want option for output drivers to suppress comments

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sat 22 May 2021 09:38:00 AM UTC
   
 
Category:  Driver - others/general Severity:  1 - Wish
Item Group:  Feature change Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 29 May 2021 01:30:17 AM UTC, comment #13: 

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?

Dave <barx>
Group Member
Fri 28 May 2021 12:09:50 AM UTC, comment #12: 

Hi Dave,

I don't see much fragility in what you are using now, the postscript language "build artifacts" are unlikely to change in any meaningful way which will stop your current workflow from continuing to work.

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. Just as you had to learn how to read the groff postscript language to understand the diffs, they may find it easier to learn the groff intermediate format which is much simpler than the postscript language.

I agree a user is unlikely to retain ancient -Z files, but in the use case you posited, they would still have the original troff input, so before making any amendments they could produce a -Z file, then make the changes and generate another -Z file which can be diffed to make sure nothing had changed. After all, an ancient groff postscript file may have many differences if changes have been made to grops, that do not alter the actual rastered content on the page.

Deri James <deri>
Group Member
Thu 27 May 2021 09:22:53 PM UTC, comment #11: 

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.

Dave <barx>
Group Member
Thu 27 May 2021 05:32:04 PM UTC, comment #10: 

You don't mention whether you found my suggestion for grepping the groff intermediate output produced by -Z was helpful or not. After all this is the input read by grops and you are not testing whether postscript has changed, but whether your changed input to groff results in an unwanted change in the output.

Deri James <deri>
Group Member
Thu 27 May 2021 12:37:18 PM UTC, comment #9: 

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.)

Dave <barx>
Group Member
Thu 27 May 2021 10:29:54 AM UTC, comment #8: 

One way of checking whether your change to roff code will alter the output is to diff the -Z output of both versions. This will easily show what page the change occurs on so you can use your slow method on just the page identified by the -Z diff. I think there was a message on here recently which highlighted how few letters were left for flags, it just seems unnecessary to add two more.

Deri James <deri>
Group Member
Thu 27 May 2021 07:35:16 AM UTC, comment #7: 

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.

Dave <barx>
Group Member
Mon 24 May 2021 02:53:50 PM UTC, comment #6: 

My question is why do you want to suppress CreationDate, since this previously came up about reproducible builds and a solution was found. I don't see a need for a general user needing to do this, so why a flag?


Deri James <deri>
Group Member
Sun 23 May 2021 02:12:57 PM UTC, comment #5: 

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?



G. Branden Robinson <gbranden>
Group administrator
Sun 23 May 2021 11:26:24 AM UTC, comment #4: 

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

Deri James <deri>
Group Member
Sun 23 May 2021 11:21:40 AM UTC, comment #3: 

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

Deri James <deri>
Group Member
Sat 22 May 2021 03:47:22 PM UTC, comment #2: 


commit 2a1f6a6c686b009748d8b58dc900958b67263f10
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat May 22 20:46:48 2021 +1000

    [grohtml]: Implement -C and -G options.

    Add -C and -G options to grohtml output driver, to suppress the output
    of CreationDate and Creator HTML comments, respectively.  These can
    inject unwanted noise into build artifacts.

    * src/devices/grohtml/post-html.cpp: Add static globals
      `do_write_creator_comment` and `do_write_date_comment`.

      (html_printer::{do_file_components,~html_printer}): Write
      comments per corresponding global variables.

      (main): Add to `getopt_long()` call parameter and set as needed.

      (usage): Document them.

    * src/preproc/html/pre-html.cpp (scanArguments): Add to `getopt_long()`
      parameter, but ignore.

    * src/devices/grohtml/grohtml.1.man (Synopsis, Options): Document them.

    Fixes 1/3rd of <https://savannah.gnu.org/bugs/index.php?60655>.


G. Branden Robinson <gbranden>
Group administrator
Sat 22 May 2021 10:16:49 AM UTC, comment #1: 

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.

G. Branden Robinson <gbranden>
Group administrator
Sat 22 May 2021 09:38:00 AM UTC, original submission:  

I propose grabbing the heretofore unoccupied (in output drivers) `-C` option for suppression of "CreationDate" and related comments in output file formats.

grodvi(1) does not already use this.  grotty(1) likely never will.

But grohtml(1), gropdf(1), and grops(1) could have use for it today.

Initially I'll implement this for grohtml since that's what I'm working on right now.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-23 gbranden StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code