Re: [groff] 28/28: [pdf]: Implement linear bookmark tag search

[G. Branden Robinson]

Hi folks,

Some really happy news on this front.

At 2024-03-04T14:22:34-0500, Peter Schaffter wrote:
> > The other thing to ask is of Peter: assuming you are among the
> > non-horrified, would you like me to prepare a patch to om.tmac to
> > migrate it to this new `pdf:lookup` macro?
>
> Assuming the migration in no way interferes with the status quo of
> mom, yes, please prepare a patch and send it to me.
>
> > If that is done (regardless of who does it), I can also chop out the
> > `ie d PRINTSTYLE` branches from pdf.tmac shown below.
> 
> Which would address Doug's concern about PRINTSTYLE (mom specific
> macro) appearing in pdf.tmac, which should be macroset agnostic.

It appears that Dave is not the only person maintaining a cape in his
sartorial armoire.  Deri swooped in from sabbatical to fix the foregoing
wart as well as several other issues.

Furthermore, in so doing, his work revealed that keeping PDF bookmarks
containing non-Basic-Latin characters in them in mom(7) documents was
_not_ gated on the revision of `\X` escape sequence semantics, as I
thought it was, and that I have been slow to land.

That's great news because it means that work isn't a blocker for 1.24
and we can kick it out past that.  (I still think it's the right thing
to do: a "node" has _no meaning_ in device-independent output, which is
why we used to warn about it by default, and still do if you set the
environment variable GROFF_ENABLE_TRANSPARENCY_WARNINGS.  And these do
still show up even after Deri's latest changes.  They are now simply
even more harmless.)

Deri did say he experienced _severe_ slowdowns when rendering the Linux
man-pages book with my linear bookmark search.  You will recall that I
measured no significant performance degradation when rendering our own
61-document, ~380-paper-page man page collection with some ~900
bookmarks (one for each page, section heading, and subsection heading).

The Linux man-pages collection is much larger.  Possibly the internal
dictionary/hash used for tracking groff string identifiers is getting
hammered in that case but not our internal one, or possibly the somewhat
bespoke version of Deri's gropdf-ng and related book-creation macro file
changes that the man-pages project is using are interacting badly with
groff Git.  We'll want to figure this out; Deri said the rendering
performance was 670 *times* worse.  That's utterly unacceptable for
release.  I'll do whatever is necessary to recover sensible performance.
A bigger hash table size (which probably hasn't been changed in decades)
in the string identifier dictionary, some kind of memoization of
bookmark-related strings in pdf.tmac--whatever.

Anyway, people can check out Deri's and my dialogue in
<https://savannah.gnu.org/bugs/?65585> for further details.

Regards,
Branden

signature.asc
Description: PGP signature