[fptex] new binaries

[Bernd Raichle]

On Thursday, 28 February 2002 14:04:49 +0100,
Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:
 > * Bernd Raichle <raichle@Informatik.Uni-Stuttgart.DE> writes:
 > 
 > > Thus it is better to use ``balbla/filename'' in your TeX document as
 > > usually and integrate a more or less intelligent logic in kpathsea
 > > which uses an existing ZIP file with the name of a directory part if
 > > there is no such directory.  A given filename ``a/b/c/d/e'' will
 > > then result in searches for file `e' in `a/b/c/d.zip', for file
 > > `d/e' in `a/b/c.zip', for file `c/d/e' in `a/b.zip', or file
 > > `b/c/d/e' in `a.zip', if there is no such directory but a zip
 > > archive ...
 > 
 > I like the idea, especially when you think about diskspace problems
 > for the texlive ;-)

I like it, too.  And this idea is old.  emTeX and other TeX
implementations on Atari ST and Amiga are using font archives files
which includes a set of tfm or pk files.  The historical reasons for
them were disk space (the last sector of a file is not completely
used, if you have a lot of small files, the relation between used and
unused sector space is low) and file name lookup in a directory (if a
directory contains a lot of files, the speed to open a file decreases
dramatically on MS-DOS, TOS etc.).


 >                     And it is really simple to implement ! There might
 > be few things to pay attention to like the new mktexlsr ;-)

Yes, the filename database will be a problem.  To speedup the file
name search, `mktexlsr' has to include the contents of each ZIP file
in an appropriate way.  Otherwise the kpathsearch lib has to search
for a file in each possible ZIP file.

Another way is to append all possible ZIP files to the search path and
use the ZIP table of contents as filename database.  Using this no
changes to `mktexlsr' are needed, but the search path gets longer and
longer with each ZIP and I don't know the speed penalty to search
through the ZIP toc.

-bernd