Hello, On Mon, 10 Feb 2003, Hans Hagen wrote:

At 12:58 PM 2/10/2003 +0100, Maarten Sneep wrote:

...

``Welcome to typeface hell'', describes my feelings correctly. I'm trying to use the free postscript fonts that come with teTeX (urw palatino, times, helvetica, courier and various others, you know the list) in ec encoding.

I thinks I followed the instructions correctly, but still no luck. I'm using teTeX 2.0 with the TeXLive binaries (the ``Gerben Wierda'' distribution) on Mac OS X 10.2.3 (Jaguar). The frustrating bit is that in LaTeX everything comes preconfigured, but for ConTeXt I have to do it myself. I also use this as a testcase before buying the lucida typefaces (I want to be very sure I can install my fonts before shelling out the money).

Here's a summary of what I've tried and noticed:

1 - I've used texfont on the type-ftm.dat file in the default installation of the distribution. This fails, because the ec.enc file isn't found. This seems correct, as it is named EC.enc (note that this is on hfs, a case insensitive system). I renamed the file to ec.enc and tried again.

strange, i noticed some problems with the texnansi vector (different versions) btu not with ec

I just checked a recent version of SuSE linux (8.1), which still uses a beat of teTeX 2, where I find ./dvips/base/EC.enc in the texmf tree.

...

2 - This time the encoding vector is found, and some files are generated. However I get a nice bunch of rectangles, I assume mean that some glyphs are missing. In fact I think the only glyphs that showed up are `borrowed' from Computer Modern.

are you sure that you said \useencodign [ec] ?

Where should I have said that? (so apparently I didn't follow the instructions...)

...

My direct questions: a - Did anyone succeed in using the free postscript fonts on Mac OS X, using a distribution that I use (i.e. the most recent version)

all these fonts should work ok, did you try

\usetypescript [berry] [ec] \setupencoding[default=ec]

I'll try again this evening. What should be the extra command for using the standard postscript fonts, is that still \setupbodyfont[pos,10pt]?

...

c - Did you experience the same EC.enc vs ec.enc naming problem?

this is new to me, in my opinion all filenames should be lowercase

There is an cork.enc file. Since the ec encoding is also known as the Cork encoding, this might be something. It seems to be something in the new teTeX, unrelated to the Mac.

...

d - Do other platforms have the same problems with teTeX 2.0 (Hans: What version of teTeX are you using on your linux system, since at your place it obviously works ;-)

tex live

but, there are mac users on this list so ...

I'll wait and see if some of them show up.

On Monday, February 10, 2003, at 07:42 AM, Hans Hagen wrote:

...

d - Do other platforms have the same problems with teTeX 2.0 (Hans: What version of teTeX are you using on your linux system, since at your place it obviously works ;-)

tex live

but, there are mac users on this list so ...

I haven't tried to use these in awhile, but I recall having similar problems. All the files are there for LaTeX support, so I had hoped to see a ConTeXt typescriptfile and maybe some environment files to access the fonts. Bruce

It seems that a number of .map files (ec-...) are missing on Mac OS X. It is my understanding that these should have been generated during the initialization of the texmf tree? If this is indeed the case, then Gerben Wierda no doubt issues a quick fix. Harri Hakula On Tuesday, February 11, 2003, at 03:29 PM, Maarten Sneep wrote:

Thanks to all who replied. I still didn't have any luck. I do have a longer log-file for anyone interested in helping further. It seems slightly specific to Mac OS X, so I'll post to that list as well.

Thanks,

Maarten Sneep

On Tuesday, February 11, 2003, at 03:32 PM, Patrick Gundlach wrote:

All TeX-systems that I have seen so far (not very many I have to admit) use virtual fonts to map from ec to 8r. There was no need so far for a map file with ec support. Doesn't Gerben's iinstaller-based TeX system provide the ec virtual fonts?

Here's what I see when I run the file you posted: pdftex : needs map file: original-ams-cmr.map pdftex : needs map file: original-ams-euler.map pdftex : needs map file: ec-adobe-utopia.map pdftex : needs map file: ec-bit-charter.map pdftex : needs map file: ec-public-antp.map pdftex : needs map file: ec-public-antt.map pdftex : needs map file: ec-urw-bookman.map pdftex : needs map file: ec-urw-courier.map pdftex : needs map file: ec-urw-helvetica.map pdftex : needs map file: ec-urw-palatino.map pdftex : needs map file: ec-urw-times.map pdftex : needs map file: ec-urw-zapfchan.map pdftex : needs map file: original-youngryu-px.map pdftex : needs map file: original-youngryu-tx.map pdftex : needs map file: ec-bh-lucida.map I don't really know what's going on, but the above map file names are not what I'd expect to see if I ran a similar file in LaTeX. Bruce

At 10:34 PM 2/11/2003 +0100, Patrick Gundlach wrote:

"Bruce D'Arcus" writes:

Hello Bruce,

...

Here's what I see when I run the file you posted:

pdftex : needs map file: original-ams-cmr.map pdftex : needs map file: original-ams-euler.map pdftex : needs map file: ec-adobe-utopia.map pdftex : needs map file: ec-bit-charter.map

[...]

now that you say this... I usually ignore these messages. They always

no problem, they're just a warning that in case you don't have some global file (as you have) you should use these

show up but the fonts work well here. This is because I use the original map files that are shipped with texlive7 that have the mappings like

ptmr8r Times-Roman "TeXBase1Encoding ReEncodeFont" <8r.enc

already built in. Along with the virtual fonts (ec to 8r encoding) and these map files, there should not be any problem!

although ... here i prefer cleaned up files, name

...

I don't really know what's going on,

neither do I ;-)

just a warning

...

but the above map file names are not what I'd expect to see if I ran a similar file in LaTeX.

Right. LaTeX does not use the run-time loading of mapfiles.

here i've split up the files (otherwise they become anoyingly large) (actually, this is why latex pdftex people have proposed to patch pdftex, because it's so slow on the large map files, something i never noticed since i use small ones -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

Don't know what is slow for your PC. I'm just looking into pdftex mapfile.c, and there is in line 142 a for-loop for checking duplicate mapfile entries (tfm). This runs some 3000*0.5*3000 times for parsing your mapfile lines, always checking for some strcmp() == 0. You can speed this up if you put a line "if (*(e->tfm_name) != *buf) continue;" into the begin of the for-loop (you need braces then!). Then the loop goes to the next map line already, if the 1st letters do not match. I have generated some 3000 random mapfile entries for testing (letters equally distributed). time pdftex on an almost empty TeX file "A \bye" tells: without patch real 0m1.463s user 0m1.370s sys 0m0.020s with patch checking inequality of 1st letters real 0m0.990s user 0m0.880s sys 0m0.030s So there might be some corner for improvement. Using strcmp() the reverse way seems not to speed up things; how to write a more sophisticated inequality-checker? Greetings Hartmut On Tue, 11 Feb 2003, Patrick Gundlach wrote:

Hans Hagen writes:

Hello out there,

...

...

Right. LaTeX does not use the run-time loading of mapfiles.

here i've split up the files (otherwise they become anoyingly large) (actually, this is why latex pdftex people have proposed to patch pdftex, because it's so slow on the large map files, something i never noticed since i use small ones -)

If I remember correctly there was a sub-optimal sorting algorithm used. With 3000+ lines in my mapfile this is getting very slow :( And even in tetex 2.0 this is (as I have heard) not fixed.

Patrick

At 08:53 AM 2/12/2003 +0100, you wrote:

Hartmut Henkel writes:

Hello Hartmut,

...

Don't know what is slow for your PC.

at least two seconds just for the map file.

...

I'm just looking into pdftex mapfile.c, about 2and there is in line 142 a for-loop for checking duplicate mapfile entries (tfm). This runs some 3000*0.5*3000 times for parsing your mapfile lines, always checking for some strcmp() == 0. You can speed this up if you put a line "if (*(e->tfm_name) != *buf) continue;"

But this also looks like O(n^2) to me. With 3000*3000 is some 9 million!

...

So there might be some corner for improvement. Using strcmp() the reverse way seems not to speed up things; how to write a more sophisticated inequality-checker?

Heiko stated that he used a hash table for this. This will speed up things dramatically.

but if i remember right he only looked at the first 8 chars (assuming berry) which is not that useful for texnansi-* files -) the best way (imo) is to let later entries overload previous ones, so not much checking is needed at all;

But this is getting slightly off topic, isn't it?

future versions of pdftex will solve this problem; another thing is reading map files after the first page is shiped out; that would permit us to postpone map file loading and speed things up a bit; currently, if you want to use a specific font on page 328 you must make sure that the associated map file is loaded before page 1 is finished! Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

At 03:07 PM 2/12/2003 +0100, you wrote:

On Wed, 12 Feb 2003 09:09:31 +0100 Hans Hagen wrote:

...

At 08:53 AM 2/12/2003 +0100, you wrote:

...

Hartmut Henkel writes:

...

...

...

So there might be some corner for improvement. Using strcmp() the reverse way seems not to speed up things; how to write a more sophisticated inequality-checker?

Heiko stated that he used a hash table for this. This will speed up things dramatically.

but if i remember right he only looked at the first 8 chars (assuming berry) which is not that useful for texnansi-* files -)

the best way (imo) is to let later entries overload previous ones, so not much checking is needed at all;

I remember this discussion on the pdftex-list and can still not understand why we should look for overloaded entries. pdftex should take the first match.

no, the last one, since users may want to overload the defaults (quite important if you use pseudo caps/slant/extend) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

At 04:56 PM 2/13/2003 +0100, you wrote:

i see its importance and i have nothing against overloading defaults. I mean that the overloading should not work in the way that an later entry replaces a prior entry, instead the map-files that contain

well, in my opinion overloading means that later entries overload prior ones; also, because \pdfmapfile adds to the end of the "files to load list" thsi is the only way to overload. same as in tex, you would be surprised if your \def\blabla{something} would not work because \blabla is already defined. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

Maarten Sneep writes: Hello Maarten,

...

Oh you don't need to reinstall your fonts! The TeX font files already a complete mess in an average TeX distribution. No need to increase this mess.

But how do you then generate the virtual fonts, or is there some trick in the map files to reencode on the fly?

For the basic fonts: they are shipped with the TeX system. For the additional fonts: fontinst (I don't like it very much) afm2tfm (don't rename your files). There are others out there. Siep has once written a replacement for afm2tfm (which I still have to test) and there is autofont.

But at some point the ec.enc file must be read...

Only when creating vf's. Patrick

Jens-Uwe Morawski writes: Hello,

The VFs are provided by the Latex PSNFSS system. Thus, if you don't select LaTeX support during TeXLive installation the VFs will not be installed. Maybe this is the case in other distributions as well.

Uh, that is a good point. Thanks for the hint. Patrick

Thanks for the advice. No luck yet. Thanks for the diff, I don't think it should make a lot of difference. I'll check with the texfont manual, I think the encodings are displayed there. (what does an /ldot look like anyway :-) On Monday 10 February 2003 15:30, you wrote:

Maarten Sneep said this at Mon, 10 Feb 2003 12:58:39 +0100:

...

a - Did anyone succeed in using the free postscript fonts on Mac OS X, using a distribution that I use (i.e. the most recent version)

Yes, but noy , I did with TeXLive7 on MacOSX, at least, which is a superset of GW's distro.

With some bugfixes: bitsream is correclty named.

...

b - What were the exact commands that you used? Can you send me a simple test file?

The key thing for me (perhaps obvious to others) was making sure the source font tree was in the same place as the destination tree, so...

texfont /usr/local/teTeX/texmf/context/data/type-tmf.dat --en=texnansi --fontroot=/usr/local/teTeX/texmf-local --install --makepath

I tried this on the main texmf tree (which makes sure that the source and dest are the same).

...

c - Did you experience the same EC.enc vs ec.enc naming problem?

I used the Hans-suggested texnansi encoding, which may have helped. I did a diff between GW/tetex2.0's new EC.enc and the older ec.enc. Just one line different: diff texmf/dvips/base/ec.enc share/texmf/dvips/base/EC.enc 67c67 < /ldot /zacute /zcaron /zdotaccent /ij /exclamdown /questiondown /sterling ---

...

/ydieresis /zacute /zcaron /zdotaccent /ij /exclamdown /questiondown

/sterling

Thanks.

...

d - Do other platforms have the same problems with teTeX 2.0 (Hans: What version of teTeX are you using on your linux system, since at your place it obviously works ;-)

I compiled the teTeX binaries myself and overlaid them on top of my TeXLive tree. Only my MP graph problems so far suggest it might not have been the best idea. :) I haven't dealt with the rest of the teTeX 2.0 tree, yet.

That's funny: Gerben uses the other combination: binaries from texlive, texmf tree from teTeX and some additions on top. Kind regards, Maarten Sneep