Follow-up Comment #16, bug #63827 (group groff): Hi Branden,
Generally it is only "distillers" which process pdfmark instruction. Given the
pdfmark.tmac only supports a subset of the pdfmark reference, none of which
alter position on the page, it is safe for an ordinary PS interpreter to just
ignore them. If you use pdfmark instructions which are modal (alter the state
of the interpreter) then I think you need specific code in the postscript
prolog, see the pdfmark reference.
Pdfmark's use of "gropdf" in "gropdf-info:href" pre-dates my introduction of
gropdf.pl. It is Keith's solution to the forward reference issue. Pdfroff
collects these outputs and writes them to a ref file as .pdfhref D commands,
you can view the file in a directory within /tmp if you pass
--keep-temporary-files to pdfroff. Gropdf solves the same problem by passing
.tm .ds lines down the pipeline.
Another issue pdfroff has to solve, is the movement of hotspots areas. Given
that the text of a forward reference may be unknown during the first run, when
it is subsequently populated in a subsequent run, the whole text flow of the
document will have changed, a hotspot may have moved from the bottom of one
page to the top of the next. Pdfroff accomodates this by using .tm
grohtml-info:page, which pdfroff collects, it contains the page number and
location on the page of a hotspot, which it then uses to mark the hotspot.
This actually comes from node.cpp. This is why pdfroff uses a loop to wait for
the page/positions to settle, which, if the document uses PDFPIC with pdfroff,
can produce very long run-times, because each time around the loop PDFPIC will
be calling pdftops -eps each time.
Gropdf has a much easier time of dealing with hotspots which may move after
the first run has populated the forward references, because it does not use
the information from node.cpp but instead plants markers in the text stream
(pdf: mark[start/stop/suspend/resume] and gropdf "knows" where it is on the
page when it receives the marker.
The inclusion of "gropdf-info:ref" lines in om.tmac is due to an oddity in
pdf.tmac (which is not in pdfmark.tmac), when pdfbookmark is called with -T,
pdf.tmac uses the -T parameter as a named target which you can link to with a
pdfhref L call, otherwise bookmarks get an anonymous name "pdf:bmNN" which are
only called from the pdf overview panel. In pdfmark (grops) -T appends a tag
name to the bookmark to become pdf:bmNNtagname, so it is still anonymous, I
believe the idea is to make it possible to merge different runs together using
the tag to differenciate otherwise duplicate names. In pdf.tmac I decided that
this problem was better solved outside pdf.tmac. In an.tmac, when you make
subsections as named destinations you realised that they would need extra
qualified names, such as "gropdf(1)#See Also" so as to be unique in documents
like groff_man_pages.pdf. So the gropdf-info lines are to make pdfmark work
the same way, i.e. if a bookmark is named it becomes a named destination as
well as a bookmark.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63827>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
