So you think you can eliminate the obvious and that would stump everyone?
1. Postscript does not technically care where objects are on the defined page. So one option would be to simply place your information off the printed page and see whether the printer complains. Postscript won't care, but sometimes the printer and controlling software might.
2. Can't use white, then how about black? Add a thick line, the height of your smallest font, across the page in the footer or just a rectangular shaded box somewhere of an appropriate size and print your text fields using a small font within those confines. Black on black will be black.
3. If you are font savvy, you could simply make a postscript font that has no graphics for the characters - where every character would print nothing other than a space. The fact that we see an 'A' when we print is a function of the font rendering. Heck, if you look around, someone might already have a font that does just this.
4. Final suggestion: How about bar codes? You just need a place to hold the field data but don't want it read by the user. These don't necessarily have to be large or ever intended to be scanned as a bar code. Still the field data assigned would be accessible by whatever needed it.
I am not familiar with the DSCHeaderComment INI options, but I do know INI syntax supports dynamic values. For example, with the use of ~GVM. So you can pull transactional data into your INI option. Each column in TRNDFDFL.DFD can be accessed via ~GVM NAMEOFCOLUMN. INI syntax:
Option = ~GVM NAMEOFCOLUMN
An enhancement has been added to Documaker Enterprise Edition 12.2.2 to allow comments to be written based on variable information;
DSCHeaderComment = %%Comment: ~GVM Company
DSCHeaderComment = %%Comment: ~GVM Lob
DSCHeaderComment = %%Comment: ~GVM RunDate
DSCHeaderComment = %%Comment: ~DALRUN TEST.DAL