Button cut and layout problems in pdf print-out for long choices list

[wroos]

Description

Radio-button cut-off in print-out on new page and layout mix-up. And empty starting page. For long choices list in print-out (pdf).

Steps to Reproduce

First example Country01.xlsx (12.5 KB)

1. Import XLSForm Country01
2. Preview and create pdf print-out
3. Look at first page of pdf: EMPTY
   4 Look at page 4 of pdf: Russia lost radio button

Second example LongChoiceList01.xlsx (32.6 KB)

1. Import XLSForm LongChoiceList01
2. Preview and create pdf print-out
3. Look at first page of pdf: EMPTY
   4 Look at page 2 & 3 of pdf:Kuwait and Jordan mix-up of layout (and radio buttons)

Expected behavior

Print-out should neither cut-off elements nor mix-up layout.
Print-out should correspond to preview.

Actual behavior

See examples and print-outs

Additional details

OCHA, XLSForm, new Enketo release (09/07/2020)
See also previous bug report: Print cut-off for long choices list. Sorry, we would appreciate if previous bug examples are used for development testing before publishing new release.

[stephanealoo]

Hi @wroos
Thank you for raising this. Just a quick query, have you tried using the print command Ctrl+P and seen how it behaves too?

Stephane

[wroos]

Dear @stephanealoo,
Sorry, I don’t know what you mean with the Crl+P in THIS context. If I open a form (in Preview) I can’t use this, as far as I can see.
We normally open in preview and use the print icon there to create a PDF print-out of an (empty) questionnaire (as backup for field work)…
Kind regards
Wolfgang

[stephanealoo]

Hi @wroos
While on the print preview and you press Ctrl+P what do you get. Just a quick check if you are on the same form.

Stephane

[wroos]

Sorry, @stephanealoo,
I used Ctrl+PrtSc (function).
If I use Ctrl+P I only get the first item.

Kind regards

[stephanealoo]

Thanks so much. Will try this out on my end and see if the issue is the same. Could you confirm the browser you used for this test.

[wroos]

Hello @stephanealoo ,
Firefox, 78.0.2 (64 bit)
It is a general KoBoToolbox print function. I wouldn’t guess that this might relate to a browser issue.
(We reported the issue before, see above. Astonished, that those input is not followed-up before release?)
Kind regards

[jnm]

@wroos

Astonished, that those input is not followed-up before release?

Please, we more than appreciate your feedback, but let’s keep it constructive

[jnm]

@stephanealoo, @wroos, sorry you’re dealing with this issue. For this and future reference, the general procedure for dealing with Enketo bugs should be:

1. Try the problematic form at https://getodk.org/xlsform/, which always has the latest version of Enketo without any of the custom widgets that KoBo adds;
2. If the problem persists at https://getodk.org/xlsform/, then file a bug at https://github.com/enketo/enketo-express/issues;
3. If the problem does not persist there, then KoBo support must handle the issue. Support staff should please raise the issue with KoBo developers by filing a bug report on the internal tasks GitHub issue tracker and pinging on Flowdock.

NB: KoBo (really Enketo, in this case, as evidenced by ee.humanitarianresponse.info ) is only serving HTML to the browser, even for this print feature. The browser is in charge of converting the HTML to PDF (or sending it to a physical printer), and browsers often vary significantly in their handling of print layouts. I would like for us to support Firefox printing, certainly, but in @Kal_Lam’s test that @wroos is citing, it’s clear to me from the screenshot that Chrome is being used. If Kalyan tested the form and determined that the print layout was correct in Chrome, then I suggest using Chrome until we can figure out the Firefox issue.

[wroos]

Hello,
Thanks for the explanation. Sorry, if you felt something not constructive here.
Just a short hint. The browser that I used for the initial post (and both screenshots attached) was Firefox.

[Kal_Lam]

Hi @wroos,

Would you mind trying it out with Chrome it should work smoothly.

FYR, the image shared below is the screenshot captured in Chrome:

Besides, thank you for flagging it out that the printing breaks in Mozilla. I just made a check and could see the same issue that you are facing while trying to print in PDF with Mozilla:

FYR, the image shared below is the screenshot captured in Mozilla:

So following John’s advise i would request you to use Chrome for the same until the issue is fixed with Firefox.

Thank you for your kind understanding. And once again thank you for bringing this issue to our attention. Would expect the same in the upcoming days as well.

Have a great day!

[wroos]

Hello @Kal_Lam, @jnm,
In the Crome screenshot of Kal_Lam you can also see a layout problem: Iraq / Israel (touching radio-buttons).

To move the issue, we did some more tests: with the two original XLS LongChoiceList01.xlsx and Country01.xlsx
with Chrome and Firefox, with letter and A4 size.
It seems, there are general problems at the page break (except for one of the A4 tests). How they show up seems to depend on the XLS example and on the page size. In one example a choice label is fully lost.
I hope, based on this, someone of you can register now a problem in github.

All prints were done with XLSForm Online (https://getodk.org/xlsform, v2.1.1) and the newest browser versions (11/07/2020)

CHROME (up-to-date. 83.0.4103.116, Official Build, 64-bit)

Example “Country01.xls”
Print Size Letter:
Bad Layout (Spain / Sweden). In addition letters I (i) and I (L) (black-bold?), different to rest grey.

Print Size A4:
Bad Layout (Russia / Sweden). In addition letters l (i) and I (L) (black-bold?), different to rest grey.

Example “LongChoiceList.xls”

Print Size Letter:
Bad Layout (Kuwait / Lebanon, touching). In addition letters l and I (black-bold), different style to rest grey.

Print Size A4:
Bad Layout (Malaysia / Oman). In addition letters l and I (black-

bold), different style to rest grey.

FIREFOX (up-to-date, 78.0.2, 64-bit)

Example “Country01.xls”
Print Size Letter:
Bad Layout (Russia, radio-button lost).

Print Size A4:
Bad Layout (Israel … Jordan), Japan is LOST!

Example “LongChoiceList01.xls”
Print Size Letter:
Bad Layout (Jordan / Kuwait).
\

Print Size A4:
Ok (only here).

Both Browsers
The first page is almost empty, losing a lot of space for in both Forms. I don’t know if this can be optimised now, after page breaks are better managed already.

[Kal_Lam]

Hi @wroos,

Kindly please be informed that the issue has already been lodged as advised by John in the tasks GitHub Enketo's GitHub.

Thank you for all the support provided.

Have a great day!

[wroos]

Thanks, @Kal_Lam,
Maybe the developers can use the 2 XLS examples for testing.
Kind regards

[wroos]

Hello @Kal_Lam,
As the problem persists with XLSForm online (see all recent screenshots) and also Chrome, maybe it should be traced at https://github.com/enketo/enketo-express/issues?

If I understand well jnm: * If the problem persists at https://getodk.org/xlsform/ , then file a bug at https://github.com/enketo/enketo-express/issues.
I leave it up to you, please.

Kind regards
Wolfgang

[Kal_Lam]

Hi @wroos,

Thank you once again for flagging it out. Kindly please be informed that i have created a GitHub issue in Enketo and the same can be followed and tracked here:

Line breaks when printing questions in PDF (in Firefox) with long list of choices

Expecting for similar contribution in the upcoming days as well!

Have a great day!

[wroos]

Dear @Kal_Lam,
Thanks again! (Problem seems to be more around PAGE breaks than line breaks)
You may have a look again at the Chrome examples, please. They are not at all working well. Even your own screenshot has touching radio-buttons/too narrow text lines.

I am sorry, the problem also exists WITH Chrome and the XLSForm Online, as we documented in the examples/screenshots provided. So just going with Chrome and/or XLSForm Online does NOT solve this problem.

Have a pleasant week.
Kind regards