earleh@dartvax.UUCP (Earle R. Horton) (08/24/87)
I am currently attempting to write a Printing Manager for use with the Macintosh and letter quality daisy wheel printers. I have some problems with the documentation and with details of implementation, however. For example, what is my printer driver supposed to do when it receives a control or status call which it does not support? This is not at all obvious. When I am doing draft mode printing, I have to supply a GrafPort. It is not at all clear to me what goes in the portBits.baseAddr field of this GrafPort (nil, or what?) when using draft mode printing. The function PrOpen is supposed to "prepare the Printing Manager for use. It opens the Printer Driver and the printer resource file." Exactly whose responsibility is this? Will my printer resource file be open when my driver receives its first open call, or am I to assume it is not, and open it myself? There are fields in the TPrPort data structure that are "for internal use only". Are these fields reserved for use by Apple, or do I get full access to them? It is not very clear how I am supposed to fill in the font characterization table for the Font Manager when I receive a control call with csCode = iFMgrCtl. This is not an exhaustive list, of course. I could, of course, obtain the answers to these and many more questions by resorting to use of MacsBug. It would be nicer, however, if Apple or someone at Apple would take the time to provide the information necessary to write a Printer Manager, in a more digestible form than currently exists. The information I really want is certainly of the type which is not made public (i.e. source code for ImageWriter driver), but there must be some way Apple could find to help out those who want to write serial printer drivers. (Especially since they do not support a large number of serial printers themselves.) Inside Macintosh, Promotional Edition: "an application uses the same routine calls to print with all varieties of printers." ^^^ Apple: **SYNZR BA** Gunaxf sbe gur rkgrafvir qbphzragngvba ba ubj gb qb guvf cebcreyl. V qb abg zvaq gung gur cevagre vagresnpr pbqr vf pbzcyvpngrq naq uneq gb jevgr, orpnhfr V frr gung vg vf hygvzngryl gb gur hfre'f orarsvg, naq nyfb nyybjf sbe pbzzhavpngvba jvgu znal qvssrerag glcrf bs qrivprf. Jung V qb zvaq vf gung gur qbphzragngvba ba ubj gb jevgr gur pbqr sbe gur cevagre erfbhepr svyr vf fxvzcl naq nccrnef gb or jevggra va nf bofpher n snfuvba nf cbffvoyr. V fhccbfr vs V unq jevggra DhvpxQenj zlfrys, gura gur jubyr guvat jbhyq or boivbhf gb zr. Ubjrire, V qvq abg, naq vg vf abg, naq V nz ernyyl gvpxrq bss nobhg guvf. **SYNZR BSS** -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
jww@sdcsvax.UCSD.EDU (Joel West) (08/26/87)
Apple has diminished the printer documentation over time
because it was obvious that the initial Printing Manager
interface was not well-designed and they wanted to
change it. (PrGeneral, for example, is a great step
in the right direction.)
Once it stabilizes, one can hope it gets the appropriate
IM treatment. If not, in the real world, we can always
DumpCode the ImageWriter and LaserWriter files and keep
our fingers crossed.
Joel West (c/o UCSD)
Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083
{ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edu
or ihnp4!crash!palomar!joel joel@palomar.cts.com
(Please don't ask about the printer driver article I promised to write)earleh@dartvax.UUCP (08/29/87)
In article <3727@sdcsvax.UCSD.EDU>, jww@sdcsvax.UCSD.EDU (Joel West) writes: > Apple has diminished the printer documentation over time > because it was obvious that the initial Printing Manager > interface was not well-designed and they wanted to > change it. (PrGeneral, for example, is a great step > in the right direction.) > This is true. I actually have parts of my daisy-wheel printer driver working at this point, and all I have to say about the people who designed the original interface is "nffubyrf!" I must admit, however, that the PACK resource (-4096) which interacts with the Chooser was particularly easy to write, and performed to specifications. There is one problem with that, however. The Chooser insists on disabling the left button in the display, but lets me use the right one. The one I want is obviously the left button, since that is the one that gets highlighted. I am not using any List Manager stuff, I just want the left button. It's annoying to see it come up enabled, but then get disabled right away. The problem is this: I want to write something which works with, say MacWrite and my Tandy printer, and I want to write it NOW! I don't want to buy a commercial product, and I don't want to have to use Microsoft Word (which doesn't work with my printer anyway.) I don't want to wait until the Printing Manager is rewritten in a reasonable manner, since that may be never. Can you imagine Apple coming up with an easy to understand interface, thereby breaking every program which prints? Therefore, what I want is an explanation of how the printing manager responds to calls, and exactly what it is supposed to do and when. For instance: I have stubs installed for all the QuickDraw calls for draft printing. I have the Style and Job dialog code completed according to the specifications in Technical Note 95. I have the driver complete, except I don't know how to implement PrGeneral, since I don't know how it gets called. (Is it a control call, or what?) According to the documentation, when I request an application to print or page setup, it should just think it is doing so, handle the dialogs, and produce nothing. When I select "Page Setup..." from the Finder menu, it says "Can't Print with this disk" but it does go through my style dialog no problem. How does it know it can't print with this disk? When I go through my Job dialog, it says the same thing, but it calls my Job dialog handler and then calls my PRINTING stubs if I click OK. It puts the "printing now" dialog box on the screen, and calls my printing code, and returns normally. All other programs fail. What am I missing here? There is simply no way to find out from the documentation. I can deduce from the meager information that I have, and perhaps with recourse to a disassembler, how most of this stuff is supposed to work. But having to do it this way "fhpxf!" Particularly since it says right there in the original, promotional edition of IM "there exists a different device driver for each printer" ^^^^ Didn't they mean "each printer sold by Apple"? Granted, Apple may not want to document the Printing Manager since the way it was designed and is now implemented "ernyyl rngf vg!" Granted, they don't have to tell anyone how it really works. However, by not doing so they prevent the Macintosh printing interface from really being "device independent". Apple has not written enough Printer drivers to give them the right to claim device independence, and they have made the code so obscure (seemingly by intent) that very few programmers will even attempt this task. Here is my question to Apple, if anyone is listening. Is the printing interface designed to provide true device independence, or is it designed to be as obscure as possible, thereby insuring that most if not all Macintosh owners will be forced to use an Apple printer? I think I already know the answer to this. Note: If you want to see what "SHPX" means in English, then most news reader programs will tell you if you use 'X' or maybe '^X'. Other posters who want to say nasty things, please note. Earle -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************