Re: fonts / proposal

[siepo@cybercomm.nl]

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