[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

[Keith Marshall]

Follow-up Comment #9, bug #64576 (group groff):

[comment #2 comment #2:]
> I reiterate that stuff like this:

> .  while dpdf:href.opt\\$1 \{\
> . pdf:href.opt\\$1 \\$@
> . shift \\n[pdf:href.argc]
> . \}


> is too clever by half--by three quarters, maybe,
This, of course, is utter nonsense.
> if you're neither doing sanitization (which will need to be
> reversible for things like link text, and therefore even more
> tedious and difficult than sanitization already is), nor input
> validation.
> 
> But the latter isn't even really what you want anyway.
You got that much right.
> There's no reason that every argument to a macro must be expected
> to be a valid *roff identifier.
Also true; however...
> This is simply a mistaken premise that appears to have driven
> several bad design decisions.
This conclusion is, once again, utter nonsense.  The design is perfectly
sound; it is the implementation that is flawed.  You even hinted at the fault,
and thus implicitly at a practical solution, in your reference to "input
validation", and *that* is readily accomplished:

.  while \A'\\$1' \{\
. if !dpdf:href.opt\\$1 .break
. pdf:href.opt\\$1 \\$@
. shift \\n[pdf:href.argc]
. \}

will prevent any attempt to match any argument which could not be legitimately
incorporated into an identifier name, (and any which follow it), to a defined
macro name, (which is the intent of this while loop).

I have identified six loops, within _pdfmark.pdf_, which exhibit such
vulnerability, and thus, where similar input validation would be advisable; I
will fix them accordingly, in my OSDN _groff-pdfmark_ repository.


___

Reply to this item at:

  

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

[bug #65117] [pdfmark] premature page break in "pdfmark.ms" output with page size A4

[Keith Marshall]

Update of bug #65117 (group groff):

  Status:None => Unreproducible 

___

Follow-up Comment #2:

[comment #0 original submission:]
> Subject: [pdfmark] premature page brake in "pdfmark.ms" output
> with page size A4
> 
> Page 14.
> 
>   The page is advanced after
> 
> invokes ``.pdfsync O'' to ensure that the outline for the
I'm not seeing that in *my* A4 format copy, (or in the current online copy, at
https://osdn.net/users/keith/pf/groff-pdfmark/wiki/FrontPage, which is also
formatted as for printing on A4 paper), where this text appears towards the
bottom of page 27, *not* page 14, on the last but one line of the last
paragraph of section 2.7; the last line of the paragraph follows
*immediately*, (still on page 27).
>   although there it plenty of space left on the page.
> 
>   The next page begins with the last line of the previous
> paragraph (widow).
*My* next page begins with the top level heading for section 3; there is no
widow line, carried forward from section 2.7.

Marking as "Unreproducible", for now; maybe should be "Invalid"?  Furthermore,
is there any real value in keeping this open?  I will certainly *not* be
pursuing it.


___

Reply to this item at:

  

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

[bug #60927] improve pdfmark documentation, including pdfroff(1)

[Keith Marshall]

Update of bug #60927 (group groff):

  Status:None => In Progress
 Assigned to:None => keithmarshall  

___

Follow-up Comment #5:

This is still a work in progress.  I consider the pdfroff(1) manual page to be
complete, but I still plan to provide two more: groff_pdfmark(7) and
groff_pdfhref(7).  I also have more content, which I plan to add, via
pdfmark.ms, to pdfmark.pdf.

Meanwhile, I have now (as of 9-Apr-2024) posted significant additions to
pdfmark.pdf; these may be found at
https://osdn.net/users/keith/pf/groff-pdfmark/wiki/FrontPage


___

Reply to this item at:

  

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

[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #10, bug #64202 (group groff):

[comment #9 comment #9:]
> [comment #1 comment #1:]
> > 3.  The reason for that is that man page content is partially
> > dynamic.  The redundancy you're observing is the result of the
> > "@g@" character sequence being replaced by the ./configure-d
> > command prefix in use by the build.  By default, and in many
> > build scenarios (of those I've seen personally, all except for
> > Solaris), this prefix is empty.
> 
> This was and remains true.
I think we had already agreed that the issue arose from expansion of the '@g@'
configuration macro, the intent of which is to support addition of (normally)
'g' as a program name prefix.  That many systems do not specify such a prefix
is certainly true, but is not germane to this issue anyway -- the addition of
'g', as prefix, would not cause any problem.  However, that the expansion of
'@g@' is similarly empty, in the case of groff's generated man pages, is
apparently *not* true.  In the case of _groff_man.7_, which I cited as an
example merely because that's what drew my attention to this issue, '@g@'
appears to expand to '\%', and when that infiltrates a PDF hypertext
reference, via a PDF-centric overridden 'MR' macro, it becomes a problem.  I
have little doubt that _groff_man.7_ is not alone, in exhibiting this
affliction.
> > 4.  @g@ is expanded in several contexts, not just the first
> > argument of `MR`.  Wherever it occurs, it is part of a literal to
> > which we do not want automatic hyphenation to apply.
> 
> This was and remains true.
I have no doubt that this is the case.  However, there are many similar
literals, which are *not* prefixed by '@g@' but should also not be hyphenated.
 You have conflated two unrelated concepts into the expansion of a single
configuration macro, which does not have sufficient degrees of freedom to
separate the two concepts.  At best, that is a gross abuse of the '@g@' macro,
which I contend is a bug.
> A built _groff_ 1.23.0 tree does not produce any instances of
> `\%\%` in any of its man pages, as a _grep_ will readily confirm.
Which is *not* the issue, and I never said that it was.  That there is just
one '\%' at the start of *some* 'MR' topic references, (and it seems to be
just those which are prefixed by '@g@'), *is* the problem, because that
infiltrates, and corrupts PDF hypertext references, which are compiled from
the 'MR' arguments.
> Your ticket title appears to have been deceptive.
Possibly.  It is, perhaps, misleading that I cited _groff_man.7_ as *the*
problem page.  It is *a* problem page; I have no doubt that there are others.
> I should have demanded evidence from you at the time; I will have
> settle for doing so now.
I based my original testing on:

$ ../groff-build/config.status --version
GNU roff config.status 1.23.0.rc4.59-51a03-dirty
configured by ../groff-tmp/configure, generated by GNU Autoconf 2.71,
  with options ""

In my local build from that _groff-tmp_ git checkout, I see:

$ grep '^\. *MR' ../groff-build/tmac/groff_man.7
.MR groff_man_style 7 ,
.MR man 1
.MR intro 1
.MR groff_man_style 7
.MR man 7
.MR grotty 1 ).
.MR groff_man_style 7 .
.MR \%tbl 1
.MR groff 7
.MR groff 7 .
.MR groff 7 .
.MR groff 7 ).
.MR \%tbl 1 ,
.MR \%eqn 1 ,
.MR \%refer 1
.MR man 1
.MR groff_mdoc 7
.MR groff_man_style 7 ,
.MR groff 7 ,
.MR groff_char 7 ,
.MR man 7

Note that of all 'MR' references, only four exhibit the redundant '\%' prefix,
(redundant because, presumably, 'MR' would be expected to suppress hyphenation
of its output, in any case, even without an explicit '\%' prefix), and
inconsistent for the fairly obvious reason: (most 'MR' references omit the
'\%' prefix, but just a few have it).  Furthermore, I see:

$ grep '^\. *MR  *@g@' ../groff-build/tmac/groff_man.7.man
.MR @g@tbl @MAN1EXT@
.MR @g@tbl @MAN1EXT@ ,
.MR @g@eqn @MAN1EXT@ ,
.MR @g@refer @MAN1EXT@

This would appear to confirm that, where this redundant '\%' prefix appears,
it is the result of expansion of '@g@'.
> In the absence of such evidence, I regard your claim of bugginess
> as unfounded.  Changing status to "Invalid".
Frankly, I could not care less what you choose to do, henceforth.  I say this
is a bug; you may disagree, in which case we must agree to disagree.  I now
have a satisfactory work around for this bug, and I have no further interest
in contributing to _groff_, or in pursuing any further local builds.  I shall
continue to maintain _pdfroff_, _pdfmark.tmac_, and associated documentation
independently; this has already diverged significantly from its state, when I
ceased to maintain it as a part of _groff_.


___

Reply to this item at:

  

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

[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #8, bug #64202 (group groff):

[comment #7 comment #7:]
> I'm rejecting this.
Fair enough; that is your prerogative.  It doesn't make it any less of a bug;
it just makes it a bug which you have decided you will not fix!  In any case,
I have a work around.
> If a PDFMark tag indexing system constructs _groff_ identifiers
> from arbitrary input strings, that system is responsible for
> ensuring that the constructed identifiers are syntactically valid.
That is *not* the issue here.  The issue is that your unnecessary '\%' prefix
infiltrates the text of the pdfmark '/Link' annotation, which defines the
destination of the resultant PDF hyperlink; there is no attempt to construct a
_groff_ identifier from this text.  My work around simply iterates over the
initial part of the string, discarding the first character while it is '\%',
and keeping the remainder of the string, as soon as its first character
becomes anything other than '\%'.

In fact, I am not aware of any code, within _pdfmark.tmac_, which attempts to
construct a _groff_ identifier from arbitrary input text; if _you_ know of
any, please do bring it to my attention.
> The _groff_ language has, for decades, supported the `\A` escape
> sequence to assist with this.
I am aware of this.  Indeed, just last week, I *did* stumble on some code
which *does* attempt to *match* arbitrary input text to (a part of) a
*pre-existing* _groff_ identifier, using _.if d prefix.\\$1_ as the sole test.
 In the particular context, the effect was completely innocuous, aside from
raising an unexpected warning.  The solution, to avoid the warning, was to
test _.if \A'\\$1'_ *first*, and to perform the _.if d ..._ test only if that
returns _true_.
> Unfortunately, it has also lacked a string iterator that would make
> it easier to _do_ something about arbitrary input strings one's tag
> indexing system encounters.  (Apart from aborting the formatter or
> risking incorrect lookups on tag values, that is.)  Providing such
> a facility is contemplated as a future _groff_ language direction
> in bug #62264.
I agree that string iteration could be made more convenient, but it *is*
already possible ... I do it, in my _sanitize.tmac_, to filter out special
codes, which do not render appropriately in PDF outline text.
> I decided to solve this problem in "pdf.tmac" by not constructing
> _groff_ identifiers from arbitrary input strings, instead using
> another string, indexed by the bookmark's sequence number.  This
> does come at the price of turning tag lookup time from constant in
> the number of already-recorded tags to linear.
As I've pointed out above, identifier construction is *not* relevant to this
issue, so what you have done in _pdf.tmac_ has no bearing on what I have had
to do, to work around your bug.


___

Reply to this item at:

  

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

[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #6, bug #64202 (project groff):

[comment #5 comment #5:]
> [comment #4 comment #4:]
> > [comment #3 comment #3:]
> > ... I don't have enough insight into the implementation you're
> > working on to offer advice.  Maybe you could share some of its
> > code.
> 
> I'll post it on OSDN, when I get it to a "commit-ready" state.
> I do have it working, quite nicely, now, but with my MR macro
> override "uglified" by the need to filter out '\%' prefixes,
> from its first argument.
You can find it at
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/commits/918f8bd24f903ec0a9e4367286eeaafdb66ece3d
groff-pdfmark commit #918f8bd] -- look, in particular, for the new
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/blobs/918f8bd24f903ec0a9e4367286eeaafdb66ece3d/tmac/anpdf.tmac
tmac/anpdf.tmac] file.


___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #14, bug #63827 (project groff):

[comment #13 comment #13:]
> [comment #11 comment #11:]
> > [comment #10 comment #10:]
> > > Should the 1.23 announcement/news mention that:
> > > * the pdfmark bundled with this release of groff is not the
> > >   latest code (and provide a pointer to that code)?
> > 
> > I don't think they've diverged all that much.
> 
> Keith addressed this in comment #12; I don't know if that changes 
> the conclusion any.

And today, there's
_[https://osdn.net/users/keith/pf/groff-pdfmark/wiki/ChangeLog even more
extensive divergence]_ than there was when I wrote comment #12.

> > pdfroff(1) will continue to exist in groff 1.23.0
> > distributions and point readers to Keith's site.
> 
> Ah, yes, I somehow missed
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=948ccc55 commit
948ccc55], even though it
> was cited in a comment to bug #63133, on which I'm cc:ed.

Yet today, following a pull and update from git master, I _still_ see no
reference in the NEWS file; given the extent of divergence, now, I think that
the obsolescence of groff's pdfroff/pdfmark distribution deserves a mention in
NEWS, as well as in pdfroff(1).


___

Reply to this item at:

  

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

[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #5, bug #64202 (project groff):

[comment #4 comment #4:]
> [comment #3 comment #3:]
> > [comment #1 comment #1:]
> > > Hi Keith,
> > > 
> > > I'm aware of this.  It's deliberate insofar as it's a consequence of
other decisions.
> > > 
> > > The main facts are these:
> > > 
> > > 1.  The new `MR` macro unconditionally prefixes its first argument with
a `\%` escape sequence to suppress hyphenation.
> > 
> > That's what I thought.  Consequently, there is _absolutely_ no need for
references, such as '.MR \%topic n', to _ever_ add that redundant '\%' prefix
to the topic name.
> 
> ...and there are no cases of it doing so in the groff tree,
Seriously?  Is your day job related to government, in some shape or form?  You
certainly seem to exhibit the politician's proclivity to spew verbiage, with
little. or no, bearing on the issue at hand.

> $ git grep 'MR.*\\%' || echo NONE
> NONE

A badly designed experiment, testing a bogus hypothesis, might be viewed as
disingenuous obfuscation ... perhaps not so in this case, but rather a
misunderstanding of the issue?  In reality, there _are_ 197 cases arising from
abuse of '.MR @g@...', and one further, from abuse of '.MR @PSPRINT@ ...'

$ hg grep '^\. *MR  *@g@' | wc -l
197

$ hg grep '^\. *MR  *@' | wc -l
198

$ hg grep '^\. *MR  *@[^g]'
src/roff/groff/groff.1.man:.MR @PSPRINT@ 1 .


> [...irrelevant verbiage snipped...]

> The purpose is not being subverted.
I guess we'll just have to agree to disagree, on that conclusion.
> You said yourself that the "seat" of this behavior is Makefile rules for
generating .[157] from .man.  It would be wrong to do so in
"makevarescape.sed", for instance, because '@g@' and friends get expanded in
contexts other than _roff_ sources.  Moreover, valid _roff_ input is indeed
being produced.
> 
> [...more verbiage snipped...]

> This is why I mentioned the following point in comment #1.
> 
> > You do not _need_ to sanitize content destined for device control escape
sequences (or the `device` request) of the `\%` escape sequence.  The
formatter will ignore this escape sequence in that context, skipping over it
without diagnostic, and it will not appear in the "x X" commands that GNU
troff produces.  This is already the case in groff 1.22.4 and therefore I
suspect it's been true for many years.

Well, it _does_ propagate through pdfmark output to grops.  Perhaps the
pdfmark macro _should_ sanitize its output, but that seems like a huge
overhead in tmac code ... every single byte of pdfmark throughput would need
to be inspected, just to weed out a miniscule few rogues.

> Are you wrapping or replacing the `MR` macro
Yes, and ...
> and "sanitizing" its first argument for some other purpose?
...no; it's a consequence of _not_ sanitizing the first argument, coupled with
your abuse of '@g@', (and maybe also of '@PSPRINT@'), in man page source, that
allows the unwanted '\%' to propagate.
> You said:
> 
> > (which, in its present state of development, does not incur any address
sanitizer overhead)
> 
> ...which I didn't completely understand, as ASAN doesn't seem relevant to
the present discussion of _roff_ macro processing.
> 
> Leaving in "Need Info" status, as I'm stuck; I don't agree with your
implication that repeated leading \% escape sequences in a word are invalid
_roff_ input,
I neither said, nor even remotely implied, any such thing.
> and I don't have enough insight into the implementation you're working on to
offer advice.  Maybe you could share some of its code.
I'll post it on OSDN, when I get it to a "commit-ready" state.  I do have it
working, quite nicely, now, but with my MR macro override "uglified" by the
need to filter out '\%' prefixes, from its first argument.


___

Reply to this item at:

  

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

[bug #64202] [man-pages]: groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #3, bug #64202 (project groff):

[comment #1 comment #1:]
> Hi Keith,
> 
> I'm aware of this.  It's deliberate insofar as it's a consequence of other
decisions.
> 
> The main facts are these:
> 
> 1.  The new `MR` macro unconditionally prefixes its first argument with a
`\%` escape sequence to suppress hyphenation.

That's what I thought.  Consequently, there is _absolutely_ no need for
references, such as '.MR \%topic n', to _ever_ add that redundant '\%' prefix
to the topic name.

> 2.  All of _groff_'s man pages (.[157]) files are produced in the build tree
from from .man inputs.

Again, I'm well aware of this, but the '*.man' sources _do not_ specify the
redundant prefix, (other than incidentally, via a malformed transform for a
'@g@' prefix).

> 3.  The reason for that is that man page content is partially dynamic.  The
redundancy you're observing is the result of the "@g@" character sequence
being replaced by the ./configure-d command prefix in use by the build.  By
default, and in many build scenarios (of those I've seen personally, all
except for Solaris), this prefix is empty.

And, therein lies the bug ... for it _is_ a bug.  The intent of '@g@' is to
add a program name prefix -- typically 'g' for GNU programs -- so that 'tbl'
becomes 'gtbl', when appropriate; it has _absolutely no business_ to _ever_
include '\%' as part of that prefix.

(FWIW, the seat of the bug is within the substitution for '@g@', as it is
specified in the generated Makefile, at the point where 'topic.n' is generated
from 'topic.n.man').

> 4.  @g@ is expanded in several contexts, not just the first argument of
`MR`.  Wherever it occurs, it is part of a literal to which we do not want
automatic hyphenation to apply.

Understood.  However, the intent of '@g@' should _not_ be subverted, for this
unrelated purpose ... either specify '\%' _explicitly_, in any context where
it is intended, or introduce a specific transform, other than '@g@' itself,
which implies the effect of '\%@g@'.

> ...snip...
> 
> What do you think?

I think that this is an insidious bug, which should be fixed.


___

Reply to this item at:

  

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

[bug #64202] [man-pages]: groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

URL:
  <https://savannah.gnu.org/bugs/?64202>

 Summary: [man-pages]: groff_man(7) inconsistently (and
redundantly) guards some .MR references with '\%'
   Group: GNU roff
   Submitter: keithmarshall
   Submitted: Tue 16 May 2023 07:20:54 PM UTC
Category: Macro man
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 16 May 2023 07:20:54 PM UTC By: Keith Marshall 
The title mostly says it all.  When groff_man(7) refers to tbl(1), eqn(1), and
refer(1), it does so using a reference of the form:

.MR \%tbl 1

while, when referring to any other page, such as groff(1), it omits the '\%'
hyphenation guard prefix:

.MR groff 1

In this context, the '\%' prefix is redundant; the MR macro -- at least in the
fall back within the man page source -- supplies an additional one anyway. 
Furthermore, specifying such a guard in the macro call imposes an unnecessary
burden on any macro implementation which constructs, for example, a PDF
external reference based on the MR macro arguments, because the generated
reference address must be passed through a sanitizer routine -- an unnecessary
overhead, when MR already prepends the '\%' in running text.

To illustrate the issue, I've attached a copy of groff_man.7.pdf, generated
from your git master source, and formatted by my development copy of pdfroff,
with complementary '-manpdf', (which, in its present state of development,
does not incur any address sanitizer overhead):

GROFF_TMAC_PATH=/path/to/groff-pdfmark/tmac ./pdfroff -manpdf groff_man.7 >
groff_man.7.pdf

Note the malformed https references for tbl(1), eqn(1), and refer(1), in the
"See also" section,for example.






___
File Attachments:


---
Date: Tue 16 May 2023 07:20:54 PM UTC  Name: groff_man.7.pdf  Size: 71KiB  
By: keithmarshall
Illustration of malformed reference link addresses
<http://savannah.gnu.org/bugs/download.php?file_id=54755>

___

Reply to this item at:

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

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

[bug #64183] [pdfroff]: sanitize.tmac throws warning when -ww specified

[Keith Marshall]

URL:
  <https://savannah.gnu.org/bugs/?64183>

 Summary: [pdfroff]: sanitize.tmac throws warning when -ww
specified
   Group: GNU roff
   Submitter: keithmarshall
   Submitted: Thu 11 May 2023 09:14:45 PM UTC
Category: General
Severity: 3 - Normal
  Item Group: Warning/Suspicious behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 11 May 2023 09:14:45 PM UTC By: Keith Marshall 
After patching test-groff, per attached, to allow me to run pdfroff within the
groff build tree, and formatting pdfroff.1 as PDF, using my own as yet
unpublished anpdf.tmac, I see:

$ CMD=pdfroff ./test-groff -ww -manpdf -dpaper=a4 -P-pa4 -rFT='(-0.75i)'
../groff-pdfmark/build/pdfroff.1 > pdfroff.1.pdf
troff:../groff-pdfmark/build/pdfroff.1:2: warning: end index of substring out
of range, set to string length
...

(the same warning is repeated a further eight times, originating from
differing line numbers within pdfroff.1).

The warning originates from contrib/pdfmark/sanitize.tmac, after inspection of
the last character in the pdfhref address string, when attempting to discard
this character from the residual string.

I've already fixed this in
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/tree/tip/ groff-pdfmark, at
OSDN]; a patch, relative to your contrib/pdfmark version, (which also adds
some additional filters from my version of sanitize.tmac, which are not in
yours), is attached.






___
File Attachments:


---
Date: Thu 11 May 2023 09:14:45 PM UTC  Name: test-groff-command.patch  Size:
381B   By: keithmarshall

<http://savannah.gnu.org/bugs/download.php?file_id=54728>
---
Date: Thu 11 May 2023 09:14:45 PM UTC  Name: reference-sanitizer.patch  Size:
7KiB   By: keithmarshall

<http://savannah.gnu.org/bugs/download.php?file_id=54729>

___

Reply to this item at:

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

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

[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #10, bug #63133 (project groff):

[comment #9 comment #9:]
> [comment #8 comment #8:]
> > The underlying issue, with pdfroff, was fixed by
> >
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/commits/5d88cef1407d5bb625a1c23a888976f6efa80fab
commit 5d88cef1407d5bb625a1c23a888976f6efa80fab]:

> > 2023-02-24  Keith Marshall  
> > 
> > Do not emit redundant 'pdfhref Z' records.
> > 
> > * pdfroff.sh [grohtml-info] (pdfhref Z): Adapt awk script, to emit...
> > (pdfhref Z 0 0 0): ...this conditionally, only if at least one prior
> > record has been emitted; delete unconditional emission, which caused
> > the anomaly reported as groff issue #63133.


> > 
> > Okay to close?
> 
> Hi Keith,
> 
> I'd prefer not to close it here since it still affects groff's
> pdfroff and therefore likely the 1.23.0 release.
> 
> Unless we cherry-pick the fix...

Okay.  You might consider just copying my latest pdfroff.sh, accompanying
pdfroff.1.man, and everything in my tmac/ subtree, *except* s.tmac, (which is
just a verbatim copy of yours, at the time I forked groff-pdfmark, and yours
has evolved since then), but I'll leave it to your discretion.

> BTW, are you sure about that commit link?

Oops! It looks like I copied, and pasted the wrong link; it should have been
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/commits/69c99bee3ce93ddaae89026d61cea9bc75ecf453
commit #69c99bee]; (I should have noticed that the hash wasn't as I
expected).

> It seems to go to this change:

> Clean up Z-shell initialization logic.
> 
> * pdfroff.sh [ZSH_VERSION]: Tidy initialization code for...
> (NULLCMD, emulate sh): ...these; bring it more into alignment with
> contemporary GNU autoconf usage.


Indeed.  That's the immediate parent of the intended commit.

> In any case I'll take responsibility for it, on the assumption I'll
> be able to cherry-pick, and mark it "Confirmed" for want of a status
> that means "fix available elsewhere".

Okay; I'll leave it with you.


___

Reply to this item at:

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

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

[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #8, bug #63133 (project groff):

The underlying issue, with pdfroff, was fixed by
[https://osdn.net/users/keith/pf/groff-pdfmark/scm/commits/5d88cef1407d5bb625a1c23a888976f6efa80fab
commit 5d88cef1407d5bb625a1c23a888976f6efa80fab]:

2023-02-24  Keith Marshall  

Do not emit redundant 'pdfhref Z' records.

* pdfroff.sh [grohtml-info] (pdfhref Z): Adapt awk script, to emit...
(pdfhref Z 0 0 0): ...this conditionally, only if at least one prior
record has been emitted; delete unconditional emission, which caused
the anomaly reported as groff issue #63133.


Okay to close?


___

Reply to this item at:

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

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #12, bug #63827 (project groff):

[comment #11 comment #11:]
> [comment #10 comment #10:]
> > Should the 1.23 announcement/news mention that:
> > * the pdfmark bundled with this release of groff is not the latest code
(and provide a pointer to that code)?
> 
> I don't think they've diverged all that much.  ...
Sorry, but I beg to differ.  Since I forked it, I have added quite a
significant amount of new content to pdfmark.ms, (and hence to pdfmark.pdf). 
I've also improved, and sometimes corrected, a few features of pdfroff.sh
operation, corrected some issues which I've identified in pdfmark.tmac, and
added the new toc.tmac facility, to improve table of contents generation
capabilities.

I no longer maintain a free-standing ChangeLog file, within my repository, but
can generate one on demand, from the mercurial log; I've attached a copy of
that, spanning the period from the time of the fork, up to the latest
published commit, from which you should be able to glean some idea of the
changes I've already published.

In addition to my published changes, I have a queue of some 16 local patches,
yet to be finalized, but I anticipate fairly imminent publication of several
of them.

(file #54446)

___

Additional Item Attachment:

File name: ChangeLog  Size:17 KB




___

Reply to this item at:

  

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

[bug #60927] improve pdfmark documentation, including pdfroff(1)

[Keith Marshall]

Follow-up Comment #4, bug #60927 (project groff):

[comment #3 comment #3:]
> [comment #2 comment #2:]
> > Further work is still required, to cover the semantics of pdfroff(1),
> 
> Should this further work be documented in a ticket on OSDN?
I plan to cover it in section 4 of pdfmark.pdf, which I am currently working
on, so a specific ticket should not be necessary at this stage.  However, if
there are any specific topics, which you think I may otherwise overlook,
please do feel free to open a ticket.


___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #9, bug #63827 (project groff):

[comment #8 comment #8:]
> [comment #6 comment #6:]
> > [comment #3 comment #3:]
> > > ...
> > > groff's man pages all have that logic at the top and bottom that
> > > takes the body of the page out of compatibility mode, ...
> > As already noted in bug #63133 comment #1
, your code, to do that:
> [snip]
> > doesn't work on groff-1.22.x and earlier, (because those older
> > groff versions do not grok the 'cp' register).
> 
> [suggested replacement]:
> 
> .\" Save and disable compatibility mode (e.g., for Solaris 10/11).
> .nr _C \n(.C
> .do rnn _C *groff_pdfroff_1_man_C
> .cp 0
> 
> 
> This is similar to something I've had in my man.local for quite a while.
> 
> 
> .if \n(.x=1&\n(.y<23 \{
> .  \" Construct an equivalent of groff 1.23's .cp register.
> .  nr }{ \n(.C
> .  do nr .cp \n(}{
> .\}
> 
> 
> I'm not sure which I like better.  Yours does have appeal.
Either _should_ work, I think.  As you might expect, I tend to favour mine,
not just because it is _mine_, but because:
* It doesn't introduce any conditional version dependency; (feature test
conditions should _always_ trump version tests, but it doesn't even depend of
a feature test).
* It doesn't pollute the register namespace with a 'cp' register, which
wouldn't otherwise be present, and shouldn't be needed, (_unless_ there is
_another_ version dependency, within the document stream, which requires it).


___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #6, bug #63827 (project groff):

[comment #3 comment #3:]
> ...
> groff's man pages all have that logic at the top and bottom that
> takes the body of the page out of compatibility mode, ...
As already noted in bug #63133 comment #1
, your code, to do that:

.\" Save and disable compatibility mode (for, e.g., Solaris 10/11).
.do nr *groff_pdfroff_1_man_C \n[.cp]
.cp 0

doesn't work on groff-1.22.x and earlier, (because those older groff versions
do not grok the 'cp' register).  I think that we should endeavour to support
such older versions, at least for as long as contemporary software
distributions continue to deliver 1.22.x; thus, unless you can see anything
obviously wrong with it, I plan to replace this, in my pdfroff.1.man, with the
following, (as reflected in the attached patch):

.\" Save and disable compatibility mode (e.g., for Solaris 10/11).
.nr _C \n(.C
.do rnn _C *groff_pdfroff_1_man_C
.cp 0

which does appear to work, on groff-1.22.4 ... at least insofar as it doesn't
raise any warnings, when run with '-ww'.

(file #54393)

___

Additional Item Attachment:

File name: manpage-compatibility-save.patch Size:1 KB
   




___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #5, bug #63827 (project groff):

[comment #3 comment #3:]
> [comment #2 comment #2:]
> > ...
> > More importantly, my simple implementation relies on the '!d'
> > conditional, which I suspect may be groff-specific, (is it?),
> 
> Yes.  Subsection "Conditional expressions" of groff_diff(7) covers
> it, and the other extensions.
Thanks, but there is no such subsection, in the version of groff_diff(7) on my
Manjaro (Arch Linux) system.  The information is there, but not so easily
found.  In any event, I had been perusing 'info groff', which -- again in the
installed version -- does not make it clear that '.if d...' is a groff
extension, at the point where the conditional operators are described.
> ...
> > if we are concerned about non-groff compatibility,
> 
> The test is not so much for implementation of groff extensions as
> the likelihood of the `MR` macro being already defined by that
> implementation.  If one exists, I don't want to clobber it because
> it can do much more than just typeset the arguments.  It can embed
> hyperlinks on supporting output devices.
Provided the implementation which does exist will DTRT, w.r.t. the
expectations from using the groff >= 1.23 implementation, sure.  But if you
don't know for sure that any existing implementation mimics groff >= 1.23
behaviour, all bets are off; you surely *do* want to clobber it. 
> groff's man pages all have that logic at the top and bottom that
> takes the body of the page out of compatibility mode,
Sure, but what if that compatibility save, disable, then restore hack doesn't
work?  If the page source is passed through a formatter which doesn't support
the 'do' and 'cp' requests, or otherwise support groff extended syntax, then
all kinds of output garbage may ensue.
> and the pages generally use groff extensions like special characters
> that aren't documented in CSTR #54, often using the \[foo] syntax
> that also wasn't supported by AT troff.
In which case, attempting to retain even a modicum of support for legacy
formatting engines is likely a forlorn venture, so why bother?
> > can we safely use long register names, such as your 'do-fallback'?
> 
> I think we can, because Heirloom, mandoc(1), and older groffs
> support them.
I'm inclined to disagree, only to the extent that any legacy formatter may be
confused by them, but maybe I'm just being excessively pedantic.
> The idea is to get something that works on Heirloom Doctools troff,
> mandoc, and older versions of groff.  This doesn't work perfectly in
> general, but for the MR feature specifically, it does.
Fair enough, provided we're happy to abandon any hope of legacy formatter
support otherwise.


___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #2, bug #63827 (project groff):

[comment #1 comment #1:]
> Some changes, since then I already have captured, in some shape or
> form; some others, (at least one of which looks suspiciously wrong,
> to me...
I guess I shouldn't make such statements, without corroboration.  I had
planned to point out the utterly borked MR fallback, but I see you've reworked
it today!  FWIW, I had already implemented my own -- simpler -- fallback, in
my fork of pdfroff.1.man:

.if !d MR \{\
.\" This document uses the MR macro, which was not available prior
.\" to groff-1.23; this minimal local fallback emulation may suffice
.\" to support formatting with earlier versions of groff.
.de MR
.IR \%\\$1 (\\$2)\\$3
..
.\}

Granted, that doesn't address the possibility that MR might be invoked with
fewer than two arguments -- because pdfroff.1.man never calls it with fewer --
but that's a trivial adjustment, for the more general case.  More importantly,
my simple implementation relies on the '!d' conditional, which I suspect may
be groff-specific, (is it?), in which case, I need to address that.  However,
on a related note, if we are concerned about non-groff compatibility, can we
safely use long register names, such as your 'do-fallback'?


___

Reply to this item at:

  

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

[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #6, bug #63133 (project groff):

[comment #5 comment #5:]
> Bug #63827 is now open to track the removal of pdfmark from the
> groff git repository.  The following is more relevant to that bug,
And I will follow up there.
> but I'm starting it here because it's a reply to a comment here,
> and Keith is already cc:ed here.
Indeed, but I'm also subscribed to bug #63827.


___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #1, bug #63827 (project groff):

bug #63133 comment #5: 
> Bug #63827 is now open to track the removal of pdfmark from the
> groff git repository.  The following is more relevant to that bug,
> but I'm starting it here because it's a reply to a comment here,
> and Keith is already cc:ed here.
> 
> comment #3: 
> > Agreed.  I have, indeed, added significant new content to
> > pdfmark.pdf, (via pdfmark.ms), and some pdfroff enhancements,
> > which are not now included in groff's contrib/pdfmark tree.
> 
> There have also been 12 commits that have touched groff's
> contrib/pdfmark tree since the 2021-11-13 creation of the OSDN
> pdfmark, according to:
> 
> git log --since 2021-11-13 contrib/pdfmark
> 
> I presume these haven't been reflected in OSDN.
Some have, albeit not in exactly the same manner; some of the others, I will
address shortly.
> Many of them are part of larger changes to the groff code base,
> and may or may not be necessary
Those which impact, primarily, on the build infrastructure, are irrelevant; I
do not use automake, (and will not entertain doing so); I *do* use GNU make,
and make no apology for introducing GNU make specific constructs, within my
makefile.
> to keep the two interoperating happily, but someone familiar with
> the code will have to make that call for each change.
I'll be happy to look into any concerns; please feel free to bring any to my
attention, either by commenting on this ticket, or by opening one on my OSDN
groff-pdfmark ticket page
; (you may need to
create a personal OSDN account, for the latter).
> (This presumes that the OSDN repository was created from the latest
> groff git contrib/pdfmark at the time;
It was.
> if it was spawned from another source, there might be more
> divergence.)
Everything, up to the date of the fork, I have captured.  Some changes, since
then I already have captured, in some shape or form; some others, (at least
one of which looks suspiciously wrong, to me), I may need to address.


___

Reply to this item at:

  

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

[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #3, bug #63133 (project groff):

[comment #2 comment #2:]
> Long story short, the `.C` register didn't work for some of the use cases
people had for it, including the one seen above.
Yep.  The interaction between compatibility mode and '.C' is kind of tricky
... when compatibility mode is on, it needs to be interpolated using the
'\n(.C' syntax, because the '\n[.C]' syntax isn't "compatible":

$ printf '.cp 0\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = 0
$ printf '.cp 1\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = troff: :2: warning: number register '[' not defined
0.C]
$ printf '.cp 1\n.tm .C = \\n(.C\n' | groff -ww > /dev/null
.C = 1

Interaction with the '.do' request compounds the trickiness:

$ printf '.cp 1\n.do tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = 0
$ printf '.cp 1\n.do tm .C = \\n(.C\n' | groff -ww > /dev/null
.C = 0

It appears that the '.do' takes effect *before* the remainder of the request
line, (and in particular, the '\n(.C' evaluation), is parsed.  Thus, within
the scope of '.do', '\n(.C' must *always* evaluate to zero.  This isn't made
particularly clear, in the relevant groff documentation.
> This went unnoticed for a long time, I think, because relatively few people
tried to render many groff man pages in series using a single invocation of
the formatter.
Or ... perhaps more likely ... few people use groff directly, to render
manpages, and even those who may have done so didn't think to add the '-ww'
option?
> > Please note that this wider issue is not even related to pdfroff:
> > 
> > $ groff -ww -man src/roff/groff/groff.1 > /dev/null
> > troff: src/roff/groff/groff.1:25: warning: number register '.cp' not
defined
> > 
> > Does this merit its own bug report?
> 
> I don't think so.  It was a deliberate feature change.  I infer that you're
running the above commands using groff 1.22.4
Yes; it's what is installed by default, by the Manjaro derivative of Arch
Linux, (which is my current distro of choice).
> (else you wouldn't get the diagnostic message, which also hasn't been worded
that way since before commit 31e8ff9daf on 30 June 2021.
Fair enough.  I noticed it when formatting up-to-date pdfroff.1.man with
similarly up-to-date pdfroff, and with '-ww' in effect, per this ticket, but
underpinned by the system-native groff installation.
> On another subject:
> 
> > in my own groff-pdfmark development fork
.
> 
> In bug #63590, you expressed disinterest in maintaining pdfmark in the groff
source tree.
I no longer feel comfortable committing directly to the groff repo, following
the debacle when you deleted a published branch ...
> Would you prefer to make your OSDN the official pdfmark resource?
so yes, I would prefer to keep control of my own development tree.
> I don't think it would do anyone any good for contrib/pdfmark to bit-rot in
groff's contrib.
Agreed.  I have, indeed, added significant new content to pdfmark.pdf, (via
pdfmark.ms), and some pdfroff enhancements, which are not now included in
groff's contrib/pdfmark tree.


___

Reply to this item at:

  

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

[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #1, bug #63133 (project groff):

[comment #0 original submission:]
> Affects groff 1.22.4.
> 
> 
> $ echo | pdfroff -ww >/dev/null
> troff: /tmp/branden/pdfroff-ehedRan1l8/pdf41844.cmp:1: warning: macro
'pdfhref' not defined
> 

Obviously, since your test case doesn't load any PDF related macro sets,
pdfhref is not going to be defined.

I do appreciate the minimalism of your test case; with the addition of the
'--keep-temporary-files' option, it becomes trivially easy to identify the
source of the spurious 'pdfhref' reference.  However, since it runs pdfroff,
with no attempt to incorporate *any* PDF features, does it really provide a
compelling incentive to pursue the issue?  I hardly think so, but I *can* find
such an incentive in the '%.pdf:%.man' Makefile.in rule, in my own
groff-pdfmark development fork
. 
Specifically, (if I edit the generated Makefile, to remove the
'--no-reference-dictionary' and '--no-toc-relocation' options, the former of
which prevents the issue from arising, but then requires the latter to avoid
duplication of output), when I invoke this, I see:

$ make -C wip/build/ pdfroff.1.pdf MAN2PDF_FLAGS=-ww
make: Entering directory '/home/keith/projects/groff-pdfmark/wip/build'
/usr/bin/sed -e 's!@VERSION@!1.23.0!' -e 's!@MDATE@!20 February 2023!' -e
's!@PDFDOCDIR@!/usr/local/share/doc/!' -e 's!@MAN\([1-9]\)EXT@!\1!g'
../../pdfroff.1.man | GROFF_TMAC_PATH=../../tmac /bin/sh ./pdfroff -man -ww >
pdfroff.1.pdf
troff: ./pdfroff-jfeZdKTQvb/pdf19949.cmp:1: warning: macro 'pdfhref' not
defined
troff: :30: warning: number register '.cp' not defined
make: Leaving directory '/home/keith/projects/groff-pdfmark/wip/build'

This does, indeed, reproduce the issue which you report, (and I do have a
practical solution, *without* requiring the '--no-reference-dictionary'
option).  However, it also reveals a more insidious issue, (viz. the reference
to undefined '.cp' number register), which appears to be endemic among the
entire corpus of manpage sources, throughout the groff code base; it appears
to have been introduced by:

$ hg annotate src/roff/groff/groff.1.man
...
3963: .\" Save and disable compatibility mode (for, e.g., Solaris 10/11).
3963: .do nr *groff_groff_1_man_C \n[.cp]
3963: .cp 0
...

$ hg log -r 3963
changeset:   3963:01c8e28fa4bd
user:G. Branden Robinson 
date:Sun Oct 18 22:56:32 2020 +1100
summary: man pages: Make preambles consistent.

Please note that this wider issue is not even related to pdfroff:

$ groff -ww -man src/roff/groff/groff.1 > /dev/null
troff: src/roff/groff/groff.1:25: warning: number register '.cp' not defined

Does this merit its own bug report?


___

Reply to this item at:

  

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

[bug #63590] [pdfmark] some spelling mistakes found with "codespell"

[Keith Marshall]

Update of bug #63590 (project groff):

 Assigned to:   keithmarshall => None   


___

Reply to this item at:

  

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

[bug #63590] [pdfmark] some spelling mistakes found with "codespell"

[Keith Marshall]

Follow-up Comment #2, bug #63590 (project groff):

Thanks for flagging these typos; I committed
https://osdn.net/users/keith/pf/groff-pdfmark/scm/commits/c0904b57e9b63b369e627d45a067ce97b289d777
to my master repo, (and this is as far as I will pursue the matter).

I am rejecting any suggestion that "co-ordinate" is misspelled; it is
completely correct, according to my 1960's UK grammar school education, and
confirmed by my 1979 printing of the 6th edition of the Concise Oxford
Dictionary of English.

Furthermore, I would point out that the "connot" reference, although
misspelled, is actually correct in the ChangeLog context in which it appears,
and the misspelled "enviroment" reference is not my typo.  In any case, since
I no longer maintain a free-standing ChangeLog file, (having deprecated it in
favour of the mercurial commit log), I will be taking no associated corrective
action.


___

Reply to this item at:

  

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

[bug #60927] improve pdfmark documentation, including pdfroff(1)

[Keith Marshall]

Follow-up Comment #2, bug #60927 (project groff):

An expanded version of the pdfmark.pdf publication may be found at
https://osdn.net/users/keith/pf/groff-pdfmark/wiki/FrontPage

Further work is still required, to cover the semantics of pdfroff(1), but
section 2 does now provide substantially complete coverage of cross-reference
mark-up, and section 3 now covers ms document structuring considerations,
including the use of macros such as XH, XN, and their user-redefinable hooks,
for mark-up of section headings.

___

Reply to this item at:

  

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

[bug #61371] [PATCH] [tbl]: tbl.1.man: use neutral wording "decimal separator" in place of English specific "decimal point" and "dot"

[Keith Marshall]

Follow-up Comment #11, bug #61371 (project groff):

[comment #10 comment #10:]
> ...
> Keith's claim that "decimal separator" is "invalid terminology" is
> contradicted by Wikipedia's extensive, and extensively annotated, entry for
the term ,
> ...
Wikipedia is *not* authoritative.  Besides, the documentation in question *is*
in the the English language, so English-specific terminology is appropriate.

*Neither* the Oxford Dictionary of UK English ,
(formerly the Oxford Dictionary of World English, and AFAIK, authoritative
throughout the English-speaking world, outside the sphere of influence of the
USA), *nor* [www.merriam-webster.com/dictionary Merriam-Webster],
(authoritative in the US English-speaking world), offers *any* definition for
the term "decimal separator"; *both* define "decimal point", (with a more
comprehensive definition in Merriam-Webster).

POSIX.1-2017

consistently uses the "decimal point" terminology, (with "separator" *only*
applied to thousands digit grouping).

Nonetheless, if you wish to engender a impression of utter technical
ineptitude, by all means adopt this asinine change in terminology ... I really
couldn't care less, any more.

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Update of bug #58946 (project groff):

 Assigned to:   keithmarshall => None   


___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Follow-up Comment #12, bug #55107 (project groff):

Deri,

[comment #10 comment #10:]
> If you read the email referenced by Branden in comment #4
> You will see that I have answered your question, I apologise if
> you had difficulty understanding my answer regarding CropBox,
> I'm happy to try and explain it again, if needed.
Sorry, but I never saw that e-mail, and I certainly don't see an answer to my
question, or indeed any reference to CropBox, in what Branden quoted in
comment #4.  You confused me, when you omitted an appropriate link in comment
#3; I will look at the reference Branden suggested, when I have time.
> My proposal (D) was never intended to be a .pdfbb replacement (nor .psbb),
remember this ticket concerns problems with .PDFPIC
No, it doesn't ... it relates to an original suggestion, from four years ago,
to extend the functionality of the built-in psbb request, so that it could
return bounding box co-ordinates from single image PDF files, just as it
originally did for just EPS files, and so that an eventual implementation of
PDFPIC could avoid unsafe forks of third party tools, such as pdfinfo.
> If accusing someone on a public forum of holding you up by not answering
your question (when they have helpfully done so), is considered disgusting
language, perhaps we can be a bit less perl!
I accused you of nothing of the sort!  1) You are not holding me up in any
way, because this ticket is of only minor interest to me; I have plenty of
other tasks to occupy my time, and 2) it wasn't your apparent failure to
answer my question, (because I never saw your e-mail), that I considered to be
disgusting ... it is the perl language itself, to which I attribute that
description.

___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Follow-up Comment #9, bug #55107 (project groff):

Branden,

[comment #7 comment #7:]
> > but troff then incurs the overhead of setting up an IPC pipeline, to
capture the preprocessor output, then fork the preprocessor,
> 
> groff already handles all of this.
I don't think that it does...
> Some of the most important bits are:
> 
>
https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n54
>
https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n576
> https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/pipeline.c
> 
> ...or I am badly misunderstanding you.
Consider pre-grohtml; that *isn't* run within groff's normal pipeline; it is
forked, with its own subsidiary pipeline, as and when required.  One of my
earliest contributions to groff was to make that subsidiary pipeline setup,
and the associated fork, MS-Windows compatible, and I would anticipate a
similar overhead, if psbb were to be delegated to a preprocessor.


___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Follow-up Comment #8, bug #55107 (project groff):

[comment #5 comment #5:]
> Am I correct in guessing that a bounding box/MediaBox extractor would have a
lot of shared logic for PS and PDF?
No.  I wrote my proposed extractor as a lex/yacc parser; from its initial
state, it diverges into two entirely distinct branches of execution, on the
basis of whether the first few bytes of the image file are '%!PS-Adobe-' or
'%PDF-', (and aborts, if anything else); the two branches converge only at the
bitter end, when the yacc terminal rule (ultimately) assigns the troff
bounding box registers.

FWIW, my EPS parsing code is feature complete.  OTOH, the PDF parsing for PDF
works only for PDF-1.4 conformant files, (it lacks rules for interpretation of
XRefStm objects, Object streams, and deflated content).  The "significant
development", to which I referred, is extend the existing lex pattern set, and
yacc grammar, to support those additional features, (if required).

Personally, I don't see a justification for implementing psbb as a
preprocessor.  I am willing to pursue an extended lex/yacc implementation,
(subject to Deri actually answering the question I've now asked twice, without
a response: should CropBoxes, or any of PDF's other bounding box attributes,
have precedence over the MediaBox attributes?), but if you insist on pursuing
a solution in Perl ... a disgusting language, IMO ... then I'm out.

___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Follow-up Comment #6, bug #55107 (project groff):

Branden,

[comment #2 comment #2:]
> I have [an] historical question.
> 
> Does anyone know why `psbb` wasn't made a preprocessor in the first place? 
...
Sorry, I don't know; the choice was made, w.r.t. EPS files, before my
association with the project began.  I can imagine, however, it may be a
matter of convenience, because by having the psbb parsing code accessible as
linked in functions, the assignment to troff's internal registers is
straightforward, whereas, if the parsing is delegated to a preprocessor, not
only does that preprocessor have to implement the same parsing logic, but
troff then incurs the overhead of setting up an IPC pipeline, to capture the
preprocessor output, then fork the preprocessor, and ultimately, reinterpret
the preprocessor output to assign the requisite register values.

___

Reply to this item at:

  

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

[bug #61294] [ms]: Stuck in recursive page trap loop at short page length

[Keith Marshall]

Update of bug #61294 (project groff):

  Status:None => Fixed  
 Assigned to:None => keithmarshall  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Fixed by commit #8830820


___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Follow-up Comment #1, bug #55107 (project groff):

In this mailing-list message
[1], Deri
 offered two PDF files, namely
Picture.pdf
[2] and
croptest.pdf
[3],
from which the original prototype code
[4],
as referenced on this ticket, is unable to extract any valid MediaBox
specification.

In this follow-up message
[5], I
explained that the failure to extract the MediaBox from Picture.pdf was caused
by an omission from the groff-psbb lexer's pattern matching rules for the PDF
dictionary scanning state, resulting in mishandling of nested dictionaries;
this is readily resolved by the [file #52093 attached patch][6].

OTOH, croptest.pdf uses new PDF (post PDF-1.5) features, and lacks any trailer
dictionary, or free-standing cross reference table, (both of which are
_required_ by the current groff-psbb prototype implementation); to support
these new PDF features, substantial additions to the current implementation
will be required.

[1]: https://lists.nongnu.org/archive/html/groff/2021-09/msg00064.html
[2]: https://lists.nongnu.org/archive/html/groff/2021-09/pdf7tyGN4NLTE.pdf
[3]: https://lists.nongnu.org/archive/html/groff/2021-09/pdfBjudbNbwI2.pdf
[4]:
https://osdn.net/users/keith/pf/groff-psbb/scm/tree/e25e11c6770a3d7a2e98cbcfce66dbffd7d8b5a0/
[5]: https://lists.nongnu.org/archive/html/groff/2021-10/msg00043.html
[6]: [file #52093 patch file #52093]

___

Reply to this item at:

  

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

[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[Keith Marshall]

Additional Item Attachment, bug #55107 (project groff):

File name: nested-dictionary.patchSize:0 KB




___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #13, bug #58946 (project groff):

Agh!!!  Why can't savannah offer a sane UI, like OSDN?  Please ignore
[comment #12 prematurely submitted comment #12], (which I seem to be unable to
either edit, or delete)!

Here's what I wanted it to say:
[comment #11 comment #11:]
> > I'm wondering if there may be some justification for incorporation of
> > simplified versions of [XH and XN], and maybe also a minimal default
> > implementation of "XH-UPDATE-TOC", within s.tmac?
> > 
> > What do you think?
> 
> I think "yes"!  Please go for it.  ...
I've attached two proposed patches; [file #52067 patch #52067] adds minimal
implementations of XH and XN, (together with default implementations of
ancillary hooks XH-INIT, XN-INIT, XH-UPDATE-TOC, XH-REPLACEMENT, and
XN-REPLACEMENT), to s.tmac, while [file #52069 patch #52069] removes the
default XH-INIT, XN-INIT, and XH-UPDATE-TOC implementations from spdf.tmac,
(adopting those from s.tmac), and reimplements XH, and XN *indirectly*, in
spdf.tmac, using XH-REPLACEMENT and XN-REPLACEMENT respectively, rather than
redefining XH and XN directly.

In s.tmac, I've preserved the same calling syntax for XH, XN, and
XH-UPDATE-TOC, as I originally specified in spdf.tmac, (and as outlined in
comment #10), *except* that the -N, -S, and -X options are unsupported, for XH
and XN; I have retained  as a mandatory argument to
XH-UPDATE-TOC, (even though the default implementation in s.tmac ignores it),
since it is an essential component of the interface design.

I did agonize, for some time, over the default implementation of XH,
(specifically, how it should be protected against use before SH); I eventually
decided that, unlike the misuse of XN before NH, no such protection is
actually necessary.

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Additional Item Attachment, bug #58946 (project groff):

File name: spdf-xh-xn-update.patchSize:2 KB




___

Reply to this item at:

  

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

[bug #61294] [ms]: Stuck in recursive page trap loop at short page length

[Keith Marshall]

URL:
  

 Summary: [ms]: Stuck in recursive page trap loop at short
page length
 Project: GNU troff
Submitted by: keithmarshall
Submitted on: Tue 05 Oct 2021 09:46:27 PM UTC
Category: Macro - ms
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Consider the following:

$ cat foo.ms
.SH
.XH 0 Introduction
.TC

which I used to test a tentative implementation of XH, as proposed for
inclusion in s.tmac, in [bug #58946 ticket #58946].  If I run this thus, (as I
— perhaps carelessly — initially did):

$ echo .pl 12v | nroff -ms - foo.ms

nroff gets stuck in a recursive page trap loop, until the macro call stack
overflows.

Given that the sum of default header and footer margins, in ms, is equivalent
to 12v, in nroff, it's hardly surprising that there is a problem with this
example; at a page length of only 12v, there simply isn't any space to
accommodate page content!  There's even a relevant comment, in s.tmac itself:

.de cov*first-page-init
.\" Invoked by '.wh 0' trap on first page.
.\" We should not come here again, but at short page length,
.\" recursion may occur; remove trap and macro to avoid it.
.ch cov*first-page-init
.rm cov*first-page-init

This correctly identifies that a '.wh 0' page trap may induce a recursive
loop, at short page length; the problem is that the workaround, here, only
prevents recursion of the first-page trap — it completely neglects that
similar recursion is just as likely to occur when a '.wh 0 pg@top' trap is
assigned, and sprung on every subsequent page, with no defensive measures to
prevent it.

To mitigate this, we need to ensure that the specified page length, when the
'pg@top' trap is sprung, is no less than (u;'\n[HM]+\n[FM]+\n[.V])'; the
attached patch addresses this



___

File Attachments:


---
Date: Tue 05 Oct 2021 09:46:27 PM UTC  Name: ms-recursive-page-trap.patch 
Size: 828B   By: keithmarshall
Patch to defend against uncontrolled page trap recursion


___

Reply to this item at:

  

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

[bug #60927] improve pdfmark documentation, including pdfroff(1)

[Keith Marshall]

Follow-up Comment #1, bug #60927 (project groff):

Hi Kurt,

[comment #0 original submission:]
> Although pdfroff(1) mentions that "transparently handles the
> mechanics of multiple pass groff  processing,  when  applied
> to suitably marked up groff source files, such that tables of
> contents and body text are formatted separately, and are
> subsequently  combined  in  the  correct order, for final
> publication as a single PDF document" it does not indicate
> how to "suitably mark up groff source files."
Suitable mark-up is that described in section 2 of our pdfmark.pdf document,
(which is generated from pdfmark.ms).  Granted, that is rather incomplete; I
am working on it, and have several patches (mostly) ready to commit.

I believe that we could also benefit from the addition of a pdfmark(7), or
maybe better named as groff_pdfmark(7) manpage, and maybe also accompanied by
a groff_pdfhref(7) manpage, to document the appropriate mark-up.  I may
provide something suitable, after I've made pdfmark.pdf more complete.
> The pdfmark.ms file mentions that the .XN macro should be used to
> do this marking up, but the section about the .XN macro is empty
> so how to use it is not documented anywhere.
Uhmm, no.  "XN" (which is provided by spdf.tmac) is only a small element of
the "suitable mark-up"; it serves a very specific purpose, (viz. the
duplication of section heading text, following a "NH" macro call, into the PDF
document outline, and — now optionally — into the TOC diversion, as I've
recently explained on [bug #58946 ticket #58946]), but plays no specific rôle
in controlling the operation of pdfroff(1).

The collation effect of pdfroff(1) is actually controlled by a troff register,
named "PHASE"; if no collation is required, (e.g. as specified by the
"--no-toc-relocation" option), this may remain undefined, or may be defined as
zero; otherwise, it will be defined as 1, in the TOC generation phase, and as
2, in the body-content generation phase.  In each of these phases, the user's
document source is expected to set troff's "pen" state, through "\O" escapes,
as appropriate for each type of content; (completely blank pages, as generated
in the "pen-up" state — and thus, not pertinent in the active phase — will
be discarded during collation).  When formatting with "-mspdf", these phases
are handled transparently, but specific handling may be necessary, for users
of other primary formatting macro packages.

I plan to cover this, in pdfmark.pdf, but I agree that it should also be
documented in the pdfroff(1) manpage.

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #10, bug #58946 (project groff):

I have now reworked spdf.tmac, to incorporate only those macros identified in
comment #9 as "necessary"; I _have_ included a completely reworked
implementation of "XN", (which also serves as a new "XH" macro, courtesy of
groff's .als mechanism).

As now implemented, the "XH" and "XN" macros conform to the following calling
syntax:

.SH
.XH [-option ...]   ...

.NH 
.XN [-option ...]  ...

In both cases, the permitted options are:

-NPlace a pdfhref destination mark, with the given name,
at the location of this heading.

-S  Sanitize  (by removal of "\F" escapes)
for use in the PDF document outline.

-X  Create a pdfhref cross-reference dictionary entry for
this heading; use the destination name specified by
-N , if given, or the first word taken from
 if not.

Both of these new macro implementations ("XH" and "XN") reproduce their
 argument(s) as running text, in the appropriate heading
font/size, and as PDF document outline entries, at the specified
, and sanitized as required.  Neither creates a TOC entry, by
default; however, each invokes a pair of callback hooks:

XH-INIT
XN-INIT
   Called on entry to XH, and XN respectively; by default, each is
   a no-op, but either, or both, may be redefined by the user, to
   perform any respective initialization, for use by:

XH-UPDATE-TOC  [] 
   Called by both XH and XN, (the  argument is
   omitted, when called by XH, and always present, when called by
   XN); once again, this is a no-op by default, but may be redefined
   by the user, to generate TOC entries.

As I had previously observed in comment #4, neither this implementation of
"XN", nor its new "XH" sibling, is an appropriate candidate for inclusion in
s.tmac; however, given this statement in the groff online manual
 (not
reproduced in groff_ms(7)):

The Groff and Friends HOWTO includes a sed script that automatically inserts
XS and XE macro entries after each heading in a document.

Altering the NH macro to automatically build the table of contents is perhaps
initially more difficult, but would save a great deal of time in the long run
if you use ms regularly.

and given that "XH" and "XN" can facilitate linking of TOC entries to section
headings, I'm wondering if there may be some justification for incorporation
of simplified versions of each of these, and maybe also a minimal default
implementation of "XH-UPDATE-TOC", within s.tmac?

What do you think?

___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[Keith Marshall]

Update of bug #61022 (project groff):

 Planned Release:None => 1.23.0 

___

Follow-up Comment #7:

Hi Branden,

As discussed on [bug #61157 ticket #61157], I've pushed the two attached
patches, (folded into one).  I'll leave it to you, to review the manpage
updates, handle info integration — I'm clueless, when it comes to writing
texinfo — and close at your discretion.

___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

Update of bug #61157 (project groff):

 Assigned to:   keithmarshall => gbranden   
 Planned Release:None => 1.23.0 

___

Follow-up Comment #7:

Hi Branden,

[comment #6 comment #6:]
> [comment #5 comment #5:]
> > Would you like me to [also] push my corresponding proposed
> > groff_ms(7) manpage patch, (and also those I've attached to
> > [bug #61022 ticket #61022], relating to FS-MARK and FP)?  Or, would you
prefer
> > to take ownership of the documentation aspect yourself?
> 
> Sure, go ahead!  ...
> I can always do my fastidious doc sync-ups and nit-picks after
> your changes land.
I've now finalized, and pushed all related patches; reassigning to you, for
manpage review, and info integration.

___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

Follow-up Comment #5, bug #61157 (project groff):

Branden,

[comment #4 comment #4:]
> [comment #3 comment #3:]
> > [comment #1 comment #1:]
> > > Will you follow up with a patch to the documentation, or would [you]
prefer me to write it?
> > I'll tackle the manpage update, if you wish, ...
> Proposed manpage patch attached.
> 
> (file #51924)
In my local sandbox, I've adapted pdfmark.ms to use TC-LEADER, and TC-MARGIN,
so I would like to push the s.tmac patch, fairly soon, (followed by several
pdfmark.ms updates).

Would you like me to also push my corresponding proposed groff_ms(7) manpage
patch, (and also those I've attached to [bug #61022 ticket #61022], relating
to FS-MARK and FP)?  Or, would you prefer to take ownership of the
documentation aspect yourself?

___

Reply to this item at:

  

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

[bug #60927] improve pdfmark documentation, including pdfroff(1)

[Keith Marshall]

Update of bug #60927 (project groff):

  Depends on: => bugs #58946


___

Reply to this item at:

  

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

[bug #61167] "make man" does not generate manpages, as it should

[Keith Marshall]

Follow-up Comment #4, bug #61167 (project groff):

In [comment #1 comment #1,] Branden said:
> Can you tell me where in the GNU Coding Standards document that a 'man'
target that generates man pages is mandated?
Section 7.2.6 "Standard Targets for Users"; at least that's where I had a
recollection of having seen it.
> Not saying it's a bad idea, I just can't locate the authority you're
citing.
My apologies; I thought "man" was among the alternative documentation formats,
but apparently, my recollection is mistaken; "man" does not appear to be a
mandatory target.

Notwithstanding, we *do* provide a "man" target, and it is completely
incongruous that invoking it elicits the response, "'man' is up to date", when
it clearly isn't!  To get the required effect, one must invoke the "all"
target, yet the GCS explicitly *does* say that "all" should *not* build
documentation, (other than, maybe, info: the actual statement suggests that
"all" need not build any documentation, since pre-built info files should be
included in the distribution, and all other formats should be requested
explicitly).
> I also don't see "man" in the list of standard targets documented in GNU
Automake.
>
https://www.gnu.org/software/automake/manual/html_node/Standard-Targets.html#Standard-Targets
That's hardly authoritative; the authoritative source is GCS section 7.2.6:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
  
In follow-up [comment #3 comment #3,] Ingo said:
> Well-designed manual pages simply don't need to be built, just installed. 
So i don't see a problem with including them in the "install" target - and if
afflicted with the autoconf disease, also in the "all" target; but in most
cases, that disease only causes mild pain and suffering for manual pages, so
"man -l foo.man.in" usually works well enough anyway if you want to read these
files without installing them.
Maybe so, but our manpage sources *do* include templated substitutions, which
need some make target to process them.  It may well be sufficient for that
target to be "install"; I also don't object if "all" performs said
substitutions, in spite of the implied GCS non-compliance.  I *do*, however,
find it incongruous that, when we have a "man" target in place, it doesn't do
the job that it should!

> Providing extra user-visible targets for every trivial detail runs conter to
the important goal of keeping build systems simple and easy to maintain.
However, it is often convenient, (and I often find it helpful, from a
maintenance perspective), to implement user-visible targets in terms of
internal targets; although not necessarily intended to be user-visible, if any
of these make sense in a user-visible context, (as a "man" target may do),
then I see no grounds for objection.

BTW, I cannot agree with the categorization of autoconf as a "disease" ... I
find it to be a genuinely useful tool.  OTOH, automake ... well, I could view
that as a disease, and I'll say no more.

___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[Keith Marshall]

Follow-up Comment #6, bug #61022 (project groff):

As an adjunct to my tentative proposal for FS-MARK documentation, previously
attached, I've further produced a tentative update to the groff_ms(7) manpage,
to document FP; this is now also attached.

(file #51947)
___

Additional Item Attachment:

File name: ms-fp-manpage.patchSize:2 KB




___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[Keith Marshall]

Follow-up Comment #5, bug #61022 (project groff):

Hi Branden,

On [bug #61157 ticket #61157], you added an incidental comment:
> ... I intended to document FS-MARK but found myself confused with respect to
use cases.  I'll follow up with you about that elsewhere since it's off-topic
for this ticket.
to which I replied that it would be appropriate to discuss it here.

The use-case, which I had identified at the time when I proposed the FS-MARK
callback hook, arose out of difficulties I was experiencing when trying to
create pdfhref links between footnote markers in body text, and the footnote
itself; it is basically an adaptation of the sample technique I illustrated in
comment #3, with a document-local redefinition of FS-MARK replacing my
original pdf:fn.mark macro, and obviating the need to redefine @FS:

.ds * \c
.de FS-MARK
.\" Macro to replace original duty performed by "\**"; invoked by
.\" callback from FS, BEFORE recording of the associated text within
.\" the footnote diversion is commenced.
.\"
.ie \\n[.$] \{\
.   pdfhref L -D pdf:fn\\$1 -- \*{\\$1\*}
.   pdfhref M -N pdf:fn\\$1r
.   \}
.\"
.\" Reference to this undocumented s.tmac counter is unfortunate, but
.\" I don't see an alternative, when "\**" no longer updates it; maybe
.\" s.tmac could expose a more suitable (documented) alias.
.\"
.el .\\$0 \\n+[fn*text-num]
..
.de FP
.\" Override s.tmac's (undocumented) footnote output hook; this emulates
.\" the default output style for \n[FF] == 3 footnotes, with the footnote
.\" number formatted as a pdfhref link back to the position at which the
.\" footnote marker appears, within the document text.
.\"
.@LP
.ds pdf:fn.tag \s'-1.5p'\\$1.\s'+1.5p'
.nr pdf:fn.tag.width (u;\\n[\\n[.ev]:PI]*2)
.pdfhref M -N pdf:fn\\$1
.in +\\n[pdf:fn.tag.width]u
.ti -\\n[pdf:fn.tag.width]u
.nr pdf:fn.tag.width -\\w'\\*[pdf:fn.tag]'u
.pdfhref L -D pdf:fn\\$1r -A \\h'\\n[pdf:fn.tag.width]u'\c -- \\*[pdf:fn.tag]
..

I've since discovered that I _can_ achieve the same effect, by redefining the
"*" string, without requiring the FS-MARK callback hook, but the redefinition
is messy, and far from intuitive, so I believe the callback is still
justified.  If it helps, I've attached a tentative manpage patch, to document
it.

You may note that a reference to the (undocumented) ms internal register,
fn*-ext-num is still present in the above sample code; I'm still exploring
possibilities for avoiding that.

(file #51946)
___

Additional Item Attachment:

File name: ms-fs-mark-manpage.patch   Size:0 KB
   




___

Reply to this item at:

  

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

[bug #61167] "make man" does not generate manpages, as it should

[Keith Marshall]

URL:
  

 Summary: "make man" does not generate manpages, as it should
 Project: GNU troff
Submitted by: keithmarshall
Submitted on: Wed 15 Sep 2021 11:04:52 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

To me, this looks like a GCS non-compliance: with a fresh git clone, after
running "./bootstrap", and "./configure", I expect "make man" to generate
manpages, but I see

$ make man
make: 'man' is up to date.

and no manpages are generated; to get them, I have to run (effectively) "make
all".

This is *not* the behaviour stipulated by the GNU Coding Standards: "make all"
is *not* supposed to generate manpages; that is the job of "make man"! 
Requiring me to execute "make all", instead of "make man" is overkill: it
forces me to build the whole kit and caboodle, when all I wanted was the
manpages.




___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

Follow-up Comment #4, bug #61157 (project groff):

[comment #3 comment #3:]
> [comment #1 comment #1:]
> > Will you follow up with a patch to the documentation, or would [you]
prefer me to write it?
> I'll tackle the manpage update, if you wish, ...
Proposed manpage patch attached.

(file #51924)
___

Additional Item Attachment:

File name: ms-toc-manpage.patch   Size:2 KB




___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

Follow-up Comment #3, bug #61157 (project groff):

[comment #1 comment #1:]
> This proposal seems fine to me.
Thanks, Branden.
> Will you follow up with a patch to the documentation, or would prefer me to
write it?
I'll tackle the manpage update, if you wish, but I am not at all familiar with
texinfo, so perhaps you could attend to that, please?

___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

Follow-up Comment #2, bug #61157 (project groff):

[comment #1 comment #1:]
> ... I intended to document FS-MARK but found myself confused with respect to
use cases.  I'll follow up with you about that elsewhere since it's off-topic
for this ticket.
There is a strong hint to the use-case, on ticket #61022
; I suggest that further
discussion be directed there.

___

Reply to this item at:

  

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

[bug #61157] [ms]: Add support for user-defined styling of TOC leaders

[Keith Marshall]

URL:
  

 Summary: [ms]: Add support for user-defined styling of TOC
leaders
 Project: GNU troff
Submitted by: keithmarshall
Submitted on: Tue 14 Sep 2021 09:33:25 PM UTC
Category: Macro - ms
Severity: 3 - Normal
  Item Group: New feature
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

ms defines the leader character, for use within tables of contents generated
by XS/XA, as:

.char \[toc*leader-char] .\h'1m'

Personally, (and this is, strictly, just my opinion),  I think that 1em of
space between the leader dots is too much.  Unfortunately, that definition of
'toc*leader-char' appears within the body of the PX macro, (which is used to
emit the collected table of contents), so even knowing the (undocumented)
internal name, I cannot easily override the hard-wired definition.

I would like to apply a patch, such as the attached, so that users will have
an opportunity to adjust the leader style, and the width of the width of the
following right-hand margin, (in which the page number is placed), by defining
TC-LEADER and TC-MARGIN respectively, (both of which we can document),
_before_ invoking PX; (in the event of neither being predefined, the behaviour
would remain _identically_ as at present).



___

File Attachments:


---
Date: Tue 14 Sep 2021 09:33:25 PM UTC  Name: ms-toc-leader.patch  Size: 912B  
By: keithmarshall
Patch to support TOC leader styling


___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #9, bug #58946 (project groff):

Ignoring those intended exclusively for internal use, (which I've elided from
the following), in spdf.tmac I see:

$ hg grep -r qparent '^\. *de ' spdf.tmac
contrib/pdfmark/spdf.tmac:5357:.de OMIT OMIT
contrib/pdfmark/spdf.tmac:5357:...
contrib/pdfmark/spdf.tmac:5357:.de XM
contrib/pdfmark/spdf.tmac:5357:.de XR
contrib/pdfmark/spdf.tmac:5357:.de XN
contrib/pdfmark/spdf.tmac:5357:...
contrib/pdfmark/spdf.tmac:5357:.de LU
contrib/pdfmark/spdf.tmac:5357:.de AN
contrib/pdfmark/spdf.tmac:5357:...
contrib/pdfmark/spdf.tmac:5357:.de OP
contrib/pdfmark/spdf.tmac:5357:.de NN
contrib/pdfmark/spdf.tmac:5357:...
contrib/pdfmark/spdf.tmac:5357:.de PXREF
contrib/pdfmark/spdf.tmac:5357:.de IS
contrib/pdfmark/spdf.tmac:5357:.de IE
contrib/pdfmark/spdf.tmac:5357:.de TC
contrib/pdfmark/spdf.tmac:5357:...

Of these, OMIT, OP, and TC are required to support the partitioned document
assembly mechanism of pdfroff.sh; as such, I would suggest that they should
remain in spdf.tmac.

Of the remainder, perhaps only XN, (with modification), is worthy of
consideration as a strictly necessary adjunct, and maybe XR as a convenient
addition.  All of the rest are essentially redundant, and may even be
worthless!  Here's what they do:

XN: sets its arguments as text, for use within the numbered heading following
NH, additionally using the same text as the content of a PDF document outline
entry, and within a TOC entry.  The modification, which I propose, is that
formatting of the TOC entry should be delegated to a user-defined callback
macro, (hence a document-local macro).  I also propose adding a complementary
XH macro, serving a similar purpose following SH.

XR: creates a ".pdfhref L" reference to a named destination, using semantics
similar to ms .B, or .I, with \$1 as the destination name, \$2 as argument to
the pdfhref "-A" option, and \$3 as argument to "-P"; reference text is
derived from the reference dictionary entry, created by ".pdfhref M".  If
deemed worthy of retention, maybe consider modification, to allow additional
arguments beyond \$3, to specify reference text.

XM: strict shorthand for ".pdfhref M -X".  Certainly not necessary.  If any
user wants such shorthand, I think it really should be defined locally to
their own document.

LU: surely not worthy of inclusion; it inserts an LP paragraph, stating — in
English — that content is to be added at some unspecified future time! 
Should be document-local, if wanted.

AN: inserts an SH heading, with default text "Note", but taking an optional
argument to override that.  It originates from my workplace documents, where I
used to introduce note, or warning annotations, or similar.  In hindsight, I
think I should have made it document-local.

NN: a contraction of NH, followed by XN, with some added bells and whistles. 
IIRC, I wrote this for one particular workplace document template; I
definitely should have kept it local.

PXREF: a parenthetical variation of XR; should be document-local.

IS:
IE: utterly useless.  Do much the same as QS...QE, which should be used
instead

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #8, bug #58946 (project groff):

[comment #7 comment #7:]
> Looks good to me--go for it!
Thanks, Branden,

It's currently sitting at 4th position, in my local patch queue; I'll push it,
after I've dealt with the three which precede it. 

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #6, bug #58946 (project groff):

I'd like to add a hook, in s.tmac's @FS macro, to facilitate bidirectional
pdfhref linking between the footnote mark (in running text), and the footnote
itself.

Okay to apply, and commit, the attached patch?  Is FS-MARK an acceptable name
for the hook macro?  (I was tempted to abuse the existing DEVTAG "namespace",
but since this hook may not normally be expected to write tag information to
the output device stream, that doesn't really seem appropriate).

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Additional Item Attachment, bug #58946 (project groff):

File name: ms-footnote-marker-hook.patch  Size:1 KB
   




___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[Keith Marshall]

Follow-up Comment #3, bug #61022 (project groff):

[comment #2 comment #2:]
> To achieve a viable mechanism for implementing the forward footnote links, I
think we need to a) redefine "\**" as "\c", and b) provide a hook within "FS",
(which then *cannot* be separated from the mark location), to manage the
counter, and plant the mark as a pdfhref link.  For the reverse link, we would
need a complementary hook within what is currently "FP", (whether that name is
retained, or some alternative is substituted).
To illustrate my point, here's a document-local change, which I have added to
my working copy of pdfmark.ms:

.\" Redefine the FS macro (from s.tmac) to facilitate the placement of
.\" footnote reference marks, with each serving as a pdfhref link to the
.\" associated footnote itself.
.\"
.\" FIXME: This may be a candidate for inclusion in spdf.tmac; (note that,
.\" when defining it before the first page has begun, we must refer to the
.\" s.tmac internal name, "@FS", rather than to FS itself; better still,
.\" rather than any redefinition of @FS, would be a hook in the s.tmac
.\" implementation itself, to which pdf:fn.mark could be attached).
.\"
.rn * pdf:*
.rn @FS pdf:fn.record
.ds * \c
.de pdf:fn.mark
.\" Macro to replace original duty performed by "\**"; must be invoked
.\" at point of footnote mark placement, e.g. by FS, BEFORE recording of
.\" the associated text within the footnote diversion is commenced.
.\"
.ie \\n[.$] \{\
.   pdfhref L -D pdf:fn\\$1 -- \*{\\$1\*}
.   pdfhref M -N pdf:fn\\$1r
.   \}
.\"
.\" Reference to this undocumented s.tmac counter is unfortunate, but
.\" I don't see an alternative, when "\**" no longer updates it; maybe
.\" s.tmac could expose a more suitable (documented) alias.
.\"
.el .\\$0 \\n+[fn*text-num]
..
.de @FS
.\" Replacement for default FS payload implementation; handles footnote
.\" mark placement, as specified above, before recording the content of
.\" the footnote itself.
.\"
.pdf:fn.mark
.pdf:fn.record
..
.de FP
.\" Override s.tmac's (undocumented) footnote output hook; this emulates
.\" the default output style for \n[FF] == 3 footnotes, with the footnote
.\" number formatted as a pdfhref link back to the position at which the
.\" footnote marker appears, within the document text.
.\"
.@LP
.ds pdf:fn.tag \s'-1.5p'\\$1.\s'+1.5p'
.nr pdf:fn.tag.width (u;\\n[\\n[.ev]:PI]*2)
.pdfhref M -N pdf:fn\\$1
.in +\\n[pdf:fn.tag.width]u
.ti -\\n[pdf:fn.tag.width]u
.nr pdf:fn.tag.width -\\w'\\*[pdf:fn.tag]'u
.pdfhref L -D pdf:fn\\$1r -A \\h'\\n[pdf:fn.tag.width]u'\c -- \\*[pdf:fn.tag]
..

Note that, to successfully inject the necessary pdfhref requests, at
appropriate locations, I need to redefine "@FS" and "FP", neither of which is
formally documented, in addition to "\**", which is.

___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[Keith Marshall]

Follow-up Comment #2, bug #61022 (project groff):

[comment #1 comment #1:]
> It certainly does seem like it was intended for a hook.  The implementation
dates back to the dawn of repo time.
> 
> 
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1582) .de FP
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1583) .br
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1584) .if !d par*fp!\\n[FF] \{\
> 1294c8d22 tmac/s.tmac   (G. Branden Robinson  2017-11-18 17:55:26 -0500
1585) . @error unknown footnote format '\\n[FF]'
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1586) . nr FF 0
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1587) .\}
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1588) .ie '\\$2'no' .par*fp!\\n[FF]-no "\\$1"
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1589) .el .par*fp!\\n[FF] "\\$1"
> ^351da0dc macros/tmac.s (James Clark  1991-06-02 04:20:34 -0500
1590) ..
> 
> 
> ...but we've gotten along for 30 years without exposing it in
documentation...do we really need it?  Is it worth the clash with Plan 9? 
(Although I have to say, using any amount of API on the ultra-legacy font
mounting position feature seems like a waste to me.)
> 
> You certainly don't need .FP to do paragraphing within a footnote; the
normal ones work fine.
They do, until you need some sort of hook, to implement pdfhref links from the
footnote mark, to the footnote text, and back again!
> Do you agree?  Should the comment be rewritten, maybe?
Well, the current support for footnotes, in s.tmac, is already inconsistent
with Mike Lesk's original implementation; he didn't have the "\**" string, and
there was no requirement for any similar construct, planted before ".FS", to
manage the footnote counter.

Some background may be helpful.  I'm looking at pdfmark.ms, (which I've left
in a rather unsatisfactory state of incompletion for way too long).  At the
bottom of page 2, (the introduction), are five footnotes; two of them are
linked, (from the mark to the footnote, but not back).  Implementing even
those two forward links was a pain; "\**" itself is an impediment, because it
defies any attempt to wrap it as a pdfhref link, unless I abandon use of its
string invocation, in the manner it is documented.

To achieve a viable mechanism for implementing the forward footnote links, I
think we need to a) redefine "\**" as "\c", and b) provide a hook within "FS",
(which then *cannot* be separated from the mark location), to manage the
counter, and plant the mark as a pdfhref link.  For the reverse link, we would
need a complementary hook within what is currently "FP", (whether that name is
retained, or some alternative is substituted).

___

Reply to this item at:

  

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

[bug #61022] [ms]: Documention neglects to mention FP macro

[Keith Marshall]

URL:
  

 Summary: [ms]: Documention neglects to mention FP macro
 Project: GNU troff
Submitted by: keithmarshall
Submitted on: Sat 07 Aug 2021 09:31:22 PM UTC
Category: Macro - ms
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Internally, groff's s.tmac defines a macro called "FP", and uses it to control
the printing of footnotes.  At the point of definition, I see:


.\" This can be redefined. It gets a second argument of 'no' if the
.\" first argument was supplied by the user, rather than automatically.
.de FP
...


To me, this suggests that the intention is to provide a hook, (albeit
inconsistent with other ms implementations — e.g. Plan-9's ms manpage
documents an FP macro associated with font positions), whereby the user may
choose to modify the appearance of footnotes, yet the documentation (neither
manpage, nor info) has absolutely no mention of it.




___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #5, bug #58946 (project groff):

[comment #4 comment #4:]
> Just one point of clarification:
> 
> [comment #3 comment #3:]
> > I merely cobbled the current incarnation of spdf.tmac
> > together, while writing pdfmark.ms; it became a conveinent
> > "dumping ground" for supplementary convenience macros, which I
> > used within pdfmark.ms, and in hindsight, would have been better
> > implemented as document-local macros.  XN is one such, (and one
> > which exhibits implementation failings, which I never managed to
> > successfully resolve); there are others, which could similarly
> > be considered for factoring out, as document-local macros.
> 
> Document-level within pdfmark.ms, you mean?
Yes.

> Are the macros you speak of (XN, et al) not general-purpose
> enough to include in pdfmark.tmac?
Definitely *not* in pdfmark.tmac; that's substantially complete, as it stands,
but it is what groff_tmac(5) dubs a "supplemental", or "auxiliary" macro set;
it shouldn't be polluted by anything which is specific to any one of the
"major", or "full-service" macro packages, of which "ms" is just one example.

Similarly, s.tmac shouldn't be made dependent on a stand-alone auxiliary macro
set, on which it has no existing dependency; I contend that a binding package,
such as spdf.tmac is the logical place to implement the interface.

Some of the stuff I shoved into spdf.tmac is nothing more than "syntactic
sugar" — shorthand for features which pdfmark.tmac already supports
adequately, with just a shorter "ms" style name.  Those, I would suggest,
don't really deserve an existence beyond document-local scope — if we
consider pdfmark.ms as an example, then that's where they belong.

That said, XN is one of the macros I dumped into spdf.tmac, which may be a
candidate for remaining there — but not as it stands at present.  It
exhibits flaws, which would need to be addressed; however, it does attempt to
address an extant limitation of "ms" itself: NH, and SH, simply instruct roff
to format the text which follows, up to the next following paragraph macro
call, as a section heading.  There is no inherent provision to use any of that
text, as the basis for a TOC entry, or as a PDF document outline entry, so the
author is left repeating content, for the three contexts; XN, when used
immediately after NH, attempts to address that limitation, by reproducing its
arguments in each of those contexts, (including the section number generated
by NH, in the TOC and PDF document outline contexts, a variant would be
required, for use after SH).

___

Reply to this item at:

  

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

[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #3, bug #58946 (project groff):

[comment #2 comment #2:]
> >> In the groff system, XN is defined in spdf.tmac
> > 
> > Which, I would suggest, it should NOT be 
> > 
> > Since it is provided purely as an example, it has no place in
> > ANY of the standard macro packages; it would be more appropriate
> > to relocate it to an "examples" repository, and, in hindsight
> > I should have defined it directly within pdfmark.ms
> 
> Keith, if this is the only task, I'll update this bug's Summary accordingly.
 (Probably the summary needs to be updated anyway, since your post implies the
bulk of the work for integrating ms and pdfmark is done, with merely some
housekeeping left to take care of.)

I never _really_ intended spdf.tmac as anything more than an example of — or
potentially, a foundation for — development of bindings for use of
pdfmark.tmac in conjunction with some other document formatting macro package
... s.tmac, in this particular case.  Just as POSIX extends ISO-C, with the
extensions normally being implemented through supplementary header files and
libraries, pdfmark.tmac extends s.tmac, (and potentially other macro packages
which offer similar functionality to s.tmac); spdf.tmac provides the
supplementary "glue" to bind pdfmark.tmac features to s.tmac, but nothing
within spdf.tmac really belongs as an integral part of s.tmac itself.

That said, I merely cobbled the current incarnation of spdf.tmac together,
while writing pdfmark.ms; it became a conveinent "dumping ground" for
supplementary convenience macros, which I used within pdfmark.ms, and in
hindsight, would have been better implemented as document-local macros.  XN is
one such, (and one which exhibits implementation failings, which I never
managed to successfully resolve); there are others, which could similarly be
considered for factoring out, as document-local macros.

So yes, spdf.tmac could _definitely_ benefit from some housekeeping, before
formal adoption as a binding between s.tmac and pdfmark.tmac; s.tmac itself
should require no associated modification.  (I left pdfmark.ms very much
incomplete, so that will require some further attention; I've also observed
some issues which may be best address within pdfmark.tmac, but these should
likely be addressed by way of separate tickets).

___

Reply to this item at:

  

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

Re: Solar Designer groff tempfile audit

[Keith Marshall]

On 23/06/11 13:39, Ingo Schwarze wrote:
 i just committed the follwing to the OpenBSD ports tree,
 where i'm maintaining a port of groff-1.21.

As you are perfectly entitled to do; however...

 This posting includes a commit message and a patch at the end.

I cannot accept this patch.  I had a similar discussion a year or two
ago, with Colin Watson of Debian/Ubuntu.  Your patch would make pdfroff
completely dependent on the availability of a working mktemp.  I cannot
assume that such a dependency will always be satisfied; indeed, until
very recently, no such utility was available on the MS-Windows/MSYS
platform which, for me, is where I have most need of pdfroff.

Some form of fall back is necessary, in the event that the host does not
provide a working mktemp; I will not accept any patch which fails to
recognise this.

-- 
Regards,
Keith.

___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

Re: Fw: [sand...@crustytoothpaste.ath.cx: Bug#538330: groff: pdfroff uses (and documents!) insecure temporary files]

[Keith Marshall]

On Sunday 16 August 2009 23:13:29 Colin Watson wrote:
 (Any particular reason why this isn't CCed to bug-groff?)

Only because Werner forwarded your original post to me privately, as 
an encapsulated message, and KMail's Reply-to-All didn't pick it 
up.  I've added it, this time around.

 On Sun, Aug 16, 2009 at 10:43:44PM +0100, Keith Marshall wrote:
  On Saturday 15 August 2009 09:26:25 Werner LEMBERG wrote:
   On Sat, Jul 25, 2009 at 09:30:18AM +0100, Colin Watson wrote:
See attached report; this is indeed a standard anti-pattern
resulting in security vulnerabilities. In Debian I'd be
rather tempted to use 'mktemp -d' to fix this. What do you
think?
  
   Nico Golde points out that Openwall have a patch for this. I'm
   applying this to the Debian package:
 
  Sorry, but I'm not going to accept this as is; it exhibits
  several unacceptable portability issues:--

 I understand; I hope you can also understand that I would rather
 have the Debian security team not hate me, so I applied it anyway
 pending discussion of something better. :-)

Sure.  What you do for Debian and Ubuntu is entirely your choice; I 
have to consider portability to a wider systems population.

-  WRKFILE=${GROFF_TMPDIR=${TMPDIR-${TMP-${TEMP-./pdf$$.tmp
+  MYTMPDIR=${GROFF_TMPDIR-${TMPDIR-${TMP-${TEMP-/tmp
 
  I deliberately used current directory rather than /tmp, as
  ultimate fallback; /tmp doesn't exist by default, on MS-Windows.

 I don't think it makes any difference to security, although I do
 think /tmp should be used as a fallback if it exists since
 otherwise you can't use pdfroff when you don't have write
 privileges to your current directory.

Well, you have to have write permission for the formatted output 
stream, and I'd expect most users to be writing that in current 
directory anyway.  Compared to the destructive effect of an 
arbitrary choice of /tmp when it does not exist, ensuring that 
current directory is writeable, or that an appropriate variable
is set in the environment, is surely a minor inconvenience.

As developer, I can be certain that current directory exists; I 
cannot be certain that /tmp does.  To make an arbitrary choice 
of /tmp -- which may be common, but is by no means ubiquitous -- 
only to then have to follow up by checking that it does, in fact, 
exist as a writeable location just seems ugly and redundant.  Any 
user who needs to run pdfroff in a non-writeable current directory 
can always set TMPDIR=/tmp, (or use any of the other environment 
variables having similar effect), to force the use of /tmp.  The 
fallback to current directory only comes into effect when none of 
those environment variables is set; I'd much rather let the user 
make an informed choice which is appropriate for his system, than 
indulge in arbitrary guesswork.

+  WRKDIR=`unset TMPDIR  mktemp -dp $MYTMPDIR 
  groff-pdfroff.XX` || exit
 
  `unset' isn't portable; this kills pdfroff stone dead, for any
  shell which lacks it.

 The autoconf documentation has a portability rune for this:

   # || exit suppresses any Segmentation fault message.
   if ( (MAIL=60; unset MAIL) || exit) /dev/null 21;
 then unset=unset
   else
 unset=false
   fi
   $unset PS1 || PS1='$ '

 (Perhaps 'unset=true' here.)

I was aware of this, thanks, but surely it is better to just avoid 
using `unset' altogether:

  export TMPDIR
  TMPDIR=${GROFF_TMPDIR-${TMPDIR-${TMP-${TEMP-.
  GROFF_TMPDIR=`exec 2${NULLDEV}; mktemp -dt pdfroff-XX` ||
  GROFF_TMPDIR=${TMPDIR}

  WRKFILE=${GROFF_TMPDIR}/pdf$$.tmp

  Even if `unset' succeeds, it will then die when it tries to
  execute `mktemp' on any system which doesn't support that, (as
  is the case on MS-Windows with MSYS -- the very system on which
  pdfroff is most important to me).

 Yes, an equivalent of mktemp will need to be provided. Just hoping
 that the path constructed with $$ doesn't exist is not adequate
 though.

 Since mkdir(1) is typically atomic and succeeds only if the
 directory did not already exist, you can probably repeatedly try
 directories of different names until mkdir succeeds. I'd still
 recommend using mktemp(1) if it's available, though - it's
 provided on many systems, and it will be much more efficient than
 a mkdir loop.

Well, the snippet above will use `mktemp', if it is available; it 
will fall back to existing behaviour otherwise.  IMO, this should 
suffice.  Any `mkdir' loop will be ugly and grossly inefficient;
rather let the paranoid use a system which supports `mktemp'.

-- 

Regards,
Keith.


___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff

Re: groff = 1.19.3, ms macros -- confusing warning for 1 pl 13

[Keith Marshall]

On Sunday 15 July 2007 06:06, Werner LEMBERG wrote:
  I observed this unexpected behaviour:-- [...]
 
  Ok to apply the following patch, which resolves this?

 Please do.

Done.

FWIW, and for completeness, I did also check with:--

  $ nroff -ms
  .pl 0
  .LP
  standard input:2: warning: number register `0:ds-type' not defined
  standard input:2: warning: number register `0:LL' not defined
  standard input:2: warning: number register `0:ri' not defined
  standard input:2: warning: number register `0:LT' not defined
  standard input:2: warning: number register `0:li' not defined
  standard input:2: warning: macro `FAM' not defined
  standard input:2: warning: number register `0:PS' not defined
  standard input:2: warning: number register `0:VS' not defined
  standard input:2: warning: number register `0:PD' not defined
  standard input:2: warning: number register `0:PI' not defined

and with:--

  $ nroff -ms
  .pl 1
  .LP
  :
  :
  standard input:2: fatal error: input stack limit exceeded
(probable infinite loop)

The `.pl 0' case is clearly some part of the initialisation code being 
skipped, at zero page length, while the `.pl 1' case is, presumably, 
recursive springing of the top of page trap.  I guess it should be 
possible to protect against these two cases, but, given the limited 
usefulness of these short page lengths, it may not be worth the effort.

Regards,
Keith.


___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff