Xref: utzoo comp.lang.postscript:836 comp.fonts:280 Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bgsuvax!edwards From: edwards@bgsuvax.UUCP (Bruce Edwards) Newsgroups: comp.lang.postscript,comp.fonts Subject: Re: PostScript compatible printers Summary: FONT SERVERS QUESTION Message-ID: <2735@bgsuvax.UUCP> Date: 9 Aug 88 05:35:50 GMT References: <5122@gryphon.CTS.COM> <1777@imagen.UUCP> <4145@adobe.COM> Organization: Bowling Green State University B.G., Oh. Lines: 98 In article <4145@adobe.COM>, greid@ondine.COM (Glenn Reid) writes: > > > > > Read the red book. The format of the font files is not specified. In > > fact, it is not even specified that outline fonts have to be used at > > all. I think Courier (an ADOBE font) is in fact a 'stroked font', I don't know of any other 'stroked fonts' by ADOBE. BTW is there a reason for this and does Courier by its uniqueness become a 'toothache-of-a-font' because of it? > > The PostScript language (as specified in the "red book") has very > specific mention of fonts and their format; it is chapter 5 in my > book. Basically, fonts are dictionaries with very specific contents > intended for use by the font machinery. This is all documented. > > Adobe downloadable fonts simply will not download into a printer which > cannot decrypt them. If the "eexec" operator is not present (or if it > is not functional) the font programs will not execute correctly. Other > downloadable fonts, however should (in theory) work correctly. How much interpreter overhead goes into decryption in comparison to a non-ABOBE font? I'm not being troublesome...just curious ;-) > > Any font program can be stored on a printer's disk as a downloadable > font program, and in fact Adobe's downloader checks to see if your > printer has a disk and lets you download it there if it does. They > might also be available out on the network on a font server, available > dynamically when "findfont" is executed. Where the font "lives" is > not really an issue, only whether they are available at all, and > whether or not they execute successfully. Our graphic arts department consists of 9 Mac SE's, an LW+, and a L-300. Each SE has a 20 meg internal hard disk. We use a relatively large number of fonts in producing custom labels and price marking products. These fonts 'exist' in three places in my understanding. 1) Bit mapped representations are installed in the SYSTEM Question: Does the new FOND type resource allow you to have only one point size installed without loss of screen appearance? This in contrast to the way we now are set up with several point sizes installed for each font? 2) 'Printer' fonts dragged to the SYSTEM folder from the font release disks so they can be 'called up' by an application for downloading. 3) Pre-rasterized versions installed on the L-300 harddisk Question: Why do we need the printer fonts in each SYSTEM folder if they are _there_ on the L-300 harddisk? Question: Assuming we do need them in _a_ SYSTEM folder. Could they be in a volume say, published on TOPs and when a station needed them could they be routed through LocalTalk to that station? i.e. Is a 'font server' product available which will allow me to keep all my 'printer font' files in one place? As it is now over 3 meg on each station harddisk is sucked up by the 'printer font' files. It is very annoying and seems redundant in light of LAN capabilities and/or the answer to number 3 above. (sorry if this seems a bit muddled, but I'm a bit fuzzy on the mechanics of it all). To clarify a point, why can't the application interogate the harddisk on the L-300 first and say 'Hey, I got it already on the disk, who cares what's in YOUR SYSTEM folder.'? All the MAC wants is the 'bit maps' for screen representation it's the printer that wants the PS, and its got 'um? Right? I should be able to empty everybody's SYSTEM folders of all those redundant files (but why do I suspect I'm mistaken...;-) The only reason I can think of to keep them around is for the LW+ when we proof to it, but that could be on one machine strictly for proofing. I know this is very long winded but its worth roughly 27 meg of work space to me. > > Glenn Reid > Adobe Systems Incorporated (Another unrelated item which you might route to the appropriate person. I understood ADOBE was coming out with an OCR-B. In fact I'm a beta test site for it. I've written a program which produces bar codes as double- clickable Illustrator files which we then build labels around. The problem is I have to use Helvetica for human readable text. According to UPC specs the font should be OCR-B. Any movement here? ) Thanks for any help. Disclaimer: I am participating as a guest of Bruce Edwards. My name is Ken Jenkins. Bruce is generally amused with my ramblings but does not necessarily agree with them. 'These are only the shadowlands.' C.S. Lewis ----------------------------------------------------------------- Ken Jenkins as guest of edwards@bgsu CSNET: edwards@bgsu ARPANET: edwards%bgsu@csnet-relay UUCP: cbosgd!osu-cis!bgsuvax!edwards -----------------------------------------------------------------