[bug #66323] [mom] rendering differences between PostScript and PDF output?

[G. Branden Robinson]

Update of bug #66323 (group groff):

                Category:            Driver grops => Macro package mom      
             Assigned to:                gbranden => PTPi                   
                 Summary: grops should handle special character escape
sequences in certain device control commands => [mom] rendering differences
between PostScript and PDF output?

    _______________________________________________________

Follow-up Comment #13:

[comment #12 comment #12:]
> * mom is not scrubbing the argument to her .AUTHOR macro.  This may be
dependent on the aforementioned #62264, but some of it may be currently
handleable.

Maybe; Deri can speak better to that.  Personally, I'm resigned to living with
the resurrected "can't output node in transparent throughput" diagnostic until
we get all the machinery required to eliminate it sorted out.  That involves
not just #62264, but bug #63074 (still a 1.24 release goal) and maybe bug
#64484, which like many of our tickets has sprawled in scope; at this point it
seems essentially a duplicate of #63074 in its central purpose, but Deri and I
have perhaps not reached a full meeting of the minds on some auxiliary issues.
 (He would like to see explicit horizontal motions discarded from device
extension command arguments automatically by the formatter; I would not
[because as input validation goes, I'm an irascible, white-gloved barracks
inspector].  But I acknowledge that without a string iterator (#62264 again),
most users will simply have to endure diagnostic messages about them.  I
wouldn't wish the tedium of composing things like "an.tmac"'s ellipsifiers on
anyone, not even those calling for me to be dragged before a war crimes
tribunal in The Hague for removing an undocumented macro without a deprecation
cycle. ;-) )

> * pdfmom sometimes exits with a 0 even if there's been an error

This one isn't _pdfmom_'s fault.  _pdfmom_ does not (directly) invoke
Ghostscript.


elsif ($dev eq 'ps')                                                     
{                                                                        
        $waitstatus = system("groff -Tpdf -dLABEL.REFS=1 $mom -z $cmdstring
2>&1 | LC_ALL=C grep '^\\. *ds' | pdfroff -mpdfmark $mom --no-toc - $preconv
$cmdstring");
        abort(autopsy($?)) unless $waitstatus == 0;                      
}


It's _pdfroff_'s, which is no longer maintained as part of the _groff_
project, and is slated for removal (bug #63827).  I see no reason to split off
a ticket for it since we won't be fixing it anyway; that's up to its
(external) maintainer.  It's _pdfroff_ that launches Ghostscript, so it's
_pdfroff_'s duty to responsibly gather its wait/exit status. 

_pdfmom_ *will* need to be prepared for _pdfroff_ not existing on the system,
but I expect to cover that base when grepping the tree for "pdfroff" in the
course of resolving #63827.

> * "special characters aren't getting into 'grout' at all."  I take it this
is a separate problem from the grops one that is now the focus of this ticket,
since grops takes grout as input.

This isn't a defect if nothing has yet taken on the responsibility of encoding
special characters in PDF bookmarks in PostScript output in the first place. 
I had assumed that was the case, in part because of the surprising spelling of
the device extension tags exercising the "pdfmark" command word ("ps: exec"),
but if these are "ps: exec"s that _grops_ will in fact never see in the first
place, then my observation is a potential feature request at best.

Besides, if I can land the rest of fix for #63074 (all that remains, that I
know of, is temporarily constructing special character nodes for composite
special character escape sequences), and if macro packages like "pdfmark.tmac"
elect to use the `\X` escape sequence and/or `device` request to embed device
extension commands instead of going behind the formatter's back with `\!` or
`output`, the formatter will take care of the special character encoding issue
for them.

_grops_ will then need to know how to translate _groff_-style Unicode special
character escape sequences like `\[u043D]` for emission to PostScript output. 
(I suppose that means conversion to UTF-16, but no one ever tells me if that's
LE or BE.)  But that, too, is already accounted for: I believe it to be part
of bug #62830, also still a 1.24 release goal.

> Should any of the above be separate tickets (besides the one that already
is) so that they don't get lost in the deluge?

The foregoing should strike a few off the list.

To summarize the central point, I withdraw my diagnosis in comment #9. 
PostScript per se doesn't support PDF bookmarks, and the only think that
injects pdfmark extension commands into GNU _troff_ output is Keith Marshall's
"pdfmark.tmac", which is no longer maintained as part of _groff_ and thus is
no longer our issue to address.

Consequently, I'm rescoping and retargeting this ticket at the first point you
raised in comment #12:

> Comment #10 talks about rendering differences between grops and gropdf. 
These have not yet been root-caused, so they may be down to user error--but if
so, this may point to a documentation deficiency.

That moves it back to _mom_, so reassigning to Peter--but I'm leaving the
status as "Need Info" because it's not clear to me that it is actually true
that any discrepancy between _mom_'s PostScript and PDF output remains; наб
noted in comment 11 to bug #66322 that the page size differences observed were
due to a Debian patch to its _groff_ package.

So, if наб can tell us, or if Peter is confident that no such differences
exist, we can close this ticket as Invalid.

Who else needs a beverage after all that?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66323>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature