Gerben, Apologies for posting any confusion.

1. The only package fink in use is the tetex placeholder system-tetex I did previously have fink tetex but now only have i-Installer tetex almost latest.

2. The texroot report no longer occurs presumably I have cleaned up my installation further. The command now aborts simply with the subpath message.

texfont --en=8r --ve=urw --co=courier --so=auto

TeXFont 1.5 - ConTeXt / PRAGMA ADE 2000-2001 (STILL BETA)

processing aborted : unknown subpath ../fonts/afm/urw/courier

--help : show some more info

Locate gives the following list suggesting that texfont is not looking at /usr/local/teTeX/share/texmf.tetex for fonts

locate /fonts/afm/urw/courier /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier/ucrb8a.afm /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier/ucrbo8a.afm /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier/ucrr8a.afm /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier/ucrro8a.afm

Texfont help suggest that I should use the following command but the same unknown subpath is returned. texfont --en=8r --ve=urw --fontroot=/usr/local/teTeX/share/texmf.tetex --co=courier --so=auto

In the file /usr/local/teTeX/share/texmf.tetex/context/config/texexec.ini There is a line which seems very odd and PC like set TeXFontsPath to l:/tex/texmf;l:/tex/texmf-local;

I have commented out this line and set TeXFontsPath to other more likely values like texmf, texmf.tetex all do not effect the unknown subpath.

I'm now beyond the end of my knowledge.

All,

I am having trouble getting the latest edition of Context to allow me to work through the Metafun manual.

This, saved as grid.tex:

\setupoutput[pdf]

\runMPgraphicstrue

\setupcolors[state=start]

\startuseMPgraphic{test} drawoptions(withpen pencircle scaled 1pt withcolor 0.625yellow); draw hlingrid(0,10,1,3cm,3cm); draw vlingrid(0,10,1,3cm,3cm); \stopuseMPgraphic

\starttext

\useMPgraphic{test}

\stoptext

Gives this error when compiled with:

texexec --pdf grid

(mpgraph.mp (C:\texmf\metapost\context\base\mp-tool.mp) (C:\texmf\metapost\context\base\mp-spec.mp) (C:\texmf\metapost\context\base\mp-grph.mp) (C:\texmf\metapost\context\base\mp-page.mp) (C:\texmf\metapost\context\base\mp-core.mp)

...

hlingrid

! Improper `addto'. <to be read again> withpen draw->...:also(EXPR0)else:doublepath(EXPR0)withpen .currentpen.fi._op_ <to be read again> ( l.221 draw hlingrid( 0,10,1,3cm,3cm); ?

Does anyone else get the same error after downloading and installing the latest version of Context?

Dear Gerben or Hans, I have been away on holiday. So I have lost the result of this thread. Have you or Hans solved this problem. If so, do I need to upgrade i-tetex or ConTeXt or both. I would really like to solve this problem and get back to standard ConTeXt fonts.

TIA

From: Hans Hagen pragma@wxs.nl At 00:05 07/08/2003 +0200, Gerben Wierda wrote:

...

Yes, this could be. If texexec or any ConTeXt tool does not use texmf.cnf values but has hardcoded ideas about where to find stuff (texmf), then the rearranging of the texmf directories could have an influence. Hans can probably say if this is possibly the case. After all, the rearranging had no ill effects whatsoever on TeX or LaTeX, because where files are is governed by texmf.cnf and that was adapted as well to reflect the changed situation. If there is hardcoded stuff in texexec that is playing a role (I am guessing here), making it dynamic by calls to kpsewhich is a good solution.

For the rest, the content of texmf.tetex is created by Thomas Esser, not me. And there you will find not a complete set of URW but an Adobe set and thatis what the discussion is also about. hans is right in stating that.

context can happily work in the texmf tree and does depemnd on its own trees; with regards to texfont:

• it will install in either texmf-fonts or texmf-local, depending on what

is present; the reason for having texmf-fonts is that we need a place for commercial fonts (and texmf-local is for my updates, local stuff etc)

• texfonts uses prefixed names (texnansi-* and alike) for several reasons:

(1) when i buy a font, i wan tto copy the fonts to some temp path, call texfont, and have the job done; i don't want to mess around with 8 char names that may conflict is i do something wrong;

• another reason for texfonts naming sheme of 'third party fonts' is that

when one starts slanting fonts (and alike) the kb naming sheme does not keep track of what slant is used, which in principle will lead to conflicts if one has multiple instances (wherever they may come from)

• for the same reason i keep separate map files for those third part

collections

• with regards to the fonts on tex live the confusion comes from the mix of

adobe names and urw type ones. So far whatever i made default, failed on someones system, which is why we have now type-akb for the mixed users

• also: context font mechanism is set up in a way that makes it possible to

combine fonts with minimal calls (once understood -), supporting relative scaling and alike; i don't want user sto be dependent on one (few) persons to define / install / use fonts.

...

If that is the case, texfont is a problem because it hard codes locations where texmf.cnf is the source for locations and kpsewhich is the way to find out about them.

afaik it uses kpsewhich an-r env vars and one can set things on the command line as well; there is not so much hard coded in there -)

Hans

Dear Patrick,

What are you trying to achieve?

I use Gerbens distribution of tetex and friends on Mac OSX. In Feb/Mar the distribution was altered which broke texfont. I had to resort to using adobekb.tex which works very well. I was hoping however at some point to be able to use the fonts in a more standard way with everybody else.

At 20:13 08/10/2003, you wrote:

Hi Nigel,

...

...

What are you trying to achieve?

...

I use Gerbens distribution of tetex and friends on Mac OSX. In Feb/Mar the distribution was altered which broke texfont. I had to resort to using adobekb.tex which works very well. I was hoping however at some point to be able to use the fonts in a more standard way with everybody else.

So what is wrong with adobekb.tex? It is now included in ConTeXt, so with \usetypescript[adobekb][someencoding] your psnfss fonts should work fine.

i can make a default for that but only when i can be absolutely sire that the metrics are there that i want there to be -)

Hans

At 11:00 09/10/2003, you wrote:

Hi,

Hans Hagen pragma@wxs.nl writes:

...

...

So what is wrong with adobekb.tex? It is now included in ConTeXt, so with \usetypescript[adobekb][someencoding] your psnfss fonts should work fine.

i can make a default for that but only when i can be absolutely sire that the metrics are there that i want there to be -)

According to to the statements from Walter Schmidt, a TeX font expert (perhaps I should say *the* TeX font expert?) in http://tug.daimi.au.dk/archives/tex-fonts/msg01328.html

\quote{% .... Note, however, that embedding of URW's fonts, while using the (PSNFSS) Adobe Base35 metrics, will _not_ lead to any bugs! The character metrics are matching! Differences in the "character bounding boxes" are irrelevant for the advance widths! The only drawback is, that you cannot access those glyphs that are in the URW fonts, but not in the Adobe fonts. Indeed, this could be overcome by providing particular metrics and VFs for the URW fonts -- see below. }

hm, there are more font experts (nelson b, boguslaw j, adam t, tom k, some people on this list as well, to mention a few), here is what Nelson Beebe says about this topic in a different thread ..

...

Walter confirms what I have assumed: we can use the "Adobe" metrics from the PSNFSS bundle with the URW fonts.

I have serious reservations about this.

While as far as I know, there has been only one release of URW fonts, and thus only one pair of (.pf[ab],.afm) files for each typeface, with Adobe fonts, over the last 19 years, there have been silent changes made to at least AFM files for many fonts, including Times-Roman.

This makes me suspect that the base-14 or base-35 fonts embedded in tens of millions of laser printers with Adobe PostScript implementations may in fact not be identical, even though they share common font names.

Of course, the changes are usually pretty small, and few people would ever notice. However, precise character positioning demands knowledge of metrics, and if a TeX job uses metrics which differ from those embedded with a font in a printer, and uses the resident fonts, rather than downloading them, then output will certainly not be what TeX (and the user) intended. That is one reason why I've never been entirely happy with fontless PostScript and PDF files, and why I was exceedingly unhappy with the change in Adobe Illustrator last year that completely ignores embedded fonts, and uses only installed fonts.

The program MIME-attached below can be used to compare AFM files, and I have just done so with the texlive7/texmf/fonts/afm/{adobe,urw}/times/*.afm files.

The first thing to note is that the URW fonts contain many more glyphs: 316 for Times-Roman compared to Adobe's 228. A TeX file that used any of the additional URW glyphs would print incorrectly with Adobe's Times-Roman.

The second thing is that the bounding boxes can be a bit different, and sometimes very different, even when the widths are identical:

% awk -f afmdiff.awk /tmp/afm/adobe/times/ptmr8a.afm /tmp/afm/urw/times/utmr8a.afm Comparison of AFM metrics in files: /tmp/afm/adobe/times/ptmr8a.afm /tmp/afm/urw/times/utmr8a.afm Font names: Times-Roman NimbusRomNo9L-Regu ... WX width differences:

Bounding box width differences: dagger -1 dieresis -1 dotaccent -1 exclam 1 exclamdown 1 Idieresis -1 idieresis 39 three -1 threesuperior -1

Bounding box height differences: Adieresis 1 adieresis 1 aring -10 Aring -17 asciitilde 6 dieresis 1 dotaccent 1 Edieresis 1 edieresis 1 exclamdown -2 greater -4 Idieresis 1 idieresis 1 less -4 Odieresis 1 odieresis 1 plusminus -62 q -1 questiondown -2 s 1 Udieresis 1 udieresis 1 Ydieresis 1 ydieresis 1

TeX uses more than just the bare width, so I suspect that we can readily demonstrate different typesetting with these two purportedly-compatible Times-Roman fonts from URL and Adobe. As a simple experiment, I created two DVI files with "tex testfont", like this:

% tex testfont This is TeX, Version 3.1415 (C version 6.1) (/usr/local/lib/tex/inputs/testfont.tex Name of the font to test = ptmr8r Now type a test command (\help for help):) *\table

*\bye [1] Output written on testfont.dvi (1 page, 10632 bytes). Transcript written on testfont.log. % mv testfont.dvi testfont-ptmr8r.dvi

and similarly for utmr8r. I then ran dv2dt on both, and compared the output:

% dv2dt < testfont-utmr8r.dvi > testfont-utmr8r.dt % dv2dt < testfont-ptmr8r.dvi > testfont-ptmr8r.dt % diff testfont-utmr8r.dt testfont-ptmr8r.dt 19c19 < (utmr8r) --- > (ptmr8r) 33,34c33,34 < d3 1518460 < d3 1911676 --- > d3 1512892 > d3 1906108 191c191 < fd1 50 24364160751 655360 655360 0 6 'utmr8r' --- > fd1 50 4767720433 655360 655360 0 6 'ptmr8r' 291c291 < d3 721220 --- > d3 715652 306c306 < sr 1016132 26214 --- > sr 1010564 26214 ... many more ...

Clearly, the DVI files differ somewhat.

I did similar AFM comparison experiments with the 3 other times fonts in TeXLive 7:

% awk -f afmdiff.awk /tmp/afm/adobe/times/ptmri8a.afm /tmp/afm/urw/times/utmri8a.afm % awk -f afmdiff.awk /tmp/afm/adobe/times/ptmbi8a.afm /tmp/afm/urw/times/utmbi8a.afm % awk -f afmdiff.awk /tmp/afm/adobe/times/ptmb8a.afm /tmp/afm/urw/times/utmb8a.afm

All had identical character widths, but many differences in bounding boxes.

Thus, I believe that it would be wrong to claim that the URW fonts are true drop-in replacements for the Adobe fonts, and of course there will be minor shape differences as well, some of which may be visible to sharp-eyed readers, at least in heading-size characters.

As an additional experiment, I ran the locate command on our large Unix installation, and found 64 instances of Times-Roman.afm. MD5 checksums of these files showed that there are only 7 different ones, so I ran the afmdiff.awk program on those 7. While there were no differences reported in character widths, there were many differences in bounding boxes and even in glyph counts (210, 228, and 315, depending on the file):

The copyright statements look like this:

Comment Copyright (c) 1984 Adobe Systems Incorporated. All Rights Reserved. Comment Copyright (c) 1984 Adobe Systems Incorporated. All Rights Reserved. Comment Copyright (c) 1985, 1987, 1989 Adobe Systems Incorporated. All rights reserved. Comment Copyright (c) 1985, 1987, 1989, 1990 Adobe Systems Incorporated. All Rights Reserved. Comment Copyright (c) 1985, 1987, 1989, 1990, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved. Notice Copyright (c) 1985, 1987, 1989 Adobe Systems Incorporated. All rights reserved.Times is a trademark of Linotype AG and/or its subsidiaries. Notice Copyright (c) 1985, 1987, 1989, 1990 Adobe Systems Incorporated. All Rights Reserved.Times is a trademark of Linotype AG and/or its subsidiaries. Notice Copyright (c) 1985, 1987, 1989, 1990, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved.Times is a trademark of Linotype-Hell AG and/or its subsidiaries.

All, I hadn't expected to create such a confusion so I will try to restate my problem.

On MacOSX Gerben has provided a restructured version of tetex where the locations of some files have changed. I am not sure of the detailed reasons for this but it certainly much easier to keep up to date. For instance he even provides an updater for ConTeXt to beta or standard using a single click (I only just found that! Thanks Gerben).

Now the line texfont --en=8r --ve=urw --co=courier --so=auto Should work but instead gives

TeXFont 1.8 - ConTeXt / PRAGMA ADE 2000-2003

processing aborted : unknown subpath ../fonts/afm/urw/courier

The subpath exists but maybe at a different root /usr/local/teTeX/share/texmf.tetex/fonts/afm/urw/courier thus I presume that --fontroot should be invoked especially since the help gives me --fontroot=path : texmf font root (default: /usr/local/tetex/share/texmf.local) So I try texfont --en=8r --ve=urw --co=courier --so=auto --fontroot=/usr/local/teTeX/share/texmf.tetex/ on one line of course

processing aborted : unknown subpath ../fonts/afm/urw/courier is the result.

The apparent error is that the --fontroot option doesn't work. Hopefully that is all I wanted fixed. Texfont has been upgraded with many new options but this 'bug' remains.

TIA

Why do you whish to reinstall all the supplied fonts? Or do you just want to learn how to use texfont?

I simply wish to use the fonts as most others do (I think) and I am unable to because of this bug. The normal context fonts do not exist on Gerben's version. Before Gerben's reorganisation they were made by texfont, this now does not work because of what I believe to be a simple (I do not understand Perl otherwise I would have a go at fixing it) bug in texfont. Maybe I am wrong but I am beginning to find this extremely frustrating (7 months). Once I realised that somebody was working on texfont 1.8 I had hoped for a fix.

If no developer/Perl expert has Gerbens version of tetex perhaps I could help debug if a version was supplied to me that printed out the full path that texfont was looking for files in. The --fontroot option or kpsewhich lookup appears to be at fault but I have no debugging facilities.

Any suggestions (other than giving up) gratefully received.

TIA

...

I simply wish to use the fonts as most others do (I think) and I am unable to because of this bug.

Nigel,

did you try

\usetypescriptfile[adobekb] \setupencoding [default=8r] \usetypescript[adobekb][\defaultencoding] \usetypescript[palatino][\defaultencoding] \setupbodyfont[palatino] \starttext This is crazy stuff. \stoptext

Yes this is the only thing I can do currently, but I thought I had more control previously.

??

...

The normal context fonts do not exist on Gerben's version.

What are normal ConTeXt fonts?

Say ec-urw-times and the typescripts etc.

...

Maybe I am wrong but I am beginning to find this extremely frustrating (7 months).

I know how frustrating fonts in TeX can be :-(