PDF (was publication of IASS papers on CDROM)

Gunthard Mueller gm at ANTHOSIMPRINT.COM
Wed Dec 20 01:33:04 UTC 2000


Hello, Kengo,
I like your way of looking at things...

Just some little tech notes again if you don't mind.
UNIX normally uses ISO-9660 as CD-ROM format. Without any additions such
as Joliet, Romeo, etc.
If you insert a non-ISO-9660 CD-ROM into a UNIX machine running, say,
Solaris or Linux, then it will try to mount it as ISO-9660, and the result
will be various shades of funny. For example, if you insert a "Windows
CD-ROM" (that normally means ISO-9660 with Microsoft's partly undocumented
(!) Joliet extension for long paths) into a Solaris or Linux machine, it
will present the files to you with ISO-9660 indexing (which it takes from
the 8.3 short-file-name list that Joliet provides as a fallback).
Something similar happens when you insert a Macintosh-format CD (and some
Solaris machines won't unmount these any more...). That's just courtesy of
the designers of these non-ISO-9660 formats which tried to give you a
smooth escape route in non-native environments.
One thing about "hybrid CDs" (Mac+Windows, for example): dangerous! Good
for general publishing sometimes, but no good for archiving, because not
normed, with several variants around, and never completely supported by
all hardware and driver makers. In addition, reproducing hybrid CDs is
quite complicated and requires special, very uncommon software.

Of course you are absolutely right -- the CD-ROM will not be supported
eternally by the hardware folks making consumer electronics. That's why I
think one important task of digital libraries will be to retain the
migration CAPABILITY for the public. Some people think it will be
necessary to migrate ALL data carriers from the respective old-norm media
to the respective new-norm media whenever a norm reaches the end of its
lifespan in general electronics. I am not sure if that is realistic. I may
underestimate future digital capabilities, but I think the infrastructure
is not going to be there for that for a long time.
What I personally envisage as feasible would be this kind of scenario.
Imagine a normed data carrier type x (currently the CD-ROM) going
completely out of popular use in y years. The academic public now finds
itself unable to use type x any longer. But most digital archive holdings
are on type x media. In this situation I think digital archives should be
able not to migrate their entire holdings from type x to the next normed
data carrier (let's call it type z) in one go, but to "migrate on demand",
i.e. on request, when a particular set of data is requested by a user.
This capability would be fairly easy to maintain with relatively little
equipment over many generations. The digital library should be able to
monitor the process and to ensure that data that are rarely requested do
not fall out of the migration framework eventually. In other words: if
there are data that are never migrated because nobody ever requests them,
then the digital librarian should step in and migrate them. Quality
management routines for such a process look feasible to me even for
relatively low-budget libraries. The job could be centralised or partly
centralised.
Personally I think that if current developments continue, the future might
see normed data carriers that will be so long-lasting and so huge that it
will be feasible to migrate larger and larger proportions of entire
digital libraries onto fewer and fewer media. When one looks back a little
over the last century, it's other things that worry me. In the past
century, Germany alone has lost roughly 30% of its library holdings to
"external factors" (wars...). Would the bits and bytes have escaped the
bombs better? Nothing  destroys the human heritage better than man...
Unfortunately, destroying digital media seems a lot easier than destroying
parchment and paper. It seems to me that digitization should go hand in
hand with "pre-emptive publishing". Proliferation is also a form of
conservation.

Gunthard

gm at e-ternals.com


Kengo Harimoto wrote:

> Hello List,
>
> Thanks for some advice to my previous post on and off the list, I
> could solve some problems.
>
> In order to view and print pdf files produced through dvi -> ps -> pdf
> properly, I needed acrobat reader 4.0.  Apparently, the rendering of
> bitmap fonts in the newer reader is much better.  It renders bitmap
> fonts in the document properly with anti-aliasing.
>
> However, I suspect that it still has a limitation of originally
> intended printer resolution in the dvi file.  If one happens to have a
> 2000dpi printer and the document was originally created with 600dpi
> bitmaps, the quality of the output won't be as nice as using outline
> fonts, I suppose.
>
> In addition, the searching the pdf file produced through TeX/LaTeX
> still does not work.
>
> If my points were not clear in my broken English, they were that:
>
> 1) I agree that pdf is so far the best solution to distribute a
> document electronically.
>
> 2) but the pdf files, produced from a document that are originally
> written in TeX/LaTeX, are not the same as the pdf files produced from
> Adobe's solution.
>
> 3) and TeX/LaTeX happen to be rather popular among indologists.
>
> It was not difficult for me to find and install the newer versions of
> softwares---in this case, Acrobat Reader 4.0.5 and Ghostscript 6.0.1.
> (Thanks again, for advice.)  But there are tons of people who are
> using antiquated software and have trouble finding and installing
> newer versions.  [I am also sick and tired of following the most
> recent development.]  The speed of advancement in the area of
> computer/digital/IT industry is astonishing, but it seems to me that
> the area is not still mature, hence rapid change.  Things will change
> in the near future, and it is highly likely that there will be a
> better solution to publish indological publications.  I thought CD-ROM
> was cool 8 or 9 years ago.  But it is already losing the luster behind
> DVD-ROM/RAM or the web.  Publishing on the web or CD-ROM may be
> fashionable these days, but I think anything fashionable will be out
> of fashion soon or later.
>
> - Regarding the storage device, I thought we were discussing about the
> medium to distribute a document.  I have no doubt that the original
> data of a publication published electronically will be stored in one
> shape or another electronically.  But if the publication was published
> in the shape of physical media, such as CD-ROM, I'd still think that
> the readability on the desktop will significantly reduce in 10 or so
> years.  DVD-ROM/RAM drives may still support the CD-ROM, but what
> about the next generation?  33 rpm vinyl record format is a norm but
> very few people these days have record players.
>
> Gunthard Mueller <gm at ANTHOSIMPRINT.COM> wrote:
>
> > Further, MacOS HFS has ALREADY been superseded by TWO other MacOS
> > file systems, and the issue has nothing to do with the ISO-9660
> > issue. MacOS HFS could easily be superseded because it is not an ISO
> > norm and not accepted by other platforms. So superseding it was an
> > Apple-internal decision and therefore bound to happen for ephemeral
> > reasons.  Things are different when norming has taken place.
> > ISO-9660 is itself a file system and has nothing to do with a single
> > company or lobby. Is is the normed file system for CD-ROMs. As such
> > it will be readable in future.
>
> Although I have to admit that I am shaky on this ground, I am aware
> that Apple now has two newer file systems.  (That's why I mentioned
> the possibility of future non-support of HFS.)  But my understanding
> of the ISO9660 and HFS was that HFS is _on_ ISO9660 on CD-ROM for
> MacOS.  My point was that there would be a danger of a cd-rom unable
> to be read properly on future systems, if it employed a OS specific
> file system on a CD-ROM, which is in ISO9660 format to be a cd-rom.
> For example, a mac cd-rom is mounted on my linux system as iso9660
> file system.  But the cd-rom looks like regular HFS volume from MacOS.
> Don't many cd-roms have both msdos and HFS volumes over ISO9660
> (hybrid cd-rom)?  If a book is published in such a hybrid format, when
> Apple disappears or Apple decides to abandon supporting ancient HFS
> format, the purchasers of the cd-rom may not be able to read the
> contents in the future.  [Perhaps this does not happen.  An CD-ROM
> witl an HFS volume will be mounted in the same manner the MacOS mounts
> UNIX cd-roms as ISO9660.]
>
> [So, if some one goes for electronic publication, better solution for
> electronic publications may be, cough, web-based, like UMI.
> User/reader/purchaser do not have to worry about longevity of the
> media [s]he purchased.]
>
> - Regarding TeX/LaTeX and SGML/XML, unicode, etc.  TeX/LaTeX happens
> to be the easiest and cheapest solution for many indologists. (And
> probably most aesthetically pleasing output for most people, IMHO.)
> It happens that XML applications for this field of study is not very
> accessible for most people yet, and XML and unicode appear to be still
> moving targets for me.  TeX/LaTeX may be dead already, and may belong
> to gurus, but indologists are known to like dead languages :-) And
> many indologists would like to be a guru, too :-)
>
> So, we still have a time-honored means to publish, i.e., on the paper,
> which happens to be readable by most people.  Perhaps it will be
> readable in near future, too.  I know some people who still print out
> their e-mails.  Although I think this practice and publication of
> newspapers on the paper is a total waste of resources, there still are
> people who like reading them in the bathroom or on the train.
> Similarly, although I would not mind publishing electronically and
> reading on screen, removing the option of publishing on the paper does
> not seem a good idea yet.
>
> --
> kengo





More information about the INDOLOGY mailing list