SYPRINT3 Background to Printers and Printing
<< Click to Display Table of Contents >> SYPRINT3 Background to Printers and Printing |
![]() ![]() ![]() |
Background to Printers & Printing - Maxim Software
The printer details that Maxim deals with are held in the magic.ini under two sections [MAGIC_PRINTERS] and [PRINTER_NAME]
[MAGIC_PRINTERS] holds the full printer name and the printer attribute file. The attribute file contains the pcl code that gets interpreted
and creates the print file somehow.
[PRINTER_NAME] holds the user's name given to the printer and the forms printer settings.
Both of these sections are referenced by a printer number, ie Printer1, Printer2, Printer3, etc.
What is held in these sections is maintained from Maxim's Printer Management screen.
The forms printer settings are updated to the User's SYUID table and can be viewed in the Update User Options screen.
NOTE: that it is the printer number only that is held on this table, ie Printer1, Printer2 etc.
The problems that we tend to have is when Maxim wants to print natively direct to a printer, that is a pcl print file is generated and sent
direct to a printer.
This is what happens in this situation:
A Maxim print program (invoices for example) receives a request to print an invoice and is passed a printer number, ie Printer2.
Maxim obtains the full printer name from the [MAGIC_PRINTERS] section of the magic.ini and creates the print file using the
matching printer driver. If a matching printer driver can't be found the print file is created based on the default printer set for the
users session.
If there is no matching printer driver and no default printer set, then this is where we are seeing problems. What happens then
depends on the computer's operating system.
If it is a terminal server session Maxim seems to “hang” on Windows 7 - Maxim doesn't hang but there seems that no print file is created.
PDF Output
Creating pdf output from Maxim is not an issue because Maxim creates the pdf natively, that is it does not require a print driver.
Adobe
Adobe requires a printer from the User's Devices and Printers folder. Adobe looks for the printer set as the default printer.
Using the print server, the User's default printer becomes the first printer in the printer groups set for the user which may not be the
correct printer for a user. This is why Maxim wants to set the users default printer based on the user's Maxim Default Printer setting.
UniPaaS Preview Option
The Maxim default printer driver is used for creating the report.
Plan of Attack
For pcl direct printing programs Maxim will interrogate the printer driver based on the full printer name for the printer number passed to the
program. Maxim should be able to obtain the PrinterName, Status and Errors for the printer.
If the returned info for PrinterName doesn't match the Maxim printer name (is blank) or non blank for Status and Errors, it will be assumed
there is an issue with the requested printer.
An appropriate screen will be displayed detailing what has been found and then the following screen can be displayed giving the user an
option to select another printer.
Maxim Printer Set-up Rationale
The printer set ups should be viewed as being tied to physical thin clients or PCs and not necessarily to a User.
Printers are located in different parts of a building and these printers are generally associated with thin clients or PCs that are in close
proximity and the printer names generally have a specific purpose like printing invoices, print A4 pages and the like. Cash slip printers
are located next to POS thin clients.
For example, if redirected printers were being used, the printers that would be available are the printers from that Thin Client or PC,
nothing to do with a user.
Now generally a thin client is also associated with a user. Every user has a magic.ini and the user's printer settings will be based on the
location of the thin client or PC and the proximity of printers.
So a potential issue is the users that use different thin clients can have an issue with printers because the printers that are set for their
magic.ini are miles away or maybe a required printer at the new location is not in the users printer group, so the printer is not even
being pulled through.
So we have a potential printer management issue for those users who use more than one thin client. I don't know the specific
user instances, but here are some ideas:
1. | If possible logon to MOL using one of the POS User Accounts and then logon to Maxim using the User's User Account, |
to get the correct Rights. The MOL logon gets the correct printer groups and printers and magic.ini with the printer settings for
the MOL User Account, not the printer settings for the Maxim User Account.
2. | Have a second user account tied to the 2nd location to deal with these users who access more than one thin client. |
3. | If a User uses their User Account to log onto different thin clients, then the user's printer group has to include all the required |
printers and the user will have to set his default and forms printers all the time. Realistically this is probably not an option
because of the size of the printer groups and the fact that the User will forget to change the printer settings and they will tend
to get mixed up. If the user doesn't log off normally the settings will be lost etc.