[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #54909] Paragraph indention after heading; extra space between head

From: anonymous
Subject: [bug #54909] Paragraph indention after heading; extra space between heading and list
Date: Sun, 28 Oct 2018 22:48:39 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36


                 Summary: Paragraph indention after heading; extra space
between heading and list
                 Project: GNU troff
            Submitted by: None
            Submitted on: Mon 29 Oct 2018 02:48:37 AM UTC
                Category: Macro - mm
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None



Computer: Core-i7 6700, 32 GB RAM
OS: Windows 10 Pro, version 1803, 64 bit
Environment: MKS Toolkit, version 10.0
groff version: 1.22.3, Windows binary distribution

There seem to be a couple of bugs in the mm macro package (file m.tmac):

0 According to the documentation (and long-established behavior), when
register Pt=2, paragraphs are not supposed to be indented following a heading,
list, or display.  Although paragraphs are not indented following a heading,
they are indented following a list or display.

0  If a list or display follows a heading, there is considerable extra
vertical space between the heading and the list or display.

I just discovered these issues because for the last 20 years, I was using a
modified version of AT&T mm (which worked fine after I made sure that requests
were followed by whitespace; I may have had to make a few other changes, but
not many).

= Paragraph Indention =
For the paragraph indention, the problem seems to arise because, although the
register address@hidden is set to zero, the P macro only checks registers nl and
.k against registers hd*last-pos and hd*last-hsize to see if there has been
any intervening vertical or horizontal motion; the address@hidden is not

One possible fix is to have the LE, address@hidden, and address@hidden macros 
set the hd*...
registers when the set address@hidden to zero, e.g.,

      .  .  .
    .nr hd*last-pos \\n[nl]
    .nr hd*last-hsize \\n[.k]
    .nr address@hidden 0
      .  .  .

Perhaps the registers could be renamed to ‘hld*...’ to indicate their
broader use.  I don’t know whether they should be considered “external,”
but if so, perhaps they should be renamed to address@hidden

= Extra Vertical Space =
For the extra vertical space, the problem seems to result from the line


near the end of the macro address@hidden, which is called at the end of macro 
This seems to generate something that is forced out when the br request is
given at the beginning of macro SP.

Offhand, I don’t have a fix.  To be honest, I don’t really understand what
is happening with the generation of HTML tags.  But—at least with mm—the
results I get from Thtml aren’t very good, so I’ve just commented out the
call to address@hidden  Although it solves my problem, it clearly isn’t a 

Jeff Conrad


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]