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
