At 2023-04-20T18:14:04-0500, Dave Kemper wrote: > On 4/19/23, G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > > We still won't be able to support Solaris sed, in either its > > /usr/bin or /usr/xpg4/bin forms. Unless we change the way GNU troff > > processes `sy` arguments, we will forever need a non-standard > > extension to sed(1) to pull [off] this sort of tomfoolery. > > It depends on how tomfoolish you want to get. It should be possible > to get the same results -- at the cost of either an additional temp > file, or an additional call to "pdfinfo" -- by invoking sed twice, > once to extract each parameter.
Yes, this and a couple of other tricks occurred to me subsequently.
1. A sed trick, to copy the pattern space into the hold space, do one
transformation, then exchange them and do the other. Two
single-line replacements instead of one double-line replacement.
I don't know the precise details of thus sort of stunt--I'm not an
advanced sed programmer--but I'm pretty confident it's possible.
2. A groff trick, using its \R register extension, to initialize both
registers on one control line. In this case it would be a
single-line replacement again, with something like
.nop \R'pdfpic*width \1' \R'pdfpic*height \2'
or something like that, ignoring backslash-quoting issues.
So my claim of "forever" was overstated.
On the other hand, both will be harder to understand; the second relies
upon a GNU troff extension; and my engineering instincts desire a
general solution to the problem, hence
<https://savannah.gnu.org/bugs/?64071>.
> I don't see much need to worry about Solaris 10 or old macOSes. And
> even Solaris 11 isn't urgent, since this pipeline hasn't worked there
> since it was introduced. But if the need for two lines in
> pdfpic*temporary-file, which can't be output portably by a single sed
> invocation, is the only tomfoolery blocking Solaris 11, it seems like
> fixing that gives you the other two for free.
Right. It's tempting, and would improve the groff story in general on
those platforms and our PDF support story in particular.
I have a cleanup of the existing logic on my personal branch
(branden-2023-04-20), but nothing intended for 1.23.0 yet. If Bertrand
sees something that he feels should really go into the next RC, I'm
inclined to oblige him. :)
Regards,
Branden
signature.asc
Description: PGP signature
