Let me suggest a vision of the future: The way information is gathered,
standardized and disseminated by traditional publishers will be based on
content encoded data -- not the printed page.
Publishers will look to add as much value to information as possible, with as
little cost as possible. If a publisher does not have to typeset a page to
market (sell) the information, then they won't.
An Acrobat PDF is a derivative of a typeset page -- which may or may not be
part of the future of at least scientific, technical and medical publishing.
I can see developing a virtual world within an CD-ROM or local Acrobat
document that has hyperlinks out to "up-to-date" information maintained on
the Web. This would be perfect for catalogs, and technical documentation, but
I'm not sure Acrobat has a place in HTML.
On the other hand, I may be way off base, and we are speaking of strictly
graphics (eps, tiff, etc. to pdf), and not "pages", then I have no opinion.
Given this, I feel content encoding is limiting our ability to effectively
deal with special characters, tables and math. That's the key issue, and we
need to come to closure on the ability to embed typesetting-like style
information within HTML.
Rich Wiklund
raw@4mesa.com
Scientific, Technical Medical Publishing Services
Richard Koman said,
> >Adopting Acrobat as a standard for embedded graphics in HTML documents
> >may be a reasonable way to proceed. I know hardly anything about
> >Acrobat. The relevant question seems to be: How much work is it to
> >convert a program that now produces Postscript to one that produces
> >Acrobat?
>
> Acrobat files are a variation of PostScript; it should be a simple
> matter, although Adobe might be trying to control it so only their apps
> can write Acrobat files.