-print-dialog options doesn't seems working

[pstarliu]

Hi, firstly thanks for a great project, not only it is appreciated by end users, but I've seen more than once that the Sumatra PDF reader is recommended in a professional setting as a PDF reader and util tools for business software recommended by our software architectures.

I just downloaded the latest version, 3.5.2 x64 portable version, and the -print-dialog command line option doesn't seem working.

For example, I tried this command on my PowerShell terminal: PS C:\Users\pliu\Downloads\SumatraPDF-3.5.2-64> .\SumatraPDF-3.5.2-64.exe -print-to-default -print-settings "landscape" -print-dialog .\ZZ8FAQ.pdf

And it silently prints out from my default printer with the landscape option as expected. But I am expecting to have a print dialog confirm my print/printer settings but nothing seems to show but does the printing on the background.

[GitHubRulesOK]

A) dont test from a system other than Command Line so you can see all behaviours B) Never run silent until all methods proven reliable C) Then test same behaviours in any other shell that may distort cmd functions

Here in current pre release and 3.5.2 version it looks reliable

3.5.2

[pstarliu]

@GitHubRulesOK thanks for your fast response, appreciate that.

I've test your scenario, and it works for me as your screenshot, but in my case, when I am using my actually printer: an Brother Laster printer, I am expecting a print confirmation dialog like this one if I am printing from Sumatra PDF:

But I just get the cmd line appears to be finihsed, and I can see that the printer actuall print the document 'slicently' in a sense there is no feedback from Sumtra PDF or the command line UI:

Just to comfirm that you are testing on a portable exe as well, I am not expecting the portable or installed version should be make differenece, but you never know?

Thanks again.

[GitHubRulesOK]

AH that's different issue that MS Dialogs are interfering with the basic method SumatraPDF printing was built on.

You will see my dialog is Windows 10 not 11 and 11 has several simple command line breaking features. One seems to be reports that page numbering is not correct, another is dialog boxes are crippled by MS replacement.

Basically you would need to roll back print dialogs to older dialog system (possible and I would for myself, but you should not do it for other users) OR use another Command line system impervious to MS involvement say High Quality Adobe or GhostScript application where the pain is worth the gain.

[pstarliu]

@GitHubRulesOK

You were right, it was on a Windows 11 VM which I took a screenshot last time, as I was using a Linux Desktop. But now I am back to my work PC which is Windows 10 and it's still the same behaviour if my default printer is a physical printer (not print as PDF file), it just prints without showing dialogue.

For what I am trying to achieve: print a file PDF for landscape orientation, and possibly more options down the track for the CMD print parameters, the dialogue is really to help me testing, as I think it's much easier for me to confirm the print CMD parameter works as expected by check it in the print dialogue rather than print it out on my printer.

So I want to confirm that:

1, it should show a print dialogue for the physical printer, and I can confirm the print settings before it prints out on the printer.

2. In my testing case it is not working could be due to a few factors outside the control of SumatraPDF, Windows component behaviour change for example?

3. How do I go about testing/diagnostic the issue, view it on the logview is probably the first thing I should try, but the link from the manual page doesn't seem working: as it shows 404 error: https://files2.sumatrapdfreader.org/software/logview/rel/logview-0.1.exe.

My questions are sort of in the order of importance as if the print-dialog doesn't work as I expected (wait until I press the 'print' button before it actually prints), then there isn't much point for me trying to get it working on end-user's system.

[GitHubRulesOK]

End user system is the key, you have no control over MS interference in print cycle, pitfalls are several

• 3 ) I have never used LogView as its was part of development cycle and not a rereleased tool for download, I also doubt it would help in this case.

• 1&2 ) every few months Microsoft (on second Tuesday) alter the basic print system security, and it can take months to adjust back to working, this can disrupt daily printing for some time and absorb you in days of frustration. Luckily it is only one or 2 months per year this seems to happen badly. Personally have not been badly affected but other have had "Blue Screen Of Death"

• 2&1 ) You cannot insist all your users stick with controlled printing as MS have full control over all windows updates and default user print setting such as reuse last printer as default. This is not a problem for single users as they can alter the settings as they desire. I switch off Windows auto controls and roll back print dialogs as required.

• 1-3 ) I will alter available print drivers as required for different print methods and dont normally use SumatraPDF for command line printing (except for comparative testing it works after a fashion, or simple inkjet outputs) as MS use a very inefficient print method compared to others. The enforced resolutions and print formats are unusually not what I desire.

• 4 ) for Printing I would suggest other Windows Users pick their own preferred methods, they usually do anyway.

[pstarliu]

@GitHubRulesOK good points.

Apology as I didn't elaborate on my requirement, the whole point of using a PDF Viewer, we were using a different PDF viewer before, but decided that SumatraPDF is likely better suited for our goal, is for efficiency.

The end goal is user should not need to adjust printer settings for each part of the application function as depending on which task it's doing the printer output will be different paper orientation, that's the part we do know needs to be dynamic.

So I don't need the -print-dialog to work, but to clarify that it should work on my case, and it's something nice for my debug/development phrases, same as LogView.

Can we archive that using different printer drivers? I assume it means the same physical printer but a different default setup?

I am only showing the default printer on the test, but it'll be specified by printer name in the real-world scenario.

Again, thanks for the inputs

[GitHubRulesOK]

If I am using SumatraPDF to output different formats, then the same as any uncontrolled printing situation, I create different printers. So A4L and A4P are 2 different printers with different settings (both happen to be Microsoft PDF, but could be physical) I can add one For A3Landscape or even left or right or lower half page, if that is the desired defaults. OR you can fiddle the registry to switch printers defaults in a batch process but you need to know and set the target formats, before print.

[pstarliu]

@GitHubRulesOK

I've tested add an alternative printer and it works as expected. So it's a pretty good option for us.

I think the -print-dialog should work, but looks like it's pretty out of the control of the SummatraPDF or the end user. So if you want please close the issue, or let me know if you need further information for the -print-dialog related issue.

Thanks for the help!

[GitHubRulesOK]

I will leave the closure decision to Developer in case he wishes to run trough comments, and or add support for windows 11 print dialog which is also 2 separate issues (numbering and choices)