Conference vaxuum::document_ft

    
    	Found at least part of cause [?] of my problem.  The VAXmate
    LN03 driver does a printer_setup sequence at the start of the
    sixel file:
    
    <CSI>!p	Soft Terminal Reset
    <CSI>7 I	Select Size Unit 7 pixels (300 dpi)
    <CSI>11h	Position Unit Mode set spacing increment = SSU
    <CSI>0;0r	DECSTBM {no effect since =0}
    <CSI>0;0s	DECSLRM {no effect since =0}
    <CSI>?20 J	Page Format Select portrait tall (DEC private)
    
    	Then, each sixel line is wrapped with the following sequence:
    
    <CR>	Hard carriage return
    <ESC>Pq	Device Control String - Sixel String introducer
    [sixel data]
    -		Graphics Next Line
    <ESC>\	String Terminator {7 bit}
              
    	The sixel data is interesting in that it uses 7-bit control
    codes although the printer setup is 8-bit, although I suspect
    this is not an issue.  I believe my problem is in the setup
    string, in that <CSI>?20 J will redefine the printable area
    and hence destroys any margins that TeX has set.
    
    	Confirm/deny/comment?
    
    	Harold
    

    I tried to edit out the setup string, but found that the record
    size was too big for EDIT (510 bytes).  I found a way to convert
    the sixel file to something more manageable.  This is truely a
    hacker's answer since the "real" fix is to go change the LN03
    driver...
    
    1.  Define (EDIT/FDL SIXEL) a file with the following attributes:
    	FILE ORGANIZATION SEQUENTIAL
    	BLOCK SPAN YES
    	MAXIMUM RECORDS 300 {or so}
    	FORMAT STREAM_CR {to break the file into smaller records}
        MEAN_RECORD 70 {or so}
    	MAXIMUM_RECORD 0
    
    2.  CONVERT/FDL=SIXEL infile.PRN outfile.SIX
    
    3.  EDIT outfile.SIX and delete the setup string noted in 622.1;
    	UNFORTUNATELY, large pictures will still exceed EDIT's buffer
    	size limit of 255 bytes, so this is only useful with small
    	icons...
    
    4.  outfile.SIX can now be included as an ICON_FILE without blowing 
    	the margins.
                 
    	I'm still looking for a fix for the bigger/more complex pictures.
    
    	Regards.                                       

    RE: the problem
    
    I suspect you are right that the Page Format Select blows away the
    environment, positioning, etc., that VAX DOCUMENT has labored hard 
    to establish.  Also, this software is expecting that the figure
    file contains only one figure (sixel region).  If I understand your
    note correctly, the VAXmate creator make every line a separate diagram,
    and does a text-mode <CR> between each one.  That certainly blows
    away the expected formatting as well.
    
    > the "real" fix is to go change the LN03 driver...
    
    [I'm fighting for a way to give a non-religious answer to this
    religious statement...]
    
    1. The only way to "fix" the driver to handle every conceivable
       situation is to implement a complete LN03 interpreter in the driver.
       That's out of the question.  A printer language, whether PostScript,
       LN03, or simple line-printer ASCII, is still a programming language,
       and when you let people throw their programs into the middle
       of yours, you're taking risks.
    
    2. We are just beginning to enter the world of compound documents.
       The biggest obstacle and least-understood complication is that
       all existing graphics tools have been preparing standalone print
       files -- files to be printed in a "top-level" environment that
       the creator is free, encouraged, even required to define.
    
       However, when you include those self-contained files in an
       environment set up by somebody else, that assumption of a "pristine"
       (or more likely, of a "chaotic") environment is just flat wrong.
       So the standalone files mess up the constructed environment.
    
    A lot of things need to be done.  We're stuck with what most existing
    graphics tools do, but we must be sure that developers of future tools 
    in this space understand this problem.  In the meantime, we can only 
    proceed empirically.  Since there are no standards for how sixel files 
    must be coded, we've got to field things as we discover them.
    
    As we gain experience with this stuff, we will provide some kind
    of documentation on recommended and "prohibited" techniques.  That
    kind of thing is under way at a corporate level for PostScript,
    and will yield its fruit in future development.  But when it comes 
    to existing tools, it's still pretty much a hacker's world.
    
    We have made some strides in this area with PostScript graphics:
    features have been added to GRED and SIGHT, primarily through
    enhancements to RENDER, that address some of these problems.  And
    we extend our appreciation to those who have contributed to this.
    But we are all new at imbedded graphics, and we are all still learning.
    
    --Mark

    >religious statement...
    
    It certainly wasn't meant as such, all I was implying is that at
    least internally we could do a better job of cooperation in device
    driver formats.  The folks in the PAGEMAKER and SCRIPTWRITER
    conferences run into this kind of problem on a daily basis...
    
    Anyway, here's how to use your VAXMATE to create useable sixel
    files.  (You can ignore 622.2, this is a much easier way...)
    
    1.  Edit your WIN.INI file to include the printer output filename,
    	as in:
    
    	SIXEL.PRN=
    
    	This creates a "connectable" device output port.
    
    2.  Use the Control Panel to connect the LN03 to SIXEL.PRN; this
    	means that all print output gets (over)written to <path>sixel.prn.
    
    3.  Use PAINT to draw whatever you want.  You will need to leave
    	about 1/2" right and 1" bottom whitespace to satisfy the maximum
    	drawing size of 37 x 44 picas.  PRINT directly from Paint.
    
    4.  Transfer the SIXEL.PRN file to your VAX, using your favorite
    	method.  I happen to use KERMIT, SET FILE TYPE BINARY.  I
    	think that if you are running under PCSA you can COPY it, and
    	under DECnet-DOS you use NFT.
    
    5.  Here's the key step:  Use EDIT/TPU and delete the first 27
    	characters, i.e., up to and including the "<CSI>?20 J".
    	TPU has a bigger internal buffer size than EDT, and does not
    	complain about the 510 byte records...
    
    6.  DOCUMENT will now happily process the sixel file just like
    	those from GRED and SIGHT.  It does not care about the use
    	of hard carriage returns in the sixel bands.
    

    "...works for me..."
    
    Harold    

    Thanks, Harold, for the hard work and careful documentation you've
    provided.  As the keeper of the VAX DOCUMENT LN03 converter, I had
    no idea that we'd see graphics from the PC world in this way.  And
    it's obvious from the data format that the folks to did the work
    on the PC side didn't expect to be "compatible" with DECslide,
    DECgraph, etc.
    
    Thanks, too, to the others like you who take the time to research
    such thorny problems and to share their findings.  In a very real
    sense you are all developers of VAX DOCUMENT, and we appreciate your
    efforts.
    
    --Mark

    
    Some additional information: "...sometimes it works, and sometimes
    it doesn't..."
    
    In certain instances, even with the editing noted in 622.4, the
    LN03 will still lose the left margin setting that TeX wants, with
    the result that the hard <CR>'s will blow you away.  I haven't
    figured out why.  But I do have a fix.  <bad_news, good_news, bad...>
    
    To make the MS-Paint/VAXmate LN03 driver output look even more like
    a pure sixel file, you have to edit out the <CR>'s, and stick in
    a graphics carriage return ($, real dollar sign) before the <ST>
    (String Terminator, an <ESC>\ string).  Also you should jump to
    the end of the file, and delete the trailing <FF> (form feed),
    otherwise the laser will split your page when it finishes with
    the sixel image.

    Therefor, your final file should look something like this:
    
    <ESC>Pq [sixel data] -$<ESC>\
    <ESC>Pq [sixel data] -$<ESC>\
    (etc.)

    ...and a final word on the (not very) religious issue, it would
    be fair to ask the Windows driver folks to produce (in addition
    to their standard LN03 driver) a "sixel" driver which would do
    nothing more than convert the screen image to sixel bands, sans
    device setup/finish strings.  I'll see if I can get someone's
    attention on the VAXMATE conference.
    
    Harold
    
    

    
    OK, I wrote a filter program that eliminates editing.  The binaries,
    sources, samples, and documentation is available in:
    
    NWLONG::DUA1:[LONG.VAXMATE.SIXEL]*.*
    
    They were placed there using KERMIT SET FILE TYPE BINARY.
    
    Read PRNTOSIX.DOC for useage and restrictions.  Good Luck!
    
    Harold
    

    
    The PRNTOSIX.EXE, .C, and .DOC have been updated, thanks to pointers
    from Rick Merrill.  Slightly larger/more complex pictures can be
    handled as a result.  They were transferred there using NFT, so
    they should be copyable by any method (KERMIT, NFT, PCSA).  The
    sixel files are now editable by EDIT/EDT, so you can also play
    with aspect ratios, etc.
    
    Good luck.
    
    Harold