Conference vaxuum::online_bookbuilding

    It's not clear from your description exactly how the <u> tag is coded
    for the return key. Please send me a sample of your coding and I will
    look into it.
    
    Thanks,
    
    Mary

    Hi Mary,
    
    Here's a very short sample.  When I build the book with
    ONLINE.REFERENCE, the box with "Return" inside is not bold.  Thanks for
    any strategy you can suggest.
    
    Joyce
    
    <INTERACTIVE>
    <S>($ )<U>(HELP OPS5 RELEASE_NOTES <key>(Return))
    <ENDINTERACTIVE>
    

    Thanks for finding this. I changed the font spec for keys inside
    interactive/code examples. This assumes <key> will *never* be
    used for system output (makes no sense, right?) and within code
    examples, which use the same macros. Anyone see a problem with this?
    The change will be in the next baselevel of the online tools.
    
    Mary 

    Recent changes allow us to use <u> without
    <interactive>/<endinteractive>. 
    
    Will your fix also cover this situation?
    
    I'm not sure what you mean about code examples -- we can still use
    <key> inside a code example, right? 

    I don't use <key> in system output, but I know there are a lot of
    manuals out there that (admittedly improproperly) code interactive
    sequences with <code_example>, and rely solely on color mark-up to make
    the distinction between system and user.  So, these lines would include
    <key> within code examples.
    
    Before ONLINE came along, the <s> and <u> tags didn't have any visible
    effect, so it was not uncommon for writers to avoid using them.
    
    Please keep us posted on what you decide.
    

    <u> without <interactive>/<endinteractive> -- no, <key>(whatever)
    won't be bolded (but the <u> text should be). I'll look into that
    if it happens all the time...?
    
    <key>() inside code examples: you can use it but it will be boldface.
    I couldn't think of why <key> would be used in that context. Do you
    have an example?
    
    Personally, I don't think the <key> output needs to be boldface in
    any context -- that the boxing provides sufficient distinction.
    Comments?
    
    Mary

    When I have interactive examples printed, we indicate user input
    with red. This includes the keys the user types.  I would expect
    that this convention should carry through to bolding the keys online
    for user input.

    When I read the base note, my reaction was, "Bold key symbols?  That's
    silly, but if that's the way it's supposed to work..."  A key is by
    definition "user input," even if mentioned in text -- it denotes the
    act of pressing the key.  Bolding it seems redundant (and probably
    doesn't look good on the screen, either, but I've never seen one).
    
    I do suspect that there's lots of interactivee examples coded as
    code_examples out there.  I always felt foolish putting those <s>s and
    <u>s in, knowing they didn't do anything.  But being a slave to
    procedure, I put 'em in anyway.  I bet many writers didn't.
    
    Andy

    I vote with Sarah (145.7) for consistency with hardcopy style, bearing
    in mind the Principle of Least Astonishment.  The only reason I brought
    up this issue is that I was surprised when I saw the non-bold Return
    keys in the Bookreader.  
    
    Also, from a coder's point of view, the <u> tag feels "broken" if an
    item within its scope does not become bold.

    OK. While I tend to agree with Andy's note that boxed keys are, by
    definition, user input, I have fixed the font specs for <U> tag
    output both in interactive examples and in text to be bold face.
    
    Someone speculated in a reply that many interactive examples are
    coded as code examples because the output from the two, to date,
    has been indistinguishable. Since this is no longer true, with
    the advent of online documentation and (coming soon) color printers,
    it is advisable for writers to make sure that their code examples
    are coded properly.
    
    Thanks,
    
    Mary

    I'd like to see the <interactive> and <endinteractive> tags go away.
    
    Why have a tag that "ennables" another tag? Seems like a really useless
    step, especially since it's not required any more.
    
    Of course, old files that use these tags shouldn't cause DOCUMENT
    errors, but let's stop telling writers to use unnecessary tags.
    
    Ross

    <interactive>/<endinteractive> tell the formatter to break the example
    out from the main flow of text (skip so much space, start on a new
    line, indent, whatever). The <u> and <s> tags flag text that, in a
    perfect world, is treated differently, the <u> text changing color.
    
    <s> and <u>, in fact, are legal by themselves in text so it's not
    that the <interactive> tag enables the <s> and <u> tags but that it
    sets up the formatting for the example.
    
    It makes a great deal of sense, in many cases, for one tag to 'enable'
    another tag(s) since some tags should not be used in some contexts.
    (It makes no sense to have a routine description on the title page,
    or a title in a routine description.) The notion of enforcing
    structure through 'zones' or context-checking is becoming more
    widespread with documentation standards such as SGML.
    
    This question actually belongs in the DOCUMENT notes conference, since
    it's not specific to online bookbuilding. 
    
    Mary

    My apologies; no one ever made this clear to me (or even tried). 
    
    Thanks.

In the DCL command template, the <EXI> tag also does not provide bold for keys. 
I've had to add the <EMPHASIS>(Return\BOLD) tag within the <KEY> tag to produce
this effect.  

Will a future release take care of this problem?

Holly Platnick

    Hi Holly,
    	The software has been modified to produce bolded text when you use
    the <KEY> tag after the <EXI> tag.  It will be available in the next
    release.
    
    Have a nice one...
    	Wayne