Hi, great, those extensions! fabrice will generate me binaries one of these days ... so then i can test them!

The font map entry management is now taken over by --- AVL-trees :-)

so this brings us to: \pdfnewtree \nameoftree \pdfaddtotree \nameoftree {string} {tokens} \pdfgetfromtree \nameoftree \pdfresettree \nameoftree {string} which will give us a huge amount of hash space

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).

good, let's get rid of the old mess

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.

good thinking!

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?

hm, one never knows ... i found out that sometimes when including files, pdftex makes invalid files due to the fact that it tries to load fonts (when it finds a tfm file, it also assumes that there is a map file, but when the map is not loaded, it results in errors (non resolved names). So, i wonder if it's possible to add a test in the pdf inclusion partwhere each tfm file to be used is checked against the loaded map entries and when not found there, no clever things are done: currently: - pdf to be included uses font ABC - pdftex locates whatever.tfm that seems to match ABC - pdftex produced invalid pdf if map file has no entry for whatever.tfm replacement: - pdf to be included uses font ABC - pdftex locates whatever.tfm that seems to match ABC - pdftex checks map files for entry for whatever.tfm - pdftex ignores tfm file for inclusion when no entry is found maybe we also need: \pdfignorefontname=1 which let map file loading skip the "Full Name" entry (another source of problems) Hans