[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
708.0. "V1.0 (BL8) Error Reporting" by 3D::BOYACK (pithy...pithy...pithy) Fri Jul 24 1987 12:55
Using version V1.0, LYNXUG doctype, POSTSCRIPT, and BATDOC,
processed a profile with three <ELEMENT>s. The last <ELEMENT>
contained the tag <MATH>(>), which caused the following error
message in the profile.LOG file:
%TAG-E-TAGNOTEND, at tag <MATH> on line 261 in file
DISK$03:[
BOYACK.DLYNX.DLOM]AA_LOM.SDML;
Tag <ALIGN_CHAR> from line 252
not terminated
However, the job did NOT terminate with an error, and the only
indication I had was that the third <ELEMENT> didn't show up in
the printed output. Therefore, I BATDOC'd the offending <ELEMENT>
by itself, and the job aborted with an error. The element.LOG file
which also included the above, plus the following:
%TAG-E-TAG_FAILS, The tag translator has detected a fatal error
-TAG-F-ABORTFORE, at end-of-file on line 978 in file
DISK$03:[
BOYACK.DLYNX.DLOM]AA_LOM.SDML;
There have been more than 0
error messages of severity level E
%DOC-E-ERROR_TAG, Errors found by the TAG Translator.
$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$AA
_LOM.TMP - End
BOYACK job terminated at 24-JUL-1987 12:20:49.29
Shouldn't the job have been terminated when I BATDOC'd the
profile as well as the single element? Luckily, this is a short
book, but I'd hate to have processed and printed a 500 page
book, only to find a chapter or appendix missing in the output.
BTW, I've only read the V1.0 release notes so far, so maybe
this behavior is documented somewhere.
Joe
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 708.1 | errors and "features" | VAXUUM::KOHLBRENNER | | Fri Jul 24 1987 13:29 | 16 |
| This is a feature! (but you do have to know about it)
Rather than kill your "bookbuild" when only one of the
elements has a serious error, we simply drop that element
and process the rest of the elements through to the end.
You can then reprocess the offending element in an "element
build," and print it separately. If the error is minor, the
results may be acceptable and you may avoid having to repeat a
lengthy bookbuild for one small error.
As for the E level error message. It looks like the problem
is with <align_char> ... <endalign_char> not being terminated,
rather than with <math>(>).
bill
|
| 708.2 | | CUPOLA::HAKKARAINEN | This too shall pass | Fri Jul 24 1987 13:32 | 11 |
| > I'd hate to have processed and printed a 500 page
> book, only to find a chapter or appendix missing in the output.
This is the behavior, for good or ill, that lots of people have sought.
I've corresponded with a number of writers who have sought this
feature. They grew tired of processing a document, finding and fixing
an error, only to have a new error reveal shortly afterwards.
There's been similar discussion of this topic when one noter proposed
<reset> tag. While this isn't quite a reset, it does provide the user
with a more meaningful way for the debugging the whole document.
|
| 708.3 | Works Form E | 3D::BOYACK | pithy...pithy...pithy | Fri Jul 24 1987 14:20 | 6 |
| Okay, sounds reasonable. Normally, I'd process single elements first
anyway.
re: .1 -- changing <MATH>(>) to > got rid of the <ALIGN_CHAR>
<ENDALIGN_CHAR> messages. Could be because the <MATH>(>) was embedded
in the table surrounded by the <ALIGN_CHAR>?
|
| 708.4 | Diag was okay | CLOSET::ANKLAM | | Wed Aug 12 1987 14:16 | 6 |
|
Yes, <math> is invalid within a sequence of <align_char> and
<endalign_char>. Any tags that handle non-alphanumeric characters
are incompatible with math.
-pa
|