Medley font-file format #2135
Comments
|
Seems almost everything you need for a generic cache function-call facility. cache-calls (fn) redefines fn to check a hash-table for EQUAL (or EQUAL-ALL) hash-key ... if found, return the hash value, otherwise compute fn and store the results in the hash table. setup: cache-calls on FONTCREATE and READ-PDF. to save from one session to the next, write out the hash-table as a hash-file. I'm wary of baking in too much specifics about the font architecture .... |
|
Is cache-calls something that exists? Is the idea to somehow capture the values from the various calls to FONTCREATE and write them out in a cache that would be probed on later calls? I'm not sure that would be better than simply storing our own fonts in our own way, not getting tangled up in a function calling interface. But it turns out that HPRINT isn't currently up to the task, since it doesn't do commonlisp arrays or allocblocks. We made a pass at upgrading EQUALALL for allocblocks, but didn't think about HPRINT. That probably should be done in any event. The blocks are easy (modulo the fact that the physical lengths may not be preserved even though the logical lengths are). The commonlisp arrays have more header junk that would have to be represented. (But commonlisp arrays are not crucial for charset info, the only vector seems to be for kerning information installed by \READACFONTFILE; could just as easily be a pointer block) |
|
See a;sp issues
|
The problem that Matt pointed out with font recoding, is that we only have a function for writing strike-format files, not for AC format or other display formats, or other hardcopy formats. And the strike format doesn't support all of the information that some of our fonts now have.
As mentioned in #2120 , this is a stumbling block in the effort to clean up the lingering confusion between our internal character codes (MCCS) and the various fonts we have for rendering those codes. I now have the tools for moving character information around in and between fonts, but there is no obvious way of saving that information for later reuse--we would have to write/debug code that accurately conforms to the AC legacy format.
The alternative idea, doing the recoding on the fly when a font is being read, runs up against the fact that font-reading is done on a character-set-within-font basis; anything that crosses character sets or fonts is incompatible with this basic architecture. That's also not really an option.
So, maybe time for a fresh approach: define and implement our own Medley-natural font-file format. We can then read legacy fonts from legacy formats, rearrange and otherwise modify them in memory, and then write them out in a Medley-specific format that we know has all the information contained in our font descriptor and character-set data structures. These files would only be for Medley use; we have no need to export our fonts in a standard format that other applications might want.
For starters, here's a really simple strategy for writing a character set from a given in-core font-descriptor, no matter its provenance:
Create a structure, say an alist, that has a pointer to the charset-info plus whatever properties of the fontdescriptor that we want to associate with the character set (e.g. family, size...charencoding...). Then open a file with an appropriate name and device-extension, print an identifying header string (e.g. "Medley character set") to distinguish this from any other font-format, and HPRINT the structure. When the generic charset-reading code has seen/read the header string, it calls HREAD to recover the alist and unpacks it into the various font-descriptor locations. No need for fancy printing or parsing code.
A minor extension would be to include a character-set dispatch vector on the front, so that all the character sets of a given font could go into a single file. Character sets could still be loaded as needed, but without requiring the multi-level directory structure.
The text was updated successfully, but these errors were encountered: