jeffhi@microsoft.UUCP (Jeff HINSCH) (03/04/91)
I've got a Nugen/480 that insists on searching for a given font in the following order: ROM, RAM, SCSI hard-disk. The problem arises when fonts with identical names (like zaph dingbats) are downloaded to the printer's hard-disk--the replacement font is never accessed because the ROM has a version of the font. I believe I need a replacement for findfont, but I really don't know where to start. The Nugen folks have been *less* than helpful. (Add'tnl background info: the built-in zaph is not adequate; because files come in from diverse sources (plus other reasons) creating new, unique font names is not feasible). Does anyone have a findfont replacement procedure that might be helpful (I can't find any examples in the std. books). My goal is to change the lookup procedure to: SCSI->RAM->ROM. Heartily grateful thanks in advance!
bcockburn@acorn.co.uk (Bruce Cockburn) (03/05/91)
Hi, An added bonus of a new font lookup might be a different substitution for unknown fonts (rather than Courier). For example if the font name requested is not found AND ends with "-Roman" then default to Times-Roman etc. Anybody got any ideas? Bruce.
rcd@ico.isc.com (Dick Dunn) (03/06/91)
bcockburn@acorn.co.uk (Bruce Cockburn) writes: > An added bonus of a new font lookup might be a different substitution for > unknown fonts (rather than Courier). For example if the font name requested > is not found AND ends with "-Roman" then default to Times-Roman etc. While my first reaction was "replace invalidfont to catch the error", this obviously doesn't work because the font name isn't handy. But you could easily replace findfont with an operator to do your substitution. If all your fonts are in the font directory, you can replace findfont completely...it would go something like (caution! untested code, for illustration only!:-): FontDirectory dup 2 index known { exch get % it's there; just return it } { pop % discard FontDirectory --have a look and wander around to find a substitute-- } ifelse If findfont does something more elaborate (e.g., if you've got fonts in more than one place), you probably want to hold on to the old findfont, and invoke it from your redefinition of findfont, then check to see if it gave you a Courier result; if so, attempt your own substitutions by modifying the font name and repeating the findfont attempt. This is sort of a sticky problem given the plethora of names used for related concepts in typography. For example, the "slanted version" in a family may be called Italic, Cursive, Oblique, or Slanted. The original posting involved a slightly different problem: Jeff Hinsch was trying to get the search order redefined so that a printer would find fonts downloaded to a printer's disk in preference to ROM fonts. This seems rather harder, because presumably the fonts on disk are not in FontDirectory (else, by the definition of findfont, they would take precedence). Jeff, or someone who's fighting that particular printer: Is findfont a procedure that you can unravel to find the separate steps? -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
pkr@media01.UUCP (Peter Kriens) (03/07/91)
> An added bonus of a new font lookup might be a different substitution for > unknown fonts (rather than Courier). For example if the font name requested > is not found AND ends with "-Roman" then default to Times-Roman etc. Is this serious? Who wants to do such a replacement "intelligence". The nice thing about Courier is the fact that it sticks out like a sore thumb wich forces your attention upon the problem. But an absent font is an absent font and with whatever you replace it, it will look horrible because widths will not match. Peter kriens pkr@media01.uucp
jeffhi@microsoft.UUCP (Jeff HINSCH) (03/09/91)
Strangely enough, the following
systemdict /findfont load type 20 string cvs ==
tells me that findfont is "operatortype" on the NewGen.
But on my LW IINT, findfont is "packedarraytype." I assume
that I can still replace the NewGen's findfont (since
showpage is operatortype on the NT), but I can't get the
NewGen's interpreter to enumerate the findfont procedure.
Is this true? Only arraytype and packedarraytype operators
can be "listed"?
Jeff Hinsch
--
{uunet, decvax, uw-beaver}!microsoft!jeffhirsmith@well.sf.ca.us (Ross Smith) (03/09/91)
rcd@ico.isc.com (Dick Dunn) writes: >The original posting involved a slightly different problem: Jeff Hinsch was >trying to get the search order redefined so that a printer would find fonts >downloaded to a printer's disk in preference to ROM fonts. This seems >rather harder, because presumably the fonts on disk are not in >FontDirectory (else, by the definition of findfont, they would take >precedence). Jeff, or someone who's fighting that particular printer: >Is findfont a procedure that you can unravel to find the separate steps? Here's a definition for the 'findfont' operator: % findfont definition in Qume ScripTEN version 47.0 /findfont { dup FontDirectory exch known { FontDirectory exch get }{ { dup type /stringtype ne { =string cvs } if print } exec ( not found, using Courier.\n) print flush FontDirectory /Courier get } ifelse } bind def Ross Smith rsmith@well.sf.ca.us {apple,pacbell,hplabs,ucbvax}!well!rsmith -- Ross Smith rsmith@well.sf.ca.us {apple,pacbell,hplabs,ucbvax}!well!rsmith