Re: CGM deployment?

Dan Connolly said:
 
> In message <199508011118.VAA23535@hades.erin.gov.au>, David Crossley writes:
> >The recent brief discussion on this list about the possibility of inline 
> >Computer Graphics Metafile (CGM) is of great interest to us. We in the 
> >geographic information community see this as a major step towards enabling 
> >online delivery of spatially relevant information.
 
> The is not the first time I've heard this. OK. Perhaps it's
> time to do something about it. I've updated the w3.org
> page on graphics formats:
> 
> http://www.w3.org/hypertext/WWW/Graphics/Overview.html
> 
> to mention some issues I've seen discussed here: format negociation
> and CGM, for example.

I had a look at the revised page and it is a definite improvement.  I
particularly like the unambiguous statement "The web standards do not
specify a graphics format you must use."

A few of points of detail, if I may, since the subject of this page has 
been brought up. 

1) You have:

  Configure your server to label the CGM graphic with the approprate 
  internet media type (aka MIME type):

     Content-Type: image/cgm

This should be image/x-cgm until the current registration process is complete.

The original application (on my advice, I hasten to add) was for
application/cgm by analogy with PostScript (application/postscript),
which is also a scalable or non-rasterised format.  However I have since
learned that 'application' is something of a ragbag for proprietary
formats; also that the IETF uses the term image to mean 2D picture,
whether rasterised or not.

This is of course contrary to generally accepted computer graphics
practice, which reserves the term image for a rasterised graphic and
uses the term picture for a 2D scalable graphic [1] 

However, the IETF does not have a separate primary type for scalable
2D graphics.  Hence, the current registration request is for image/cgm.

2) You have: 

  Make a thumbnail of your image in GIF format (use a screen capture, 
  if necessary) 
  
Fine, but given what is correctly said about GIF elsewhere on the page I
would omit the phrase "in GIF format".  One could substitute "in JPEG
format" but a graphic with sharp lines is unlikely to translate well to
JPEG.  PNG would be suitable but is not yet widely enough implemented
inline (the current list supporting inline PNG is I believe Amiga Mosaic,
Mosaic for X 2.7b1, emacs-w3 and Chimera). So, I suggest leaving the 
format unspecified.

3) You have:

  After GIF, there will probably bee GIF24, see our Overview of PNG. 
  
CompuServe have abandoned the idea of a GIF24 'based on' PNG, and now
support PNG (or as their PR department recently claimed, they invented
PNG ;-)

4) You have:

  The particular format usually used for JPEG-compressed images on the 
  Web is JFIF. 

Correct.  I would suggest adding "This is distinct from a JPEG
compressed PICT file, which is often referred to as 'a JPEG file' on the
Macintosh platform".

5) Under PNG, could you add:

  MIME content type 
        image/x-png 
     
PNG is currently undergoing registration as an Internet Media type, so x-png 
should be used for now.

5) You have:

    "Tagged Interchange File Format" suffers from its expensibility:
    there are extensions to TIFF suhc that it is not easy to know what
    application will accept what TIFF file.  TIFF files are
    uncompressed, and if large must be compressed for transmission.  The
    version adopted by NeXTStep/OpenStep allows a transparency ("alpha")
    channel which allows semitransparent effects which are powerful for
    icons.

a) I would like to see the distinction drawn between baseline TIFF and 
   extended TIFF, and a pointer to the specification [2]
   
b) TIFF files can have internal compression, but of the available types
   packbits is not very useful, LZW has the same problems as with GIF,
   and JPEG compression is currently undergoing, erm, re-specification
   [3] - I hope that is the correct euphemism.

c) Alpha channels are not specific to NeXTStep, they are part of the
   extended TIFF specification. Also, they are not specific to TIFF, 
   PNG has them too.

Well, enough of the W3C Graphics page, back to Dan's suggestions re CGM:

> I'd like to see the following:
> 
> 1. Some data on the web (i.e. available via HTTP, ftp, or gopher) in
> CGM format.

Yes. See for example the University of Manchester logo [4]

> 2. Some free CGM viewers, with documentation on how to use them
> as MIME viewers.

Done, see [5].  I need to add pointers to GDOC.  Note that GDOC only
appears to support an earlier version of CGM (the 1987 version [6] ) so
it lacks a lot of features such as font naming, control and aliasing;
external symbol libraries; compound clipping paths; colour calibration;
line termination, joining and mitring control; conformance criteria (etc).

> 3. Software for converting CGM to GIF/JPEG, as well
> as to Postscript, configured as a translator inside
> a web server.

Taking that one step at a time:  conversion to PostScript can be done
with RALCGM which can operate as a batch converter in addition to being
an X application.  Conversion to raster image formats is best done via
Postscript and a PostScript rasteriser such as Ghostscript.  As for
stripping the conversion code out and having some server (presumably
CERN or Apache, ie the ones that support content negotiation) do on the
fly conversion is interesting.  I do not have the resources currently.
I will ask around and see what can be done on that one.


> 4. A discussion of CGM authoring tools (and/or
> conversion tools)
> 
> 4. Modular web browsers that can incorporate software like
> (2) as an OpenDoc part, OLE control, Fresco object, etc.
> 
> 5. libraries for processing CGM, so that even monolithic
> browsers can use CGM inline.

All I can say about those three is that I would like to see them too.  

I have already suggested this to the CGM Rapporteur group of ISO/IEC
JTC1 SC24 (ha!  ie the CGM committe in ISO, more or less).  Here is what
I said:

    What are the plans for PD code?  To achieve the best market
    acceptance of CGM, what is needed (IMHO) is:

    * a _fully_PD_ (ie, including commercial use) platform independent,
      C++ compatible, C-coded CGM library, after the fashion of the
      TIFF, JPEG and PNG libraries

    * freely distributable Mac, MS-Windows and X-Windows viewers that
      use this library.  These should view CGMs, allow easy (rubberband
      box) zooming and panning, and provide a means to load and save
      files.

    This way, there are immediate viewers for external CGM files to get
    the ball rolling.  The benefit of a truly Public Domain CGM library
    is that browser vendors can use it to do inline CGM, and other
    implementors can use it to make value-added CGM viewers or to add
    CGM capability to existing image viewers.

    Inline CGM, in HTML 3.0 FIGures, would be a good enabling technology
    for large sections of the scientific and engineering Web user
    community.  At present there does not seem to be a clear leader in
    the various competing technologies for helper application
    integration (W3A etc) so a library is currently the best way to
    allow browser developers to add a new inline graphics type.
    Certainly this is what the NCSA and Netscape developer teams told
    the PNG group.


> We don't have much W3C staff time to spend on this, but I'm willing to
> do some coordination. But actually, Chris Lilley seems more
> qualified. I nominate him as "editor" of a "CGM and the web" page to
> collect this info.

Hmm. Did I walk into that one?
 
> So: who's got software? Who's got data? Who wants to do beta
> testing? Who wants to write documentation?


> Attached is the best peice of info I've seen about CGM references.
> http://pscinfo.psc.edu/general/software/packages/cgm/cgm.html

Note that the reference to the CGM standard is considerably out of date.
It references ISO DIS 8632 (1987).  DIS means Draft International
Standard.  It became an International Standard., and was adopted in toto
by national standards bodies such as BSI (UK), ANSI (USA), DIN (Germany).

After that was Amendment 1 (in 1990) [7].  Then a further amendment
was specified.  Because there were substantial changes, the standard was
completely republished (much easer to read than an amendment, which is
like reading a diff!)  in 1992 [8].  Since then there has been at least
one amendment, for standard profiles; another two were being discussed
last year but I do not know their current status.


> From: James D Mason <MASONJD@oax.a1.ornl.gov>
> If you want the real word on CGM, try the leading experts from ANSI X3H3:
> 
> Mr. Lofton Henderson
> Henderson Software
> P.O. Box 4036
> Boulder, CO  80306 U.S.A.
> Telephone: +1 303 442 6570 
> Facsimile: +1 303 440 0640
> 
> Mr. Steve Carson
> GCS Associates
> 13254 Jefferson Avenue
> Hawthorne, CA  90250 U.S.A.
> Telephone: +1 310 675-2093
> Facsimile: +1 310 675-2159
> Internet: carson@siggraph.org

Yes, indeed.  ANSI X3H3 represent the USA on ISO/IEC JTC1 SC24/WG6, the
working group that deal with CGM.  (Or dealt, they may have reorganised
the WG numbers since then, I hazily recollect).  Other people on that
committee include (from the UK)

Dr Anne Mumford <a.m.mumford@lut.ac.uk>
Alan Francis <a.h.francis@open.ac.uk>

The latter recently submitted CGM for registration as an Internet Media
type.

[1] Computer Graphics Reference Model, ISO/IEC 11072: 1992
[2] <URL:ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.Z>
[3] <URL:ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt.gz>
[4] <URL:http://info.mcc.ac.uk/CGU/CGM/manchester.cgm>
[5] <URL:http://www.agocg.ac.uk:8080/agocg/CGM-MIME.html>
[6] Metafile for the storage and transfer of picture description 
    information, ISO 8632-1:1987
[7] ISO 8632:1987/Amd.1:1990
[8] Metafile for the storage and transfer of picture description 
    information, ISO 8632-1:1992

-- 
Chris Lilley, Technical Author
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
|     URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html       | 
+-------------------------------------------------------------------+

Received on Tuesday, 1 August 1995 14:20:33 UTC