Angular Client Pages Can't be Printed

[Steve Callender]

3.7 Angular Search

When doing an angular search and obtaining search results, if you use the print function that's built into the chrome browser, the print preview does not populate nor does will it actually print the screen.

The Chrome built in print function does work however in the Search The Catalog (Traditional) screen as well as pre-angular screens.

[Jason Boyer (jboyer)]

I've updated the title on this bug because while catalog search results are the most likely place you'll notice this, I've done some checking and *every* Angular page "prints" blank.

[Tiffany Little (tslittle)]

Marking Confirmed, and also seconding that the issue is around using the Chrome (I didn't test on Firefox) browser print function. When using the browser print, you get the blank "prints".

If you go through the Print option on whatever Angular screen you're on, where there's an underlying action trigger print template, you actually get content. It's in tiny font (see: bug 1912504 ), but it doesn't print the same blank page that going through the browser print option does.

[Lindsay Stratton (lstratton)]

FWIW, can confirm that the "blank" prints happen in other browsers (Edge, Firefox, Vivaldi).

It wuld be very useful to staff to be able to quickly print catalog screens, particularly capturing both record summary and cover image elements.

[Bill Erickson (berick)]

Just noting the page is blank because we have custom print CSS that's required for printing miscellaneous HTML (receipts, etc.).

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/eg2/src/styles.css;h=13506c9633563444d4e8298674ae69d846e704b9;hb=HEAD#l200

We'll need a way to optionally enable/disable the @media print {...} stuff depending on the source of the print request.

[Galen Charlton (gmc)]

While hooking onto the beforeprint event gives us an opportunity to munge the CSS, it may or may not be able to distinguish between PrintService initiated a browser print vs. the user doing so.

However, it occurs to me that since we know that receipts, grid printouts, etc. all go through PrintService, we could take a different approach: have the '@media print' CSS not hide the normal web page by default, thus allowing Ctrl-P to work normally. The CSS would flip to printing just the contents of eg-print-container only when the browser print goes through PrintService.

Seems like this should work, although I can imagine that there might be some timing issues during printing and print preview to work through.

[Galen Charlton (gmc)]

If we can pull that off, it would help with bugs such as bug 2003090. While we ultimately probably want to create print templates for such interfaces, being able to just do a browser print would probably tide users over for many interfaces.

[Galen Charlton (gmc)]

What I've outlined is more or less how the AngularJS pages do it. Bill, do you recall why you selected the current approach for the Angular side?