fonts / proposal

fonts / proposal

[Hans Hagen]

Hi,

I'm currently working on fonts, not so much in context itself, as well as 
installation. Since i want a clean way to install fonts [commercial ones 
for instance] and since licence policy is always tricky, i now put them in 
a dedicated tree texmf-fonts.

In the texmf tree [as distribited by tex live] there are a couple of free 
fonts [we're talking outlines] but not that much. I don't want to let the 
rather latex oriented font naming and organization scheme 'spoil' things 
and i want users to be able to easilly use other encodings that ec too. How 
do users handle this currenlty, say that they want polish encoding?

Installing fonts comes down to

(1) generating the tfm's
(2) if needed create vf files
(3) if neede copy files to the right location
(4) create a decent map file for pdftex

in addition, if needed:

(5) create slanted fonts
(6) create small caps

Now, since one font can be on the system in say texnansi, ec, pl0, csr or 
whatever encoding, and since users may have different opinions on how 
slanted or small capped a font may be, we end up in so many files that the 
current tex naming sheme drives at least me crazy. Also, i really want to 
avoid latex like fd files scattering the system. Therefore, this is what i 
have implemented and can support:

(1) users choose a default encoding but can derive from it if needed, let's 
assume ec here

(2) texfont creates a series of files from the afm files (we assume urw 
palatino):

     ec-urw-palatino.map
     ec-raw-*.tfm
     ec-*.tfm
     ec-*.vf

(3) if needed also create slanted/caps alternatives

(4) also, a tex test file generated that show that things are done ok

(5) typescript files will mape symbolic names in an efficient way

(6) map files will be loaded at run time [when enabled]

an example of a generated file is: ec-blabla-slanted-167.tfm which is a 
bitthe x windows way of naming fonts. If needed one can have say 10 slanted 
and 5 extended and 2 capped files of one font.

[there is currenty a make file that makes all files needed]

What does this mean in practice? A couple of more files, but named in such 
a way that simple font users like me can see what happens. It also means 
that we can use one set of typescripts for all kind of encodings. A 
dedicated font tree so that we can consider zipping it and posting it.

Now, if context comes with the typescripts that define fonts this verbose 
way. we can have a problem with users who want to stick to the 8 byte names 
and/or want to sort out the funny names themselves. Since filename mapping 
is implemented recursively, they can have a way out with a special file like:

\definefontsynonym [ec-uplr8a-slanted-167] [uplro8t]

where they may hope that the latter is indeed available, slanted 167, and 
in ec encoding.

Are there any strong [and valid] objectiona against this scheme? The idea 
is, in the end to have a way to set up a minimal consistent system.

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[Giuseppe Bilotta]

Friday, August 03, 2001 Hans Hagen wrote:

HH> Hi,

HH> I'm currently working on fonts, not so much in context itself, as well as 
HH> installation. Since i want a clean way to install fonts [commercial ones 
HH> for instance] and since licence policy is always tricky, i now put them in 
HH> a dedicated tree texmf-fonts.

I think the TeX Directory Standard puts fonts under

\texmf\fonts\<type>\<class>\<vendor>\<name>

e.g.

\texmf\fonts\type1\public\ams\cmr

or something of the sort.

[snip]

HH> an example of a generated file is: ec-blabla-slanted-167.tfm
HH> which is a bit the x windows way of naming fonts. If needed
HH> one can have say 10 slanted and 5 extended and 2 capped files
HH> of one font.

I think the (only) problem with this is that it fails on pure DOS
system (8.3 naming constrictions). Since the font naming is X
Windows-like, why don't you just use the X Windows scheme?

[snip]

HH> Now, if context comes with the typescripts that define fonts this verbose
HH> way. we can have a problem with users who want to stick to the 8 byte names 
HH> and/or want to sort out the funny names themselves. Since filename mapping 
HH> is implemented recursively, they can have a way out with a special file like:

HH> \definefontsynonym [ec-uplr8a-slanted-167] [uplro8t]

HH> where they may hope that the latter is indeed available, slanted 167, and 
HH> in ec encoding.

HH> Are there any strong [and valid] objectiona against this scheme? The idea 
HH> is, in the end to have a way to set up a minimal consistent system.

I don't find any objections. The recursive fontsynonym technique
also allows for automagic font substitutions: if
ec-uplr8a-slanted-167 is not available, it can be mapped to the
closer available font (e.g. removing the 167, which would seek
for a "default" slanted font, then removing the "slanted" etc;
something like using a * in a fontname part under X Windows).

Giuseppe "Oblomov" Bilotta

Re: fonts / proposal

[Taco Hoekwater]

Giuseppe Bilotta wrote:
> 
> I think the TeX Directory Standard puts fonts under
> 
> \texmf\fonts\<type>\<class>\<vendor>\<name>

I strongly believe that was a mistake. Because that way, the different
parts
that make up a font are split over two or three separate directories.
But that is not important now...

> I think the (only) problem with this is that it fails on pure DOS
> system (8.3 naming constrictions). Since the font naming is X
> Windows-like, why don't you just use the X Windows scheme?

The X system has rather a lot of keys that dont make sense in TeX.

Here is the list and an example:

Foundry            Adobe
Family             Helvetica
Weight             bold
Slant              oblique
Set Width          expanded
Additional Style   
Pixel Size         12
Point Size         120
Resolution X       75
Resolution Y       75
Spacing            proportional
Average Width      69
Charset            iso8859-1

Slant and Spacing are actually one letter in the X font name, so this
font's name is:

-adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso8859-1

Slant is normally one of (o,r,i) for oblique,roman,italic

Spacing is normally one of (c,p,m) for cell,proportional,monospaced
(cell is roughly the same as monospaced)

AddStyle is normally not used.

Point Size is in 1/720th of an inch (value 0 for scalable font). 

PxlSize, resX and resY are never really applicable to a type 1 font. 
(values 0)

AvgW is a bit of a weird thing that is sometimes handy when trying to
replace the font for a block of text, but it is usually generated 
on-the-fly and not saved in the name (value==0).

Therefore, the example font is actually specified in the font directory
as:

-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1

Whatever Hans comes up with, at should be documented straight away. And 
by that I mean a precise specification of what the font installer can
generate in the fields.

Just some background info.

Greetings, Taco

Re: fonts / proposal

[siepo]

On  3 Aug, Hans Hagen wrote:
> Hi,
> 
> I'm currently working on fonts, not so much in context itself, as well
> as installation. Since i want a clean way to install fonts
> [commercial ones for instance] and since licence policy is always
> tricky, i now put them in a dedicated tree texmf-fonts.
> 
> In the texmf tree [as distribited by tex live] there are a couple of
> free fonts [we're talking outlines] but not that much. I don't want
> to let the rather latex oriented font naming and organization scheme
> 'spoil' things and i want users to be able to easilly use other
> encodings that ec too. How do users handle this currenlty, say that
> they want polish encoding?
> 
> Installing fonts comes down to
> 
> (1) generating the tfm's
> (2) if needed create vf files
> (3) if neede copy files to the right location
> (4) create a decent map file for pdftex
> 
> in addition, if needed:
> 
> (5) create slanted fonts
> (6) create small caps
> 
> Now, since one font can be on the system in say texnansi, ec, pl0, csr
> or whatever encoding, and since users may have different opinions on
> how slanted or small capped a font may be, we end up in so many files
> that the current tex naming sheme drives at least me crazy. Also, i
> really want to avoid latex like fd files scattering the system.
> Therefore, this is what i have implemented and can support:
> 
> (1) users choose a default encoding but can derive from it if needed,
> let's assume ec here
>
> (2) texfont creates a series of files from the afm files (we assume
> urw palatino):
> 
>      ec-urw-palatino.map
>      ec-raw-*.tfm
>      ec-*.tfm
>      ec-*.vf
> 
> (3) if needed also create slanted/caps alternatives
> 
> (4) also, a tex test file generated that show that things are done ok
> 
> (5) typescript files will mape symbolic names in an efficient way

What do you mean by efficient?

> (6) map files will be loaded at run time [when enabled]

What do you mean by this?

> an example of a generated file is: ec-blabla-slanted-167.tfm which is
> a bitthe x windows way of naming fonts. If needed one can have say 10
> slanted and 5 extended and 2 capped files of one font.

Ok. But I wouldn't want proper X Window font names, as Guiseppe
suggested, because those contain 13 parameters, which is a bit over
the top.

> [there is currenty a make file that makes all files needed]
> 
> What does this mean in practice? A couple of more files, but named in
> such a way that simple font users like me can see what happens. It
> also means that we can use one set of typescripts for all kind of
> encodings. A dedicated font tree so that we can consider zipping it
> and posting it.
> 
> Now, if context comes with the typescripts that define fonts this
> verbose way. we can have a problem with users who want to stick to
> the 8 byte names and/or want to sort out the funny names themselves.
> Since filename mapping is implemented recursively, they can have a
> way out with a special file like:
> 
> \definefontsynonym [ec-uplr8a-slanted-167] [uplro8t]
> 
> where they may hope that the latter is indeed available, slanted 167,
> and in ec encoding.
> 
> Are there any strong [and valid] objectiona against this scheme? The
> idea is, in the end to have a way to set up a minimal consistent
> system.
> 
> Hans

Is there going to be LaTeX support?

How would your scripts handle `real' oldstyle figure and small caps
fonts and expert sets? The character sets of these don't seem to be
entirely standardized. I think that was the reason why I needed
low-level fontinst macros to use my Times OSF&SC fonts even though I had
expected the high-level latinfamily fontinst macro to generate the vfs
and tfms that I wanted.

Siep

Re: fonts / proposal

[Hans Hagen]

At 10:06 PM 8/3/2001 +0200, Giuseppe Bilotta wrote:

>Friday, August 03, 2001 Hans Hagen wrote:
>
>HH> Hi,
>
>HH> I'm currently working on fonts, not so much in context itself, as well as
>HH> installation. Since i want a clean way to install fonts [commercial ones
>HH> for instance] and since licence policy is always tricky, i now put 
>them in
>HH> a dedicated tree texmf-fonts.
>
>I think the TeX Directory Standard puts fonts under
>
>\texmf\fonts\<type>\<class>\<vendor>\<name>
>
>e.g.
>
>\texmf\fonts\type1\public\ams\cmr
>
>or something of the sort.

right, and since i like to delete and reinstall the base path's i don't 
want my own fonts or patches there -)

I think the (only) problem with this is that it fails on pure DOS
>system (8.3 naming constrictions). Since the font naming is X
>Windows-like, why don't you just use the X Windows scheme?

right, in which case one can use filemapping to map back on 8 char names 
for which i provide

   \usetypescript [map][berry]

>I don't find any objections. The recursive fontsynonym technique
>also allows for automagic font substitutions: if
>ec-uplr8a-slanted-167 is not available, it can be mapped to the
>closer available font (e.g. removing the 167, which would seek
>for a "default" slanted font, then removing the "slanted" etc;
>something like using a * in a fontname part under X Windows).

right, can even be automated,

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[Hans Hagen]

At 12:30 PM 8/4/2001 +0000, siepo@cybercomm.nl wrote:

> > (5) typescript files will mape symbolic names in an efficient way
>
>What do you mean by efficient?

say

\usetypescript [palatino] [ec]

and

\usetypescript [times] [ec[

and then use \palatino and \times to swhich between font collections.

Also, to be able to combine predefined typescripts.

> > (6) map files will be loaded at run time [when enabled]
>
>What do you mean by this?

that, instead of editing the pdftex.map file, context will instruct pdftex 
to load the map files needed.

>Is there going to be LaTeX support?

The current tools and texmf tree is rather tuned for latex. I think latex 
users are already served by fontinst and all those fd files. Bu

>How would your scripts handle `real' oldstyle figure and small caps
>fonts and expert sets? The character sets of these don't seem to be
>entirely standardized. I think that was the reason why I needed
>low-level fontinst macros to use my Times OSF&SC fonts even though I had
>expected the high-level latinfamily fontinst macro to generate the vfs
>and tfms that I wanted.

right, and i think in this respect fontinst is more powerful; the thing 
that i have in mind are for users (like me) who have not the faintest idea 
about what font tricks can be done.

in a later stage i will certainly look into expert fonts and alike [maybe 
taco wants to extend afm2tfm a bit for this], and there i definitely need 
your expertise in the font field -)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[siep]

On  6 Aug, Hans Hagen wrote:
> At 12:30 PM 8/4/2001 +0000, siepo@cybercomm.nl wrote:
> 
>> > (5) typescript files will mape symbolic names in an efficient way
>>
>>What do you mean by efficient?
> 
> say
> 
> \usetypescript [palatino] [ec]
> 
> and
> 
> \usetypescript [times] [ec[
> 
> and then use \palatino and \times to swhich between font collections.
> 
> Also, to be able to combine predefined typescripts.
> 
>> > (6) map files will be loaded at run time [when enabled]
>>
>>What do you mean by this?
> 
> that, instead of editing the pdftex.map file, context will instruct pdftex 
> to load the map files needed.

For me, it is a frequent source of confusion when Context does things
its own way. Filesearching deviating from kpsewhich filesearch was one
example; mapfile loading different from what dvips and pdftex do on
their own would be another.

>>Is there going to be LaTeX support?
> 
> The current tools and texmf tree is rather tuned for latex. I think latex 
> users are already served by fontinst and all those fd files. Bu

Well, I am primarily a LaTeX user, but would welcome an alternative to
fontinst and would certainly like to have a single font setup for all
TeX macro packages. For regular text fonts, creating fd files should be
no big deal, and maybe I could contribute there.

Siep

Re: fonts / proposal

[Hans Hagen]

At 11:22 AM 8/6/2001 +0200, siep@elvenkind.com wrote:

>For me, it is a frequent source of confusion when Context does things
>its own way. Filesearching deviating from kpsewhich filesearch was one
>example; mapfile loading different from what dvips and pdftex do on
>their own would be another.

actually, file searching is not that different, since the only filetype 
supported by kpsewhich in tex itself are "tex" and "tfm"; i only block 
system wide searches for certain cases by forcing local searches, an dmost 
can be configured; global searches screw up any project with similar file 
names; context is meant for usage is highly structered projects' if you 
refer to figure inclusion, well this is messy anyway between tex's and apps -)

concerning map files: dvips and pdftex already live in a world on their 
own, also, mapfiles can be highly conflicting [try to include a pdf graphic 
while using the default pdfonts.map and there is a reasonable change that 
you run into troubles due to naming conflicts]; also, many fonts in the map 
files are either not on any system, or in different names, etc etc. 
Actually, pdftex should be capable of using a format specific cfg file.

I try to adapt as much as possible to anything standard, but esp with 
regards to fonts, less is standardized that one wishes, and i want once and 
for all to get rid of missing glyphs depending on what cd i mounted.

Actually, it would already help a lot if mapfiles would be structured, 
properly named, etc

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[siep]

On  6 Aug, Hans Hagen wrote:
> At 11:22 AM 8/6/2001 +0200, siep@elvenkind.com wrote:
> 
>>For me, it is a frequent source of confusion when Context does things
>>its own way. Filesearching deviating from kpsewhich filesearch was one
>>example; mapfile loading different from what dvips and pdftex do on
>>their own would be another.
> 
> actually, file searching is not that different, since the only filetype 
> supported by kpsewhich in tex itself are "tex" and "tfm"; i only block 
> system wide searches for certain cases by forcing local searches, an dmost 
> can be configured; global searches screw up any project with similar file 
> names; context is meant for usage is highly structered projects' if you 
> refer to figure inclusion, well this is messy anyway between tex's and apps -)
> 
> concerning map files: dvips and pdftex already live in a world on their 
> own, also, mapfiles can be highly conflicting [try to include a pdf graphic 
> while using the default pdfonts.map and there is a reasonable change that 
> you run into troubles due to naming conflicts]; also, many fonts in the map 
> files are either not on any system, or in different names, etc etc. 
> Actually, pdftex should be capable of using a format specific cfg file.
> 
> I try to adapt as much as possible to anything standard, but esp with 
> regards to fonts, less is standardized that one wishes, and i want once and 
> for all to get rid of missing glyphs depending on what cd i mounted.
> 
> Actually, it would already help a lot if mapfiles would be structured, 
> properly named, etc
> 
> Hans

I am certainly not claiming that things are perfect the way they are,
but I have my own workarounds, and I get along ok with kpsewhich and
mapfiles as they are.

What about letting out-of-the-box pdftex and dvips read the same
mapfiles that they would read outside Context, and letting Context use
kpsewhich for all its file searching, and that any non-standard
behaviour would have to be explicitly turned on in a configuration file?

Siep

Re: fonts / proposal

[Taco Hoekwater]

siep@elvenkind.com wrote:
>
> What about letting out-of-the-box pdftex and dvips read the same
> mapfiles that they would read outside Context, and letting Context use
> kpsewhich for all its file searching, and that any non-standard
> behaviour would have to be explicitly turned on in a configuration file?

One way out of this should be create font-name mapping entries for the
new system. the 'fontname' directory in your TeX tree. Then users can
decide for themselves whether or not they want the new-style names.

I don't really know how this works though, and I am not too eager to
find out how it *should* work (and it doesn't solve the IMO nastiest
problem:
2 times [a-z0-9] is just not enough for the family name to be anywhere 
near meaningful: most big vendors have more than 36*36 font families
available).

-- 
groeten,

Taco

Re[2]: fonts / proposal

[Giuseppe Bilotta]

Monday, August 06, 2001 Hans Hagen wrote:

HH> At 10:06 PM 8/3/2001 +0200, Giuseppe Bilotta wrote:

>>Friday, August 03, 2001 Hans Hagen wrote:
>>
>>HH> Hi,
>>
>>HH> I'm currently working on fonts, not so much in context itself, as well as
>>HH> installation. Since i want a clean way to install fonts [commercial ones
>>HH> for instance] and since licence policy is always tricky, i now put 
>>them in
>>HH> a dedicated tree texmf-fonts.
>>
>>I think the TeX Directory Standard puts fonts under
>>
>>\texmf\fonts\<type>\<class>\<vendor>\<name>
>>
>>e.g.
>>
>>\texmf\fonts\type1\public\ams\cmr
>>
>>or something of the sort.

HH> right, and since i like to delete and reinstall the base path's i don't 
HH> want my own fonts or patches there -)

use \localtexmf instead of \texmf as the root. the local tree is
supposed to be used exactly for this purpose.

--
Giuseppe "Oblomov" Bilotta

Re[2]: fonts / proposal

[Hans Hagen]

At 07:59 PM 8/7/2001 +0200, Giuseppe Bilotta wrote:

>use \localtexmf instead of \texmf as the root. the local tree is
>supposed to be used exactly for this purpose.

that one is already taken for updates and so, fonts may be put on some 
server somewhere; now texfont searches for both, so if you don;t have a 
dedicated font path, local is used

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[Hans Hagen]

At 10:40 AM 8/7/2001 +0200, Taco Hoekwater wrote:
>siep@elvenkind.com wrote:
> >
> > What about letting out-of-the-box pdftex and dvips read the same
> > mapfiles that they would read outside Context, and letting Context use
> > kpsewhich for all its file searching, and that any non-standard
> > behaviour would have to be explicitly turned on in a configuration file?
>
>One way out of this should be create font-name mapping entries for the
>new system. the 'fontname' directory in your TeX tree. Then users can
>decide for themselves whether or not they want the new-style names.

there is indeed a mapping from the long names to the texmf-berry names, but 
that happens in tex; indeed an alternative is dedicated map files; should 
be doable for the couple of standard encodings; on the other hand, if we 
can work out a decent collection of nicely organized map files in the next 
year, i'm sure that we can convince the tex live people to add them

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: fonts / proposal

[siep]

Let's try to summarize a few things.

dvips reads psfonts.map to find the PostScript font for a given tfm,
plus any transformations that have to be applied to that file. You
can have as many tfms as you like for one PostScript font. For this,
you can simply add a bunch of (Context) tfm-s to an existing
psfonts.map and since the new tfm names are different from existing
tfm names, it won't upset existing usage.

The tricky part is reverse lookup. I understand from Taco that this
occurs when a to-be-included epsfile needs fonts. Here, additional
mapfile entries can cause problems. I am not familiar with the
details. However, offhand I would say that for reverse lookup only
the PostScript fontname and the filename would be used, and that
there should be no problems as long as all entries referring to the
same PostScript fontname also refer to the same pfb. It shouldn't be
that hard to write a script which validates and corrects mapfiles for 
this.

The point of all this is that it should be possible to stuff everything
you need in your default psfonts.map.

Also a word about fontinst. If you read the documentation then it is
very LaTeX-centric. I believe however that this is mainly true for the
top-level commands. I created three testfonts with fontinst, all based
on Helvetica Light, with the following input file:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input fontinst.sty
\transformfont{phvl8r}{\reencodefont{8r}{\fromafm{phvl8a}}}
\transformfont{transhv}{\reencodefont{8y}{\fromafm{phvl8a}}}
\installfonts
  \installrawfont{installhv}{phvl8a,latin}{8y}
    {}{}{}{}{}
  \installfont{virthv}{phvl8r,latin,8r}{T1}
    {}{}{}{}{}
\endinstallfonts
\bye
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

As you see, you can name fonts whatever you like, and you can set the
LaTeX-specific parameters to null values; these would only be needed for
creating font families and fd files I think.

These are the mapfile entries:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
transhv Helvetica-Light "TeXnANSIEncoding ReEncodeFont " <texnansi.enc <phvl8a.pfb
installhv Helvetica-Light "TeXnANSIEncoding ReEncodeFont " <texnansi.enc <phvl8a.pfb
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A LaTeX testfile:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{minimal}
\usepackage[LY1,T1,OT1]{fontenc}
\DeclareFontFamily{LY1}{transhv}{}
\DeclareFontShape{LY1}{transhv}{m}{n}{<->transhv}{}
\DeclareFontFamily{LY1}{installhv}{}
\DeclareFontShape{LY1}{installhv}{m}{n}{<->installhv}{}
\DeclareFontFamily{T1}{virthv}{}
\DeclareFontShape{T1}{virthv}{m}{n}{<->virthv}{}
\begin{document}
\fontencoding{LY1}\fontfamily{transhv}\selectfont
Font generated with transformfont (non-virtual, no kerning,
texnansi)
German sz in wrong slot

AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss \char223\par~\par

\fontencoding{LY1}\fontfamily{installhv}\selectfont
Font generated with installrawfont (non-virtual, generic kerning, texnansi)
German sz in wrong slot

AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss \char223\par~\par

\fontencoding{T1}\fontfamily{virthv}\selectfont
Font generated with installfont (virtual, generic kerning, T1)

AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss\par~\par
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A Context testfile (contributed by Taco):

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\definefontsynonym[Atranshv][transhv][encoding=texnansi]
\definefontsynonym[Ainstallhv][installhv][encoding=texnansi]
\definefontsynonym[Avirthv][virthv][encoding=ec]

\definebodyfont [14.4pt,12pt,11pt,10pt,9pt,8pt,7pt,6pt,5pt] [rm]
[bi=Atranshv sa 1,
bf=Ainstallhv sa 1,
it=Avirthv sa 1]    

\switchtobodyfont[10pt]

\starttext
Font generated with transformfont (non-virtual, no kerning, texnansi)

{\bi
AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz \par~\par}

Font generated with installrawfont (non-virtual, generic kerning, texnansi)

{\bf
AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz \par~\par}

Font generated with installfont (virtual, generic kerning, T1)

{\it
AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz\par~\par}
\stoptext
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

You can find pdfs of the testfiles at www.cybercomm.nl/~siepo/.

Siep

Re: fonts / proposal

[Hans Hagen]

At 11:34 AM 8/8/2001 +0200, siep@elvenkind.com wrote:

>dvips reads psfonts.map to find the PostScript font for a given tfm,
>plus any transformations that have to be applied to that file. You
>can have as many tfms as you like for one PostScript font. For this,
>you can simply add a bunch of (Context) tfm-s to an existing
>psfonts.map and since the new tfm names are different from existing
>tfm names, it won't upset existing usage.

right, i'm now using a psfonts.map file with all names stripped out [second 
entry] in which case it does not conflict.
for the sake of simplicity, i furthermore leave that file untouched

>The tricky part is reverse lookup. I understand from Taco that this
>occurs when a to-be-included epsfile needs fonts. Here, additional
>mapfile entries can cause problems. I am not familiar with the
>details. However, offhand I would say that for reverse lookup only
>the PostScript fontname and the filename would be used, and that
>there should be no problems as long as all entries referring to the
>same PostScript fontname also refer to the same pfb. It shouldn't be
>that hard to write a script which validates and corrects mapfiles for
>this.

right, with reverse lookup, the FontName is used, unless removed. Since 
this name has no info on shape changes or alike, i removed them, otherwise 
pdftex will start loading the associated tfm file [funny confusing messages 
about fonts you don't use then show up] -)

>The point of all this is that it should be possible to stuff everything
>you need in your default psfonts.map.

it would be a nice option [i will discuss this with thanh] if entries could 
be overloaded

>Also a word about fontinst. If you read the documentation then it is
>very LaTeX-centric. I believe however that this is mainly true for the
>top-level commands. I created three testfonts with fontinst, all based
>on Helvetica Light, with the following input file:

ok, thanks for testing, i will look into that when i'm back from tug2001

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------