From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/658 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: LaTeX's T1 encoding / LaTeX PS fonts Date: Sat, 17 Jul 1999 01:57:03 +0200 Sender: owner-ntg-context@let.uu.nl Message-ID: <378FC6CF.8270E083@wxs.nl> References: <199907161426.QAA29283@dep.eco.rug.nl> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1035391507 25941 80.91.224.250 (23 Oct 2002 16:45:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 16:45:07 +0000 (UTC) Cc: ntg-context@ntg.nl Original-To: E.H.M.Frambach@eco.rug.nl Xref: main.gmane.org gmane.comp.tex.context:658 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:658 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 -----------------------------------------------------------------