Conference vaxuum::document_ft

    <MATH_CHAR>(BULLET) generates the bullet character already.
    
    -tl
    
    PS  Seems like a <MATH_CHAR>(BIGBULLET) like <MATH_CHAR>(BIGCIRC)
        might be a nice addition.

    
    and square_bullet and bigsquare_bullet and ... we will over time
    be adding to the list of special characters. It would be good to
    get some idea (besides those mentioned here already) what characters
    folks need.
    
    -pa

    I thought that something analogous to the keypad_row tag for hardware
    LEDs would be appropriate.
    
    Or it could be more generalized and called bit_string, or on_off,
    with a choice of square or round "lights."
    
    Marty

    Well... there are a series of international symbols in DEC STD 178-5
    and many of these have applications in hardware docs. In particular,
    a symbol with a dot above a circle to complement <MATH_CHAR>(ODOT)
    would comply with one of the switch standards. Two others would
    be an exclamation point in a triangle and a lightning bolt. The
    question is, I guess, where do symbols stop and icons begin?

    do you mean to say that someone KNOWS what those internationalized
    symbols mean?   and it is written down in a standard?  what 
    language did the standard use to explain them?    hmmm...

    Why not just plan to extend to use all of Digital's standard character
    sets.

    Based on the user interface standard being set for DECwindows, it
    is probably wise to implement for V1.1 an <ICON_CHAR> (or some such
    name) tag to support the printing of actual iconic figures like
    those that will be appearing in DECwindows displays.
    
    jack

RE: < Note 456.6 by VIDEO::LASKO "Using Workstation-Like Features" >
    >                     -< Here's a wild thought... >-
    >
    >Why not just plan to extend to use all of Digital's standard character
    >sets.
    
    After the "motherhood" statement is done -- what does that MEAN
    in the context of VAX DOCUMENT?
    
    We use our own fonts because we require some characters that are not
    in any of the "standard character sets".  Consequently, we know
    how to get to the characters we use.  It doesn't really matter if
    the <mumblefratz> character is in position X in ISOLatin-1 or position
    Y in DECMCS as long as we know how to get to it in the fonts we
    use.
    
    It makes it easier for us to build our fonts, of course, if the
    share a common base with an existing standard -- and they do.  The
    "DOCUMENT character set" is DECMCS plus 10 publishing characters.
    Our 10 publishing extensions *do* exist in the DEC Publishing character
    set -- except the same font is not DEC Publishing and <anything_else>
    at the same time.  And, the DEC Publishing stuff doesn't exist in
    a marketable, supported version for PostScript (as far as I know).
    
    So what does it mean to "extend to use all of Digital's standard
    character sets"?  It's a noble-sounding goal ... but I don't see
    how it applies here.
    
    Thanks,
    Mark

    Re: .8                       
              
    Character coding is fundamental.  Once one moves away from standard
    encodings, one has two choices: do one's own thing and accept the cost
    of specialty fonts and potential incompatibilities; or try to build a
    consensus with the rest of the company so that those potential risks
    and costs are avoided.  One also ends up setting expectations as to the
    capabilities of all of our products, creating requirements willy-nilly
    in lieu of deliberate choice in our repertoire.  (This is actually
    my more serious concern--a lot of my time lately has been spent
    excising specialty sets from general purpose products.)
    
    What does my suggestion MEAN in the context of VAX DOCUMENT?  Well, you
    say in .8 that the project went ahead and did it's own coding because
    nothing was handy at the time, but now that it does do it's own coding,
    it can't come back to meet standard interchange sets because nothing
    seems to be out there.  This is fine, if DOCUMENT will remain a
    completely bounded system using it's own storage and output formats. If
    this isn't true, then I think my statement is highly relevant. 
    
    One more point: you'll notice I said "plan" in .6; DEC Publishing and
    Output Rendering are being discussed with Adobe.  Things work much
    faster when there's actual product weight behind it, though.

    RE: .9
    
    If something comes along that meets our needs, we'd love to cooperate.
    It would be great if we could get out of the font-preparation business
    and use everything off-the-shelf, and if a DEC customer could buy
    fonts from the same bag to serve many tools.  I'm sure there will
    be movement in that direction among many DEC products, including
    VAX DOCUMENT.
    
    We are not non-standard out of pride or territoriality, but out
    of necessity.  The things we need are not completely available yet
    in any existing packaging.  We do provide for interchange, and will 
    do so more in the future.  But interchange often means "lowest common
    denominator".  Well, the lowest common denominator in text presentation
    is the monospaced stuff you get on a line printer. We cannot
    limit our capabilities to the restrictions of that device -- but
    we do provide support for even that low-level device (though it's
    much more limited than our real targets: laser printers and
    typesetters).
    
    To your question, "Do you plan to be bounded forever?", I respond
    thus: We plan to do what we need to do.  We have a strong desire
    to be an integrated part of DEC's electronic publishing world.
    But we are not TBU, and its product focus so far has seemed to
    concentrate more on the single-user or small-group office publishing
    environment, and less on the large-group, "corporate" publishing
    environment.  There is nothing necessarily wrong with that -- it's
    important that they serve their chosen markets well.  
    
    We are working to represent the perceived needs of our market as well, 
    and to characterize both the differences and the similarities among 
    these various market levels.  But we are also getting V1.0 out the
    door.  It's important to participate in discussions of long-term
    strategies, but if we never get version 1 on the market, it doesn't
    matter how great version 2 might have been.
    
    Do we *plan* to be bounded forever?  No.  
    *Will* we be bounded forever?  Who knows?
    
    Thanks,
    Mark                                       

    Whoa!  I don't like the implication that I'm suggesting a delay in VAX
    DOCUMENT.  Farthest from the sort--it's a marvelous product, and I'd
    love to write my character set standards using it (hint, hint).  The
    operative verb in my suggestion was *PLAN*, and I thought that the
    intent of this note was to sound out future possibilities. I know why
    VAX DOCUMENT is different, and I am not criticizing that pro or con. 
                                
    I encourage cooperation: DEC Publishing frankly is sort of sitting in
    the water because not enough people have stood up and said "this meets
    our needs"--despite it's already wide review.  In the meantime, it has
    and may again go through changes. Interchange will also not mean lowest
    common denominator within two years: DDIF and DDFF are coming along
    very quickly. 
    
    The point I'm trying to emphasize is that it is in Digital's best
    interest to have a common repertoire and encoding [at least at the
    interchange level] for Publishing characters (and electronic symbols,
    and anything else that can be described as a character)--if only
    because it means we only have to go to Adobe, Compugraphic, and
    Bitstream once for the zillions of fonts that we now use.  There
    already is a common set of characters for LPS and LN devices, we're
    already using it, and video devices are finally comming out with DEC
    Technical standard.  I don't want to see any more specialty sets
    beyond those if it can at all be helped.
                            
    Thank you for listening...
    
    Tim
    TBU Architecture/Systems
    
    P.S. Let me clear one other point: while PKO3 is where I happen to hang
    my hat in the morning, don't assume I'm trying to invoke ``TBU market
    requirements'' over VAX DOCUMENT.  My job as ``character sets
    architect'' is to be concerned with corporate wide interchange at that
    most fundamental level.   
    
    P.P.S. It's been pointed out off-line to me that my reply in .6
    may have had a touch too much sarcasm in it--if this is the main
    reason why we're in violent agreement then I apologize.

    > I think we're in violent agreement
    
    I agree.  Thanks for your interest and good suggestions.  We look
    forward to cooperating with many other groups as standards -- and
    our understanding of them -- develop.
    
    Mark

re: 456.0


>It would also be useful to have the complete ISO character set.

What do you mean? The number of "ISO character set"s is greater than 1.

re: 456.6

Yup, and what about all of the ISO character sets, as that is what is required
by the marketplace.