> The recent mail about WWW and the search for a graphical file format
> illustrates a certain lack of awareness of the status and capabilities
> of CGM. So far, all of the requirements which have been articulated
> are directly met either by CGM:1992 itself, or one of the industry
> profiles
Certainly there is a lack of awareness about CGM, particularly the ammendments
which were rolled in to make the newer 1992 edition of the standard. Perhaps
this is because commonly available software still only generates and understands
the earlier 1987 version of the standard. Do a search for CGMs on http and ftp
sites - most are 1987 CGM generated by Corel Draw.
> Chris Lilley wrote:
>>But yes, CGM does not have hooks for URLs and so on, nor would it be simple or
>>timely to add them. On the other hand, used in an HTML 3 FIG element CGM could
>>have hotspots added fairly easily.
> This is wrong.
I hope you mean, the first sentence is wrong (which it is; thanks for the
information about Amd. 2 which I was unaware of). The second one is, of course,
correct.
> Amd.2 is a simple
> addition to the standard to define Application Structures. The purpose of
> these (or one purpose) is exactly to enable structuring and hot links.
OK so the ammendment, soon to form part of the standard, says how applications
define application structures; it would be possible (but the standard does not
say how)to use these to implement Web hotlinks.
Problems with this, unless the precise method of doing so is defined - perhaps
in an application profile - how do I know how a particular CGM encodes this
particular information?
Particularly since URLs are not an ISO standard, so a method for encoding Web
links into a CGM cannot form part of an ISO standard. Perhaps as a non-normative
annex. Thus, Sods law dictates that different industry groupings will pick at
least two ways of doing this.
The problem of incompatible implementations, which was a significant one for
CGM in the early years and which seems to have been largely dealt with by
application profiles, looks set to rear it's head again.
One cannot assume that all CGMs met with on the net belong to a particular
application profile. So the browser, or a viewer working in concert with the
browser, has to understand all CGMs and the way in which each group of users has
overlaid Web link information onto the Application Structures, so that hotlinks
can be supported. This sounds like a recipie for browser bloat, to me.
Furthermore, the hotlinks would then be intimately associated with the CGM, so
if you want to use the same CGM in different situations you need to make copies
of the CGM and edit the Application Structures to suit.
It is not at all obvious that this is the way to proceed.
HTML 3 FIG elements define hotlinks and active regions in a standardised way for
all inline figures, to allow
- client side processing
- user feedback such as cursor changes or URLs shown as the user
moves over an active area
- automatic support for non-imaging clients (text prowsers, browsers for
the print impaired)
Provided the units can be ems as well as pixels, as is done with other parts of
the HTML 3 sketch DTD, then in conjunction with the width and height attributes
of the FIG element this support could be trivially extended to inline vector
graphics, inline movies, etc doing all this in a consistent way.
This would also allow a form-driven CGI script to generate HTML as required with
different hot areas on the same CGM (which, being in the browser cache, will
greatly speed up responsiveness to the user).
Using the Application Structures to implement hot areas would remove all these
advantages for CGM, while providing none, that I can see, in return.
A different way of working for one content type among many - is this desirable?
> Products are already being built and sold which use these standard CGM
> features!
I would be interested in a list of these, particularly ones which embed URLs (as
opposed to other hyperlinking technologies) and which are either free, or
shareware at, say, less than US$ 25.00
Pointers to freely available code libraries to parse the latest version of CGM
would also be appreciated.
>> A new format is fine if it does a different job, and if it is possible to
>> convert to and from it on multiple platforms. I assume Softsource have
>> addressed this issue, and their CAD programs will not be the only software
>> to read and write the format.
> It is hard to believe that the world needs yet another graphical file
> format.
People said that in 1987 about CGM ;-)
Also this is obfuscation; as Lofton is well aware, putting all "graphics"
formats in one basket is hardly comparing like with like. Placing these as data
capture metafiles on a Computer Graphics Reference Model, we see rather less
than the stated "90" files in the Viewing Environment, where CGM sits. I can
think of EPS, Adobe Illustrator EPS, Coreltrace EPS (think of these as
application profiles using subsets of EPS to allow editing) and DXF. These all
have different characteristics, even within the one environment. DXF provides
features, for example, that EPS does not and vice verca.
So, my original comment still stands: A new format is fine if it does a
different job (if not, it is not fine). Surely Lofton does not argue with this?
Reading the original propsal for moline, it seems that some thought has gone
into the proposal which I assume Lofton read before commenting on it. I would
therefore be interested to hear his specific objections to it, apart from the
fact that it has not settled on CGM. Then again, it has not NOT settled on it
either, as the paper makes clear.
Does anyone have Jodi Moline's email address?
Relevant Links
--------------
<http://www.agocg.ac.uk:8080/CGM-MIME.html>
Using CGM in HTML 2.0 documents
<http://www.ncsa.uiuc.edu/SDG/Proceedings/DDay/moline/moline.html>
The moline paper
If replying to this message, please note the additional CC: in the headers.
-- Chris Lilley