Re: CM-Super font package v0.2.0
On 2001-10-14 12:03:15 +0200, Berthold Crysmann wrote: on CTAN anymore. Is there a way around downloading an entire TeX-Live image, if the only thing one needs is dvips 5.86d ??? DANTE members just got the latest TeXlive cd. :-) Best regards Martin -- http://www.tm.oneiros.de/calendar/2002/
Re: CM-Super font package v0.2.0
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. -- Nico
Re: CM-Super font package v0.2.0
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.prot1.enctexps.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
Re: CM-Super font package v0.2.0
+ Rolf Niepraschk [EMAIL PROTECTED]: | Harald Hanche-Olsen wrote: | [...] | texc.prot1.enctexps.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
Re: CM-Super font package v0.2.0
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)? The font files seem to confuse the heck out of this version of dvips. Since Vladimir runs dvips 5.86d and is unable to reproduce my problem, it is my conjecture that it is indeed my older dvips that is at fault - but I would like to have that confirmed or disproved before deciding what to do next. Below are two sample runs. The first one is from a document I have, the other from running tex testfont on ecrm1000: ; dvips -Pcm-super -o test.ps froberg This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2001.09.22:1558' - test.ps texc.prot1.enctexps.pro. sfti0900.pfb Second number not found in Char string of '/FontName' At this point, dvips just stopped, producing no further output. ; dvips -Pcm-super testfont This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2001.10.07:2224' - testfont.ps texc.prot1.enctexps.pro. cmtt10.pfbsfrm1000.pfbcmti10.pfbcmti10.afmThis is DVIPS, t1part module cmti10.afm: No such file or directory Warning: after loading AFM file only 0 chars found instead 135981465 for cmti10.pfb cmr10.pfbcmr10.afmThis is DVIPS, t1part module cmr10.afm: No such file or directory Warning: after loading AFM file only 0 chars found instead 135981465 for cmr10.pfb cmr7.pfbcmr7.afmThis is DVIPS, t1part module cmr7.afm: No such file or directory Warning: after loading AFM file only 0 chars found instead 135981465 for cmr7.pfb [1] So this one actually produced some output, only missing the glyphs from the fonts mentioned after sfrm1000 in the dvips run. And in case you wonder about my file config.cm-super used in these runs: o p +bsr.map p +bsr-interpolated.map p +hoekwater.map p +cm-super-t1.map p +cm-super-t2a.map p +cm-super-t2b.map p +cm-super-t2c.map p +cm-super-ts1.map p +cm-super-x2.map Any ideas? (I did RTFS a little bit, but the code in t1part.c, where all this seems to happen, takes too much work for me to figure out right now. I'll do it if I have to, of course, but hope to avoid it.) - Harald
Re: CM-Super font package v0.2.0
i've put the new version of CM-Super package (two days ago) to ftp://ftp.vsu.ru/pub/tex/font-packs/cm-super/ you could try the mirror if connection to vsu.ru is slow: ftp://ftp.chg.ru/pub/TeX/RussianSupport/font-packs/cm-super/ Changes from previous version: * Changed license from Aladdin Free Public License (AFPL) to GNU General Public License (GNU GPL). That license would allow to be included in any (te)TeX distribution. Good. BTW. Since you used TeXtrace, and FontLab, I would like to point out about MF - Type1 conversion. There is another tool (although it has several restrictions) called mf2pt1 (on CTAN:support) allowing such kind conversion (resulting is more precise than tracing [although has overlaps] because has fewer nodes, and thus files shorter), and there is also a freeware font editor, called PfaEdit, at http://pfaedit.sourceforge.net, which has TWO interesting features: - 'Simplify': simplify the fonts reducing the number of unneeded nodes, make PFB file shorter. - 'Remove Overlap': remove overlaps in font paths. The second question is. Is there a table about choosing the UniqueID to be used for each of the Metafont fonts converted to PFB? If not how about to write one? Bye. Giuseppe.
Re: CM-Super font package v0.2.0
At 11.42 +0200 2001-09-24, Giuseppe GhibÚ wrote: The second question is. Is there a table about choosing the UniqueID to be used for each of the Metafont fonts converted to PFB? If not how about to write one? I don't think that's a kosher idea. UniqueIDs exist to help a PS printer cache the result of rendering a font. Since MF - PFB is not one-to-one, but in general one-to-many as some fonts have been converted several times, such a table would assign the same UniqueID to different PFBs. If you use the same UniqueID for a cheapo and a luxo conversion of the same font then you may find that the printer is using the cheapo conversion throughout, when that happens to be what got put in the cache. Furthermore the UniqueID is an optional entry in the font; what you may loose by not having it is merely some processing efficiency. Lars Hellström
Re: CM-Super font package v0.2.0
GG == Giuseppe Ghibò writes: GG BTW. Since you used TeXtrace, and FontLab, I would like to point GG out about MF - Type1 conversion. There is another tool (although GG it has several restrictions) called mf2pt1 (on CTAN:support) GG allowing such kind conversion (resulting is more precise than GG tracing [although has overlaps] because has fewer nodes, and thus GG files shorter), yes, i know about mf2pt1, and it could not convert arbitrary METAFONT fonts, because it uses METAPOST (which does not support some features of METAFONT). GG and there is also a freeware font editor, called PfaEdit, at GG http://pfaedit.sourceforge.net, which has TWO interesting GG features: GG - 'Simplify': simplify the fonts reducing the number of GG unneeded nodes, make PFB file shorter. GG - 'Remove Overlap': remove overlaps in font paths. i used FontLab to simplify (optimize), remove overlaps, and autohint the fonts. i'm not sure that PfaEdit will give better results than FontLab. The current fonts are already quite short, e.g. they are about the same size as commercial Type 1 EC fonts provided by Micropress, Inc. This comparison was made on fonts which contain only glyphs from EC fonts, because CM-Super fonts contain much more glyphs than fonts from Micropress. And there are possibilities to make the fonts even more short, which will be used in next versions: move definitions of glyphs with the same shape into subrs, and construct accented glyphs from non-accented and accents via subrs. GG The second question is. Is there a table about choosing the GG UniqueID to be used for each of the Metafont fonts converted to GG PFB? If not how about to write one? I'll add such a table. Best, v.
Re: CM-Super font package v0.2.0
yes, i know about mf2pt1, and it could not convert arbitrary METAFONT fonts, because it uses METAPOST (which does not support some features of METAFONT). of course it is not a total automatic tool (and in most case it is giving glyph totally messed up, if not converted at all), but it could be interesting to obtain more precise glyphs (or a set of them). On the other hand a big set of glyps replicated on various CM/EC, etc. fonts in the same way, as they are derived from Knuth ones. So the glyphs in Type1 should be always the same. Currently with t1asm/t1disasm it should be not much difficult to extract these glyphs (of course in a semi-automatic way) and combine them into arbitrary fonts to have a precise conversion for EC, etc. For instance see at the attached file: A.gif. Look at the A converted with TeXtrace. On the right, you'll see some distortion (the straight segment show this). On the other attached file you'll see the differencs in node numbers between a A converted with mf2pt1 (left) and yours with TeXtrace (right). i used FontLab to simplify (optimize), remove overlaps, and autohint the fonts. i'm not sure that PfaEdit will give better results than FontLab. Well, FontLab is commercial, while PFAEdit is free and it is getting better and better. Furthermore on font sfrm1000.pfb I achieved a +8-10kb shorter PFB file. Bye. Giuseppe A.gif mf2pt1-textrace.gif
Re: CM-Super font package v0.2.0
On Mon, 24 Sep 2001, Lars [iso-8859-1] Hellström wrote: At 11.42 +0200 2001-09-24, Giuseppe GhibÚ wrote: The second question is. Is there a table about choosing the UniqueID to be used for each of the Metafont fonts converted to PFB? If not how about to write one? I don't think that's a kosher idea. UniqueIDs exist to help a PS printer cache the result of rendering a font. Since MF - PFB is not one-to-one, but in general one-to-many as some fonts have been converted several times, such a table would assign the same UniqueID to different PFBs. If you use the same UniqueID for a cheapo and a luxo conversion of the same font then you may find that the printer is using the cheapo conversion throughout, when that happens to be what got put in the cache. Furthermore the UniqueID is an optional entry in the font; what you may loose by not having it is merely some processing efficiency. Well, I talked about UniqueID in general, not about SuperFont specifically. The idea is to have this UniqueID to avoid this, i.e. to avoid 27 kind of Type 1 conversion of the same fonts (of course not considering the commercial ones which are not freely downloadable). In other word to have (in the free fonts) only ONE official conversion to Type-1 of the same Knuth, EC, etc. MetaFont fonts. Up to not much time ago, the only free fonts available in Type 1 were the BlueSky set of CMR/AMS (which were not covering all the sets), and which were integrated on many TeX distributions, such as teTeX, by some font from the Bakoma free set, some fonts converted by TacoHoekwater (with MetaFog, if I remember right), and not much time ago the TX/PX fonts. Today with the availability of TeXtrace, mf2pt1, and PFAEdit, I think the number of free converted fonts availabile in Type1 format (which is a must for PDF files) is growing (for instance recently someone used TeXtrace for converting MusiXTeX fonts to Type1), so possible there should be a co-ordination to avoid overllaping and to do the same job twice. Bye. Giuseppe.
