woody@tybalt.caltech.edu (William Edward Woody) (03/10/88)
In article <44630@sun.uucp> PUGH@NMFECC.ARPA writes: >These fellows ask about Hypercard and non-Apple printer drivers: > tgl@ZOG.CS.CMU.EDU and > woody@tybalt.caltech.edu (William Edward Woody) > >Hypercard makes use of a new print manager call PrGeneral which is documented >in IM V-410. It is present in Imagewriter drivers >= 2.5 and LaserWriter >drivers >= 4.0, and not in any third party drivers (including SoftStyle's HP >Thinkjet driver that I have). > >Any drivers that intend for Hypercard to use them MUST implement the PrGeneral >call. (he he he) Excuse me, but it's 2:00 in the morning, and I'm a little groggy... (To PUGH@NMFECC.ARPA: Please don't sound so rightous about something you don't completely understand. Had I had not known better, I would have wasted several hours following your advice down the wrong trail... It's late, so please excuse me if this sounds negative...) Uh, (1) Yes, Hypercard makes use of the new print manager call PrGeneral documented (incompletely--I used MacNosy to figger out the lil' bugger...) in IM V-410, and (2) the lack of PrGeneral is not what's making Hypercard go belly up. It's the fact that PrDrvrVers() (IM II-163) is returning 0 for every third party driver I've seen, including mine, until Now! And (as it turns out), if you (1) do set the version number correctly (see below) in your printer driver, and (2) you DON'T implement PrGeneral AT ALL (PDEF 7 doesn't even exist!), Hypercard WILL PRINT CORRECTLY. (Gosh, I'm so supprised.) It's almost as if Hypercard isn't looking for PrGeneral... What's going on is this: Hypercard calls PrDrvrVers() to get the version number of the driver, and checks to see if it is greater than or equal to the constant iPrRelease. Most third party compiler developers don't know how to extract PrDrvrVers(), so they don't implement the routine in their runtime support libraries, but (as Apple has their finger in the pie) MPW does. For Third Party Compiler Developers: How to write PrDrvrVers() glue: Open the printer driver in question. Now, get the DCtlEntry for that driver. (IM II-190). Now, get the low-order byte of the dCtlQHdr.qFlags field in the DCtlEntry. The low-order byte is the version. Return version number. For Third Party Printer Driver developers: How to set the PrDrvrVers() val: When your driver gets the Open call, somewhere during your driver open routine, get your DCtlEntry, and place the version (at least 25 to fool, er, ah, indicate to Hypercard to use your driver) into the low byte of the dCtlQHdr.qFlags field. The version number for the printer driver is placed in the low order byte of the DCtlEntry.dCtlQHdr.qFlags field. It says so right here, buried in the middle of the first paragraph under the subject "The Driver I/O Queue" in the Device Manager documentation. [IM II-191]. Obscure, no? How did I ever figure this out? I took MacNosy to the _PrLink glue in MPW, that's how! Sorry if this is long and confusing, but it's late. I posted this in the .Hypercard group because this is where the discussion started, and into the programmer's group because this is where the discussion belongs. Please follow up only in the programmer's group for any more techno mumbo about drivers. - William Edward Woody woody@tybalt.caltech.edu (Mac>][n&&/|\)&&(MacII>AT) Disclamer: I haven't the foggiest idea what I'm talking about...
earleh@eleazar.Dartmouth.EDU (Earle R. Horton) (03/13/88)
In article <5720@cit-vax.Caltech.Edu>, woody@tybalt.caltech.edu (William Edward Woody) writes: > In article <44630@sun.uucp> PUGH@NMFECC.ARPA writes: > >These fellows ask about Hypercard and non-Apple printer drivers: > > tgl@ZOG.CS.CMU.EDU and > > woody@tybalt.caltech.edu (William Edward Woody) > > ... > go belly up. It's the fact that PrDrvrVers() (IM II-163) is returning > 0 for every third party driver I've seen, including mine, until Now! ... > For Third Party Printer Driver developers: How to set the PrDrvrVers() val: > When your driver gets the Open call, somewhere during your driver open > routine, get your DCtlEntry, and place the version (at least 25 to fool, > er, ah, indicate to Hypercard to use your driver) into the low byte > of the dCtlQHdr.qFlags field. > > The version number for the printer driver is placed in the low order > byte of the DCtlEntry.dCtlQHdr.qFlags field. It says so right here, > buried in the middle of the first paragraph under the subject "The Driver > I/O Queue" in the Device Manager documentation. [IM II-191]. Obscure, > no? I have never done as William suggests, but my printer driver (Daisy) prints fine with HyperCard, although I did notice that the program does not use my Job Dialog. (I suppose I should feel grateful that it condescends to use my Style Dialog.) My practice has been to set the "iPrVersion" field of the Print Record as returned by my PrintDefault() routine equal to the constant "iPrRelease", which is currently 3. I ** do not ** recommend using a value of 25 or even 4, since this could present problems for users when "iPrRelease" changes, reflecting possible changes in the printer code which your driver does not now implement. This value should also be present in the default 'PREC' in the printer resource file. The fact that William got his driver to work with HyperCard by setting his "DCtlEntry.dCtlQHdr.qFlags", while Daisy works with HyperCard by setting the "iPrVersion" field of the Print Record, indicates that perhaps HyperCard looks first in the default Print Record, then calls PrDrvrVers() to make sure. It shouldn't be necessary to have the driver open() routine set the flags word for the version, since I would think setting the flags word in the copy of the driver in the resource file should be sufficient, also. (Disclaimer: Apple doesn't appear to set the low-order byte of the driver flags in the printer resource file, so maybe this wouldn't work.) There is one other detail which I am aware of, which may cause PrGlue() to handle my driver differently, although I don't see how. My printer resource file is of type 'PRER', while many third-party printer resource files are of type 'PRES' (same as ImageWriter.) While we are on the subject of printer drivers, how can I vent my anger against application developers who bypass my Job and Style dialogs? Apple has provided a mechanism whereby the print dialog code gets the top half of the screen, and applications get the bottom half for extending the dialogs (see Technical Note #95). If this is not enough, Technical Note #95 recommends having a separate application Job/Style dialog "in addition to the existing Printing Manager dialogs." Apple went to a lot of trouble to make the user interface to printing as generic as possible, and I went to a lot of trouble to follow their guidelines in my printer driver. Now, some clown comes along who thinks he can do it better, and the user never gets to see my carefully designed Job/Style dialog. It just burns me up! > Disclamer: I haven't the foggiest idea what I'm talking about... Nor do I. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************