Having not used GDI before just a few newbie questions:

1) Is it ATE compatible yet?

2) what other compatible issues are there ZTerm looks OK, any printer compatibly problems?

3) Can it be sent to a print file and printed later if required (we archive all reports)

4) Is there a manual/list of commands.

5) Is it snowing? it is here!

1. ATE Compatibility: Yes, I believe it is compatible. (This was, in fact, one of the fundamental features that ATE was designed to have.) The concept is as follows: on the UNIX side, just print to a printer that uses DEVICE=AUXLOC: - this will cause ATE to transfer the file to the PC side (like any emulator supporting aux porting printing would), and then pass it on to a Windows printer.

Where ATE goes one step beyond, is that it's printer configuration dialog allows you to specify not just the Windows printer name, but nearly all of the settings that would otherwise go into an A-Shell/Windows printer init file. However, for starters, the only option you must set for GDI printing is the GDI (instead of "passthrough") option in the Print Mode group. For testing, you might want to set the printer name to so it will just prompt you. (Ideally you have the NED Image Printer driver, or perhaps a fast PDF writer so you can just preview your creations without actually wasting paper.)

NOTE: a good place to start is by just printing the TSTGDI.TXT file, which you will find in [7,376].

For just printing of "standard" 80/132 column reports, you'll want to set the Auto Pitch option and plug in suitable values for the normal and wide columns (80, 132) and LPP (60-66).

2. Compatibility: As far as printers goes, GDI printing should work with virtually any Windows printer, because it uses the standard Windows printer interface system. If you use the Auto Pitch feature, it should either select or synthesize a font that works, although sometimes you may find that the resulting font is slighly too wide, in which case the simple solution is to just bump the CPP figure up, from, say 80, to 82 or so. The main compatibility problem is that you can't use your cherished ESC sequences (or PCL commands) with GDI mode. In that case, use the passthrough mode, and if your printer driver still doesn't work, then try the Generic / Text driver.

One limitation here, like with ZTERM and most other emulators, is that the app on the server can't easily determine what printer the emulator is set to use, or to change it. (I think I worked on this issue, or maybe just thought about it, awhile ago, but can't remember now, so I may need to get back to you on it. Ideally, we should have a way to define multiple ATE printer configurations, so that you could, for example, send a PCL file thru passthrough mode direct to a specific printer, and then a GDI file which prompted for a printer, etc.)

Obviously trying to send a file full of A-Shell/Windows GDI directives to a non-ATE emulator is not going to work, since those directives are only understood by A-Shell/Windows (i.e. ATE).

Similarly, while you can VUE/EZTYP a file full of GDI commands, you'll see the commands rather than the effect of the commands. (Same idea as with PCL, except that the GDI commands are a bit more "friendly" and don't include any escape sequences).

3. Can it be sent to a printfile? There are a couple of ways to do this. One is to just store the printfile on the server like you do now and resend them to the PC for previewing/printing. Another is to use the COMMAND= option in the ATE printer configuration to invoke your own SBX on the ATE side to do whatever you want with the printer. (See the printer init docs in the Setup Guide for details on the COMMAND= feature.)

4. Most, if not all, of the //GDI command are documented in the Developer Guide available on the microsabio.com download page (or better yet, just get the "consolidated" version, which contains all the manuals). There are a couple of recently added //GDI commands that are not in the main docs but can be found in the ash49devnotes.txt. (The XCALL Reference, on the other hand, is substantially up-to-date, with an updated version posted just last night.)

5. Snowing? That would be a nice change of pace from all this rain we've been getting.

Thanks Jack for that fantastic insight into GDI, i'll have a play with the options you suggested and see what I endup with.

Thanks again.

I am also basically just starting on GDI. I have talked about it many times with Jack, but am "really" ready to go this time. I have used some of the GDI commands in a one page document we fax, but nothing other than that.

The first real program I started to convert has caused me heartache from the first line. I have some questions if anyone could offer help.

1. I recall reading, and can no longer find it, that some GDI commands are reset after each form feed. What are these so I can reset them at the beginning of each page? I want to do all commands in the program and not set this in the printer ini so I have control.

2. Are there some fonts that don't respond to weight, etc.? I was playing around with Courier and changed the weight with no effect.

3. //BIN - Yes Jack I know we have talked this into the ground. I have finally figured out that you use it instead of the form feed, but can never get it to change the tray. I have a program that will list the name and number of all bins on all printers on the system. I have tried both the name and number, but to no avail. Does anyone use Lexmark printers that could offer a suggestion?

4. I need to print outside the normal print area on an 8.5x11 form. We now use PCL code to change the logical print area but see no GDI command for this. I tried using negative positions and it worked, sort of. It moved the print, but chopped off what was outside the logical print area. How can I accomplish this?

5. I'm sure there will be more questions coming. Do I know less about this or miamex/hostex?

None of these questions are very easy to answer, but I'll give it my best jet-lagged effort...

1. GDI commands being reset after form feed: after some thinking about this and a little testing, I would say that most of the GDI commands (i.e. those that start with //, such as //SETMAPMODE, //SETBRUSH, //SETFONT, etc.) are not reset by a form feed. Similarly, it would not be an issue for commands with an immediate one-time effect (e.g. //TEXTOUT, //LINETO, //RECTANGLE, etc.)

I think the line spacing will be reset on formfeed, based on the current TMARGIN and font, and since //BIN causes a formfeed, that might indirectly cause the line spacing to page between pages. But that would seem to be expected. Other than that, I can't think of anything but if you have any suspicions about particular commands, we can look at them more closely.

2. Font weight: this is an example of A-Shell passing through options that are offered by the underlying Windows API, but which may or may not always have an effect. As with most other font attributes, weights are merely "suggestions" to the font mapper about what you'd like, and it decides for itself based on a set of priorities, capabilities, etc. As an example, on my laser printer using the Arial font, weights 0-500 all print the same; 600 is somewhat heavier and wider, and 700-900 are noticeably heavier (but oddly, take up less horizontal space). My guess is that in general, unless you want to resort to trial-and-error, you can probably only expect two usable weights: normal (0), and bold (700).

3. I thought we had this one licked. On my Okipage laser, I can change the bin from one page to the next, but it does take some trial and error to figure out which bin is which. The SET LP TRACE ON command will show, among other things, what the choices are. But if you're saying that //BIN doesn't work within a printout on your Lexmark, then I guess we have to go back through our archives to see what we did in the past to make it work (or did it ever work)? Anybody else out there using bins?

4. Printing outside the normal print area: ugh. You've got me stumped on this one. I haven't been able to find any documentation suggesting how to do that, nor can I find any such option in the printer driver properties for my Oki laser printer. The only thing I can think of is that we might be able to implement a passthrough sequence to pass the PCL command to the printer even though we are otherwise in GDI (non-passthrough) mode. Or, maybe somebody in tech support at Lexmark can tell us how to do this via Windows API commands?

5. Unfortunately, I don't know that answer to this one.

As an aside, designing printed output using GDI commands typically involves, as you surely know, considerable trial-and-error. But one advantage you do have with the GDI commands is that you can use various paperless output technologies for most of your testing (although not for bins, changing the hardware paper margins, etc.) Before burning through a ream of paper on your next project, I strongly suggest installing something like NED Image Printer, or one of the many PDF writers, such as PDF995, and then printing to the PROMPT printer (so you can choose one of the paperless options except when you really need the real thing).

Thanks for the good explanations, Jack.

Jim may or may not have gotten the //bin to work, but he has since retired. I will try the SET LP TRACE ON command and see if I can get it to work.

As far as the logical print area, I will see if anyone around here knows anything about the API commands or if they can contact Lexmark about it.

Hi,

Since I'm using only GDI for printing since it was implemented under A-Shell, let's see if I can add something useful here.

Starting with the BIN issue; to avoid the hard task on discovering the UPPER,LOWER,... corresponding name for each tray of each printer, recently I asked Jack to allow BIN parameter on the PQI (or INI) files to accept the names from the Windows Registry, and it's working perfectly. With that, my SBX for handling printers selection, go to the Registry and create a TXT file with all the printers and corresponding available trays, following is an excerpt of the generated file:
0HP LaserJet 2200 Series PCL~HP LaserJet 2200 Series PCL,0Tabuleiro 2~Tabuleiro 2
0HP LaserJet 2200 Series PCL~HP LaserJet 2200 Series PCL,0Tabuleiro 3~Tabuleiro 3
0hp2200-brn~hp2200-brn,0Selecção automática~Selecção automática
0hp2200-brn~hp2200-brn,0Primeiro tabuleiro disp~Primeiro tabuleiro disp
0hp2200-brn~hp2200-brn,0Tabuleiro 1~Tabuleiro 1
Note: each line is a Printer/Tray where I add a few more parameters to allow the user to rename each entry with more meaningful names and structured to be used in GUI combo fields

With this method, I don't need anymore to create PQI files for each printer/tray and no more have to worry on defining network printers with the same name on all workstations to respect what is defined on the PQI files, the PQI file is just created on the fly after selecting the desired option and only with the following statements:
open #10,"%TEMP%"+gf'pqi+".pqi",output
print #10, "DEVICE = ";impressora'buf
print #10, "BIN = ";tabuleiro'buf
print #10, "PASSTHROUGH = OFF"
print #10, "NOABORTDLG = TRUE"
close #10

The above illustrates how I workaround the problem on assigning the BIN nomenclature to the real tray on each printer.

About changing the BIN in the middle of a print job, I don't use exactly that, but I have a few programs that use different printer or tray in a printer for different pages, what I do for that is to just consider different output files and, at the end send them to their predefined destinations as different prints (in my case, the association between programs/options to printers/trays is also handled by the SBX, but out of the scope of this post).

I'm a little bit confused why you need to know anything about a specific printer (Lexmark), GDI is supposed to work with any printer assuming the correct driver is installed.
Since GDI was implemented, I never bother about which printer my customer is using and sometimes I found a few very strange ones like printer/copiers, but never had to adjust any parameter.

To handle the printer workspace, I just need to know if the it will be printed in portrait or landscape and on which paper size. With that, I know which margins to consider and using //SETMAPMODE,LOMETRIC, it's me who controls when to form feed.

About fonts, by default I use TAHOMA where I have enough options to play with size and bold parameters.

When I started using GDI, like in GUI, I changed completely the logic of the programs to process data for printing, mainly what concerns to header/footer/form feed; on text mode printing, I had to follow something like:
. print header
. loop to print lines
. print footer
With GDI, I just define the page layout and print all the static data after what, I just print the details to fit on the page layout.

Since the above is more a generic explanation of the method I'm using and probably will not solve any of your problems, maybe it can point some ways that you can follow to make the things easier in future.
If some of the issues here could look interesting, I can detail more, or even send the mentioned SBX.

Regards

Jorge

Thank you for the detailed explanation. I will have to digest some of this over the weekend. I would love to look at the sbx you are talking about if you don't mind emailing it to me at herman@lexicomcomputers.com. I would really appreciate it.

As far as the Lexmark printer, it just happened to be the one I was working with. We do use all Lexmark, but as you point out, one reason for doing this is to be printer independent.

As far as the workspace on the page, do you print outside the logical print area of the page, either portrait or landscape? We are unable to print closer to the edge than about 0.25 inch without using a PCL sequence to allow us to change this. We print pharmacy labels which require us to print almost to the top and left of the page. Without changing the logical print area using this command, we are unable to do so. In the label printing program we change this and then return it to it's normal state. Am I missing something that would make this possible?

Thanks again Jorge,
Herman

Hi Herman,

No problem, I'll prepare a full functional A-Shell package to run a test program that uses the SBX and with all the parameters defined for the best GUI interface (yes, it's full GUI).

About printing outside the logical print area, I think I can, at least I never had any problem about that and I have some special cases where I need to go close to the edges, but the usual is to keep by default margins on all sides of the page.
I think you're using 8.5x11 forms correct ?
And you need to go as far as possible down to the page, or also to the top,right and left margins ?
I'll make a test here with that format.

Regards

Yes we are using 8.5x11 forms and we need to go as far as possible to the edges. At this time we are only going to the left, top, and right, but may need to go to the bottom at a later date. I think some printers can be set for full page mode in the menu (we have not tried this, just saw it on Lexmark's web site), but I believe this would change the registration of all the other printouts we do and some of the older printers may not have this feature.

Thanks again,
Herman

I really think I am going to use GDI, finally!

I now understand that the //BIN command causes a formfeed and changes the bin for the next sheet printed, but how do you specify the bin for the first sheet. Is it the bin=upper, etc. in the printer ini file? If so, then for each printer I need an ini file that would start with the top tray and one that would start with the bottom tray. Is this correct? I could also build them on the fly as in Jorge's example above. My question is really, where do I specify the bin for the first sheet printed? Is the only place in the printer.ini file?

Yes, I agree that it seems a bit awkward, but since the //BIN causes a page feed, there appears to be no other solution than to put a BIN= statement in the printer init file, and maintain multiple printer init files for each printer if you want to have different versions for different starting bins. (Or create them on the fly.)

Actually, I shouldn't sound so negative - think of the ability to dynamically create logical printers, and to have multiple logical printers per physical printer as a fantastic feature! :p

Thanks Jack, just one more question. Is xcall ezspl done with the pqi file quickly enough that I can xcall ezspl and immediately erase the temporary pqi file? I think I like the idea of the on-the-fly pqi files if I can do this.

Certainly - by the time the XCALL EZSPL (or SPOOL) returns back to the program, it no longer needs the PQI file, so it is safe to erase.