Re: [NTG-context] How to use PostScript font
----- Original Message -----
From: Hans Hagen
[ppl,12pt]
may work, but nowadays we say:
\usentypescript[palatino][\defaultencoding] \setupbodyfont[palatino,12pt]
With this: \setupbodyfont[ppl,12pt] \starttext The quick brown fox jumps over the lazy dog. \stoptext I get errors. I am using Fedora Core 2 with teTex 2.02. The error messages follow this message. I also tried: \usetypescript[palatino][\defaultencoding] \setupbodyfont[palatino,12pt] without any luck. Someone suggsted that I use the actual font names. So I tried: \setupbodyfont[uplr8a,12pt] and it generated an error message something like: "bodyfont : unknown variant uplr8a" Here are the error messages using [ppl,12pt]: kpathsea: Running mktexmf ec-uplr8a ! I can't find file `ec-uplr8a'. <*> ...jfour; mag:=1; nonstopmode; input ec-uplr8a Please type another input file name ! Emergency stop. <*> ...jfour; mag:=1; nonstopmode; input ec-uplr8a Transcript written on mfput.log. mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input ec-uplr8a' failed. kpathsea: Appending font creation commands to missfont.log. ! Font \*12ptrmtf*=ec-uplr8a at 12.0pt not loadable: Metric (TFM) file not foun d. ... ... ... l.2 [ppl,12pt] ?
Hi, [...]
I also tried:
\usetypescript[adobekb][\defaultencoding]
\usetypescript[palatino][\defaultencoding] \setupbodyfont[palatino,12pt]
Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
Patrick Gundlach wrote:
Hi,
[...]
I also tried:
\usetypescript[adobekb][\defaultencoding]
\usetypescript[palatino][\defaultencoding] \setupbodyfont[palatino,12pt]
Patrick
Concerning those fonts, there are differences between distributions: different metrics, different subpaths, urw instances either or not present; i got the feeling that sometimes fixes/changes take place when a font contributer finds out that his/her system does not work thereby breaking other things); unfortunately much of those pieces of distributions are dictated by what latex wants to see instead of being generic (one reason why i always generate metrics myself, although i found out that on the current tex live some of the files needed for that are not present of in different paths, so watch your logs -) 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.com | www.pragma-pod.nl -----------------------------------------------------------------
Hello Hans, [.. psnfss fonts ..]
Concerning those fonts, there are differences between distributions: different metrics, different subpaths, urw instances either or not present; i got the feeling that sometimes fixes/changes take place when a font contributer finds out that his/her system does not work thereby breaking other things); unfortunately much of those pieces of distributions are dictated by what latex wants to see instead of being generic
Well, we are talking about the fonts required by the psnfss (latex) system. Those should be all the same for all systems. The files typset should be completely portable. Maybe the outcome doesn't look right, but I doubt it will. I'd like to hear about any problems with psnfss not being compatible among distributions. And the argument about being too LaTeXy: the encoding of these files is not LaTeX specific (besides from the fact that LaTeX can only handle T1/OT1 encoding right), so what is not generic about them? Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
Patrick Gundlach wrote:
And the argument about being too LaTeXy: the encoding of these files is not LaTeX specific (besides from the fact that LaTeX can only handle T1/OT1 encoding right), so what is not generic about them?
if you run afm2tfm on some files you get different results that the 'handcrafted' ones that come with distributions; (afm2pl for instance defaults to different metrics [esp spacing] than afm2tfm); many of these things are not really documented and done by people who use latex and know about latex internals (for instance how they deal with spacing); concerning generic ... when discussing the fact that some files were not present or zipped with some people at a tex conference (in de) one of contributers remarked "why should they be there, since everyone uses latex and the stuff i make and no one is supposed to generate metrics") similar things are true for patterns: they are supposed to be generic, but for instance the czech patterns (on tl2003) simply quit when not used in latex. Other changes take place as well, like changes in names of files, and if someone changes a name and then patches some latex source file, users won't notice; when such things are not communicated, 'generic' users end up with a non working system; i think that the amount of real generic stuff out there is much smaller than people think (for instance bibtex files that have latex commands in entries) concerning fonts: if you want texnansi encoding, there are in most cases no tfm files etc. They are mentioned here and there, but often not on the system. It took me a while to find out that -because of that- i could not use precoockes metrics at all -) 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.com | www.pragma-pod.nl -----------------------------------------------------------------
Hello Hans,
And the argument about being too LaTeXy: the encoding of these files is not LaTeX specific (besides from the fact that LaTeX can only handle T1/OT1 encoding right), so what is not generic about them?
if you run afm2tfm on some files you get different results that the handcrafted' ones that come with distributions; (afm2pl for instance defaults to different metrics [esp spacing] than afm2tfm); many of these things are not really documented and done by people who use latex and know about latex internals (for instance how they deal with spacing); concerning generic ...
Yes, but you stated that "different metrics, different subpaths, urw instances either or not present". Different metrics? I can't see any differences in metrics between differnent distributions on those fonts! Can you? They come from one source, i.e psnfss. Different subpaths? Perhaps, but what is the problem? Kpathsea is taking care of this. URW or not to URW? Good question, lets get started on this subject :-)) If we accept that there is such thing as "psnfss", which is preinstalled on almost all TeX systems out there, we can let the user decide: use "psnfss-metrics" or the ones generated by $TOOL. And I can't see any problems with the spacing with those fonts being too LaTeX related. We should be happy about those fonts, since we get good fonts (in terms of encodings/spacing/finetuning) for free from the LaTeX side. You are right that there are many other things being to LaTeX related. The situation is getting much better. A few years ago the distributions only knew about LaTeX. I had major problems with old tetex (memory problems for example), now most things work out of the box. [...]
latex commands in entries) concerning fonts: if you want texnansi encoding, there are in most cases no tfm files etc. They are mentioned here and there, but often not on the system. It took me a while to find out that -because of that- i could not use precoockes metrics at all -)
Who needs texnansi anyway? (OK, perhaps there are few who really need texnansi :-), but we might aks Mr. psnfss to generate texnansi metrics as well). [...] Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
Patrick Gundlach wrote:
Yes, but you stated that "different metrics, different subpaths, urw instances either or not present". Different metrics? I can't see any differences in metrics between differnent distributions on those fonts! Can you? They come from one source, i.e psnfss. Different subpaths? Perhaps, but what is the problem? Kpathsea is taking care of this. URW or not to URW? Good question, lets get started on this subject :-)) If we accept that there is such thing as "psnfss", which is preinstalled on almost all TeX systems out there, we can let the user decide: use "psnfss-metrics" or the ones generated by $TOOL. And I can't see any problems with the spacing with those fonts being too LaTeX related. We should be happy about those fonts, since we get good fonts (in terms of encodings/spacing/finetuning) for free from the LaTeX side.
sure, and anyone is free to use what he/she wants; but ... my main problem is that i want to *know* what i use; recently i generated a set of metrics files using afm2pl which defaults to the ps* defaults and since a different spacing and emwidth metrics are used i got strange incompatible typeset results; (afm2pl now has a afm2tfm compatibility switch); there have been many discussions on how well for instance adobe metrics (the standard 35, present in printers, but they may differ over time and per platform) match urw's (on tex live, used when embedded) [nelson beebe has done quite some research on that]. One problem with all those fonts is that they have characteristics that are not reflected in the filename (take for instance the slant), emwidth, spacing, etc. The later may differ from the ones specified in the afm file. (actually, setting those probably makes more sense in tex itself, font dimens and such; if i have time i'll look into that: psfnss files with overloaded font dimens -) Imagine what would happen if protruding and hz was defined in fonts -) say that i want to mix polish and german (using qx and ec encoding) in one doc, i want similar spacing etc, don't i? concerning the akb file, that's more related to wanting to use adobe related metrics
You are right that there are many other things being to LaTeX related. The situation is getting much better. A few years ago the distributions only knew about LaTeX. I had major problems with old tetex (memory problems for example), now most things work out of the box.
let's hope it stays that way; e.g. context uses one format name for all engines, and until now could distinguish on suffix (fmt,efmt,ofmt) but web2c/tds now uses one suffix (fmt) and $engine subpath; but not all distributions will follow that spec, so context users who use pdfetex alongside aleph are worse off (well, texexec can be configured to use the web2c/$engine subpath: --engine of in texexec.ini) another everlasting issue is 8 bit in - 8 bit out (which is now solved by context always loading natural.tcx) that only leaves fonts, patterns, encoding vectors (yes they sometimes change, and there can be duplicates in the tree -)
encoding, there are in most cases no tfm files etc. They are mentioned here and there, but often not on the system. It took me a while to find out that -because of that- i could not use precoockes metrics at all -)
Who needs texnansi anyway? (OK, perhaps there are few who really need texnansi :-), but we might aks Mr. psnfss to generate texnansi metrics as well).
we've always used them, probably before ec was around -) actually, the nice thing about afm2pl is that it creates texnansi metric files avoiding virtual fonts. 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.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi Hans, [psnfss fonts]
sure, and anyone is free to use what he/she wants; but ... my main problem is that i want to *know* what i use;
That is exactly why I use the psnfss fonts. They are stable, the spacing doesn't change.
(afm2pl now has a afm2tfm compatibility switch); there have been many discussions on how well for instance adobe metrics (the standard 35, present in printers, but they may differ over time and per platform) match urw's (on tex live, used when embedded) [nelson beebe has done quite some research on that].
Yes, but what was the conclusion? As far as I can see the metrics only changed in terms of the character bounding box. But these are not considered for the advance width. So the change in metrics is irrelevant for typesetting with TeX.
One problem with all those fonts is that they have characteristics that are not reflected in the filename (take for instance the slant), emwidth, spacing, etc.
Yes, but what is the problem? We are not talking about "other fonts", just the ones preinstalled by psnfss. We know ervery bit of those fonts, so no need to reflect the spacing etc. in the filename, since e.g. phvr8t will always have the same characteristics thougout all distributions.
say that i want to mix polish and german (using qx and ec encoding) in one doc, i want similar spacing etc, don't i?
Right, but qx isn't supplied by psnfss anyway, is it? So you'd have to make your own font; but I still can't see the drawback in using those fonts for 99% of [texts covered by ec encoding]. I can agree on "don't mix fontinst installed fonts with afm2... installed fonts when you need same em width (and alike)." But for most texts I bet that this is not an issue.
concerning the akb file, that's more related to wanting to use adobe related metrics
Absolutely. The choose the adobe metrics from psnfss, but as I am told the URW metrics have somewhat questionable kerning data. And using URW metrics with Adobe fonts will break on glyphs that are in URW but not Adobe.
all engines, and until now could distinguish on suffix (fmt,efmt,ofmt) but web2c/tds now uses one suffix (fmt) and $engine subpath; but not all distributions will follow that spec, so context users who use pdfetex alongside aleph are worse off (well, texexec can be configured to use the web2c/$engine subpath: --engine of in texexec.ini)
I should make a macro in my Mailreader for default answer for those questions and put it on a easy to remember key :-)
actually, the nice thing about afm2pl is that it creates texnansi metric files avoiding virtual fonts.
That is really good. Let me see what I can do with respect to psnfss/texnansi... Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
Hi Patrick,
Yes, but what is the problem? We are not talking about "other fonts", just the ones preinstalled by psnfss. We know ervery bit of those fonts, so no need to reflect the spacing etc. in the filename, since e.g. phvr8t will always have the same characteristics thougout all distributions.
that's fine for those who use ec fonts, but i happen not to use them (we started using texnansi a long time ago; i'm not even sure if ec was around that time, and i definitely didn't have access to metrics then)
say that i want to mix polish and german (using qx and ec encoding) in one doc, i want similar spacing etc, don't i?
Right, but qx isn't supplied by psnfss anyway, is it? So you'd have to make your own font; but I still can't see the drawback in using those fonts for 99% of [texts covered by ec encoding]. I can agree on
well, (other thread), this is why we need an encoding with 'as many characters as possible' which means, no funny characters like copyright and registered and such (which spoils slots) -)
"don't mix fontinst installed fonts with afm2... installed fonts when you need same em width (and alike)." But for most texts I bet that this is not an issue.
probably, so, i have no problems with everyone except me using ec and psnfss fonts; and indeed i don't want to mix systems (most of the documents i process here use commercial fonts and for those i depend on my own font hackery; it simply does not pay off to spent much time on figuring out fontinst for that, apart from the fact that i lost track of font names long ago -)
Absolutely. The choose the adobe metrics from psnfss, but as I am told the URW metrics have somewhat questionable kerning data. And using URW metrics with Adobe fonts will break on glyphs that are in URW but not Adobe.
right, and that's why i use the urw metrics with urw files (i always embed those files, since i don't want operating systems/acrobat/printers to swap in their own substitutes and clones); when i use for instance palatino from adobe or linotype, I just generate new metric files.
That is really good. Let me see what I can do with respect to psnfss/texnansi...
ok; btw, also take a look at sieps afm2pl since it has some other nice features 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.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mon, Aug 23, 2004 at 01:26:06AM +0200, Hans Hagen Outside wrote:
ok; btw, also take a look at sieps afm2pl since it has some other nice features Hans
My belated three cents on some of the things which were discussed in this thread: As to texnansi: this is supported in Latex by texnansi.sty. For Western European languages, it seems to cover pretty much everything, so there is no need for text companion fonts or virtual fonts. Basic support (without artificial smallcaps) for a font family with non-virtual texnansi fonts consists of just four tfms, a mapfile fragment and, for Latex, an fd file. As to fontinst: doing it the easy way, using just the latinfamily command, you get dozens of files, in 8R, T1, OT1 and TS1 encoding. You have to be pretty expert if you want more fine-grained control and a more economical set of support files. I don't even know whether Fontinst can generate non-virtual texnansi fonts which are suitable for regular typesetting. Besides, I believe that nowadays fontinst depends on Latex. Sorry about just mentioning Latex here: I am only an occasional Context user, and don't use typescripts or texfont at all. As to afm2pl: the latest version available from tex.aanhet.net is 0.6; later versions are written to be part of TeX Live 2004 which is currently under development. Because of changes in the TDS, these may not work correctly in an older TeX installation. Version 0.7.02 with afm2tfm compatibility is not yet in the TeX Live source tree, last time I checked. -- Siep Kroonenberg
Hello Siep, [...] Only commenting on this one:
As to texnansi: this is supported in Latex by texnansi.sty. For Western European languages, it seems to cover pretty much everything, so there is no need for text companion fonts or virtual fonts. Basic support (without artificial smallcaps) for a font family with non-virtual texnansi fonts consists of just four tfms, a mapfile fragment and, for Latex, an fd file.
texnansi does not work with german.sty which I'd say is necessary for german texts. T1 and OT1 is hardcoded. I don't know about babel. Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
On Tue, Aug 24, 2004 at 12:09:50PM +0200, Patrick Gundlach wrote:
texnansi does not work with german.sty which I'd say is necessary for german texts. T1 and OT1 is hardcoded. I don't know about babel.
Patrick
Checking babel.def, I saw that it sets \latinencoding to OT1 if T1 is unavailable - which might explain some encoding-related oddities I have run into in the past. Guess some patches for babel and german are needed. -- Siep Kroonenberg
On Wed, 18 Aug 2004 15:16:43 -0400 skhilji@tampabay.rr.com wrote:
I get errors. I am using Fedora Core 2 with teTex 2.02. The error messages follow this message.
I'm using TeXLive 7 and this works for me: \usetypescript[berry][ec] % or [8r] \usetypescript[palatino][ec] % \setupbodyfont[palatino] I have other typeface examples in the "Predefined fonts" section of this document: http://home.salamander.com/~wmcclain/context-help.html -Bill -- Sattre Press Tales of War http://sattre-press.com/ by Lord Dunsany info@sattre-press.com http://sattre-press.com/tow.html
On Wed, Aug 18, 2004 at 03:16:43PM -0400, skhilji@tampabay.rr.com wrote:
Someone suggsted that I use the actual font names. So I tried:
That would be me. But what I really meant was that you may need to know those names in order to solve the problem, not that you can expect to use them directly in ConTeXt. Now I would say you should use a typescript if you can. There's no real benefit to using low-level font commands except that you might avoid the need to create typescripts. Because it looks to me like you probably need to either change the names of the fonts to conform to the built-in typescripts, or write your own typescript. The former could cause trouble if you ever want to use the fonts in LaTeX, so you're probably better off writing your own typescript. It's a bit weird at first, but really quite easy when you get used to it; hmm--let me give you a sample: I'll attach below my Palatino typescript. I haven't used it much lately, so I can't recall if it works 100%, but it might help you get started. I also use TeTeX on Linux, so it might be usable as is. For more info, there's a Fonts in ConTeXt manual that tells you most of what you need to know, and then Bill McClain has some good examples on the Web ... I believe his site is http://home.salamander.com/~wmmclain/. Fonts in TeX take a while to master, but once you do, life is great! (I think ... I hope ... I'll let you know when I get there ;-) -- type-palatino.tex ------------------------------------------------- \usetypescriptfile[type-buy] \starttypescript [serif] [palatino] [8r] \usetypescript[serif][fallback] \definefontsynonym [Palatino-Roman] [pplr8r] [encoding=8r] \definefontsynonym [Palatino-Bold] [pplb8r] [encoding=8r] \definefontsynonym [Palatino-Italic] [pplri8r] [encoding=8r] \definefontsynonym [Palatino-Bold-Italic] [pplbi8r] [encoding=8r] \definefontsynonym [Palatino-Slanted] [pplro8r] [encoding=8r] \definefontsynonym [Palatino-Bold-Slanted] [pplbo8r] [encoding=8r] \definefontsynonym [Palatino-Caps] [pplrc8t] [encoding=8t] \stoptypescript \starttypescript [serif] [palatino] [name] \definefontsynonym [Serif] [Palatino-Roman] \definefontsynonym [SerifBold] [Palatino-Bold] \definefontsynonym [SerifItalic] [Palatino-Italic] \definefontsynonym [SerifBoldItalic] [Palatino-Bold-Italic] \definefontsynonym [SerifSlanted] [Palatino-Slanted] \definefontsynonym [SerifBoldSlanted] [Palatino-Bold-Slanted] \definefontsynonym [SerifCaps] [Palatino-Caps] \stoptypescript \starttypescript[PalatinoFace] \definetypeface [Palatino] [rm] [serif] [palatino] [default] [encoding=8r] \stoptypescript -- Matt Gushee When a nation follows the Way, Englewood, Colorado, USA Horses bear manure through mgushee@havenrock.com its fields; http://www.havenrock.com/ When a nation ignores the Way, Horses bear soldiers through its streets. --Lao Tzu (Peter Merel, trans.)
[...]
I get errors. I am using Fedora Core 2 with teTex 2.02.
the ConTeXt in tetex 2.02 should be new enough to handle what Mari and I have pointed out. Please post an error message on the things that we have written. (But I doubt you will get any.) Patrick -- ConTeXt wiki: http://contextgarden.net texshow-web: http://texshow.contextgarden.net List archive: http://archive.contextgarden.net
participants (7)
-
Bill McClain -
Hans Hagen -
Hans Hagen Outside
-
Matt Gushee -
Patrick Gundlach -
Siep Kroonenberg -
skhilji＠tampabay.rr.com