| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 239.1 | Not looking ahead. | VAXUUM::KOHLBRENNER |  | Fri Apr 10 1987 14:29 | 14 | 
|  |     I suppose you could argue that "the system ought to know that
    text that follows a <headx> tag is a paragraph."  Unfortunately,
    it doesn't.  So you have to label it as a paragraph.
    
    I don't know why you get the strange behavior.  
    
    The system can't default the text following a <headx> as a paragraph,
    for the same reason that it can't warn you about it.  Basically, 
    it doesn't know what follows a <headx> tag until it "gets to the next tag."
               
    Likewise, following an <endtable>, <endlist>, etc, you must label
    the next thing, even if it is "just text," which you might think
    of as a continuation of the paragraph that preceded the <table>,
    <list>, etc.
 | 
| 239.2 | Maybe I didn't state the problem clearly enough... | COOKIE::WITHERS | Le plus ca change... | Fri Apr 10 1987 14:41 | 13 | 
|  | /set mode=digression
Er, excuse me, but DSR understood that text usually follows headings,
to whit:
.ap
.hl 1
text goes here and becomes a paragraph.
/set mode=discuss_problem
The problem is not that SDML doesn't recognize that a paragraph could
follow a <HEADx> tag,  but that the subsequent paragraph AFTER the one
that wasn't specified with the <p> tag gets put in the wrong place.
 | 
| 239.3 | No tag, no format | CLOSET::KOHLBRENNER |  | Fri Apr 10 1987 15:32 | 24 | 
|  |     Yep, sorry, I didn't acknowledge your main topic because I assumed
    that it was caused by the missing <p>.  I'm as puzzled as you as
    to why the missing <p> affected the text following the <p> that 
    was there.
    
    Patti can answer that question, I can't.
    
    I was trying to anticipate the folks who would start a discussion
    on why the system can't be smarter regarding the unlabelled text
    following a tag like <headx>, <endlist>, etc.  And if it can't be
    smarter about formattng that text, why can't it at least complain
    that it doesn't know what to do with this unlabelled text.
    
    DSR looked at the text, and at the blank lines, or the lines that
    started with blanks.  The tag translator in DOCUMENT does not look
    at such text.  It only looks at tags.  So it just shuffles text
    from input to output until it finds a tag and then it does something
    with it, depending on what the tag's definition says to do.  When
    you leave out a tag, the wrong stuff gets sent on to TeX for
    formatting.
    
    The bug, in this case, is that we don't complain that a tag is
    missing.  The fix for that "bug" will be difficult because of 
    the design of the tag translator.
 | 
| 239.4 | cannot modify the behavior at this point | CLOSET::ANKLAM |  | Mon Apr 13 1987 08:33 | 14 | 
|  |     
    The symptom of a missing <p> following a <headx> tag varies from
    doctype to doctype (based on the standard left margin). I
    understand why people assume that SDML should behave like DSR,
    but it just isn't in he design. I also am sympathetic with the
    difficulty of diagnosing the absence of a <p>. I won't go into
    the gory details of the implementation decision that has the result,
    but suffice it to say it keeps me awake at night. (The alternative
    to the current behavior, by the way, would have been to require
    a different tag for paragraphs immediately following <headx> tags
    than to use the standard <p> tag.)
    
    patti
     
 | 
| 239.5 | Is this the proverbial "Fixed in next release"? | COOKIE::WITHERS | Le plus ca change... | Mon Apr 13 1987 10:13 | 1 | 
|  |     
 | 
| 239.6 |  | CUPOLA::HAKKARAINEN | Albatross! | Mon Apr 13 1987 14:59 | 11 | 
|  |     Re .5
    
    More like, ``Fixed the next time the tag translator is rewritten.''
    
    I believe that DSR handled the situation by setting out a .p. It then
    checked to see if the next command was a .p; if so, it was thrown away.
    Personally, I much prefer having the explicit tagging of items in
    text. I spent too many years cleaning up runoff files that relied
    on hidden side effects. 
       
    kh 
 | 
| 239.7 | a second for .6 | 3D::BOYACK | pithy...pithy...pithy | Tue Apr 14 1987 07:26 | 8 | 
|  |     I agree with Karl. I was never sure (and too lazy to find out) if
    and how much space followed each RUNOFF header level. It might be
    useful (if possible) in some generation of the documentation to
    describe the parameters imposed on text elements, using some "base
    level" doctype as a reference.
    
    Joe
    
 |