T.R | Title | User | Personal Name | Date | Lines |
---|
239.1 | Not looking ahead. | VAXUUM::KOHLBRENNER | | Fri Apr 10 1987 15: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 15: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 16: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 09: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 11:13 | 1 |
|
|
239.6 | | CUPOLA::HAKKARAINEN | Albatross! | Mon Apr 13 1987 15: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 08: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
|