[bug #62190] [PATCH] [mm] equation label wrongly positioned within indented display

[Dave]

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

This bug was originally discussed in the email thread starting at
http://lists.gnu.org/r/groff/2022-03/msg7.html


___

Reply to this item at:

  

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

[bug #62955] [grops] \(va fallback character overrides glyph available in S font

[Nikita Ivanov]

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

I've changed some of the request (see _schar.patch_). Does it look right?

(file #53666)

___

Additional Item Attachment:

File name: schar.patchSize:1 KB




___

Reply to this item at:

  

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

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

Hello Branden,

..again, and sorry, for the noise..

Steffen Nurpmeso wrote in
 <20220907210913.drf4v%stef...@sdaoden.eu>:
 |P.S.:
 ...
 |||(Actually my less(1) pull request will not find the IDs my mdocmx
 ...
 |I updated the pull request with an additional fix commit that
 ...
 |I would still hope for a possibility to create anchor-only OSC 8.

Actually i will update it again with

osc8_inspect(): ignore "#[no ID]" local anchor URIs..

Like in HTML #ID are in-document local anchor references.
An URI # without ID does not lead anywhere usually.

Ignore them in the sole case that there also was an id= parameter,
meaning this OSC 8 construct is meant to *create* a local anchor.

Like this less(1) will be capable to deal with local anchors
generated by grotty(1)'s 1.23[.0] \X'tty: link' command.
(Which, perspectively, will be used for interactive Unix manual
pages.)

Whether it will make it i cannot tell.  But i can tell you
i _love_ to use the interactive manual pages since 2014.
Of course, only for the programs i created myself, but that is
a pity!

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[bug #62471] [tbl] horizontal and vertical rules are drawn too long in nroff mode

[G. Branden Robinson]

Update of bug #62471 (project groff):

 Summary: [tbl] draws horizontal lines that are too long by 1n
in nroff mode => [tbl] horizontal and vertical rules are drawn too long in
nroff mode


___

Reply to this item at:

  

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

[bug #61915] grohtml: .EX/.EE is not monospaced

[G. Branden Robinson]

Update of bug #61915 (project groff):

  Status: In Progress => None   


___

Reply to this item at:

  

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

[bug #61915] grohtml: .EX/.EE is not monospaced

[G. Branden Robinson]

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

Nothing clears the mind like posting an embarrassing ramble publicly.

What the report complains of is the handling of the EX/EE macros.

What I used to _test_ presence of the Courier typeface in output was a tbl(1)
table that selected the Courier roman font.

These are not the same thing.

The problem seems to be much simpler, and indeed is present in groff 1.22.4

Ya wanna know what grohtml does when you request a Courier family font?

It opens a "" tag.

My eyebrow just about arched through the ceiling.

Whatever other complaints we may have about this, it explains why grohtml
honors \f[CR] and .ft CR but not .fam.

Check this out.


$ cat EXPERIMENTS/EX-EE.man 
.TH foo 1 2022-09-08 "groff test suite"
.EX
baz
.EE
.nf
.fam C
qux
.fam T
\f[CR]barR
\f[CI]barI
\f[CB]barB
\f[CBI]barBI
.ft CR
gakR
.ft CB
gakB
.ft CI
gakI
.ft CBI
gakBI
$ ./build/test-groff -Thtml -man EXPERIMENTS/EX-EE.man | tail -n 11
barR
barI
barB
barBI
gakR
gakB
gakI
gakBI





So that's why .EX/.EE is not monospaced.  I suspect a better approach would be
to produce  or  tags with style attributes.


___

Reply to this item at:

  

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

[bug #61915] grohtml: .EX/.EE is not monospaced

[G. Branden Robinson]

Update of bug #61915 (project groff):

  Status:None => In Progress

___

Follow-up Comment #2:


[comment #1 comment #1:]
> I think I found the cause of this.  It's some code I added to an.tmac.

This isn't quite true.  Font remappings like that have been present since
2007.  They formerly resided in the an-ext.tmac file.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=259929625b21595951ed3ef5dba9aaaea359b464

Consider the following simple reproducer.


$ cat EXPERIMENTS/courier-in-table.man 
.TH foo 1 2022-09-08 "groff test suite"
.TS
Lf(CR).
baz
.TE


The puzzling bit is that you could still get the Courier family in tbl(1)
tables anyway up through groff 1.22.4; the above example _works_ in released
groff.  It is only since then that that regressed--almost surely my fault, but
it's hard for me to reason out why.  It's fairly well-known that groff's html
output devices transform tbl tables and (sometimes) eqn equations into
PostScript (using groff again) and then convert that output to image files
which are then linked from the HTML output.

But since 'ps' is not an nroff device (it's troff), the font remappings would
not have taken place.  This explains why Courier shows up in the table.  But I
haven't hacked on grops much, and if I'd broken its ability to change font
families I'd have noticed long before now.

Weirder still, the following fix _works_.


diff --git a/tmac/an.tmac b/tmac/an.tmac
index 90ccb67fc..f4f9d28a3 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -1158,8 +1158,9 @@ contains unsupported escape sequence
 .ds an*body-family T \" Times
 .ds an*example-family C \" Courier
 .
-.\" Map monospaced fonts to standard styles for groff's nroff devices.
-.if n \{\
+.\" Map monospaced fonts to standard styles for groff's nroff devices,
+.\" except HTML, which _can_ change font families.
+.if !\n[an-is-output-html] .if n \{\
 .  ftr CR R
 .  ftr CI I
 .  ftr CB B


But given my analysis above, this should not have fixed the bug at all--the
missing conditional has been missing since groff 1.20.  And yet it does.

Very mysterious.



___

Reply to this item at:

  

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