Printing PDF with light-gray backgroud

[lirm-math]

When I print a PDF file with SumatraPDF (v3.1.2 64-bit), the background color is not white but light gray.

If I print the PDF file with Adobe PDF Reader, the background is white.

Anyone has the same problem with me?

Original PDF file.pdf

[SumatraPeter]

• Does this happen with every file or a particular one? If the latter, can you share the file?
• Can you test with the latest pre-release version too?

[lirm-math]

This happens with every file I created with TeX Live 2018. To be specific, XeTeX, Version 3.14159265-2.6-0.99999 (TeX Live 2018/W32TeX).
I tried the Pre-Release 3.2.11133 64bit. This happens, too. TestSumatraPrinting.pdf

Please find the attachment for a sample PDF file.

[SumatraPeter]

In that case, have you tinkered with:

• any of the Color values in Sumatra's settings, especially BackgroundColor?
• the Page Background color in Adobe Reader's settings?

Another thing to compare closely would be the print dialog in both apps. Any differences at all in any of the settings selected, say when it comes to printing in color vs. monochrome and other similar stuff?

[lirm-math]

I didn't change anything. Every option has the default value. I tried to print the PDF files in another computer, but the result is the same.

In Adobe, the "Replace Document Colors" is not checked.

What can I do to help find out the problem?

Part of my Sumatra Options: FixedPageUI [ TextColor = #000000 BackgroundColor = #ffffff SelectionColor = #f5fc0c WindowMargin = 2 4 2 4 PageSpacing = 4 4 ] EbookUI [ FontName = Georgia FontSize = 12.5 TextColor = #5f4b32 BackgroundColor = #fbf0d9 UseFixedPageUI = false ]

[SumatraPeter]

Can't seem to think of anything else that might be the cause right now. Perhaps @kjk (the dev) might have an idea...

[GitHubRulesOK]

@kjk this issue raised some questions on my part I naively thought that printing from ANY application to the built in Microsoft to PDF should produce similar output. In fact the outputs from Acrobat, Edge and SumatraPDF appear to have a similar pure white background. However the output PDF file format is unexpectedly significantly different from each. There have been comments that printing from Acrobat is quick and does not stress the printer whilst printing from SumatraPDF seems to take "forever" (exageration) and on occasion undesired dropouts or in this case additional backround colouration. What I observed was the output file size differs significantly, I accept this is not a fair representation of streaming to Hardware and does not explain the core issue above, but it may have some relationship to such problems ? Microsoft PDF from Acrobat=13,2 Kb from Edge=21.4 Kb from SumatraPDF=626 KB !! 1180 from acrobat.pdf 1180 from Edge.pdf 1180 from SumatraPDF.pdf

[kjk]

There are 2 ways to do printing.

One is to send the printer commands like "print text 'foo' at position x, y".

Another is to render to a bitmap and send that bitmap to the printer.

The bitmap method uses much more space but is guaranteed to generate the exactly same results as on screen.

Initially, Sumatra used bitmap method because mupdf doesn't have the code to print PDF to windows printer.

Then zeniko wrote a printing code that used the optimized method. Unfortunately that method wasn't as good as bitmap method so people would complain that some PDFs wouldn't print well.

So we added an option to either print optimized or using the bitmap method.

Then we removed the optimized method because it generated a constant stream of bug reports.

[GitHubRulesOK]

@kjk ok I understand better the large size is microsoft storing pure bitmap rather than other compressed instructions. However the assurance that what is on screen i.e. Blank background (pure white #ffffff) seems to somhow be diluted to an off white in this case when it reaches the paper.

[gaoqiangks]

I encountered the same problem today, and I'm using v3.5.2-64. I deleted my SumatraPDF-settings.txt, but it didn't take affect.

[GitHubRulesOK]

@gaoqiangks There is no need to alter any thing simply use Acrobat Reader (GUI vector edits) or GhostScript (CLI printing), perhaps a picture shows the differences. Acrobat sends one letter at a time to a printer, Edge sends bigger chunks of data, SumatraPDF has to LET MS printing convert the whole page into Images that are written in ginormous pieces and are speckled (dithered)

Thus MuPDF has no print function other to hand over to the vagrancies of Windows system (Artifex use Ghostscript for Printing not MuPDF). It would be same as Convert documents to images and depend on the quality MS decides.

[user1823]

Just wondering, is it not possible to include GhostScript's printing code in Sumatra just like MuPDF code is used to render PDFs? That would hopefully solve most of the printing issues in Sumatra.

If you don't want to include the code in Sumatra, I have another solution:

If a user has GS installed on their system, Sumatra can ask GS to print the file. If GS is not installed, Sumatra would use the current bitmap method. This way, printing will be improved at least for those users who already have GS installed on their system.

[GitHubRulesOK]

@user1823 absolutely no problem it is the same as using GS to read [e]PS as PDF and recently removed for 2ndary process "save as PDF". However the problem lies with constant changes in GS syntax causing high maintenance time and would need a whole raft of options to cater for multiple users systems and preferences.

There is no problem you can send the current page or current filename to GhostScript command see https://github.com/sumatrapdfreader/sumatrapdf/issues/4261#issuecomment-2132299358 but then you will need to add your own custom page sizes and rotation and staples etc.

Simplest is write a GS batch file with Q&A (if needed for what pagesize / which printer) and let SumatraPDF pass the page number and file name to that. but if you need graphic choices Acrobat is far simpler.

[user1823]

Thanks for insights.

Simplest is write a GS batch file with Q&A

Can you share an example if you have it ready?

[GitHubRulesOK]

@user1823 I dont have one to hand as each case will be different and usually write GS commands as one line only perhaps with @file for injecting filenames or settings. They can with checking and comments reach a couple of hundred lines for a more complex set of choices. However as a complex example see line 155 AND 163 of this rotate cmd where only the rotation is requested after other inputs were confirmed.

https://github.com/GitHubRulesOK/MyNotes/blob/master/AppNotes/SumatraPDF/Addins/RotatePDF/Rotate.cmd

For GS it would be simpler to decide on your minimal range of actions such as pick from a list of known printers or set a page size etc. something along the lines of

set "gs=c:\path\gswin32c.exe"
set /p "unknown=whatever I need?"
"%GS%"  -switches=known  -%unknown% -o="%~dpn1.mod" -f "%~dpn1.pdf"
pause

[gaoqiangks]

I reinstalled Windows operating system and fixed the problem. However, months later, it appears again, and it only happens with my HP printer, and works well with my Brother printer.

[GitHubRulesOK]

@gaoqiangks Thanks for an update but if SumatraPDF has not changed for months then the only other recent change was the monthly Windows update ? Either changes to HP drivers or Windows Printing core has somehow affected throughput ?

[gaoqiangks]

@gaoqiangks Thanks for an update but if SumatraPDF has not changed for months then the only other recent change was the monthly Windows update ? Either changes to HP drivers or Windows Printing core has somehow affected throughput ?

I think this may be a driver problem. I test printing a document with Acrobat, Sumatrapdf and Chrome. Paper printed by Acrobat and Sumatrapdf both have light grey background, but not Chrome .

[gaoqiangks]

If quality of printing is set to FastRes 1200, then paper printed has light grey background. If quality of printing is set to ProRes 1200 180lpi, then it didn't.

[GitHubRulesOK]

@gaoqiangks Thanks again for analysis so it seems to be the "FAST" option is not controlling background well ? that is very odd ! but outside of SumatraPDF's control, it simply hands the pixels over and windows tends to use a variable render sometimes seen when zoom in as pale random dithered colouration. One of the reasons Monochrome tends to have odd stipples, seen as random black dots.