bugGNU roff - Bugs: bug #40793, [grohtml] inappropriately nests...

 
 

bug #40793: [grohtml] inappropriately nests adjacent \s escape sequences

Submitter:  None
Submitted:  Tue 03 Dec 2013 06:13:40 PM UTC
   
 
Category:  Driver grohtml Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 01 Jun 2022 01:59:30 AM UTC, comment #4: 

There is a bug here, as Bjarni's reproducer illustrates.

Here's another.


$ cat EXPERIMENTS/repro-40793.roff
A \s-2B\s+2 C \s+2D\s-2 \s+4E\s-4
$ groff -Thtml EXPERIMENTS/repro-40793.roff
<!-- Creator     : groff version 1.22.4 -->
<!-- CreationDate: Wed Jun  1 01:46:25 2022 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="generator" content="groff -Thtml, see www.gnu.org">
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<meta name="Content-Style" content="text/css">
<style type="text/css">
       p       { margin-top: 0; margin-bottom: 0; vertical-align: top }
       pre     { margin-top: 0; margin-bottom: 0; vertical-align: top }
       table   { margin-top: 0; margin-bottom: 0; vertical-align: top }
       h1      { text-align: center }
</style>
<title></title>
</head>
<body>

<hr>


<p>A <small>B</small> C <big>D <big>E</big></big></p>
<hr>
</body>
</html>


grohtml is failing to reset the type size where it should, and creating invalid nesting of the HTML elements.

However, the originally reported input (the gcc(1) man page) is not well-formed.

This can be seen if you format it for PostScript.


$ groff -ww -z -mandoc ATTIC/gcc.1
troff: ATTIC/gcc.1:1027: warning [p 9, 8.1i]: cannot adjust line
troff: ATTIC/gcc.1:2892: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2893: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2893: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2902: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2905: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2908: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2913: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2915: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2915: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2918: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:2919: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:3901: warning: \s escape results in non-positive point size; set to 1
troff: ATTIC/gcc.1:3901: warning: \s escape results in non-positive point size; set to 1


This is due to constructs like the following.


$ grep -C1 -n corrigendum ATTIC/gcc.1
1648-.PD
1649:The 1998 \s-1ISO \*(C+\s0 standard plus the 2003 technical corrigendum and some
1650-additional defect reports. Same as \fB\-ansi\fR for \*(C+ code.


Observe the embedding of the `C+` string interpolation amid a pair of type size alteration escape sequences.

What is that string's definition?


$ grep -n 'ds C+' ATTIC/gcc.1
25:.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'


`\s0` means "set the type size to the previous value".  No *roff maintains a stack of previous formatter values.  Only the previously selected one is remembered.

So when the "The 1998" line is formatted, assuming we're at the default type size when it starts (and we seem to be) the type size is decreased by 1 (scaled) point, reduced again by 2 points, restored to 1 point smaller than the default, then "restored" again to 2 points smaller than the default.

This is simply incorrect use of *roff.

I am sorely tempted to editorialize on the wisdom of using Perl to transform Texinfo to perlpod and thence to a man page...

G. Branden Robinson <gbranden>
Group administrator
Sun 25 Nov 2018 07:59:34 PM UTC, comment #3: 

Bjarni, re comment #2:

Your statement in item "1)" is incorrect.  The "\s0" is not a bug.  It is documented in https://www.gnu.org/software/groff/manual/html_node/Changing-Type-Sizes.html :

  "The size 0 (for both .ps and \s), or no argument (for .ps only), goes back to the previous size."

Besides, a bug of this size (pun intended) in the standard pod2man(1) preamble would be rather astonishing.  :-)

But the rest of your analysis seems quite useful, in case somebody wants to fix the bug.

 Ingo Schwarze <schwarze>
Group Member
Sun 25 Nov 2018 07:25:59 PM UTC, comment #2: 

  1) There is a bug in the man page "gcc(1)".  The definition of the
string "C*" uses "\s0" instead of an absolute change (here "\s+2").

  2) The bug in "grohtml" (post-grohtml) is seen in this simple example
(in gcc(1) it is "\*(C+ \s-1ABI\s+1")

.pl 10v
Begin \s-2UPPER\s+2 \s-1lower\s+1 normal

  Output from "test-groff -Thtml <file>" :

...
<hr>


<p>Begin <small>UPPER</small> lower <big>normal</big></p>
<hr>


  Output from "test-nroff -Thtml -Z <file>":

...
f1
s10
V80
H0
md
tBegin
ws8
h24
tUPPER
ws9
h24
tlower
ws10
h24
tnormal
n40 0
x trailer
V400
x stop

  1) Font size changes around a space (' ', '\ ', '\0', and "\h'2n'")
are summed to one size change.

  2) The postprocessor must know (check) the normal (default) font size
to avoid adding "<big>" or "<small>"


Bjarni Ingi Gislason <bjarniig>
Fri 06 Dec 2013 02:19:08 PM UTC, comment #1: 

This is caused by the <big> tags in the HTML source. The big text starts when the nested <big> tags start to appear.

 Anonymous
Tue 03 Dec 2013 06:13:40 PM UTC, original submission:  

I was redirected here from http://savannah.nongnu.org/bugs/index.php?40781

On Arch Linux, groff version 1.22.2

Steps to reproduce:
1) Obtain the file gcc.1 by uncompressing /usr/share/man/man1/gcc.1.gz or see the attached files in this bug report
2) "groff -mandoc -Thtml ./gcc.1 1> gcc.html 2> errors.html"
3) "firefox ./gcc.html"
4) Scroll to the middle of the page
5) Huge fonts are unreadable

Alternativley, just run "man -Hfirefox gcc".

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29775:  gcc.1 added by None (877KiB - application/octet-stream - gcc uncompressed manual from /usr/share/man/man1/gcc.1.gz)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by schwarze (Updated the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-01 gbranden Summary&quot;groff -mandoc -Thtml ...&quot; produces huge fonts [grohtml] inappropriately nests adjacent \s escape sequences
    2018-02-16 schwarze CategoryNone Driver grohtml
        Item GroupNone Incorrect behaviour
        StatusNone Confirmed
    2013-12-03 None Attached File- Added gcc.1, #29775

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-461b.
    Corresponding source code