Konica Minolta bizhub C658 sometimes uses wrong default printer settings

Discussion in 'Konica Minolta Color Laser Printers & Copiers' started by ams_tschoening, Nov 9, 2017.

  1. ams_tschoening

    ams_tschoening New Member

    Joined:
    Nov 2017
    Messages:
    1
    Location:
    Germany
    Hi all,

    I'm the developer of an application which supports automatic printing of files of various formats with different settings in some very special context. Thos different settings contain the paper bin to use and the duplex mode, if any at all. Because we need to support various formats, the currently implemented approach is to set default printer settings for the current user in Windows to the settings we need and afterwards use whatever native application is able to print some format. Sometimes this simply includes executing ShellExecute with the "print" verb and let Windows handle everythign else, sometimes we directly execute apps using a specially configured command line etc. This approach worked quite well for some years now.

    One of my customers recently changed its printer from some small business HP device to a Konica Minolta bizhub C658 and starting with that we recognized printing errors in the special case a PDF is printed using the PDF Viewer SumatraPDF on the command line. It's really only the printer that changed, nothing else related our app, Sumatra, the OS or whatever and I can reproduce that error with the same printer on my own laptop using different verison of Windows, as long as my settings as well use SumatraPDF. If SumatraPDF is replaced with some other printing app, things start working again as expected, no exceptions. For various reasons we would like to stay with SumatraPDF, though.

    So, I'm pretty sure that the problem is the combination of SumatraPDF and the concrete printer. What happens is, that after setting some combinations of default printer settings to print individual PDFs, it seems that the printer is simply ignoring my settings and printing pages according to some own, maybe internal defaults. Some example: 4 PDFs which I want to print simplex, duplex, simplex, duplex. The default printer settings before my app starts working are set to simplex. What happens is that all but the last PDF print correctly as expected, but the last one is printed simplex instead. If the printer settings were set to duplex by default before my app was started, the third PDF would have been printed as duplex already instead of simplex and the 4th PDF would be printed as duplex as well.

    My app is strictly following the API docs of Microsoft regarding changing printer settings using DocumentProperties and SetPrinter and this worked with SumatraPDF and the HP printers for years and with some replacement for SumatraPDF and the Konica printer as well. Additionally, during debugging my app I can see that in all cases my settings for the printer are successfully applied and visible in the printer dialog in Windows right before Sumatra starts working. Obviously, I don't get any error from the Windows API that setting my new settings failed as well. Though, after some successful prints my settings seem to be ignored at some point during actual printing.

    It might be important to note as well that SumatraPDF is not started with any custom print settings or such, it just prints to the default printer with its current settings. Reviewing the printing code of Sumatra doesn't reveal any obvious error and as said before, using the HP printers it worked for years.

    In the end, I would like to ask if someone ever heard of a similar problem or has any advice on how to debug this further. Is there any tracing log in the printer driver or on the device? Where might the wrong default settings come from, if those are not the one set by my app for the current user? It seems like it's always those settings set before my app started working, but I'm using the user related printing API of Windows as well.

    The MSDN contains somethign which reads like is the problem I'm facing:

    https://msdn.microsoft.com/de-de/library/windows/desktop/dd183490(v=vs.85).aspx

    But as my problem doesn't occur always, only after some successful prints and only with SumatraPDF, which is not changing DEVMODE according to what I see in the code, it should be somethign different damaging DEVMODE then. Additionally, it would be nice to know where that "default DEVMODE" structure comes from.

    If there's anyone out there with some useful idea about how to debug this, what the problem might be etc. I would be very thankful! Thew only solution I currently have is to not use Sumatra with those printers, but having no idea why is bad. :)

    Thanks!
     
Loading...