Printing HTML in OJS 3.01 using Firefox seems to stop after page 1

Dear all,
I just upgraded to 3.01 and I am getting settled in, but I got an email from a colleague who told me that printing results in printing only page 1.
Is it only me/us? (http://www.inklusion-online.net/index.php/inklusion-online/article/view/377/298)
Thank you!
Best
Frank J.

Hi @Frank_J

I think it is displayed as iframe, thus you could use the option this frame -> print frame... visible on the right click :-\

Best
Bozana

Hi Bozana,
hmm. This sounds really bad, because it is kind of counter intuitive. :frowning:
If the editors have no idea, how should users do?
Maybe there could be a print button somewhere that opens an printversion or in the top bar above the iframe?
This would be helpful.

And I already asked it in the German forum but it got lost somehow. Is there an option to turnoff sending notification emails when creating new messages/mitteilungen?

Thank you!
Viele Grüße
Frank J.

Maybe something like this?

1 Like

Hi @Frank_J

The new print button/option question I will leave to a UI and HTML galley guru :slight_smile:
What notification do you mean, on Settings > Website > Announcements > Add Announcement ? What happens then? – In the code I only read that a trivial notification (that the announcement is successfully created) is created for the current user.
Every user can configure what kind of actions he/she would like to be informed about i.e. not to be informed about, but I do not see announcements actions there, thus I will have to search further…

Thanks!
Bozana

Ah, I think I found the place in the code, where the e-mails are sent: https://github.com/pkp/pkp-lib/blob/master/controllers/grid/announcements/form/AnnouncementForm.inc.php#L191-L213

Hi Bozana,
yeah and it would be nice to have a warning about such a change in behaviour and maybe an option to turn it off. :wink:
Because I experimented with the announcements and send 3 mails to an unknown number of users (up to 3000).
And I am trying my very best not to annoy them :wink:
Best
Frank J.

Yes, I’ll see… At the moment there seems not to be able to turn it off, as journal manager for example…

Hmm, this presents a bit of a bind.

We could add a print button that would print the iframe. But this wouldn’t solve the case when a user initiates the brower’s print functionality directly (ctrl+p or through the browser’s menu). Furthermore, I’m not sure if we want to encourage printing an HTML galley when the vast majority of our users are preparing PDFs for printing.

One more thing that causes me to hesitate to make changes is that, ideally, HTML galleys are going to be a legacy feature. As we move to encourage more of a web-native display within the system architecture (either through our Open Typesetting Stack or through additional fields in the workflow), we’re hoping to make HTML galleys obsolete. I’m not tempted to spend more time on the outdated iframe approach.

Hmm. I get that.
We don’t offer PDFs because it is much more work (and we are running noth on a non-profit but rather on a -x profit base :wink: ).
I haven’t looked into the Open Typesetting Stack thing yet, but it seems painful to convert 300 articles to any new format.
Is the Open Typesetting Stack thing working already? Or is an overview somewhere?
Thankyou!
Best
Frank J.

No, the Open Typesetting Stack isn’t yet ready. I’m thinking 1-2+ years in the future.

I am getting afraid of the future :wink:
I totally see the need for a better solution and converting word to something better sounds great, but it would be nice if there would be a way to convert html files easily.
Best
Frank J.

We had the same problem with users printing from the browser and only getting one page without realizing why. We had one idea: using CSS print-media, replace the contents of the page with a message that says something like ""To print this article, use the embedded PDF reader print function instead of the browser print, or first click to download, open the pdf and then print. This way you ensure a high quality print result with the proper article layout. " Then the user will at least understand what went wrong, and hopefully see the message already in the preview. This would be a simple hack for us, but preferrably there would be a standard PKP solution.

We too have same problems with printing HTML-articles with IE, Ff, Chrome, Opera. Running OJS 3.0.2

Printing PDF-articles results with IE in an incomplete first page, with Chrome the print is full of special signs over the Layout. Printing PDF with Ff and Opera is OK.