Conference vaxuum::document_ft

    RE: figure files in MAIL
    
    The intent of the MAIL destination is to provide files that VAXmail
    can read.  Since the escape character is explicitly excluded by
    the VAXmail READ function, we cannot put sixel figures in MAIL.
    
    The TERMINAL destination, however, does use escape sequences, and
    your request is a legitimate wishlist item for such devices.  
    
    The question we have to wrestle with is this:  Will many users expect to
    read TERMINAL files on a lot of terminals that do not support sixels?
    If so, we could (1) continue to deny sixel support (yucch!);  
    (2) create a different destination and filetype for terminals with 
    sixels (ptui!);  (3) add the support and leave it up to customers 
    to control distribution of such files (arrggh!).  And there are
    probably other possibilities too.
    
    In short, this is good wishlist stuff.  We will have to decide on
    a greater strategy for monospaced and terminal support, and then
    evaluate such requests in the context of that strategy.  Otherwise,
    no one will ever be able to figure out *what* we support.
    
    --Mark                

    (RE: .1)
    Mark,
    
    I gather from the comments on your three options that you need some
    more input to determine a good possibility.  I'll start by asking
    a question (to stimulate the thinking...)
    
    I'm not sure I understand the differences between LINE_PRINTER and
    TERMINAL.  Could someone summarize the differences?
    
    Brad

    All three monospaced destinations -- LINE_PRINTER, TERMINAL, and
    MAIL -- travel through the tag translator and text formatter the
    same way, and produce the same .DVI_LINE file.
    
    In this limited environment, there are not really "fonts", just
    different kinds of emphasis [like the SDML code <EMPHASIS>() or
    <EMPHASIS>(\BOLD)].  Any other font variations map into these
    renditions, so you get a total of four presentations possible:
    
    o	normal
    o	underscore (for normal emphasis)
    o	overstrike (for bold)
    o	underscore and overstrike
    
    LINE_PRINTER: Our big, fast line printers can overstrike but do not 
    execute escape sequences, so these renditions are represented thus:
    
    	BOLD by overstriking the character with itself;
    	UNDERSCORE by overstriking the character with the underscore.
    
    
    TERMINAL: These things support escape sequences and do NOT support
    overstriking, so these renditions are represented by the corresponding
    escape sequences.
    
    
    MAIL: VAXmail READ does not support escape sequences either, so
    everything prepared for this destination comes out in the same normal
    rendition.
    
    I realize that there are dot-matrix printers with fonts, even
    proportional fonts.  I realize, too, that some printers and terminals
    support sixel graphics, and that various things (but not all) support
    VT100 graphics.
    
    I imagine it is confusing enough for the casual or new user to
    appreciate even the three flavors we have now.  I am reluctant
    to propose that we support still more formats which are subsets
    of the monospaced destinations we now support.
    
    My overriding concern is that, if we add all these other features,
    we will be encouraging users to make files that many others cannot
    read or print on the devices available to them.  Therefore I challenge
    you, the VAX DOCUMENT users, to explain why any additional monospaced 
    format provides so much for the greater good that it justifies the 
    additional confusion it might introduce.  [And I suspect some of
    you *will* provide that explanation.]
    
    Thanks for your participation,
    Mark
    
    

    
    The last time I looked, there were something like 97 output device
    alternatives for Microsoft Word (supplied with the kit!), and probably
    many more on the market.  Even DEC was there, at least with the
    LN03, but not the LA75 or LA50.  The whole issue of output file
    mapping to physical device is getting out of hand.
    
    Anything that encourages folks to continue writing additional device
    drivers, one per device, is probably not good.  As a <flame_level>
    supporter of standards, I would vote for an intermediate format
    output which would then be interpreted BY THE DEVICE as it needs.
    Unfortunately, this does not exist, at least in any great measure.
    There are some emerging standards (TFF, and others) but the only
    one that seems to be taking hold is PostScript, and you won't see
    PostScript compatible terminals and printers at the <$800 level
    for a while yet...  and I kind of doubt they would have any reasonable
    level of performance (compared to a 19.2 Kbaud ascii screen refresh)
    at that price.
    
    OK, so what.  None of this addresses the initial request, <FIGURE_FILE>
    suppport for [I assume] VDT's.  Actually it's a reasonable request
    for INTERIM/INTERNAL use, until we have a more broadly accepted
    standard for compound document exchange.  I would not go so far
    as to suggest different destinations/doctypes for each possible
    terminal, but a more general set of alternatives (flags) such as
    the following:
    
    DOCUMENT foo doctype TERMINAL/REGIS
    			 TERMINAL/ASCII_ESCAPE
    			 MAIL/SIXEL
    			 [etc.]
    
    ...or whatever number of variants are appropriate and supportable.
    
    Cheers.
    
    Harold
    

  > ........................................  I would not go so far
  > as to suggest different destinations/doctypes for each possible
  > terminal, but a more general set of alternatives (flags) such as
  > the following:
  > 
  > DOCUMENT foo doctype TERMINAL/REGIS
  > 			 TERMINAL/ASCII_ESCAPE
  > 			 MAIL/SIXEL
  > 			 [etc.]
    
    It's just a name game -- whether to call it TERMINAL/REGIS (destination
    with qualifier) or TERMINAL_REGIS (distinct destination).  The
    *problem* is that you can make a nice compound document and send
    it to me, but I can't read it on my terminal.  That problem is further
    hidden if different protocol lurk within the cover of the same file
    extension (I can read my .TERM file -- can I read yours?).
    
    Actually, the seed for such a problem is there already.  Monospaced
    output can be had in two flavors -- 8-bit DEC MCS or 7-bit, with
    fallback representations for the MCS characters.  I'm nervous about
    those "hidden" incompatibilities already, and that's a variation
    that will probably be standard on a regional basis.  What can we
    do about protocol alternatives that vary according to equipment
    available or the personal preference of the creator?
    
    Certainly,"standard" output languages like PostScript will help
    in certain situations, and I agree that it will be a long time before
    such things penetrate the "desktop eye" market.  What should we
    do now, with the existing set of alternatives?  What do you, the
    document creators and readers, consider the highest priority
    enhancements in the area of terminal and cheap-printer (including
    dot-matrix) output support?
    
    	REGIS?  SIXELS?  VT100 LINE GRAPHICS?
    	ALTERNATE FONT SELECTION?
    	PROPORTIONAL FONT SUPPORT?
    
    How about other renditions, such as reverse video, blinking,
    shadow-bold, whatever.
    
    Please, please consider the greater DEC community (at least).  I'm
    asking for what you think would be most important for the most people 
    in the next release of VAX DOCUMENT.  I'm *not* asking what you wish 
    it could do someday.  Those discussions are interesting and worthwhile
    and will continue -- but we need to know your short-term priorities
    among all those possibilities.
    
    Thanks for your interest and advice,
    Mark

    I started this note because I have a current need.  If I can't satisfy
    that need with DOCUMENT, then I must do more work (manually edit
    my SIXEL figures into a TERMINAL output document), maintain my source
    document in both RUNOFF and DOCUMENT, or not use DOCUMENT at all.

    Let me explain my problem in a bit more detail.  I am creating reports
    and articles for distribution to both an internal audience, a
    semi-internal audience (via Sales Update, Competitive Update) and
    at times an external audience.  The internal audience is widely
    distributed geographically, but is all only "a few DECnet hops away".
    
    DOCUMENT seems to provide a major improvement in the amount of work
    that I put into a document vs the quality of the output.  A
    particularly powerful feature is the ability to produce output for a
    wide variety of devices with an identical input file.  These output
    files can then be "distributed" (by announcement, via COPY, by MAIL, in
    a notesfile, hardcopy, etc.)
    
    A year ago we were distributing strictly via hardcopy after a "cut
    & paste" of the figures.  A quantum leap forward was a "kludge" I
    put together to imbed the SIXEL graphics within a RUNOFF document.
    The resulting file is MAILable (not viewable within MAIL, but
    distributeable with the comment, "Extract & print on a SIXEL printer")
    
    It seems that almost everybody I have sent a report to has been
    able to find at least a LA50.  I have asked about LN03 but that
    seems to be a bit harder to find (especially in the field offices).

    I am willing to <CONDITION> my document if necessary to produce output
    for a non-SIXEL device (A <NOT_CONDITION> would make this easier), but
    I need the ability to generate a mono-spaced, SIXELs included file. 
    

    For V1.1 I suggest that <FIGURE_FILE> be enhanced to include a no-holds
    barred, mono-spaced target device.  How about DOT_PRINTER?
    
    Has Digital produced a dot-matrix printer that can't do SIXELs and
    VT100 line-drawing?  The LA34, LA50, LA75, LA100, LA210 all can.
    
    I am willing to sacrifice REGIS, ALTERNATE FONT SELECTION, and
    PROPORTIONAL FONT SUPPORT as well as reverse video, blinking,
    shadow-bold, etc.