[bug #60930] Integrate Peter Schaffter's font installer script into groff

[Dave]

Follow-up Comment #7, bug#60930 (group groff):

Branden mentioned two more to-do items in the email cited in comment #5:
* giving it a less name-space-stomperific name ("groff-font-install" or
"groff-install-font" would be clear enough, but I think either would annoy me
[and other users] when tab-completing "groff")
* giving distribution packaging folks enough guidance that they will
understand how to correctly call our tool from their package triggers or
"postinst"s or similar
The first of these is trivial.  The second seems worthwhile but shouldn't be a
barrier to getting something out the door that users can use.  In fact, if
others agree there's value in deferring the task of POSIXifying the entire
script, writing distro-facing documentation should probably depend on that.

Kurt, do the points above and in comment #6 make a first cut seem more
manageable?


___

Reply to this item at:

  

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

[bug #60930] Integrate Peter Schaffter's font installer script into groff

[Dave]

Follow-up Comment #6, bug#60930 (group groff):

[comment #0 original submission:]
> * Make the script portable by removing dependencies on
> bash-specific features

I'm now wondering if there's some wisdom to doing a first cut that simply
checks whether bash is available and bails gracefully if not.  This would
leave some users out in the cold, but it would serve a lot of them, and that's
got to be an improvement over serving none.  And it wouldn't require a bash
install dependency for groff, just a run-time one for one groff utility that
provides functionality groff didn't provide before anyway.

> * Write a man page

Four years ago, James K. Lowden volunteered to do this
(http://lists.gnu.org/r/groff/2020-04/msg00071.html).  I'm adding him to the
cc to see if he's still up for this.  Divide and conquer!

> * Write some test cases to ensure it works as expected

It's possible Peter Schaffter, the script's developer, has some he's used
privately and would be willing to share.  Putting him on cc as well.


___

Reply to this item at:

  

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

[bug #62921] want another monospaced font in the default set

[Dave]

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

[comment #8 comment #8:]
> Thanks (to whoever that anonymous submitter was ;-) )!

You've probably deduced this, but the reason I sometimes file groff bugs
"anonymously" is not to evade credit/blame, but so that I'm not forever tied
to a bug I have no stake in.  Savannah seems to support a submitter removing
themself from the cc list (in that there's a button for it, though I've never
tried it), but the Submitter field is immutable.

> That's not exactly true as I understand it.

I'm glad to be wrong about that.

> (Probably the former; continuing AT's abbreviation-happy tradition is
> likely to lead to collisions.)

...and less meaningful to human eyes, of course.


___

Reply to this item at:

  

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

[bug #65190] [man, mdoc] revise implementation of continuous rendering mode

[Dave]

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

[comment #6 comment #6:]
> I've heard no demand expressed for continuously rendered
> ms/me/mm/mom documents.

Less self-serving instances:
* http://lists.gnu.org/r/groff/2006-05/msg00102.html
* http://lists.gnu.org/r/groff/2008-03/msg00012.html
* http://lists.gnu.org/r/groff/2020-04/msg00072.html
There may well be more, but it's not an easy thing to search because there's
no historically consistent terminology for the concept.


___

Reply to this item at:

  

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

[bug #65242] [gropdf] should validate and diagnose ill-formed "download" files

[G. Branden Robinson]

URL:
  

 Summary: [gropdf] should validate and diagnose ill-formed
"download" files
   Group: GNU roff
   Submitter: gbranden
   Submitted: Sat 03 Feb 2024 12:32:11 AM UTC
Category: Driver gropdf
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: Sat 03 Feb 2024 12:32:11 AM UTC By: G. Branden Robinson 
If I slip to _gropdf_ a "download" file with only two tab-separated fields
instead of three, I get the following spew.


Use of uninitialized value $file in substr at
/home/branden/groff-HEAD/bin/gropdf line 1167, <__ANONIO__> line 1.
Use of uninitialized value $file in substr at
/home/branden/groff-HEAD/bin/gropdf line 1174, <__ANONIO__> line 1.
Use of uninitialized value $file in concatenation (.) or string at
/home/branden/groff-HEAD/bin/gropdf line 1174, <__ANONIO__> line 1.


In my opinion, _gropdf_ should check that the lines in the "download" file are
of satisfactory form, and throw a complaining diagnostic if they aren't.







___

Reply to this item at:

  

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

[bug #62921] want another monospaced font in the default set

[G. Branden Robinson]

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

[comment #7 comment #7:]
> [comment #1 comment #1:]
> > groff's _ms_ and _me_ have support for bold-italic already (and have
> > for decades), and it wouldn't be hard to add it to our _mm_ either;
> 
> This has been filed as bug #65241.

Thanks (to whoever that anonymous submitter was ;-) )!

> [comment #5 comment #5:]
> > Ideally, distributors like Fedora and Debian would have "package
> > triggers", scripts that hook up the plumbing between TrueType
> > fonts installed on the system, and the _grops_ and _gropdf_
> > output drivers.  But even after almost 30 years this has never
> > happened.  The reason may be that the specialized knowledge
> > required is fairly scarce,
> 
> Other possible reasons:
> * Supporting groff for anything other than displaying man pages on
> terminals has never been a high priority / something that distro
> managers are even aware it can do.

Fair point.  Maybe in the 1.24.0 release announcement we can get a few
more people to wake up and smell the PDF.

> * To be useful, the triggers would have to be bidirectional, running
> whenever a new groff or a new font is installed.  While the target
> code could be largely the same, the triggers themselves would be two
> mostly non-overlapping development efforts.

That's not exactly true as I understand it.  While RPM had a thing
called "triggers" first, Debian's had them as well for...15 years or
something.  And the way they work is that package A can lay a trigger
that any packages B, C, or D will step on it and cause action.  (To this
day I'm not sure exactly how triggers work--they came in right after my
heyday of intense involvement with complex package development.)  Any
time I install or remove a package that supplies a man page, dpkg
dutifully runs the "man-db" package's trigger afterward.

The scenario I think you're describing is not a trigger--it's just what
in Debian is called a "postinst" script, and those have been around
since practically the first Debian pre-release ever, in 1993 or so.
Before even _my_ time...

However, in working on Robin Haberkorn's recent problem with Russian
documents (bug #65323), I've noticed that some cooperation from
font-providing packages is likely necessary anyway, to solve the problem
of picking a groff font name for installed faces.  Should
"LiberationSerif-Regular" be named "LiberationSerifR" or "LSR"?

(Probably the former; continuing AT's abbreviation-happy tradition is
likely to lead to collisions.)

Regards,
Branden



___

Reply to this item at:

  

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

[bug #62921] want another monospaced font in the default set

[Dave]

Follow-up Comment #7, bug#62921 (group groff):

[comment #1 comment #1:]
> groff's _ms_ and _me_ have support for bold-italic already (and have
> for decades), and it wouldn't be hard to add it to our _mm_ either;

This has been filed as bug #65241.

[comment #5 comment #5:]
> Ideally, distributors like Fedora and Debian would have "package
> triggers", scripts that hook up the plumbing between TrueType
> fonts installed on the system, and the _grops_ and _gropdf_
> output drivers.  But even after almost 30 years this has never
> happened.  The reason may be that the specialized knowledge
> required is fairly scarce,

Other possible reasons:
* Supporting groff for anything other than displaying man pages on terminals
has never been a high priority / something that distro managers are even aware
it can do.
* To be useful, the triggers would have to be bidirectional, running whenever
a new groff or a new font is installed.  While the target code could be
largely the same, the triggers themselves would be two mostly non-overlapping
development efforts.


___

Reply to this item at:

  

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

[bug #65241] [mm] support bold-italic

[G. Branden Robinson]

Update of bug#65241 (group groff):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

[comment #0 original submission:]
> Buried in the novella that is bug #62921 is this observation:
> 
> "groff's _ms_ and _me_ have support for bold-italic already (and have
> for decades), and it wouldn't be hard to add it to our _mm_ either"
> 
> (This ticket merely notes that Branden has noted the feature gap.  I
> know of no -mm users who have requested this feature, and the
> functionality is already available to -mm users with appropriate base
> roff requests or escapes.)

I'm personally unlikely to tackle this due to its implications for the
_mm_ macro name space.

Consider first that _mm_ has macros for selecting roman, bold, and
italic faces called `R`, `B`, and `I`, respectively.

Next consider that _mm_ also has font alternation macros like _man_;
these are `BI`, `BR`, `IB`, `IR`, `RB`, and `RI`.

Notice the preëxisting status of a macro called `BI`.

Finally, consider that even we had a macro for switching to the
bold-italic face (maybe `FBI`), orthogonality would suggest that we'd
need to add several more, to complete the Cartesian product of
alternation with the new `BI` font.

BBI
BIB
BIR
RBI
IBI
BII

I think this would become hard to decipher.

What I would suggest to _groff mm_ users instead is to temporarily remap
fonts in a context where bold-italic is desired.  My suspicion is that
in most practical typesetting contexts, this will arise mainly in
situations where the non-italic face is already bold anyway.  That is
the shape of solutions I have applied in _groff man_, which doesn't
expose the bold-italic face, but does _use_ it in (sub)section headings
if it infers that the configured heading font (`HF` string) represents a
bold typeface.  It then temporarily remaps `I` to `BI` when setting the
headings.

Regards,
Branden



___

Reply to this item at:

  

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

[bug #62921] want another monospaced font in the default set

[Dave]

Update of bug#62921 (group groff):

  Status:   Need Info => None   

___

Follow-up Comment #6:

This bug was put into Need Info status with comment #1, which asked for
feedback that the submitter supplied in comment #4.  I don't readily notice
any other info this bug report is waiting on, so I'm resetting the status.  If
it's "waiting on" anything, it's a resolution to this question that only groff
developers can decide:

[comment #5 comment #5:]
> It is a question of whether it is a good idea for the _groff_
> project, which is not drowning in developers, to expand its
> charter to get into the general purpose font distribution business.


___

Reply to this item at:

  

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

[bug #65241] [mm] support bold-italic

[anonymous]

URL:
  

 Summary: [mm] support bold-italic
   Group: GNU roff
   Submitter: None
   Submitted: Fri 02 Feb 2024 11:11:40 PM UTC
Category: Macro mm
Severity: 3 - Normal
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 02 Feb 2024 11:11:40 PM UTC By: Anonymous
Buried in the novella that is bug #62921 is this observation:

"groff's _ms_ and _me_ have support for bold-italic already (and have for
decades), and it wouldn't be hard to add it to our _mm_ either"

(This ticket merely notes that Branden has noted the feature gap.  I know of
no -mm users who have requested this feature, and the functionality is already
available to -mm users with appropriate base roff requests or escapes.)







___

Reply to this item at:

  

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

[bug #61434] [man] want support for hyperlinked paragraph tags

[G. Branden Robinson]

Follow-up Comment #5, bug#61434 (group groff):

Hi Deri,

[comment #4 comment #4:]
> [comment #3 comment #3:]
> > This was an important follow-up commit.

> > commit 52a5a89c0da9f90c83441b8eb8020344a8468686
> > Author: G. Branden Robinson 
> > Date:   Thu Feb 1 23:23:45 2024 -0600
> > 
> ...
> > Unfortunately, "pdf.tmac" doesn't
> > expose a clean abstraction for "link starts here" and "link stops
here",
> > instead implementing a hugely featured `pdfhref` macro that attempts
to
> > do everything--except support bracketing the link text in a
diversion,
> > which our man(7) design requires.


> Is this accurate?

To the best of my knowledge, yes. 
[https://git.savannah.gnu.org/cgit/groff.git/commit/?id=dc265728eee39db3bf5e2f3b09f8f124880f8f05
The GNU MT/ME and UR/UE extensions date back to 2007]; MR is much more recent,
and the design of the last is deliberately closely modeled on plan9port's
macro (originally named `IM`, I think, but they renamed it to `MR` at my
request), which in turn looks very much like the `BR` and `IR` calls people
have been writing for man page cross references forever.

So the fact that `MR` is in the shape that the `pdfhref` approach expects is
largely a happy coincidence.

But it also makes sense for the other foregoing macros to work as _they_ do. 
The link text of `MR` won't sprawl due to its nature, whereas someone might
want to hyperlink an arbitrary run of text to a URL or an email address.

[https://git.savannah.gnu.org/cgit/groff.git/commit/contrib/pdfmark/pdfmark.tmac?id=f9503b9746b93a624339d488ebb29b77a4fbf667
That `pdfhref` didn't anticipate this in 2004 is unfortunate.]

> It was true before my commit d71f9264 which enabled .MT and .UR to be
hyperlinks (both of which used diversions) and provided a means to "bracket"
the resulting text as a hotspot. Maybe the mechanism of using the pipe
character to "open" the bracket needs further promulgation,

...I'm a little uneasy with that, in part because it constitutes in-band
signaling.  What if a document author wants to hyperlink a pipe sign?  This is
unlikely in conventional prose, but what if someone has a table of punctuation
glyphs, like an ASCII code chart?  Maybe each cell in the grid could hyperlink
to (a section of) a document explaining the history of the code point.

> or perhaps we should add a pair of macros to pdf.tmac, something like:-

> .de pdflinkstart
> .  ds pdf:col \\n[.m]
> .  pdfhref \\$1 -D \\$2 "|"
> ..
> .
> .de pdflinkend
> .  nop \X'pdf: markend'\m[\\*[pdf:col]]\c
> ..


> Which could be used as:-

> .pdflinkstart W http://bbc.co.uk
> .nf
> A multi
> line hotlink (possibly from a diversion)
> .fi
> .pdflinkend


> Just a thought.

I like this much better, but you might go further and have "pdflinkstart"
employ a "markstart" command so that you don't have to impute special meaning
to "|".

I think this aspect of the pdfmark API constitutes technical debt (from a
contributor who declines to work with us any longer, moreover) and I encourage
you to develop your own ideas for _groff_ support of PDF features.

Best regards,
Branden


___

Reply to this item at:

  

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

[bug #61434] [man] want support for hyperlinked paragraph tags

[Deri James]

Follow-up Comment #4, bug#61434 (group groff):

[comment #3 comment #3:]
> This was an important follow-up commit.

> commit 52a5a89c0da9f90c83441b8eb8020344a8468686
> Author: G. Branden Robinson 
> Date:   Thu Feb 1 23:23:45 2024 -0600
> 
...
> Unfortunately, "pdf.tmac" doesn't
> expose a clean abstraction for "link starts here" and "link stops
here",
> instead implementing a hugely featured `pdfhref` macro that attempts to
> do everything--except support bracketing the link text in a diversion,
> which our man(7) design requires.

Is this accurate? It was true before my commit d71f9264 which enabled .MT and
.UR to be hyperlinks (both of which used diversions) and provided a means to
"bracket" the resulting text as a hotspot. Maybe the mechanism of using the
pipe character to "open" the bracket needs further promulgation, or perhaps we
should add a pair of macros to pdf.tmac, something like:-

.de pdflinkstart
.  ds pdf:col \\n[.m]
.  pdfhref \\$1 -D \\$2 "|"
..
.
.de pdflinkend
.  nop \X'pdf: markend'\m[\\*[pdf:col]]\c
..

Which could be used as:-

.pdflinkstart W http://bbc.co.uk
.nf
A multi
line hotlink (possibly from a diversion)
.fi
.pdflinkend

Just a thought. 


___

Reply to this item at:

  

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

[bug #64597] [mom] spurious newline after image label

[G. Branden Robinson]

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


commit 11016d37f1e16fa71407f9802b105c016263128c
Author: Peter Schaffter 
Date:   Sat Aug 26 14:25:38 2023 -0400

[mom]: Fixes captions not attaching to PDF_IMAGE labels.




___

Reply to this item at:

  

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

[bug #57515] [troff] "-Wdeprecated-copy" warning in node.cpp

[G. Branden Robinson]

Update of bug#57515 (group groff):

Severity:  3 - Normal => 2 - Minor  
  Item Group:  Build/Installation => Lint   


___

Reply to this item at:

  

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

[bug #65215] [man] .MT/.ME and .UR/.UE should make hyperlinks in PDF

[G. Branden Robinson]

Update of bug#65215 (group groff):

 Planned Release:None => 1.24.0 


___

Reply to this item at:

  

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

[bug #61434] [man] want support for hyperlinked paragraph tags

[G. Branden Robinson]

Follow-up Comment #3, bug#61434 (group groff):

This was an important follow-up commit.


commit 52a5a89c0da9f90c83441b8eb8020344a8468686
Author: G. Branden Robinson 
Date:   Thu Feb 1 23:23:45 2024 -0600

[man]: Back away from color management concerns.

Hyperlink colors in PDF were showing a tendency to get "stuck on" when
they shouldn't, and the extra difficulty of managing nested traps (`TP`
followed by `UR`, for example) is proving tricky to sort out.  On top of
that, the man(7) package historically has no cognizance of color issues
and it's doesn't seem like a good time to start, particularly if we only
do it for the 'pdf' output device.  Unfortunately, "pdf.tmac" doesn't
expose a clean abstraction for "link starts here" and "link stops here",
instead implementing a hugely featured `pdfhref` macro that attempts to
do everything--except support bracketing the link text in a diversion,
which our man(7) design requires.

* tmac/an.tmac (an-input-trap): Set stroke color to default after
  springing `TP`'s supporting trap.

  (an*begin-hyperlink, MR): Stop saving the stroke color.

  (an*end-hyperlink, MR): Stop restoring the saved stroke color.  Set it
  to the default instead after formatting the link text.




___

Reply to this item at:

  

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