[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:DOCUMENT T1.0
Notice:**New notesfile (DOCUMENT.NOTE) now available (see note 897)**
Moderator:CLOSET::ADLER
Created:Mon Feb 09 1987
Last Modified:Thu Oct 31 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:897
Total number of notes:4397

239.0. "MEMO, <HEADx>, <P>, conspire to lose blank lines" by COOKIE::WITHERS (Le plus ca change...) Fri Apr 10 1987 13:14

Problem summary:

If one does not place a <p> tag at the start of a paragraph that follows a
<headx> tag, then the space between that paragraph and the one that
follows it (and has been delimited by a <p> tag) is missing.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 

Detailed Description:

In the MEMO style, the following strange behaviour occurs:

If one has coded:

<Headx>(mumble)

Text in free form for the first paragraph of the section.

<p>

More text.

and processes it through document, one gets:

	Text in free form for the first paragraph of the section.
	More text.


but if one says:

<Headx>(mumble)

<p>

Text in free form for the first paragraph of the section.

<p>

More text.

and processes it through document, one gets:

	Text in free form for the first paragraph of the section.

	More text.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 

Example files:

Can be found in COOKIE""::DISK$CSSE_DISK:[WITHERS.DOC_WIERDNESSES]

The file MEMO_TEST.GNC and its compiled versions demonstrate the problem
and MEMO_TEST_WITH_EXTRA_P.GNC (and company) produce anticipated results.

T.RTitleUserPersonal
Name
DateLines
239.1Not looking ahead.VAXUUM::KOHLBRENNERFri Apr 10 1987 15:2914
    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.2Maybe I didn't state the problem clearly enough...COOKIE::WITHERSLe plus ca change...Fri Apr 10 1987 15:4113
/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.3No tag, no formatCLOSET::KOHLBRENNERFri Apr 10 1987 16:3224
    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.4cannot modify the behavior at this pointCLOSET::ANKLAMMon Apr 13 1987 09:3314
    
    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.5Is this the proverbial "Fixed in next release"?COOKIE::WITHERSLe plus ca change...Mon Apr 13 1987 11:131
    
239.6CUPOLA::HAKKARAINENAlbatross!Mon Apr 13 1987 15:5911
    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.7a second for .63D::BOYACKpithy...pithy...pithyTue Apr 14 1987 08:268
    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