[NTG-pdftex] [pdftex] \pdfmapfile-Patch

Hartmut Henkel hartmut_henkel@gmx.de
Sun, 9 Nov 2003 23:22:47 +0100 (CET)


Hi pdftex fans,

there is another experimental patch for pdtex-1.11b: This tackles with
two problems (see Hans' E-Mail below): 1. Mapfiles could not be read in
after the first page. 2. There is an annoying warning "duplicates
ignored" if the same mapfile line appears twice; overloading was not
possible.

With the patch, there are now the following options:

* \pdfmapfile(mapfile.map) starts fresh map set (only at start).

* \pdfmapfile(+mapfile.map) appends map, warns about duplicate entries
and then ignores them.

New:

* \pdfmapfile(++mapfile.map) replaces former map line entries for all
  matching fonts, which are not yet in use.

The font map entry management is now taken over by --- AVL-trees :-)
Actually the whole former fm_tab list is replaced by a tree, which were
lots of "trivial" mini changes (that's where the bugs are :-), but
scattered over many files, therefore the many diffs. But this should now
allow with high speed to register map entries, find existing ones, and
replace/overload them by newer ones, if needed. There is also a new flag
in the fm_entry structure, which tells, whether a font is already in use
(the info might also be elsewhere but this flag came in handy).

Another change is, that now \pdfmapfile{} primitives are also active
after the first page, as many as you need, wherever. As long as a font
is not in use, its entry is overloaded when \pdfmapfile{++mapfile.map}
is given on any page. A font is actually used, when the first letter of
the font is given. Then also a fresh mapfile scan is done (before this
font is used), if new mapfiles are available.

I have further re-organized the function fm_read_info() in mapfile.c,
and separated it into file and line scanning functions, for hopefully
better legibility. (I had to remove Heiko's fine hashing patch, as it
conflicted with the AVL stuff; the hashing is taken over by the tree
with similar speed).

In principle, it should also be possible with a little work (but not
implemented yet) to say \pdfmapfile{-mapfile.map}, which would _remove_
all entries matching those in this file, if not already in use. Any
application for this? Also possible (but not yet implemented) should be
something like:

\pdfmapfile{*++phvr8r Helvetica-Down "TeXBase1Encoding ReEncodeFont"...}

Any need for such a direct map-line registering?

You find a .tgz-file with the experimental patch (mostly diffs) at:

http://www.circuitwizard.de/pdftex/patch2/pdftex-avlpatch2-20031109.tgz

Small print: This is an experimental patch, in a rather early phase, and
buggy. No warranty whatsoever! It just happens to run over the few test
files I have here :-) Much more testing is needed. Particularily dark
corners are extended fonts...

Anyway, my current feeling is, that these AVL-trees would really help in
quite a few corners of pdftex, to improve organization, versatility, and
speed.

Is there anybody out there who would like to help with debugging?

Comments, bug reports welcome!

Best Regards

Hartmut


On Thu, 6 Nov 2003, Hans Hagen wrote:

> At 00:59 05/11/2003, Hartmut Henkel wrote:
> >On Tue, 4 Nov 2003, Hans Hagen wrote:
> >
> > > ...(actually dups should overload previous ones)
> >
> >Currently one adds a mapfile by "map myfonts.map" for fresh create,
> >or "map +myfonts.map" for append. It seems that a change in config.c
> >should be possible to allow also "map -myfonts.map", in which case
> >myfonts.map would be read in _before_ other map files, so in effect
> >it would overload them. Would this help?
>
> sounds ok to me although we can run into ptoblems when map files can
> be read after the first page (currently pdftex does not permit that
> which is painful because it complicates mid document font changes)
>
> so, next to -name we also need =name meaning 'load now and overload
> previous entries unless the font is already used'


------------------------------------------------------------------------
Hartmut Henkel, Oftersheim, Germany
http://www.circuitwizard.de
------------------------------------------------------------------------