Hi Hans,

[psnfss fonts]

> sure, and anyone is free to use what he/she wants; but ... my main
> problem is that i want to *know* what i use; 

That is exactly why I use the psnfss fonts. They are stable, the
spacing doesn't change.

> (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].

Yes, but what was the conclusion? As far as I can see the metrics
only changed in terms of the character bounding box. But these are
not considered for the advance width. So the change in metrics is
irrelevant for typesetting with TeX.

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

Yes, but what is the problem? We are not talking about "other fonts",
just the ones preinstalled by psnfss. We know ervery bit of those
fonts, so no need to reflect the spacing etc. in the filename, since
e.g. phvr8t will always have the same characteristics thougout all

> 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?

Right, but qx isn't supplied by psnfss anyway, is it? So you'd have
to make your own font; but I still can't see the drawback in using
those fonts for 99% of [texts covered by ec encoding]. I can agree on
"don't mix fontinst installed fonts with afm2... installed fonts when
you need same em width (and alike)." But for most texts I bet that
this is not an issue.

> concerning the akb file, that's more related to wanting to use adobe
> related metrics

Absolutely. The choose the adobe metrics from psnfss, but as I am
told the URW metrics have somewhat questionable kerning data. And
using URW metrics with Adobe fonts will break on glyphs that are in
URW but not Adobe.

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

I should make a macro in my Mailreader for default answer for those
questions and put it on a easy to remember key :-)

> actually, the nice thing about afm2pl is that it creates texnansi
> metric files avoiding virtual fonts. 

That is really good. Let me see what I can do with respect to

ConTeXt wiki: http://contextgarden.net
texshow-web:  http://texshow.contextgarden.net
List archive: http://archive.contextgarden.net
ntg-context mailing list

Reply via email to