I have been watching this thread and meant to respond sooner. Any dvips which uses t1part for font subsetting is BROKEN with respect to font subsetting. Use the latest dvips from TeX Live 6.0, which uses the writet1 module from pdftex to take care of susetting.
There are other bugs in dvips with respect to font subsetting. In particular, one problems is that one cannot (usually) reencode a font multiple times and subset the PFB/PFA file sent to dvips. Tom Rokicki and I are aware of this problem and we will work on getting this fixed. The fonts that Vladimir asked me to look at are OK; the problem is with dvips. Tom On Wed, 10 Oct 2001, Harald Hanche-Olsen wrote: > + Rolf Niepraschk <[EMAIL PROTECTED]>: > > | Harald Hanche-Olsen wrote: > | [...] > | > <texc.pro><t1.enc><texps.pro>. <sfti0900.pfb> Second number not found in Char >string of '/FontName' > | > > | > | I have found a similar problem with dvips 5.86e and the brushscript font > | (the previous version). With > | > | ..> type1fix --infile=pbsi.pfa.orig --outfile=pbsi.pfa \ > | --kill-unenc=yes --ofmt=pfa > | ..> t1binary pbsi.pfa pbsi.pfb > | > | I have solve this problem. `type1fix' is a perl script from the TeXtrace > | package. May be this helps also with CM-Super... > > No, it didn't help. With --kill-unenc=yes it removed a bunch of glyphs > from the font file; and whether I included that or not, dvips failed > in the same way. > > + Nicolas Markey <[EMAIL PROTECTED]>: > > | Le 08.10.01, Harald Hanche-Olsen a écrit : > | > | > Just a quick question to you all: Did any of you successfully use the > | > CM-super fonts with teTeX 1.07 (or dvips 5.86)? > | > | I got the same problem; installing dvips 5.86d solves that problem. > > Well, Nelson Beebe did some extensive testing. With dvips(k) 5.86e, he > got these results: > > On linux: ok; on irix: segfault; on alpha/osf: 531 Subr not found. > The latter happened also with 5.86d. > > He also suggested trying t1disasm, t1binary, and t1ascii on the > fonts. They will work on the font files (well, I only worked on > sfrm1000.pfb) without complaint, and converting between format and > then back to pfb yields a file identical to the original. I also got > hold of Adobe's specifications, and can certainly see no lack of > compliance there. > > I know it's usually bad form to quote private mail in a public forum, > but this one from a mail exchange with Nelson Beebe sums up the > situation better than I could have stated it myself: > > + "Nelson H. F. Beebe" <[EMAIL PROTECTED]>: > > | You are right that dvips may well make assumptions about fonts > | that are unwarranted. This has been an ongoing problem, with > | Adobe's own TypeManager assuming more stylized formatting than > | Adobe's black-and-white book requires in its documentation > | of the Type 1 format. > > So, I guess the next step is to try to understand t1part.c and how it > fails on these font files. Then maybe the font files can be tweaked so > the problem does not happen, and an improved t1part.c might make it > into dvips in the long run. > > Please note that, as I no longer believe the dvips version is an > important factor in this problem, I think this discussion properly > belongs on the tex-fonts lists and should be discontinued on the teTeX > list. I have set the Reply-To header accordingly; override it only if > you must. > > - Harald >
