Conference bulova::decw_jan-89_to_nov-90

    
    For your stuff, try the ISL (Image Services Library (I think)) stuff
    which should produce DDIF images.  I'm just now learing that everyone
    has re-invented the wheel for DDIF and the same DDIF file is
    interpreted differently by different implementations depending on
    their subset and their set of bugs :-(  But it looks like most
    everything handles images produced by the ISL stuff.
    
    

Both paint and cardfiler use ISL to read and write DDIF images and to store and
retrieve them from the clipboard.

ISl is quite good at take pixmaps and creating images and vice versa.  The new
version can even do color.

Neal

Make sure it's a format that UTOX can read and write!   (Since
UTOX seems to be the de facto conversion tool around here).

Thanks.  Where do I find out about ISL?  My DECwindows documentation makes no
mention of it.

--PSW

    
    That's because it's a layered product that isn't part of the base!
    Try the IMAGING conference (don't remember where).
    
    _Fred

    Another conference you might try is EDWIN::IMAGE_SERVICES which is
    devoted to 'ISL', now known as DECimage something or other.
    
    IMAGING is VISUAL::IMAGING.
    
John
(KP7 for IMAGE_SERVICES conference)

Are there any non-layered-product alternatives?

--PSW

    
    I assume that the runtime library is on VMS, or the object library is
    available internally - since things like PAINT use it.
    

    Paul,
    
    We (the CDA Program) certainly hope that the commonly available format
    for what you want is CDA/DDIF.  DDIF can describe your graphics
    pictures as either synthetic graphics (things composed of polylines,
    arcs, bezier curves, etc. that are stroked and/or filled, etc.) or as
    pixmap images.  [DDIF does text of course, but that doesn't seem to
    apply here.]  DDIF does color for text, graphics, and images.
    
    There is a DDIF->PS converter (and it does color as well).  There is no
    DDIF->Sixel or DDIF->ReGIS converter.  There are a lot of other
    converters, but most of them are document oriented.  The UTOX thing (it
    is not a product as far as I know) does a number of conversions and
    will do DDIF.
    
    The DDIF->PS converter and the CDA viewer (which would view your DDIF
    files) both use the ISL (Image Services Library) for the image
    manipulations.  ISL (which will also read/write DDIF for you -- but
    only DDIF that contains just images) will do lots of things like
    dithering color into gray-scale and/or bitonal, etc.  This is not built
    into the CDA converters except in the sense that the viewer will use
    ISL to re-do the image from whatever it is (like full 24-bit color) to
    match the display -- whatever it happens to be -- automatically.
    
    If you are doing images (pixmaps), the best thing would be to build up
    your pixmap and then use ISL to generate a DDIF file with it.
    
    ISL is part of DECimage (nee VAXimage) and, as of DECwindows/VMS V2.0,
    will be automatically supplied to all customers.  Some of the other
    DECimage pieces will continue to be layered products, but we (CDA) help
    make the base bits (ISL) be part of the standard kit so that
    image-capable applications could be built by everyone!

    
    What are the plans for CDA/ISL on Ultrix (that other OS)...?
    
    And who is the Product Manager?

RE: .9

Glad to hear that ISL will be bundled in DECwindows V2.  It means I can use
it.  At first glance, it seems to be just what I need.  I'm glad to hear this--
I was starting to read the CDA documentation, and doing raw DDIF is a bit
daunting when all you have is a raster of pixels you want to write out.

--PSW

    
    CDA is daunting for *anything* except simple text.
    

>    CDA is daunting for *anything* except simple text.
    

And reading bitmaps in Ddif format..thats nice 'n' simple

    RE: .10
    
    CDA has been available on Ultrix since V3.0.  Product Managers are Don
    Hedman and Eirikur Hallgrimsson.
    
    ISL currently runs on Ultrix, but I don't know if they've released that
    version yet.  Barbara Liberty is one of the Product Managers.

    RE: .12 (CDA is daunting for *anything* except simple text.)
    
    Actually, I'd say that anyone who did "simple" text was over 75% of the
    way to doing almost anything with CDA!  Yes, there is a learning curve
    and yes, the toolkit is quite daunting.  But, the potential results
    (full multi-font text integrated with graphics and images) are also
    quite daunting to whoever you are trying to impress/please/etc.
    
    One of the V2 work items for the CDA toolkit is a set of "higher level"
    interfaces to make doing simple things simpler.  We do try harder.

    
    Hmmm.  I have 3 people working on a converter and they're finding that
    even when we do find ways to get CDA to let us write things, that it's
    pot-luck in finding applications that can read the DDIF input or even
    getting two applications that read DDIF input to do the same thing with
    it (refrain:  I say guttenburg, you say BMU - let's call the whole thing
    off...)!
    
    DDIF is probably great for text applications that import simple
    graphics and scanned images, but it's not a great graphics metafile
    format...  I hope somebody is figuring out a standard graphics format
    for X11 generated graphics...
    
    

    
    re .14
    
    Ah,  good. 
    
    I find that yes, text works fine (on Ultrix) but polylines
    seem to be ignored. 
    
    Is this a bug or do I have an out-of-date libddif.a?

	One major difficulty in programming DECwindows and getting hardcopy 
	output is that there are two different sets of semantics for drawing
	the objects.  What VAX PCA and a few other products are doing is 
	using GObE to handle both windowing and DDIF output, (almost like 
	using display postscript).  Thus, the logical layering of calls is...

		     Application
			  |
                          V
		  	GObE
			  |
                         / \                    
             Xlibrary <-+   +-> DDIF toolkit

	DEC needs to focus its attention of this problem.  With common
	character cell, we don't care to what type of device that we are writing.
	That is why we have dispatch tables and device drivers, back 
	to programming in the '60s. 

	Thank you. 


						Steve Simmons

    RE: .16
    
    I'd say we (CDA) are doing quite well given that our FCS was in
    December -- last's a total of 6 months ago.  [I remember UIS at 6
    months of age!]
    
    At an ISV conference earlier this year quite a number of ISVs involved
    in graphics thought DDIF was a very good graphics file format.  It does
    not match X11 graphics in some sort of one-to-one mapping, but doing so
    wasn't (and, I believe shouldn't be) a goal.  The CGM->DDIF converter
    converts extremely complex, full color graphics generated by
    CompuGraphics to DDIF.  I find it hard to believe that the UIS->DDIF
    converter is an order of magnitude more complex.  See another note for
    GObE which provides an abstraction that will drive both X11 and DDIF.
    
    If you are having problems with the CDA base components then please
    report them as bugs in the DDIF::CDA_BUGS conference.  If with other
    applications then in report using their bug reporting mechanism.

    RE: .17
    
    When you say "works fine" or "ignored" you haven't stated by what.  By
    our CDA viewer?  The DDIF->PS converter?  By DECwrite?  By your own
    application?

                
    The application is a demo program written by someone in CDAland.
    
    It constructs the structures for text and polylines using CDA 
    calls. It writes these structures to a DDIF file. However, when
    I view this file with dxvdoc there is only text, no polylines. 
    
    The DDIF file appears not to contain any info for the lines...
                                           
    Running strings on the DDIF file yields the following:
    
       DDIF$
       Test V1.0
       E/USA/
       Mandarin
       C+This is the first line of the example text.I
       This is the second line of the example text, and should be separated from the fi
       rst line by a single space.J
       The third line of the example text will begin on a new line.J
       The fourth line of the example text will be separated from the previous lines by
       a blank line.J
       The following is a polyline within a frame:J
       0
       FRAME
       pline
       FRAME
       The following is a Bezier curve, using the same path as the polyline, within a f
       rame:J
       bline
       FRAME
       The following is a basketweave-filled arc within a frame:J
       filled_arc
       FRAME
       This ends the examples.A
        
    I compiled it with vcc (pcc can't handle it). 
    
    The program lives at 
        tiglth::/usr/users/holt/src/x11/clipboard/appendixb_orig.c
    
    I'd appreciate any attention you can give this.
    
    -bob