steve@violet.berkeley.edu (Steve Goldfield) (10/07/88)
I haven't been reading this group, and maybe what follows has already been discussed. If someone from Apple reads this, I'd greatly appreciate a response, because I am extremely disgusted at the way the Macintosh system was designed in respect to user control of printers. The Background I have a label program which prints mailing labels from my database. I've used essentially the same program on many printers and from various versions of dBASE and now McMax on my Mac II. I've found that the most general way to write such a program to print on continuous labels is to set the form length to the length of the label and eject after each label. I have a LaserWriter but purchased an LQ specifically to print continuous labels. The Problem When I got my Imagewriter LQ, I diligently read the manual and found the control code to reset the form length (it wasn't easy to find since it only appears on a fold-out card in the back and has a typically cryptic explanation of its critical parameters). So I programmed those (and other control codes to control the quality of printing) into my McMax program, and to my horror found that nothing I had sent was having any effect except to print strange characters on the printer. After frantically calling several sources, including Apple Customer Relations, I've been informed that the Macintosh system prevents me as a user from controlling the printer, that the printer can only be controlled through its driver, and that to do what I want I'd have to write a custom driver, which is an extremely demanding project. I managed to rewrite my label program to get around the form-length problem (though I still can't control print quality through software commands). But I would still like to know why Apple chose to implement the Macintosh system in such a way as to prevent the user from making optimal use of her/his equipment. Why couldn't the existing driver have been written in such a way as to pass user-generated control codes on unchanged to the printer? And a more minimal request: why couldn't the manual at least spell out clearly that Macintosh users can't use these control codes. I quote from the LQ manual, page 199: "Macintosh note: You can command the printer through programs on a Macintosh, but not through typing a direct command, even though some Macintosh keyboards have an Escape key (Esc)." This sure implies to me that I *can* use escape sequences to control my printer. But reality, as described above, is different. So, in summary, if this limitation is an intentional part of the Macintosh design, I ask Apple (or anyone else who wants to comment), why was such a design chosen for the system? If it wasn't intentional, then what does Apple propose to do about it? Steve Goldfield
usenet@cps3xx.UUCP (Usenet file owner) (10/07/88)
In article <15098@agate.berkeley.edu>, Steve Goldfield (steve@violet.berkeley.edu) writes: > When I got my Imagewriter LQ, I diligently read the manual > and found the control code to reset the form length (it wasn't > easy to find since it only appears on a fold-out card in the > back and has a typically cryptic explanation of its critical > parameters). So I programmed those (and other control codes > to control the quality of printing) into my McMax program, and > to my horror found that nothing I had sent was having any > effect except to print strange characters on the printer. > > After frantically calling several sources, including Apple > Customer Relations, I've been informed that the Macintosh > system prevents me as a user from controlling the printer, > that the printer can only be controlled through its driver, > and that to do what I want I'd have to write a custom driver, > which is an extremely demanding project. There are at least two ways to get around this. The first is not to use the printer driver at all--just use the serial port driver (.Bout). This is probably the simplest and best way, if you just want to send stuff directly to the printer. Chapter 9 of IM Vol. 2 has information on this. You can also send codes to the printer using the printer driver, with the appropriate PrCtlCall (IM vol. 2, ch. 5, p. 165). I'm not sure how this would interact with PrOpenPage and PrClosePage, though (haven't done it myself). > Why couldn't the existing driver > have been written in such a way as to pass user-generated > control codes on unchanged to the printer? Because printer control codes can overlap with the character set (ESC may have a printable form in some fonts). More generally, because printer imaging is usually done via a GrafPort and drawing calls, not through text handling at all. > So, in summary, if this limitation is an intentional part of the > Macintosh design, I ask Apple (or anyone else who wants to > comment), why was such a design chosen for the system? Because it helps prevent application writers from coming up with printer-dependent code (otherwise we might have seen hordes of programs which only worked on the ImageWriter). This way, the printer manufacturer just needs to supply a driver, and the application needs to call it in standard ways--you don't need the lists of hundreds of printers that IBM word processors (to pick an example) support. > Steve Goldfield Anton Rang (rang@cpswh.cps.msu.edu) +----------------------------------+------------------------+ | Anton Rang (grad student) | "VMS forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +----------------------------------+------------------------+
casseres@Apple.COM (David Casseres) (10/11/88)
In article <15098@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: >... I've found that the most general way to write >such a program to print on continuous labels is to set the >form length to the length of the label and eject after each >label. I have a LaserWriter but purchased an LQ specifically >to print continuous labels. It sounds to me as if you're trying to port a non-Macintosh program to the Mac, without having learned much about the software architecture of the Mac. You get points for bravery but I'm not surprised that you're getting some big surprises. >The Problem > >... I've been informed that the Macintosh >system prevents me as a user from controlling the printer, >that the printer can only be controlled through its driver, >and that to do what I want I'd have to write a custom driver, >which is an extremely demanding project. > >I managed to rewrite my label program to get around the >form-length problem (though I still can't control print >quality through software commands). But I would still like >to know why Apple chose to implement the Macintosh system >in such a way as to prevent the user from making optimal >use of her/his equipment. The bad news is that label printing is a very specialized application, and the existing architecture for printing just doesn't handle it very well. To make printing work the way you would like it to would mean a reimplementation of all of Apple's drivers, and Apple hasn't considered that a high enough priority. The good news, though you may not like it much, is that the way printing works on a Mac DOES make optimal use of the equipment for a very large and important class of applications, namely the ones that print documents in the form of pages. The printing architecture is what supports the WYSIWYG paradigm that is central to the Mac's design. It isn't that Apple said "let's screw the label-printing applications," it's label printing was not as important as WYSIWYG page images and there were some conflicts between the two. The problem could be solved, but so far, as I've said, it hasn't been a high priority. David Casseres
jfbrule@cmx.npac.syr.edu (Jim Brule) (10/11/88)
In article <18536@apple.Apple.COM> casseres@Apple.COM (David Casseres) writes: > >The bad news is that label printing is a very specialized application, and >the existing architecture for printing just doesn't handle it very well. To >make printing work the way you would like it to would mean a reimplementation >of all of Apple's drivers, and Apple hasn't considered that a high enough >priority. I have found that I can get around this (ok, it's a kludge, but I =need= labels) by using Hypercard, and reading in text to a stack that I've designed for this purpose. Other solutions have not worked as well, namely, trying to use MS Word and its merging capabilities. Admittedly, MS Word gets around thr problem of blank fields, but I haven't yet found the time to adequately train my secretary in its use (and believe me, she's no dummy!). -- //\//\\ //\//\\ //\//\\|"Time flies like an arrow; \// // \\// // \\// // \| Fruit flies like a banana." G. Marx // //\\ // //\\ // //\\ |-------------------------------------- /\// \\//\// \\//\// \\/|Jim Brule' | jfbrule@cmx.npac.syr.edu
alexis@ccnysci.UUCP (Alexis Rosen) (10/12/88)
In article <18536@apple.Apple.COM> casseres@Apple.COM (David Casseres) writes: >In article <15098@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: >>... I've found that the most general way to write >>such a program to print on continuous labels is to set the >>form length to the length of the label and eject after each >>label. I have a LaserWriter but purchased an LQ specifically >>to print continuous labels. > >It sounds to me as if you're trying to port a non-Macintosh program to the >Mac, without having learned much about the software architecture of the >Mac. You get points for bravery but I'm not surprised that you're getting >some big surprises. > >>The Problem >> >>... I've been informed that the Macintosh >>system prevents me as a user from controlling the printer, >>that the printer can only be controlled through its driver, >>and that to do what I want I'd have to write a custom driver, >>which is an extremely demanding project. >> >>I managed to rewrite my label program to get around the >>form-length problem (though I still can't control print >>quality through software commands). But I would still like >>to know why Apple chose to implement the Macintosh system >>in such a way as to prevent the user from making optimal >>use of her/his equipment. > >The bad news is that label printing is a very specialized application, and >the existing architecture for printing just doesn't handle it very well. To >make printing work the way you would like it to would mean a reimplementation >of all of Apple's drivers, and Apple hasn't considered that a high enough >priority. I'm going to have to be careful here, contradicting an Apple Expert :-) The fact is, the Mac does quite well at printing labels. The only problem is that the Imagewriter II, like some other printers, dies a horrible death if you try to do a pagesuck (or just suck a bunch of lines) since the label tends to get pulled off of the page and onto the platen or {metal thingy that touches the platen}. To print labels is quite easy. You can either choose to do it the Mac way or the DOS way. If you want to do it the Mac way, you edit the PREC 3 resource in your printer driver so that one of the page sizes is the same vertical size as a label. Then just print normally, and everything will work fine. I've done this for several clients. If you want to do it the DOS way, it's even easier. I suspect that this was your intention since you mention McMax. (And might I suggest here that you switch to FoxBase. It's better than McMax in just about every way, more able to do the Mac interface correctly, AND more dBase III+ compatible.) You simply print in the Draft mode, and then all of your beloved escape codes will work just the way you want. In FoxBase you can use the printer driver in either a totally Mac mode, or in draft mode. You can ALSO bypass the printer driver entirely and print directly to the serial port. This is more efficient than printing in draft mode, but of course you can forget about the Mac graphics. This mode will also allow you to connect any non-Apple printer to your Mac and use your IBM printing code entirely unchanged (you will need a parallel-to-serial converter if you have a parallel printer). <flame on> In general, the Mac Printing architecture doesn't have any of the minor flaws mentioned in the original article. It has the _overriding_ flaw that it is impossible to write a truly compatible third-party driver right now. Apple has guaranteed that they will break, since the whole architecture will change. That's understandible- it has to change. I just wish they'd do it SOON. <flame off> That problem won't stop you from printing labels, though. ---- Alexis Rosen {allegra,philabs,cmcl2}!phri\ Writing from {harpo,cmcl2}!cucard!dasys1!alexis The Big Electric Cat {portal,well,sun}!hoptoad/ Public UNIX Best path: uunet!dasys1!alexis
steve@violet.berkeley.edu (Steve Goldfield) (10/13/88)
I appreciate the many comments and helpful suggestions I've received about the problem I posted. To summarize, however, a general response, I'm not a Mac programmer. I'm sure I could become one, though it seems hard to justify to my boss that we spend over $100 to buy Inside Macintosh and other resources just to print labels. The same applies to the suggestion of purchasing FoxBase. I have an operating database in McMax (when we bought it the only choices were McMax and the new and disparaged dBASEMac from Ashton-Tate). It doesn't seem realistic to spend the money to buy new software and the time to adapt 100 or so custom programs to it. A few people suggested using the serial port to send directly to my printer. Since my Mac II and my Imagewriter LQ are connected via the printer port and a TOPS network, that doesn't appear to be a viable solution. In any case, I managed to print labels by rewriting my program in such a way that the form length doesn't matter. And it isn't too much of a hardship to walk over to the printer and set print quality by pushing buttons. I also have a general comment about the Mac system, however. Unlike other operating systems I've used, there appears to be a huge gap between the Mac programming level and the system ordinary users see, a gap both financial--i.e., in acquiring the necessary tools for Mac programming--and in the complexity of knowledge needed to program. I question the design of the system because I question whether this was necessary. Although personally I can see why the system is excellent for people new to computers and even that it has some other advantages, I don't think it would have been harmed by having an easily accessible command shell available, too. And, in my opinion, some of these commands should allow the user to set basic configuration parameters like the form length of a printer. What I'm getting at is that Apple appears to have divided users into two groups: system and application programmers (like most of those who read this group) and users who don't want to have to think about how the system works. I suggest that there is at least one other group: people like me who don't have the time or need to learn Mac programming but who have a fair degree of computer skill (I've been programming on various machines and in various languages for 22 years) and want the kind of control over the system we had easily available in CP/M or DOS. Perhaps all that is needed is a set of applications. If so, there may be a market waiting to be filled.
casseres@Apple.COM (David Casseres) (10/14/88)
In article <914@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >I'm going to have to be careful here, contradicting an Apple Expert :-) Actually my posting was a bit sloppy so I don't feel contradicted; what you say is true and I will just add a comment here and there: >The fact is, the Mac does quite well at printing labels. The only problem >is that the Imagewriter II, like some other printers, dies a horrible death >if you try to do a pagesuck (or just suck a bunch of lines) since the label >tends to get pulled off of the page and onto the platen or {metal thingy that >touches the platen}. Quite so. This problem with the ImageWriter is one of the reasons Apple hasn't had much enthusiasm for serious work on the label problem. BTW at least one company, Williams & Macias, sells special label stock with their label program, MyLabelMaker. This label stock works much better than the ordinary stuff. >To print labels is quite easy. You can either choose to do it the Mac way or >the DOS way. If you want to do it the Mac way, you edit the PREC 3 resource >in your printer driver so that one of the page sizes is the same vertical size >as a label. Then just print normally, and everything will work fine. I've >done this for several clients. But many who have tried this approach say that the labels still peel and jam because of the ImageWriter's infamous "top of page dance." If you found a way around that one, please share! David Casseres