Conference vaxuum::online_bookbuilding

You shouldn't have to conditionalize the figures.

If you just code as follows, DOCUMENT includes the correct file for your
destination:

<FIGURE>(blah)
<FIGURE_ATTRIBUTES>(whatever)
<FIGURE_FILE>(BOOKREADER\DIAGRAM.FSE\22.1)
<FIGURE_FILE>(POSTSCRIPT\DIAGRAM.PS\22.1)
<FIGURE_FILE>(LN03\DIAGRAM.SIX\22.1)
<FIGURE_FILE>(LINE_PRINTER\SPACE\22.1)
<ENDFIGURE>

You need to conditionalize only if you want to include different text in the
two situations.

(If you use UTOX or RAGS, you can create an SDML <include> file and all the 
figure types you need in one operation, with automatically-sized figure spaces.

Ross

Well that answers one question....Thanks.

All I have to do now is remove the conditionals I've put into the on-line FS !

However, the question of a single file still remains unanswered. But, if UTOX 
already produces suitable output it would seem that a single file is the 
intention of at least some bookbuilders.

John

    Yes, a single source file is certainly our intention. As Ross points
    out, you do not need the conditionals in .0 (UTOX once-upon-a-time
    generated such code, but no longer does as it's no longer necessary).
    
    I'm not clear on exactly what question remains unanswered?
    
    Thanks,
    
    Mary

If a single source file is the intention, then no questions remain unanswered.
But let's be clear...

Many moons ago I heard rumblings about a single source file for DECwindows
help and documentation. This, I understand (and hope) is not the intention of
anyone. 

As I understand it now, a DECwindows manual has a single source file that can
be used to produce Bookreader, LN03plus, Postscript and line-printer output.
Further, UTOX will provide assistence in generating the SDML source code and
DOCUMENT recognises the appropriate figure without the need for conditionals.

Thanx

John

    John,
    
    I meant single source file for the online books, not for help *and*
    books.
    
    I personally favor the idea of a single source file for both, but
    realize 1) that it's not currently a popular approach with writers
    (who ought to know) and 2) it's a rathole we could spend millenia
    arguing about. The current tools (while far from perfect) accommodate
    both approaches, and that's the important thing.
    
    Cheers,
    
    Mary 

RE: .4, using a single file for doc. and DECwindows Help --

	that is, running a chapter, etc. through the SDMLHELP utility
	to produce DECwindows Help. You can do some quasi-conditionalizing 
	there, using <BOOK_ONLY> and <HELP_ONLY> tags, if you're concerned 
	that online help should not be as detailed as the manuals.

Ross

    
    [I apologise if this has already been reported elsewhere, but
    response times on this conference are very slow for me]
    
    I am putting this feature in this topic as it is closely related to the
    suggestion of using the <CONDITION> tag in <FIGURE>s.
    
    There seems to be a glitch in DOCUMENT V1.1, in that the conversion to
    BOOKREADER requirements and adding a <FIGURE_FILE>(BOOKREADER\x.FSE\...)
    line to the existing figures works beautifully for BOOKREADER....
    
    ....until you try to produce a hard copy version of the document again.
    
    The LN03 output format attempts to include the BOOKREADER file into the
    document as well as the LN03 file, finds that the included file is the
    wrong format, gives a warning message and continues on it's way.  No
    problem you may think !    What happens inside the resulting document,
    is that an extra figure heading/space with no picture is part of the
    output.
    
    The only workaround I have found is to actually use the
    <CONDITION>(BOOK) tag around the BOOKREADER <FIGURE_FILE> and include
    the condition on the command line for online requirements.
    
    Has this been cured in V1.2 ?
    

    Yes, this is cured in V1.2. I think there was also a workaround for
    this problem in V1.1 (but it's hard to remember back that far...:-)
    Check the documentation and see if it says anything about using a
    \SYMBOLS qualifier to include a .GDX file for hardcopy processing.
    That .GDX file contains the necessary definitions for DOCUMENT to
    recognize the BOOKREADER destination in hardcopy processing and do
    the right thing.
    
    In V1.2A, I know we released such a .GDX file to work around such
    problems. In V1.2B, we merged the necessary tag definitions into the
    global tag set and the .GDX file is no longer necessary.
    
    Mary

For V1.2A, include this on the DOCUMENT command line:

	/SYMBOLS=DOC$LOCAL_FORMATS:CUP$ONLINE_DEFS.GDX

If you're already using another symbols file, add an <INCLUDE> to it specifying
this file.

DON'T do this for V1.2B. It's already taken care of.