Message-Id: <9409161008.AA59497@4mesa.com> Date: Fri, 16 Sep 1994 10:08:59 +0000 From: "Richard A. Wiklund Jr" <RAW@4MESA.COM> To: firstname.lastname@example.org Subject: 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 email@example.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.