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
