[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

641.0. "Some wishes from the field - 1644 format?" by SAACT0::LEON_M () Sat Jul 11 1987 21:08

    First of all, permit me to say that VAX Document is <emphasis>(great)
    !
    
    I have done some very nice example stuff for possible customer here
    at General Electric, in Daytona Beach, Fl.
    
    The problems that I have mostly relate to formatting features which
    don't seem to exist (at least for V1.0), and our customer here is
    getting the increasingly annoying attitude of <quote>(If DEC doesn't
    have it now, we'll go somewhere else) (ala Scribe, maybe).
    
    Now that the general attitude of my customer is known, here are
    some specific problems:
    
       o (Big Problem) There is no 1644 format.   GE has a program which
         is currently updating its documentation for something the
         government calls "block updates", and it would be *very nice*
         if we could give them a 1644 template, so they could see some
         of their documents prepared with Document.
    
       o (Related to the foregoing) the current limitation of <headx>
         tags, where x .le. 6 is not deep enough.  Some of the current
         document's headers go as deep as 40.1.3.1.2.4.5.10 (believe
         it or not), and they (GE) don't wish to change this, since
         the document has already been delivered).
    
       o When doing "red-lines" for the customer, GE has to turn in
         the pages that are likely to change with the update.  Only
         thing is, there isn't any way (that I know) to artificially
         <SET_HEADER_LEVEL>(40.4.1).

       o It is very important to GE to be able to create not only designs
         but to design TAGS (I know we have heard it before), because
         they would very much like to be able to use Document to set
         up LETTER.GE and LETTER.PIR_GE and ... (just to name a few).

       o Seems silly (as in previous notes) that we don't have a
         <reference(item\PAGE> and/or <reference>(item\HEADER_NUMBER)
         tag.  We would seem to need this to be competetive with products
         like Scribe.
    
    It is likely to get any|all of this funcionality in V1.0 or V1.1
    or V1.2 (when is it likely to be there) ?

    All in all, its a great product, it just needs more functionality
    to be useful to customers like GE (they tell me).
    
    If some of these things <wish>(all of it?\hopeful) could be added
    <emphasis>(fast\font=big) we might not lose this important customer.
    
    Thanks in advance for your input.
    
     Marilyn
    
T.RTitleUserPersonal
Name
DateLines
641.1Have you consideredBUNSUP::LITTLETodd Little, New York Area SWS, 323-4475Mon Jul 13 1987 13:1317
    Regarding "red-lines", isn't the change bar support and the update
    range capability adequate?
    
    Not trying to suggest that the issue of customer written tags isn't
    a worthwhile cause, but can't some of what they want get taken care
    of by modifying existing designs and using their tagsets?  How does
    LETTER.GE and LETTER.PIR_GE differ in tags from LETTER?

    Also, DOCUMENT does support <reference>(item\HEADER_NUMBER), if
    what you mean by HEADER_NUMBER is the section number.  Any header
    that defines a symbolic name, i.e. <HEAD2>(This is a test\test_sec)
    defines test_sec, then <REFERENCE>(test_sec) will produce Section
    c.n1.n2, where c=current chapter #, n1 = current <HEAD1> #, and
    n2 is the current <HEAD2> #.  Or were you looking for something
    like Section n2?
    
    -tl
641.2Customized doctype neededCLOSET::ANKLAMSun Jul 19 1987 15:5315
    
    The information in .0 is very useful for overall planning purposes
    and these are things we should look at, but obviously can't make
    any commitments right now. 
    
    This type of request, and others for special-purpose doctypes and
    tags should eventually be handled by software services, who should
    be able to help customers design their own doctypes. That is the
    primary audience for the in-progress 'Tag Designer's Guide', which
    should also be accompanied at some point by more information on
    the TeX macros, etc. 
    
    patti
    
    p.s. Thank *you* for your positive comments!