Conference vaxuum::document_ft

    	Not having heard anything yet, I'll just throw in what amounts
    to a "hack" that I'm now using.  Basically, since I've  found no
    other way of "disabling" certain Table-of-Contents entries
    (particularly Tables), I now process my file as follows:
    
    	I do the "DOC/CONTENTS" command to create the file_CONTENTS.TEX
    file; then I edit the flippin' file!  Crude, I know, but it's the
    only way I've come up with so far.  It's not all that bad, especially
    if I'm just looking for certain Tables, since I search the .TEX
    file for a "\begintables" and start deleting from there.
    
    	After that's done, I continue processing normally.  Not great,
    but it works.  Anybody know if there's a simpler way to do this?
    
    	Frank

I've also edited file_CONTENTS.TEX.

However, that is not a very user friendly mechanism in a released product.

The equivalent of DSRs .enable TOC and .disable TOC are mandatory.
It would also significantly improve conversion from DSR(PLUS) to DOCUMENT.

    Whether tables appear in the TOC would seem to be a classic example
    of a formatting issue that should be handled in the doctype, not
    in the writer's source file.  Similarly, if you want a format that
    specifies two-line headings for tables, you probably need to define 
    that in the doctype file as well. (Currently, I believe most doctypes 
    will wrap extra-long headings, but do not expect explicit multiple
    lines.)
    
    As a hack, table headings in tables-of-contents can be disabled 
    by defining part of the \toctexentry macro (identified by a first 
    argument of 8) as null in the DTP file. However, that is a hack...
    
    --Andrew

    It seems that DOCUMENT T1.0 won't generate a table of contents for
    the GENERAL doctype.  I say this because I can't get DOCUMENT to
    build one for me, though I'm following what appear to be the
    directions:
    
    	DOCUMENT filespec GENERAL LN03 /CONTENTS
    
    Could someone tell me what I'm doing wrong (and preferably, how to
    fix it, as well)?
    
    Thanks,
    
    Stew

re: 164.3

It is NOT an issue of the doctype.

For example, in doctype MOO you might automatically include n levels in the TOC.
However, a situation may arise in which certain of those levels should not 
appear, e.g. you want 1.1.1 but not 2.2.2.

It makes no sense to have to edit the file_CONTENTS.TEX file to achieve this as
an enable/disable mechanism surely must be easy to implement.

This is particularly important for general purpose doctypes such as GENERAL
that will be used by many authors for many different styles of books.

    <set flame simmer>
    
    This is an old, and as yet quite unresolved problem of control.
    The software issue is minimal. The hard stuff comes from the desire
    of some writers to have full control over their documents, the desire
    of tool-makers, often as representatives of management, to make
    sure that the documents are standardized. Many of the limitations
    in the software are not oversights; multi-line titles don't work
    because multi-line titles are not useful to the reader. Similarly
    I would find it confusing if sections were left out of the contents,
    whatever the reason might be.
    
    Document was designed and built to ensure standards for documentation.
    It is not intended to be a ``compose-as-you-go'' software package.
    The use of centralized doctypes is very deliberate, helping to meet
    the needs of team publishing. 
    <set flame off>

    

    [not meaning to sound sarcastic, but...] Thanks for resolving that
    simmering issue.  I'd like to call it a draw.  You're both right.
    Sometimes people want total control of their documents, but that's
    not always appropriate in a corporate environment.
    
    Now back to the question at hand...  Where's my table of contents?
    
    Thanks,
    
    Stew

    DO
    	DOCUMENT/NODEVICE       file          style device /CONTENTS
    	DOCUMENT/NOTAG/NODEVICE file_CONTENTS style device
    	DOCUMENT/NOTAG/NOTEXT   file          style device
    
    And voila!
    
    The final product will do all this in one easy operation, so I
    understand.
    
    jack

    Stew,
    
    Besides the method Jack indicated in the previous reply I have also
    found that /CONTENTS (and /INDEX) don't seem to like a preceding space.
    
    DOC file design LN03 /cont/index/nodev  may not always work whereas

    DOC file design LN03/cont/index/nodev   has always worked (aside from the
                                            fun I've been having with the 
                                            index.......)
 
    It's also just as easy (and less processor time) to do the following:
    
    DOC file design LN03/cont/index
    DOC file_contents design LN03/notag
        
    The first pass prints the document minus contents and index, the
    second pass produces the contents - without the need for the third
    pass just to get the contents to print in the correct place in the
    file. It is a trivial matter to put the contents in the correct
    place by hand.

re: 164.6

    <set flame ON>

There is NO conflict with what 164.6 wants and what I, and others, have 
proposed. General purpose doctypes such as GENERAL, functional specs,
ANSI/ISO/etc. standards documents, military specs, etc. have no business making
such choices for the user.

In specific doctypes, or those for specific books, do whatever you want, but I
won't use them.

If DOCUMENT is to be (more) successful, then doctype GENERAL has to provide
nearly every widget and gadget that is reasonable. Other doc types can then be
built by adding to, modifying or deleting those gizmos.

    <set flame ETERNAL>

> I have also found that /CONTENTS (and /INDEX) don't seem to like a preceding
> space.

This sounds very unlikely to me.  You can put those qualifiers everywhere and
 anywhere (e.g., "DO/CONTENTS file/INDEX design destination").
  <_Jym_>

 re .11
    
    Yes.  You can put the qualifiers anywhere.  The question is:  
    
    		Do they work? 

    	<no_flame_intended>
    
    	I have to agree with .10 (and, hence, disagree with .6).  I
    understand the need -- and motivation -- for document consistency.
    However, I would hasten to point out that *NOT* all documents have
    the same requirements.  And no single application can determine
    what *every* document should look like.
    
    	Yes, I understand the concept of document types!  But by the
    same token, I don't believe that we should force the creation of
    new document types on each user who has something slightly different
    to write/format.  In fact, I don't at all disagree with the concept
    of standard document *types* used by everyone in an organization.
    But then give me more flexibility within the *TAGS* to do the things
    I need to do.
    
    	In the particular case mentioned in my original (.0) query,
    for example, the Tables I am using are not really being used in
    the ordinary sense of tables at all!  However, in order to accomplish
    the formatting that I was looking for, my only alternative -- given
    the current capabilities -- was to use the table processing which
    currently exists.  What spawned my original question, then, was
    the fact that I *don't* want these tables to appear as "Tables"
    in the TOC.
    
    	If I had more formatting control, I would not have had to resort
    to using one of the few, fixed formatting techniques available.
    And I would not have had the original problem.  I appreciate all
    of the replies; I believe, however, that for the present, my "solution"
    of manually editing the file_CONTENTS.TEX file is going to have
    to do.  Maybe some day...
    
    	Frank

    If you don't want them to appear in the TOC, can't you use an informal
    table (without a numbered caption)? I believe that is exactly what
    informal tables are for.
    
    --Andrew

{RE .12} - I've tested the qualifiers.  I put them everywhere, with or without
 spaces.  They work.  I've looked at the code.  There's no reason why they
  wouldn't work.

If the problem can be reproduced, I'd like to see it.
 <_Jym_>

    
    Andrew is correct (.14). The format of a table is the same regardless
    if it has a caption. Why not precede the tables with <subhead1>(text)
    tags instead of using a table caption?
    
    patti anklam

Hmmmmmmmmmmmmmmmm!

It appears that this topic has diverted into at least 2 discussions.

It would be a lot easier if we split them up.

    Back to my question about generating the contents file...
    
    I always though that you could tell it /CONTENTS, and it would generate
    it automatically.  Then the tag <CONTENTS_FILE> would pull the file
    in for me.  I consider having to do two or three passes to be
    suboptimal, to put it diplomatically.
    
    Thanks for explaining the proper procedure.
    
    Stew

    
    Agreed that it's not the best way, but it was as close as we could
    get in order to get FT1 out. It all comes together as documented
    in the update. The restrictions were documented in the release notes.
    
    

    Re the space problem.
    
    I haven't had it happen lately as I don't put any spaces in....
    
    It may have been tied up with the indexing problem I have been
    having. Since it is all a while ago that I had the space problem,
    and with no spaces I don't get it, I can't be much more use. I do
    know it effected contents for me. I'll try and duplicate it and
    say some more then.
    
    Regards
    Kevin M

re: 164.19

What are you discussing here?

See 164.17.