![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Patrick Gundlach wrote:
Yes, but you stated that "different metrics, different subpaths, urw instances either or not present". Different metrics? I can't see any differences in metrics between differnent distributions on those fonts! Can you? They come from one source, i.e psnfss. Different subpaths? Perhaps, but what is the problem? Kpathsea is taking care of this. URW or not to URW? Good question, lets get started on this subject :-)) If we accept that there is such thing as "psnfss", which is preinstalled on almost all TeX systems out there, we can let the user decide: use "psnfss-metrics" or the ones generated by $TOOL. And I can't see any problems with the spacing with those fonts being too LaTeX related. We should be happy about those fonts, since we get good fonts (in terms of encodings/spacing/finetuning) for free from the LaTeX side.
sure, and anyone is free to use what he/she wants; but ... my main problem is that i want to *know* what i use; recently i generated a set of metrics files using afm2pl which defaults to the ps* defaults and since a different spacing and emwidth metrics are used i got strange incompatible typeset results; (afm2pl now has a afm2tfm compatibility switch); there have been many discussions on how well for instance adobe metrics (the standard 35, present in printers, but they may differ over time and per platform) match urw's (on tex live, used when embedded) [nelson beebe has done quite some research on that]. One problem with all those fonts is that they have characteristics that are not reflected in the filename (take for instance the slant), emwidth, spacing, etc. The later may differ from the ones specified in the afm file. (actually, setting those probably makes more sense in tex itself, font dimens and such; if i have time i'll look into that: psfnss files with overloaded font dimens -) Imagine what would happen if protruding and hz was defined in fonts -) say that i want to mix polish and german (using qx and ec encoding) in one doc, i want similar spacing etc, don't i? concerning the akb file, that's more related to wanting to use adobe related metrics
You are right that there are many other things being to LaTeX related. The situation is getting much better. A few years ago the distributions only knew about LaTeX. I had major problems with old tetex (memory problems for example), now most things work out of the box.
let's hope it stays that way; e.g. context uses one format name for all engines, and until now could distinguish on suffix (fmt,efmt,ofmt) but web2c/tds now uses one suffix (fmt) and $engine subpath; but not all distributions will follow that spec, so context users who use pdfetex alongside aleph are worse off (well, texexec can be configured to use the web2c/$engine subpath: --engine of in texexec.ini) another everlasting issue is 8 bit in - 8 bit out (which is now solved by context always loading natural.tcx) that only leaves fonts, patterns, encoding vectors (yes they sometimes change, and there can be duplicates in the tree -)
encoding, there are in most cases no tfm files etc. They are mentioned here and there, but often not on the system. It took me a while to find out that -because of that- i could not use precoockes metrics at all -)
Who needs texnansi anyway? (OK, perhaps there are few who really need texnansi :-), but we might aks Mr. psnfss to generate texnansi metrics as well).
we've always used them, probably before ec was around -) actually, the nice thing about afm2pl is that it creates texnansi metric files avoiding virtual fonts. 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 -----------------------------------------------------------------