T.R | Title | User | Personal Name | Date | Lines |
---|
89.1 | it works for me withthe tags | ATLAST::BOUKNIGHT | Everything has an outline | Wed Mar 11 1987 22:08 | 6 |
| Did you include the aforementioned tags in your base .GNC file?
Sounds like you didn't, and DOCUMENT didn't have any hook points
in the .DVI file for the device convertor to merge the files
together with.
jack
|
89.2 | Tags are there. | TOOK::PEARSON | Larry Pearson | Thu Mar 12 1987 15:11 | 6 |
| Yes Jack, I included the tags in the profile. It doesn't seem to
make any difference whether they are there are not. <contents_file>
seems to be a NOP on our system.
Larry
|
89.3 | Can't get the supplied example to work either. | TOOK::PEARSON | Larry Pearson | Thu Mar 12 1987 15:43 | 20 |
| I tried the procedure on the sample document supplied with DOCUMENT,
ALASKA_MANUAL.GNC which contains a <CONTENTS_FILE> tag. The following
set of commands do not produce a document with a table of contents:
$ DOCUMENT/NODEV/CONTENTS ALASKA_MANUAL MANUAL LINE
$ DOCUMENT/NOTAG/NODEV ALASKA_MANUAL_CONTENTS MANUAL LINE
$ DOCUMENT/NOTAG/NOTEXT ALASKA_MANUAL MANUAL LINE
Of course the examples do not include a document profile, just a
self-contained file. The documentation seems to infer that you
need a profile in order to get a table of contents. Is that true
or not?
The only way we've been able to include the table of contents is
to use the old undocumented <include_tex_file> tag. Even that isn't
particularly successful, the dotted lines are random length and
some of the page numbers disappear into the twilight zone.
Larry
|
89.4 | only the Ln03 in T1.0 (-01 will fix) | CLOSET::ANKLAM | | Thu Mar 12 1987 20:34 | 6 |
|
The <contents_file> inclusion isn't yet supported for the LINE,
TERM, MAIL, or POSTSCRIPT destinations. This was in the releas notes.
It only works for the LN03.
pa
|
89.5 | A blind spot I guess | TOOK::PEARSON | Larry Pearson | Fri Mar 13 1987 11:29 | 3 |
| Thanks. I don't know how I missed the reference. It took me
two additional passes to find it even after you told me it was
there.
|
89.6 | can't make it work either | PUGET::SIPE | | Fri Mar 13 1987 20:44 | 8 |
| I seem to be another "blind" person. I am doing the same thing
as Larry is (although, am processing as LN03) and all I get is the
.TEX file for contents. I have the <CONTENTS_FILE> tag in the .GNC
file and am giving a command line as follows:
DOCUMENT filename GENERAL LN03 /CONTENTS
and I still can't make it work. Any suggesstions?
|
89.7 | Process filename_CONTENTS, too | COOKIE::JOHNSTON | | Fri Mar 13 1987 21:09 | 13 |
| DOCUMENT filename GENERAL LN03/CONTENTS produces
filename_CONTENTS
Which you then have to process using DOCUMENT, just like 06; except that
06 had you use TRUN, I think.
There is one explanation on page 1-7 in the release notes. Another, longer
explanation is also floating around in the notes.
Rose
|
89.8 | whats <CONTENTS_FILE> tag for? | PUGET::SIPE | | Sat Mar 14 1987 13:48 | 5 |
| If you have to make a second pass using DOCUMENT on the
filename_CONTENTS.TEX file, then what is the purpose of the
<CONTENTS_FILE> tag that is inserted in the main body of the text??
Jim
|
89.9 | it's not exactly clear in the installation guide | ATLAST::BOUKNIGHT | Everything has an outline | Sat Mar 14 1987 18:58 | 15 |
| If you look at the three DOCUMENT commands in .3, you see 1) the
initial run on the file to generate both the basic .DIV_LN03 for
the document body and the .TEX file for the table of contents,
2) a second run to make the .DVI_LN03 file for the table of contents
and 3) a final DEVICE CONVERTER run only to merge the two .DVI_LN03
files into one final .LN3 output file.
In effect, the <CONTENTS_FILE> tag results in a placeholder that
the DEVICE CONVERTOR will use to merge the final output results.
This is only working for the LN03 DVI processor; the others are
to come later.
A single commmand won't do it.
jack
|
89.10 | will be implemented | CLOSET::ANKLAM | | Sun Mar 15 1987 10:20 | 6 |
|
That is, a single command won't do it in the T1.0 version of DOCUMENT.
In the final version, it will all be accomplished with single command.
patti
|
89.11 | Help Please! | HADRON::SIM | | Thu Mar 26 1987 06:18 | 10 |
| I'm completely confused! I don't have a copy of the release notes
so I can't check on how to form a table of contents and I've been
trying to create one for a whole day now! Could someone please
take pity on a semi-technical person like me and explain from the
beginning how to create a table of contents? I am using doctype
'manual' with an LN03.
Thanks in advance
Alison
|
89.12 | Try this | DECWET::CUSTER | | Thu Mar 26 1987 11:58 | 12 |
| In the current version of DOCUMENT, you need to enter four commands:
$ DOCUMENT /NODEVICE/CONTENTS/INDEX profile doctype device
$ DOCUMENT /NOTAG/NODEVICE profile_CONTENTS doctype device
$ DOCUMENT /NOTAG/NODEVICE profile_INDEX doctype device
$ DOCUMENT /NOTAG/NOTEXT profile doctype device
The final command produces a printable file, whose filename is the same
as the profile's, but with a device-specific file extension. The file
contains the table of contents and the index where the <CONTENTS_FILE>
and <INDEX_FILE> tags appeared in the profile (except in Postscript
output, which has a bug - I think).
|
89.13 | Release notes are online | CLOSET::ADLER | | Thu Apr 02 1987 19:46 | 4 |
| Also, if you've got DOCUMENT installed, the release notes should be
in SYS$HELP:DOC010.RELEASE_NOTES.
--Brian
|
89.14 | I still can't get a TOC %^< | JAWS::STRYKER | Stew Stryker | Fri Apr 03 1987 10:26 | 72 |
| I just moved this reply from note 164, since this deals only with
the problem I'm having.
Thanks for the pointer to the Release Notes. [Wish I could have
remembered reading that.] However, with my latest doc file, I can't
even get it to generate the TEX file, even though I'm following Jack's
and the Release Notes' suggestion. It's as if it's not even seeing the
Contents items. Under BL06, it generated a great TOC.
Maybe someone can give me some more pointers.
Thanks,
Stew
Log file follows, editing slightly to improve brevity:
$ set default userdisk5:[stryker.data_guide]
$ D /NODEVICE DATAPRO SOFTWARE.REFERENCE -
LN03/CONTENTS/SYMBOLS=GLOBALDEFS.GNC/BATCH
%DOC-I-IDENT, VAX DOCUMENT T1.0-001
[ T a g T r a n s l a t i o n ]...
%TAG-I-TAG_IDENT, T1.0
%TAG-I-DEFSLOADD, End of Loading of Tag Definitions
%TAG-I-ENDPASS_1, End of first pass over the input
%TAG-I-FILEWRTOK, File DATA_FRONT.TEX written
%TAG-I-FILEWRTOK, File DATA_CH1.TEX written
%TAG-I-FILEWRTOK, File DATA_CH2.TEX written
%TAG-I-FILEWRTOK, File DATA_CH3.TEX written
%TAG-I-FILEWRTOK, File DATA_CH4.TEX written
%TAG-I-FILEWRTOK, File DATA_APP.TEX written
%TAG-I-CPU_USAGE, Pass 1: 109.1 Pass 2: 84.5 Total: 193.6 seconds
[ T e x t F o r m a t t i n g ]...
%TEX-I-IDENT, T1.1
%TEX-W-LINETOOLONG, line too long by 8.34158 points
%TEX-I-ONPAGE, on page [A-1]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-W-LINETOOLONG, line too long by 9.64817 points
%TEX-I-ONPAGE, on page [A-5]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-E-TEXERROR, Error found by TeX
%TEX-I-ONPAGE, on page [A-5]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-W-LINETOOLONG, line too long by 9.64817 points
%TEX-I-ONPAGE, on page [A-5]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-E-TEXERROR, Error found by TeX
%TEX-I-ONPAGE, on page [A-5]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-E-TEXERROR, Error found by TeX
%TEX-I-ONPAGE, on page [A-6]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-W-PAGETOOLONG, page too long by 299.0 points
%TEX-I-ONPAGE, on page [A-8]
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%TEX-I-PAGESOUT, 31 pages written.
%TEX-I-OUTFILENAME, 'userdisk5:[stryker.data_guide]DATAPRO.DVI_LN3'
%DOC-E-ERROR_FORMATTER, Errors found by Text Formatter.
$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$8FEC8320600E758D64FAE0.TMP - End
STRYKER job terminated at 2-APR-1987 16:57:50.09
Accounting information:
Buffered I/O count: 383 Peak working set size: 2048
Direct I/O count: 891 Peak page file size: 6776
Page faults: 5587 Mounted volumes: 0
Charged CPU time: 0 00:08:34.11 Elapsed time: 0 00:12:05.41
|
89.15 | You need to fix TeX errors first | CRAYON::GENT | Party gone out of bounds -- B52's | Fri Apr 03 1987 10:47 | 11 |
| Stew,
I believe that DOCUMENT will stop processing if it encounters
unexpected TeX errors (%TEX-E-TEXERROR, Error found by TeX).
Your TeX processing generates this error, so DOCUMENT does not
generate a contents file.
You need to look at the .LIS file and find out what is causing the
TeX error.
--Andrew
|
89.16 | try /notag/notex | UBEAUT::MANDERSON | the wind don't blow..... it sux | Sat Apr 04 1987 23:02 | 7 |
| Stew,
Although the document production was not well it still produced
the .dvi_ln3 file. you can see what it looks like with
DOC FILE DESIGN DEST/NOTAG/NOTEX
Regards
Kevin M
|
89.17 | How about POSTSCRIPT | GENRAL::RINESMITH | Roger | Fri May 22 1987 10:44 | 3 |
| Ok... but how do I go about getting the CONTENTS and INDEX with
a POSTSCRIPT printer with document T1.0 ??
|
89.18 | need bl8 | CLOSET::ANKLAM | | Fri May 22 1987 13:32 | 6 |
|
In T1.0 (base level 7), the inclusion of contents and index in
the output files was not supported for POSTSCRIPT. It is supported
in the UPDATE to T1.0, Base level 8.
|
89.19 | when is t1.0 not t1.0? | REGENT::MERRILL | Glyph, and the world glyphs with you. | Tue May 26 1987 11:41 | 4 |
| Why isn't b18 called T1.8 ? Has the naming std. changed?
rmm
|
89.20 | "bl8" is outside the naming "standard" | KALKIN::BUTENHOF | Approachable Systems | Tue May 26 1987 12:03 | 6 |
| .19: Because V1.0 still hasn't shipped, so calling something
"T1.8" (a field test of V1.8) would be pretty meaningless.
bl8 (not b18) is simply another baselevel progressing towards
the actual V1.0 kit. It's really T1.0.
/dave
|
89.21 | anyone remember VMS base level 5? | CLOSET::ANKLAM | | Tue May 26 1987 12:15 | 5 |
|
Yes, we have been calling versions of DOCUMENT 'base levels' for
some time (before we even planned to make it a product). It's just
been useful nomenclature, which I suspect we'll have to change...
|