Re: Acrobat, HTML and Publishing economics

Re: Acrobat and HTML

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. 

Received on Friday, 16 September 1994 16:08:07 UTC