Conference vaxuum::document_ft

    This is just a reply to two points in your note, the point about
    what the tag translator is doing to the TeX output that you
    want, and the question about whether you are going about it 
    in the right way.
    
    There is a "post-translator", that is, another pass over the
    output of the tag translator that does all kinds of character
    transformations.  As you have discovered the backslash that
    signals a TeX macro is difficult to output.  The reason is that
    within argument lists, the backslash is an argument separator.
    If you wanted a backslash that would PRINT IN THE OUTPUT, you
    would specify <backslash>, and it would get converted into
    <literal>(\).  But what you want is a backslash that will NOT
    BE PRINTED, but will instead be interpreted by TeX as the character
    that starts a macro.
    
    The tag translator writes its output to a file with the type INT_TEX.
    Backslashes that are to be printed appear in this file as \.
    Backslashes that are to be interpreted by TeX appear as control-T.
    
    The post translator then reads the INT_TEX file and writes a TEX
    file.  It looks for \ and transforms it to "\backslash".  It also
    looks for control_T and transforms it to \.  So the magic comes
    from the fact that the desired TeX macros are disguised
    in the STT files by coding certain of their characters as control
    characters, with reliance on the post translator to put them back
    into the form that is expected by TeX.
    
    If you use an editor like EDT you can "see" the control characters
    as you type or edit them, so it is a little easier.  There is a
    tool that converts a GDX file to a GDE file by converting the 
    control characters into pairs of "visible" characters and there
    is another tool that can be used to convert the GDE file back to
    its GDX form.  This allows you to edit the GDE file with any editor,
    even the ones that don't show you the control characters, and then
    convert the GDE file back to a GDX file.
     
    So, you are doing the right thing and are stumbling on things that
    you should be stumbling on.  And of course, if you had the GDX files
    instead of the STT files you would be looking at "source code" instead
    of "object code," so your sleuthing would be easier.
    
    The main problem is that you are out ahead of us.  We haven't made
    all this obvious because we haven't had the time to "package" it
    and document it so that it can be easily used.  With enough "hard
    work" you can discover most of it, as you have.
    
    What we tried to do for version 1.0 was to package the major design
    decisions regarding layout and to document that in the Doctype Designer's
    Guide.  The creation of new tags is still to come, along with the TeX
    macros.
    
    bill 
    
    

    Ah, the mists clear.
    
    After the previous note, some quick Scan and EDT inside .STT
    files with the Tag translator manual in one hand and the dec
    internal notes in the other, I began to see what is going on.
    
    The problem I had with author was solved by the substitution
    of ^T for "\", ^B for "{" and ^E for "}".
    
     I then searched around for the titlepagesysteminfo TeX macro
    and I now beleive it is part of standard TeX. This makes my
    life much easier in writing the tags, although I have changed
    to using the standard <revision_info> tag as it seems to do
    the job I wanted.
    
    I presume when you guys implement user-written tags, user's
    will not have to enter control characters and the like.
    
    				--
    
    The other problems in .0 I do not know how to solve, though.
    
    Malcolm Exton (doc$fan)

    
    Yes, we will definitely simply this process when we allow users
    to create their own tags. For V2, we will also have a powerful
    design-building tool for changing formats more easily.
    
    I'm not sure what other problems you mean ? 

    Patti,
      To re-iterate the referenced part of .0:
    
     o  Change the look of tables so that vertical lines are present
        e.g.:
    
                +------------------+--------------------------+
    		|   col-head1      |       col-head2          |
                +------------------+--------------------------+
    		|   item           |      another item        |
    		|   item           |      etc.                |
                +------------------+--------------------------+

    
        Instead of just horizonatal lines as appear in all doctypes
        I have used so far.
    
      o  Produce output for single siding - e.g. page numbers all
         appear on the rhs of the page instead of alternating.
    
      o  Integrating Doc fonts into pictures (I only have access
         to an LN03, so the sixel quality for text is poor compared
         with the document text).
    
         Also is it possible to rotate standard Doc fonts on the page?
    
    Malcolm

    
    Most of those items are on the wishlist, i.e.
    
    1. vertical rules in tables
    2. Support for specifying either double or single-sided printing
    3. Printing in landspace mode
    
    I'm not sure about the fonts in graphics. How are you creating the
    sixel files ?
    
    patti
     

    Re .-1
    
    I am using GRED/SIGHT to create the sixel files...