[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fontinst with 8y.etx



At 8:08 pm -0400 11/6/98, Berthold K.P. Horn wrote:
>Hi:
>
>At 04:11 PM 98/06/11 +0200, Thierry Bouche wrote:
[snip]

>>For instance: is there a way to combine LY1 & Melissa's Mac mods?
>
>AFAIK, Mellisa's `mods' are simply work-arounds for the limitations
>of Mac: problems due to not being able to access 21 of the 228 glyphs
>on the Mac (due to lack of ability to reencode fonts - somthing not
>fixed by VF, I hasten to add, because VF only `remaps').  So something
>has to be done to approximate lslash, ff, eth, thorn etc.

This is not a limitation of Macs, but a limitation of some software on Macs.

>>Well, does there exist something working proprely on unices, macoses &
>>windowses95-99/Nt?
>>Doesn't that whole question seem surrealistic to you, talking of some
>>_portable_ doc format???!!
>
>Well, I gather that some people on Unix are using LY1, as are some
>OzTeX users...

Some people have rings in their noses.  It doesn't make them particuarly
sensible.

(Note: this is a joke of sorts)

[snip]

>Not sure what that refers to.  Only CM and EM fonts use `non-rounded'
>numbers.  As for overhead, it took a few minutes to do all 2300
>fonts in the Adobe library, while I have heard R&R estimate 5min
>to 30min per font using fontinst...

That's on my obsolete 25MHz 68LC040 Mac, which has roughly the same
processing power as a 40MHz 80486SX PC.  30 minutes is nearer the time it
takes to run \latinfamily on a *typical* set of 4 afms; it's *very* much
slower if you have what spqr refers to as a `pathologically kerned' set of
founts.

There's no doubt that fontinst is slow, but on a modern computer, it's not
that much of a problem.  If you assume an average of 12 minutes per fount
on my computer (geometric mean of 5 and 30), and that you're using a modern
computer that's 100 times faster than my 1993 Mac, it'll take:

2300 x 12min / 100 = 4.6 hours

to process the whole lot with fontinst.  It might be that that estimate is
flawed in some way.  Even if I'm out by an order of magnitude, that's still
less than 2 days to process the whole lot.  Slow, yes; but not
impractically slow.

>>but y&y doesn't put its ton of LY1 TFMs on CTAN, and they don't
>>conform to karl berry names?
>
>You can happily take the TFM files now on the Y&Y web site and port
>them to CTAN.  As for Karl Berry names: more than half of those fonts
>don't have Berry names (and this is just the Adobe Type Library),
>and in some cases it wasn't clear what some fonts were called. So it
>was easier to organize the files on the names given by Adobe.
>It would be easy to extract those that have Berry names and rename
>them, given that the HTML table has both names (and more) listed.
>But what do you do with the rest?
>
>Since few people are now stuck on 8+3 platforms, maybe it is time to
>forget this.

I'd say not: the 8+3 filename limit applies to ISO9660 CD-ROMs, as well as
MS-DOS.  MS-DOS is still widely used, especially in `developing nations'
which have plenty of obsolete computers still in use.  I wouldn't be happy
with excluding people just because they happen to live in the `wrong'
country.

And please note that I have frothed at the mouth in a screaming fit at the
horrible things I've had to do to filenames before uploading packages to
CTAN (download my rmpage package and search for `Gates' if you want to read
several looney rants about this); I dislike this limit, but I think that it
does make sense to stick with it for the foreseeable future.

>  We could use PS FontName as the TFM file name,
>or, since those can get rather long, use the Mac 5+3+3+...
>contracted names, which are unique also (or supposed to be anyway
>- for otherwise the font cannot be used on the Mac).

To be more specific: or else the fount can't be used on Macs running mfs or
hfs.  hfs+ can handle longer filenames as far as I know, but it's hardly
widely used.

[snip]

Rowland.