Follow-up Comment #14, bug #66323 (group groff): First a comment on a mom difference between grops and gropdf post 1.23.0, when both used the same method, ascii-ing the pdfmark parameters by calling pdfmomclean, (pdf.tmac had an eqivalent pdfclean routine which did a similar job). In HEAD, mom no longer uses pdfmomclean for pdf output the whole "dirty" string is passed to gropdf, whereas it is still used for grops.
What this means is that gropdf more intelligently "cleans" the string than is
possible by using asciify, in particular the \[uXXXX] characters are converted
to UTF-16, any glyphs (\C, \N, etc) are converted back to ascii, and spaces
are handled.
[comment #13 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.
If you look at -Tps -Z output for good.mom the Author/Title have been cleaned
(asciify) so unicode has been dropped, but for pdf the dirty string is passed
and pdfinfo shows:-
Title: N????: stdarg.h wording...
Author: наб, seb, rCs,
Creator: groff version 1.23.0.2178-b25f0
Producer: gropdf version 1.23.0.2178-b25f0
So this is definitely not an issue, except for postscript pdfmark not
supporting unicode.
> 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.
No longer occurs with -Tpdf, since asciify no longer used.
> 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].
I don't remember saying this, perhaps you can point me in the right direction.
I do remember telling you I wanted 'x X' output untouched by the formatter,
just passed as a string (copy-in mode?) the same as it was in 1.23.0.
#63074 is not required for 1.24 since all the advantages this would bring, are
already available in pdf output now, and you have known that even before you
started your long (oft complained of) travails with this self imposed wish.
> But I acknowledge that without a string iterator (#62264 again), most users
will simply have to endure diagnostic messages about them.
If using -Tps.
> 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. ;-) )
And removing a line simply because you did not know what it did!!
>
> > * "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.
Correct. PDFMARK is an extension to the postscript language which allows
distillers to include pdf features, I am not sure if it even allows UTF-16
strings, although pdf detects UTF-16 with an initial BOM, so if ghostscript
treats pdfmark input as an array of 8-bit codes and plomps them straight into
the pdf there is at least a chance it may work, given the correct input.
[...]
>
> 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.
It is definitely not mom, this is a question of minute differences in the
positioning of text on the page between grops/ghostscript and gropdf. The
example shown in comment #10 (appears to be a diffpdf output) is a little
misleading since it is apparent the OP is testing his own created grops fonts
(from /gsfonts using afmtodit) with the stock devpdf fonts (which are a copy
of the original devps groff fonts). The gsfonts contain many more kern pairs,
which affect the output, so its comparing apples with pears.
However, I am still investigating, and when I compare apples, there are still
differences. Initially it looks like a tiny bug in ghostscript which
introduces .11 of a point difference in the vertical positioning of all text,
and it specifies colours to six decimal places, with the 3 least significant
containing garbage. I don't currently believe my findings, and I am currently
documenting them in an email to the groff list in the hope I have made a
mistake!!
>
> So, if наб can tell us, or if Peter is confident that no such differences
exist, we can close this ticket as Invalid.
Since the grout produced on the same mom document by both -Tps and Tpdf is the
same in all respects regarding text positioning the issue is definitely not
mom.
> Who else needs a beverage after all that?
A pint of "Old Peculiar", since you're offering - thanks.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66323>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
