Re: <ATTN task force> LaTeX's T1 encoding / LaTeX PS fonts

[Hans Hagen <pragma@wxs.nl>]

Erik Frambach wrote:

> Until now always had problems with Times: first ConTeXt seems to insist on
> using tir.tfm, etc., then I get problems with either missing accents or funny

Hm. One can use filemapping to use other names, so it is under your
control. Currently the method is: 

(1) define font in terms of Regular/Sans/Mono)
(2) map those on verbose names, like TimesRoman
(3) map these on filenames 
(4) if needed remap these names (and so on)

Step (3) happens in for instance font-ber; this means that a different
local mapping can be acchieved by overloading this file. The file
font-fil maps to original filenames and does not use virtual fonts. The
advantage of this approach is that one can stick to logical names
(Regular). So, 

  \font\test=\truefontname{Regular} at 12pt

or 

  \definefont[test][Regular sa 1.5] 

gives the main regular body font. This is an advantage in defining
styles. Some special ones, like OldStyle and Gothic are defines using
this mechanism. 

Defining a new fontset is not that hard: 

Mapping names (Serif is equivalent to Regular): 

  \definefontsynonym [Serif]            [AntykwaTorunska-Regular]
  \definefontsynonym [SerifBold]        [AntykwaTorunska-Bold]
  \definefontsynonym [SerifItalic]      [AntykwaTorunska-Italic]
  \definefontsynonym [SerifSlanted]     [AntykwaTorunska-Italic]
  \definefontsynonym [SerifBoldItalic]  [AntykwaTorunska-Bold]
  \definefontsynonym [SerifBoldSlanted] [AntykwaTorunska-Bold]
  \definefontsynonym [SerifCaps]        [AntykwaTorunska-Regular]

Defining the whole set, based on the default relations:  

  \definebodyfont [14.4pt,12pt,11pt,10pt,9pt,8pt,7pt] [rm] [default]

Mapping the names onto files: 

\definefontsynonym [AntykwaTorunska-Bold]    [anttb]
\definefontsynonym [AntykwaTorunska-Regular] [anttr]
\definefontsynonym [AntykwaTorunska-Italic]  [anttri]

So, there is only one place where the filename comes into focus. 

BTW, Defining those non native (vf) fonts always was (and still is)
beyond me because I have only one set of times files and, using
dvipsone/dviwindo, cannot test virtual fonts at all. Some day --when I
got this new big laptop-- I will install more fonts and metrics and
viewers and start testing this. Until then I completely depend on others
for testing. 

BTW, does anyone know what encoding the antikwa fonts use? Seems like a
useful one (poland + neighbours). 

> characters instead of ligatures ff, fi, fl or funny characters instead of quotes.

This reminds me of the time we started using a ps printer, windows +
dviwindo, dvipsone (ps) and at the same time mattes viewer. I never
found out why windows remapped fonts, but I got it working and since
then never changed my tfm/pfb/etc files. Acrobat was yet another pain,
because it optimized some glyphs into the void (spaces and quotes) but
there was a workaround for that. 

> But never everything correct at the same time.

This is an encoding issue and related to the previous. We use times a
lot (tir files) and never had those problems, but I think your problem
could have been due to missing texnansi tfm files. Taco once suggested
to set up an archive for this (if only because texnansi is a rather good
encoding).  One reason for using the tir ones is (was) that I dislike
those (sometimes even) changing berry names, and prefer originals.  It's
also the reason why I have my own mapping files (taco, should we also
provide a map file?). 

> Maybe I'm stupid, but anyway I for one am VERY happy to see that this new
> method actually WORKS for me.

Good to hear that! 

Since the names in font-ber change now, we must make sure we make the
right choices once and for all (that is: taco makes the choices -). Some
time ago I got some baskerville fonts needed to typeset some UKTUG
stuff, and ended up with 5 subdir with 5 sets of tfm files and I never
could sort out which one to use, especially because the names in the map
files were yet another set. 

> I noticed a few strange characters in Taco's example, but maybe that's on
> purpose:
> - \v d yields d'
> - \v l yields l'
> - \=d yields a d with a dash that collides with the stem. \= b and other
>   "tall" characters look fine with the dash somewhat above the stem

Hm. v+d is mapped directly to a glyph, so this is a characteristic of
the font used. I just changed the underlying code to always prefer the
direct glyph (instead of falling back on the plain method when using
{}). 

BTW, the next release of context will have \showencoding, that shows a-z
combined with accents and also shows (in color) if they are composed or
not. Maybe that helps.  

For the curious ones: watch the pdf sections in the encoding files.
These make sure that as good as possible characters are mapped onto
pdfdoc encoding. So we have several mappings: glyphs, lower- and
uppercase, output encodings like pdf, etc. 

> What is "t: \t ae" supposed to yield? I get simply "t: ae".

tea -)

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