Ewriter "Print Topic" truncates text: DPI issue?

[Tim Frost]

On one of my machines, I cannot find settings that do not truncate (omit) the last half-dozen or so characters on each full-width line, and also the last few lines of text on each page, leaving truncated character glyphs in each case. I have tried printing to Microsoft Print to PDF with and without shrink to fit, and at various percentage scalings, with A4 and letter page settings, with different margin settings in the driver. I have also printed to real printers and to other 'save file' drivers. I have no issues like this when printing from other applications.

This happens on v4 and earlier Ewriter versions, and only on a machine which has two monitors, one of which is set to 196 ppi and the other 120 ppi. It happens when the program is running on either monitor, but not on another machine where both monitors are 120 ppi.

[Tim Green]

Hi Tim,

Which print option are you using? The Print icon in the eWriter toolbar at the top or the skin's own print option in its hamburger menu? The skin's own option should work better, generally, because it will generate a printable page in your browser first.

[Tim Frost]

I am using the Print Topic button, top right, the same function as Print Topic in the menu top left. This is a quick and simple way to make a PDF of a single topic for review by a colleague. And also, a customer might find this before the hamburger menu. No problems with printing from a browser.

[Tim Green]

I am using the Print Topic button, top right, the same function as Print Topic in the menu top left. This is a quick and simple way to make a PDF of a single topic for review by a colleague. And also, a customer might find this before the hamburger menu. No problems with printing from a browser.

Please try the skin's Printable Version option in its hamburger menu. Do you get the same result there?

[Tim Frost]

No, there are no issues when the topic is opened in a browser first, which, as you said, is what the button in the hamburger menu does I am aware there is a simple workaround, but I am simply trying to help by reporting what looks to me, and perhaps to some of our users, like a bug. If the Print Topic button was reliable I would probably remove the hamburger menu item from the skin, to keep things simple for our users. As it is, I don't like having to advise users not to try the Print Topic button if they have dual monitors, so we may just decide to scrap the top Ewriter menu line. I posted in the other thread concerning the appearance of this menu before I was aware that Print Topic fails on my own system.

[Tim Green]

Hi Tim,

Don't scrap anything yet, please... I'm sure this is a solvable issue. I just needed to know first where you are experiencing it, so that we know where to look to fix it.

The next question, before I can pass this on to the eViewer developer, is: Do you also see this when using standard skins, or only with these skins? For example, can you reproduce it with one of the regular WebHelp skins with the word "responsive" in its name?

[Tim Frost]

Yes, it also happens with "Webhelp iframes responsive blue"

[Tim Green]

Hi Tim,

Thanks for the information. By the way: The Print tool in the eViewer toolbar actually opens the IE print preview display. Have you tried selecting the Shrink to Fit option there in the right-hand drop-down selector in the toolbar? That should actually fix any truncation problems due to dpi issues or similar.

[Tim Frost]

Yes, my first post in this thread describes what I have tried. I have been writing and testing software that renders documents to printers for much longer than I have been using H&M. But I will not be offended if you point out some simple setting I have missed!

[Tim Green]

Hi Tim,

Sorry for not checking that. As you can imagine, I'm answering a lot of support requests at the moment with all the new users...

[Tim Frost]

Yes, I have been very impressed by the number of responses and at the same time the usual quick resolution of issues! And just after my reply to you I found I had also asked a question of a customer for which he had provided an answer only a few hours earlier.

[Alexander Halser]

Hi Tim,

I am afraid there isn't much we can do about this. Try to export this eBook without a skin - HTML code as basic and simple as possible. If this makes a difference, tinkering with the HTML code in the skin might help.

But in general, the eBook viewer uses the system's internal web browser to display and print content. On Windows, this is notorious MS Internet Explorer / MS Edge. If it doesn't print perfectly, well, it doesn't. Once we manage to build the ebook viewer for MacOS, which is planned, it will be Safari that does the display (and, if possible, printing). But we expect many more limitations and shortcomings depending on the OS version. We won't be able to rebuild Safari, either.