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

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 cou

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

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 >

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

Update of bug #60927 (group groff): Status:None => In Progress Assigned to:None => keithmarshall ___ Follow-up Comment #5: This is still a work in

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

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

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

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 indexi

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

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 OS

[bug #63827] withdraw contrib/pdfmark

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 point

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

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: > > > > > >

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

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 `\%` escap

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

ed 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),

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

: 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 pdf

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

efa80fab 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 conditionall

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

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

[bug #63827] withdraw contrib/pdfmark

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'v

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

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 a

[bug #63827] withdraw contrib/pdfmark

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 i

[bug #63827] withdraw contrib/pdfmark

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 ,

[bug #63827] withdraw contrib/pdfmark

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

[bug #63827] withdraw contrib/pdfmark

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 p

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

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

[bug #63827] withdraw contrib/pdfmark

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

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

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

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

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

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

Update of bug #63590 (project groff): Assigned to: keithmarshall => None ___ Reply to this item at: ___ Messag

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

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

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

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 comp

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

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 , > ... Wi

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

Update of bug #58946 (project groff): Assigned to: keithmarshall => None ___ Reply to this item at: ___ Mess

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

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

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

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

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

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 entire

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

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 pr

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

Update of bug #61294 (project groff): Status:None => Fixed Assigned to:None => keithmarshall Open/Closed:Open => Closed

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

Follow-up Comment #1, bug #55107 (project groff): In this mailing-list message [1], Deri offered two PDF files, namely Picture.pdf

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

Additional Item Attachment, bug #55107 (project groff): File name: nested-dictionary.patchSize:0 KB ___ Reply to this item at:

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

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 w

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

Additional Item Attachment, bug #58946 (project groff): File name: spdf-xh-xn-update.patchSize:2 KB ___ Reply to this item at:

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

Follow-up Comment #12, bug #58946 (project groff): [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?

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

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

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

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

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

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).

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

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, (fo

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

Update of bug #61157 (project groff): Assigned to: keithmarshall => gbranden Planned Release:None => 1.23.0 ___ Follow-up Comment #7: Hi Branden, [comment

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

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, ... > Prop

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

Update of bug #60927 (project groff): Depends on: => bugs #58946 ___ Reply to this item at: ___ Mess

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

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

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

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) __

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

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 ticke

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

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

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

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)

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

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 texin

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

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

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

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 -

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

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/pdf

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

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. ___

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

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

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

Additional Item Attachment, bug #58946 (project groff): File name: ms-footnote-marker-hook.patch Size:1 KB ___ Reply to this item at:

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

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 man

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

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 mac

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

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

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

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 supplementar

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

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 w

Re: Solar Designer groff tempfile audit

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 s

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

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

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

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 :2: warning: number register

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

, but does not remove the trap. It then overflows the short page length, springing the trap again on the second page. Ok to apply the following patch, which resolves this? 2007-??-?? Keith Marshall <[EMAIL PROTECTED]> * tmac/s.tmac (cov*first-page-init): Remove invoking

Re: [Groff] Compliments----

Peter Schaffter wrote, quoting John Rupley: >> May I complement you and your colleagues and thank you all for the >> GNU troff suite. It is obviously excellently done. > > Thanks, John, for taking the time to make your appreciation known. I > can't speak for others on the list, but I always w

Re: pdfmark.tmac conflict with -mm

On Sunday 15 May 2005 7:19 am, Werner LEMBERG wrote: > > [...] This conflicts with mm's macro LB that is used internally to > > begin a list. I worked around this by renaming the pdfmark LB to > > PDFLB, but it would be worth fixing this before it is officially > > released. Patch attached. > >

Re: pdfmark.tmac conflict with -mm

On Saturday 14 May 2005 7:18 am, Werner LEMBERG wrote: > > The new pdfmark.tmac macros (thanks for these!!!) have a string LB: > > > > This conflicts with mm's macro LB that is used internally to begin a > > list. I worked around this by renaming the pdfmark LB to PDFLB, but > > it would be worth f