bug-groff
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: G. Branden Robinson
Subject: [bug #40793] [grohtml] inappropriately nests adjacent \s escape sequences
Date: Tue, 31 May 2022 21:59:31 -0400 (EDT) 
Update of bug #40793 (project groff):

                 Summary: "groff -mandoc -Thtml ..." produces huge fonts =>
[grohtml] inappropriately nests adjacent \s escape sequences

    _______________________________________________________

Follow-up 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...



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
reply via email to
[Prev in Thread] Current Thread [Next in Thread]