On second thought, yes, that was a mistake - I had said that simply in the
frame of "Quark doesn't have hyperlinking now...", to defer arguments against
it and in favor of a complex HTML++ scheme. I was also thinking that the
interface questions (i.e., highlighting Quark objects which are hyperlinks,
then making them a different color once they've been selected) didn't have
to be addressed now.
> Just overlay shaped
> regions on top of the image. Or, create an associated hyperlink file that
> the rendering agent for Quark Xpress would use like this:
>
> The Web browser might ask the question to the rendering agent whenever a
> user poked the image with a mouse. Other commands like "search this" and
> "print this" also need to be defined so that external data is not second
> class.
I'd prefer to keep it in the Web browser, for efficiency and
simplicity reasons. I had heard there was talk about putting the
ISMAP functionality directly into HTML - instead of calling an
imagemap script on the server side, the map of polygon spaces to URL's
is delivered within the HTML file itself. This would be a Very Good
Thing, people - this is also how we could overlay hypertext
capabilities on objects like Quark files and such (polygons being
defined as either pixels for bitmapped inlined stuff or in percentage
points for non-bitmapped objects).
> > ... because everyone out there has a free plug-in
> > provided by Quark that does the rendering into every Web browser (and if
> > people don't have it they can get it from our site anyways), they'd do
> > backflips.
>
> Could be one provided by Quark. Could be a competing implementation. They
> would all work in everybody's browser. The resulting applet market would
> really take off.
It would probably have to come from the company that owns the
patent/copyright on the language - try doing that for PDF and see if
Adobe doesn't give you a phone call... :)
Brian