Mojca Miklavec wrote:
What are we talking about? Do you mean the old virtual fonts (.vf files) or mkiv's virtual fonts or something completely different?
What You Don't Want To Know: a virtual font is just a regular font but has references to other fonts instead, like char 1 -> font x, char 10 (or dvi commands instead) and then it can has kerning etc within its own set tex itself only sees characters as things with dimensions and a few properties and when typesetting the paragraph uses info from the font with respect to kerning and ligature building now, traditional tex has only tfm files and when virtual fonts were introduced the engine was not adapted at all; so, a virtual font still has a tfm file (with characters etc) however, when the font is being used in the backend, an extra lookup takes place and when a vf file is found, information from that file is used for embedding (in pdftex); of course dvi postprocessors also look at that file so we have: tfm -> tfm used by frontend and backend tfm + vf -> tfm used by frontend, vf used by backend on top of that a map file will point from fontname to real name (pfb) and this is why in a map file you don't see the virtual font names at all, as it's the names inside the vf that matter so say that we have: a.tfm + a.vf but internally a.vf -> font b, c, d (or further chained) then b, c, d need to be resolved to real names as there is no checking going on and as the tfm file has no info about itself being virtual you can imagine that interesting side effects can take place when an old (unknown of) vf lays around ... it will kick in at backend time (this is why the texfont script does a clean up) in luatex we have integrated these mechanisms, so internally a font can have virtual properties (a few more than original tex) however, by default luatex acts like tex, so users won't notice; as luatex has the backend integrated, at some point it will need the vf and mkiv will happily fulfill that request but ... and this is the catch ... in mkiv we use (1) opentype, (2) type 1 and (3) traditional tex fonts (1) is not related to virtual fonts but we can (and do) extend fonts internally using virtual technology (2) in pdftex tfm/vf files are used but mkiv does not look at those files but uses afm files directly (right from the start) (3) the only place in mkiv where tex metric files are still used is in math as we need the additional (math specific) info as it makes no sense to keep supporting the old math fonts while open type variant sare under way, i decided to stick to unicode math and as a result we need to use virtual font technology to make that unicode variant for the lm fonts, this is mostly done and as they have no virtual (vf based) fonts it's transparent for tx/px however, as they use virtual fonts, it gets hairy what file to load; technically there is no obstacle but i've chosen to stay away from the tfm/vf mess and use just the natural tfm variants (i.e. the ones that match the pfb) and therefore we might need a few extra vectors (and maybe font files) in math-vfu that map to the right slots; using the vf's as well would complicate matters and it's not worth the trouble so, what we need to do is to figure out teh few missing files/vectors, add them, and then let users fill in the gaps in vectors are you still there? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------