jas@ISI.EDU (Jeff Sullivan) (11/17/89)
I used to think that I knew why ATM wouldn't let you save the bitmaps created on the fly. Now I'm not so sure. The obvious argument was "so people don't steal the bitmaps," but this doesn't hold water. If people were going to steal from an ATM-equipped system, they could just as well steal the whole ATM setup, right? All ATM would have to do is check to see that ATM is running before allowing certain bitmaps (atm-created ones) to be used. Maybe store them in a special format so that ATM must be used to read them. This way, I could "install" the fonts, and ATM would check the first time I used them to make sure I was legit, then I wouldn't have to worry about rebuilding them if my queue got flushed, and I wouldn't have to allot a cahce (not queue) to keep them from flushing. For instance, there are certain fonts that I use in my letter head that I don't have in bitmap, so every time I bring up a new letter, they get created (pause), then when I'm playing around with other fonts, they get flushed. Bring up another letter (pause), etc. Another gripe/wish list would be a list of the fonts currently in the cache, the cache hit rate, and the ability to selectively flush the cache under user control. And to make it faster. And to support Type 3 fonts, or supply a conversion utility (even if it's not going to translate hints). -- -------------------------------------------------------------------------- Jeffrey A. Sullivan | Senior Systems Programmer jas@venera.isi.edu | Information Sciences Institute jas@isi.edu DELPHI: JSULLIVAN | University of Southern California
dpaight@HP-UX.ucsd.edu (Dan Paight) (11/17/89)
In article <10597@venera.UUCP> jas@ISI.EDU (Jeff Sullivan) writes: > > >This way, I could "install" >the fonts, and ATM would check the first time I used them to make >sure I was legit, then I wouldn't have to worry about rebuilding them >if my queue got flushed, and I wouldn't have to allot a cahce (not >queue) to keep them from flushing. For instance, there are certain Speaking of the RAM cache, just how does ATM handle it? What I mean is, does the program take whatever cache space is available, or does it leave some for other programs? It would be a shame if ATM rendered the RAM cache practically unavailable to other programs. Could I "tell" it to, say, take 96k for itself, but to leave another 64k for applications? If not, wouldn't it be better to store all of ATM -- fonts and all -- in the system heap and then make the amount of space ATM occupies configurable in a cdev or something? dp
allbery@NCoast.ORG (Brandon S. Allbery) (11/19/89)
As quoted from <2070@network.ucsd.edu> by dpaight@HP-UX.ucsd.edu (Dan Paight): +--------------- | Speaking of the RAM cache, just how does ATM handle it? What I mean | is, does the program take whatever cache space is available, or does | it leave some for other programs? It would be a shame if ATM +--------------- ATM uses its own cache, not the General CDEV RAM cache. ATM's cache size can be changed via the "~ATM" CDEV. BTW, to jas@ISI who asked about Type 3 fonts: Brian Beziaton pointed out that Type 3 fonts are pretty much general PostScript, so for ATM to handle them it would have to be a Display PostScript program and not just a font generator. That *is* asking for a bit much.... ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.