Has anyone successfully developed (and documented) a MAC driver package that will work with Konica Minoltas and price correctly for both black & white and color prints? We are in the process of upgrading to Pharos 8.4.
Darn. I was looking for the same thing. I'll be diving into build shortly.
Hi Cristine Dixon,
I built a couple of deployment packages for the Pharos/Konica Minolta drivers yesterday afternoon. It was basically same process as building Pharos/Ricoh packages. The specific details change of course.
We are in the process of evaluating the Konica Minolta printers, and so far, the black and white vs. color charging appears to be fine.
The documentation exists for creating Mac Pharos print driver packages.
Pharos Support :: powered by RightNow Technologies
There are/were discussion threads here answering some questions that seemed unclear to techs creating packages.
When you get into it, if you have a specific question/s, search the discussions for answers. If none present, either create a new discussion thread, or add on to this one.
The following statement is not specific to Konica-Minolta drivers...it's more a pervasive "please watch for this" declaration:
Apple's CUPS print subsystem allows for the inclusion of plug-ins that can perform several different functions as desired (though sometimes not required) by the manufacturer. These plug-ins can have the following effects:
Technically, we (Pharos) cannot work past this because of where we have to live in CUPS in order to effect job control. When either occurs, you can open the .PPD file and look for the CUPS plug-ins in use and then check with the printer's support folks if those plug-ins are really necessary (some are language translators that allow conversion from PostScript to some other format needed by the device; those would not be negotiable), and comment those out prior to installing the driver. You can sometimes get past this by checking to see if the manufacturer supplies a "for QuarkXPress" PPD file; they typically do not include the plug-in calls because they are not necessary, but still allow for device configuration and job option control, making them perfect PPDs with which to build your Mac packages.
I can confirm that the issue is not there under OS X 10.9.2.
I tested my print package installers (one color 1 sided, and one black and white 1 sided) for our current Pharos Ricoh printers (modified last year), and our new evaluation Konica Minolta printer.
I haven't had a need to go into the workstation's local CUPS configuration page except to confirm setting names when I wasn't too familiar with PPD editing. I just hope no one wants me to set the book finishing or fax preferences.
We had to run the Konica .pkg in the installer. Just moving the .gz driver isn't enough. Both the .pkg files for the older Bizhubs as well as the new Xerox we have ran w/o a hitch in 10.7 - 10.9.
We were not able to get the printer, once installed to pull the 'settings' of the MFPs or Printers (what finisher, what trays, hole punch, duplex, etc). Those still had to be manually set... although there is probably a way to add an lpadmin -o command to preset, I just haven't looked farther than to not have the printers shared by default.
Confirmed in 10.6.8, 10.7.5 and 10.9.2 that Blk and Color are recorded appropriately to both the Bizhubs.
Failure to run the pkg (just adding the ppd.gz files) the 'options' available are not named appropriately and the prints may or may not go through at all (they will through Pharos and be counted, but the Bizhub will drop the job).
Sometimes you have to be tricky. You often have to edit the provided PPD files to force options (like duplex, finishing, etc.) prior to installing them "for Pharos" and then pushing them back into the .PKG.
I've not thought of editing the .gz files directly; we could simply overwrite the file after the pkg has been installed. I wonder if I grabbed a .gz after settings in the GUI have been set and have the script copy that right before executing the add printer command... thus avoiding possibly injecting an error. I had assumed such settings were in a Preference file somewhere, I've just not had time to look further.
Thanks for a diff. angle to attack on.
I install the printer vendor's drivers, decompress the .gz, then move and edit the PPD. I use only the bare edited ppd file in my Pharos install.
For mass deployment, I deploy the vendor's drivers, and the Pharos install components. The Pharos install is slightly tricky in "my" mass deployment, as I don't deploy the DMG, but repackage Pharos components (package and Custom folder including the PPD) to install (postinstall package script) from a specific "local" directory. I do make the DMGs for one-off installs, but could use my mass deployment package as well...
This means that the printer vendor's driver install isn't altered. The printer vendor's defaults are as supplied from the vendor. Since OS X and Pharos use CUPS, then print defaults for Pharos are supplied by the specific PPD in /etc/cups/ppd/ (seems to work that way).
We therefore don't need to maintain separate installers for the printer vendor's drivers.
I'm not saying you need to do it this way, just that it's another way to do it.
Although, I don't recall that you need to deploy the printer vendor's drivers. I think it should work with just the PPD?
Seems to be a MacOS kind of week!
Michael, some drivers include references to CUPS plug-ins, and if the PPD is installed on the client without them, you may sometimes get a "jumping" printer icon in the bar saying that the printer is missing bits, so won't work.
Eh, yup. I just got confirmation that yes, the Konica Minolta printer drivers DO have to be installed as well. (was that user reading my posts!??!! )
One way to save some time and trouble figuring out lpadmin options or manual PPD edits: install the printer and configure it manually on one machine. Then copy the PPD for that printer from /etc/cups/ppd (it will be named the same as, or close to, your printer name) and use that directly in your custom package. This doesn't avoid the need to install driver packages, as per Scott's earlier note, but it does usually set printer options you want with a minimum of fuss.
Retrieving data ...