Conference vaxuum::online_bookbuilding

    Actually, Chris, this has been suggested, although maybe not in this
    notes conference. I agree, this would be a *great* feature. But not
    easy to implement currently because VAX DOCUMENT is not an integrated
    text and graphics authoring tool (the graphics are created separately
    and only integrated upon output). In addition, RAGS will not always be
    only the graphics tool for online docs (and isn't now if you can convert
    your graphics-from-whatever-source to FSE bitmaps). So the current
    state of authoring tools (*any* authoring tools) would have to be
    enhanced to support graphics->links -- sounds like a great use for
    MEMEX to me...
    
    It's on the wishlist but not for the near term...
    
    I wonder if you could use the <icon> tags? (It might be tricky to
    make this work for both online and hardcopy.) If your flowchart
    is not very wide you might be able to include the graphic with
    the <icon_file> tag and put the cross ref to a section of text
    in the <icon_text> tag.
    
    Thanks,
    
    Mary

    Mary,
    
    Thanks for the suggestion. This may well be a possibility. The sort of
    flowchart we are thinking of does not extend very much in the
    horizontal plane, so we may have enough space to play with to make this
    a viable solution.
    
    Chris

    What does the <icon> tag do?  I too have a need to have hotspots
    included with a figure.
    
    John
    

    The <icon> tags are documented in the VAX Document User Manual, Vol 1:
    they allow including a graphic image next to text. They work exactly
    the same way for online as for hardcopy and have nothing to do with
    hotspots. I suggested their use in .1 as a way to get text labels
    (possibly with <reference>s) next to a graphic. It seemed like it
    might work for the particular case in .0, but for the most part 
    would be unworkable and even in the case of .0 might require too
    many contortions to make it worthwhile. There are no graphics tools
    that allow hotspots in the graphics at this time.
    
    Mary

I would like to endorse hotspots in figures, especially figures containing
schematics; you can extend this idea in all sorts of directions, for instance a 
pictorial table of contents. I appreciate that there are technical difficulties
and I have no wish to add to them, but I do have an idea that has some bearing
on the subject.

As Mary says, DOCUMENT provides very little control over graphics (even over the
alignment of graphics in some cases) and accepts graphics inputs from a variety
of sources; from MacPaint to Rags. However, the graphics file types are standard
and, for the majority of cases, there are three types:

SIXEL for quality hardcopy
PS for Postscript hardcopy
FSE for Bookreader

Perhaps the introduction of hotspots into these files could reduce the technical
difficulties. Maybe that sounds a bit far-fetched. But consider a utility like
UTOX which allows for conversions of several file-types. Extending this utility
to allow for the introduction of hotspot markers that could be made meaningful
to DOCUMENT is feasible; UTOX already has a menu with two items that relate
specifically to SDML output. Of course there would be symbolic names to 
<REFERENCE> and these could be recorded as <COMMENT> next to the tags produced 
by SDML output. 

Of course this means that UTOX would have to introduce something into the SIXEL,
PS and/or FSE file. Alternatively, convert to DDIF, introduce the hotspots, and
then convert to a format suitable for inclusion in a DOCUMENT file.

Now that I put this idea into writing I am wondering if it reduces the technical
difficulties or not.. any thoughts...

Finally, I would like to suggest the following tags for some wish list:

<STARTPS>
   .
   .
Postscript language statements
   .
   .
<ENDPS>

These tags would simply turn off the formatting for PS destinations so that 
the Postscript code could be included (unchanged) in the .PS file.

John

    Thanks, John. I put your note in the DOCUMENT notes conf as well to
    see if some discussion might be generated there (esp. regarding the
    Postscript tags).
    
    Mary

I agree that hotspots in figures is something that could be widely of use.
The major difficulty of creating and defining these hotspots is NOT that
current graphics applications do not contain these capabilities.  UTOX and
RAGS are closely enough tied to VAX DOCUMENT that they could be modified to
perform this function.  The problem lies in the fact that the graphics file
formats themselves contain no mechanism for the specification and/or storage
of hotspots.

"Hotspots" are interactive links between portions of a document.  PostScript
and sixel are non-interactive (hardcopy) formats so the notion of hotspots
doesn't even make sense within that realm.  The FSE format used for the
bookreader is defined as a simple monochrome image format - there is no way
of representing a hotspot within the FSE format, just as there is no way to
store a color image in the FSE format.  PostScript, Sixel, and FSE formats
are defined by other people.  We are not at liberty to re-define these
formats so there is no way to define hotspots in graphics using these
formats.

The RAGS metaformat, on the other hand, is defined by us.  It is
"conceivably" possible extend the RAGS file format to permit the
representation of hotspots.  The problem is that the "long term" goals of
the company are to move toward more standardized formats which currently
means DDIF.  From the standpoint of a developer, I don't know if I would
want to invest the great deal of work necessary to develop a capability that
relies a format that we may be trying to phase out in the future.
Engineering resources are limited and I as application developer don't have
the time to do all the things I want to do.  The best I can do is to try to
get the most useful results I can in the least amount of time.  From the
standpoint of an application user, I don't know if it would be a good thing
to give me a certain capability and then at a later time, to possibly take
that capability away from me.

It seems logical to me that the best way to provide this capability would be
to use DDIF as the format of choice.  I'm not sure that DDIF has any
mechanism for defining hotspots, but even if it doesn't, it is recognized
that DDIF needs more work to be done in that area and that its still
evolving in general.  IMHO (In my honest opinion), it would seem best to
wait until the roads of development begin to converge before taking on a
subject like this.  In this way, images and graphics object figures could
both make use of hotspots.  But the current reality is that DDIF is not at
the point where we can do with it want we need, and the graphics-generating
applications aren't as fully tied into DDIF as they would need to be.


*** My disclaimer ***
It's important for me to say that some of the futures I mention here are
only my speculations and idealistic views of the future.  It really does not
constitute any plans or committments for me or anyone else who is
responsible for the involved projects to carry through with what I think
should happen.  Although I may be able to influence what happens, for you to
rely on my speculation as if it were fact would be pretty foolish.

-Mike

>Finally, I would like to suggest the following tags for some wish list:
>
><STARTPS>
>   .
>Postscript language statements
>   .
><ENDPS>
>
>These tags would simply turn off the formatting for PS destinations so that 
>the Postscript code could be included (unchanged) in the .PS file.


This is exactly what <FIGURE> <ENDFIGURE> already do.  Anything you can do
with your proposed tags you can already do with these (although you might
not like the automatic figure headers you get).

-Mike

Well shut my mouth...

Thanks for adding my note to the DOCUMENT conference Mary and thanks to Mike for
applying some technical knowhow to my half-baked suggestions.

Turning first to the graphics hotspots I agree that DDIF would be the logical
target for introducing hotspot markers into graphics. In fact, I meant to 
mention that in the original reply. As I am not a developer I also accept what
Mike says about DDIF. However, leaving development resources aside, I do wonder
if there is time to wait for convergence when HyperMedia (not to mention
Multimedia) is already emerging elsewhere. 

As for the <STARTPS> <ENDPS> tags. It is great to know that they already exist
under different names. All the same, I feel it would be nice to have these tags
without being forced to unwanted figure headings. The main idea is to have 
complete freedom over what part of the printed page you use, since postscript
language allows for precise placement of both images and text.

John 

    I think it would be possible to achieve hotspots in graphics with some
    work on the SDML layer, rather than the graphics layer, for those
    graphics tools that also generate companion SDML files.
    
    Conceivably, such a tool could supplement the figure tags it now
    generates with a hotspot tag that describes a specific rectangle within
    the image space - something that would have this effect:
    
    	"Make the region whose bounding box is (LLx, LLy, URx, URy)
    	a hotspot that refers to symbol (symbolname)."
    
    Some tools would require the user to provide explicit offsets, while 
    others could allow the user to define a region visually.  As for the 
    symbolname that would be required, the tools could ask the user to 
    provide it or they could write out the tag with a fixed name and require 
    the user to edit it once the correct symbolname is known.
    
    I'm not saying that such a tag exists, or that the work is trivial -
    but it does seem like a possibility much more within our control than
    changing the definition of standard graphics interchange languages.
    
    Mark

    RE <<< Note 232.9 by NRMACW::CARPENTER >>>

>As for the <STARTPS> <ENDPS> tags. It is great to know that they already exist
>under different names. All the same, I feel it would be nice to have these tags
>without being forced to unwanted figure headings. 

    If you don't give an argument to the <FIGURE> tag, you don't get a
    heading (or a table of contents entry).  This is generally known as
    an informal figure.
							-- Nina

I like Mark's suggestion in .10.  I don't know how much work it would be in
the tag translator, but the Bookreader and Bookwriter would not need any
change.  Presumably, the tag translator would pass a special to the device
converter giving (x, y, width, height, and target symbol) for the hotpspot
and the DVC would make the same call to the Bookwriter as it does for
hotspots in text.  (This could even be generalized to non-rectangular 
hotspots once I get a Bookreader bug fixed...).  This would give us a 
short term solution at least--and it would allow you to superimpose hotspots
on top of ANY graphics format supported by the Bookreader.

The problem with this solution is that it is very manual and would probably
require a lot of tweaking to get the hotspot positioned correctly on the 
graphic.  Then if you change the graphic, you must remember to tweak it
again.

joe

Yes, good idea Mark.  It's also good to know that the book reader and writer
should not need modifications.

A few more questions...  Would the bookreader/writer have trouble defining
hotspots in popup figures? How about inline figures? Margin Icons? It looks
like there may be a short term solution but how complete is it?

>The problem with this solution is that it is very manual and would probably
>require a lot of tweaking to get the hotspot positioned correctly on the 
>graphic.  Then if you change the graphic, you must remember to tweak it
>again.

Yes, this could be a problem.  But if a hotspot function was put into RAGS
and/or UTOX, then it wouldn't be such a trial and error situation to
define the placement of hotspots in graphics.

-Mike

If Mark's idea is technically feasible, as it seems to be, then I like it with 
one reservation. The writer must be able to acccurately position the hotspot 
before including the figure in the DOCUMENT file. If I understand what Mike said,
this can be done with UTOX or RAGS. 

If it goes to a vote, I would vote for UTOX, since RAGS is only one of the 
graphics tools available, whereas UTOX will tend to be used consistently. On
the subject of UTOX, it would be very nice if it were endowed with some minimal
graphics capacity itself; such as the ability to introduce text into a figure.

John

    I have prototyped hotspotted graphics using DECwrite V1.1. See the
    ON_HELP and BOOKREADER notesfiles. Admittedly it was done using a
    workaround. 
    
    I worked with a DECwrite developer to get cleaned up code to do the
    same thing more cleanly for DECwrite V2.0. The functionality will be
    available in the DECwrite V2.0 IFT within a few weeks. Look for notes
    announcing the capability and, if I have time, a new prototype to demo
    it.
    
    Jack