Form "date" field missing when trying to print

I have sent you the information in a private message, hope you have been able to connect to the project.

Thank-you very much

1 Like

Hi @jborruel
We are in receipt of your message and @Kal_Lam and I have looked at the issue but we cannot replicate the problem you are experiencing. I need to ask you to carry out some trial diagnostics:

  1. Confirm which browsers are giving you this issue, and try out others you may not have tried. (test: browser specific issue)
  2. Could you try this on a different computer from the one you are using and see what comes up? (test: computer specific issue)
  3. Can you try this on a different project from the one you have currently and see whether the problem persists? (Test: project specific issue)
  4. kindly confirm if you had made changes to the form recently?
  5. If you clear your cache, does the problem persist?


1 Like

Hello Stephane,

Thank you for your response, I have tried all the items your have pointed out, and still no luck:

  1. It happens in every browser, Chrome (my usual choice), Edge and Firefox
  2. It happens in my home computer, work computer (both windows) and another personal computer (linux)
  3. It also happens in an old project that was not yet deployed. I have also cloned the project, and happens again… I attach the XLS definition of the project, should you be able to import it and see wether it happens on your end.
  4. I haven’t make changes to the form recently. It used to print out just fine last week, only this week the date and the composite field next to it are missing int he printed forms.
  5. Also tried to clear the cache, still no luck.

It is very strange, as it used to work nicely. We keep pdf output of every form for our records, as we attach them to our processes.

Thank-you very much. Best regards,


aNbYBBtcsAGoQVfcEJgBPw(1).xlsx (9.72 KB)

just an idea:

  • Did you try with different printers?
  • Does it work when you change printer format to landscape?
  • Did you try several prints (as sequence)? Depending on internet strength, we often need several tries from KoBo Preview before ALL text comes out .)
    Kind regards
1 Like

Thank you very much for your suggestions,

I have tried them all, and still same outcome…

I have created another kobotoolbox user, and deployed another simplified copy, and still same result. I am using Enketo with Grid Theme…

And with this idea in my mind, I have revisited: , and tried again :, that has a date field… I fill it up, try to print (even in Linux with Firefox browser, so it is not a brower or OS issue) and it still apears blank. Can you try this yourself? It seems like a Enketo printing problem…

Thank you all for your support

Reviewing the timeline of the issue, I can see that it dates back just on the last enketo update:

Could it have any relation with this issue?

It finally happened to be an Enketo issue.

It has been solved as per:

Hopefully it can soon be released and update within kobotoolbox…

Thank-you very much.



Hi @jborruel,

Kindly please be informed that the new release (Enketo upgrade from 2.3.3 to 2.3.5) on both HHI as well as OCHA server has solved your issue.


You are now able to see the date while printing the same as PDF. Thank you for flagging this issue in the forum and github. Expecting the same in the upcoming days as well.

Have a great day!

Thank you very much for the information and the good news.

On the other hand, I am afraid that there still is some error, as the calculated field next to the date (to the right of the red-lined box in your image) still does not print out right.

It is a calculated field based on the date, I thought that fixing the date printout would as well fix the calculated field, but unfortunately it has not been the case.

Best regards

1 Like

Hi @jborruel,

Would you also mind checking out for other calculated fields and see if it’s an issue with all the calculated fields value or is just a case with this form.

Have a great day!

Hello again,

I have checked several things, and it seems to narrow down to it being a “note” type calculated field.

I have changed it to “text” type instead, and now it prints out just fine.

It is weird, since it used to print fine even with the “note” type before release 2.3.3.

I attach the printout with the “text” type, as it comes out just fine:

Maybe it should be moved to a different issue, since it finally has nothing to do with being a date-dependent calculated field.

Thank you for continuous support. Best regards

1 Like

Hi @jborruel,

Thank you for confirming this!

Have a great day!

Hello @jborruel,

Could you explain for the community, please, which (note related) print problem exist in the new release, Maybe including an example?
“calculated field based on the date”, referenced as ${…}in the note?

A print problem touches Enketo and KoBoCollect users, and it would be great to know about it.
Thanks in advance.

Hello again,

I have made a few tests, and it seems to happen with any calculated field with the “NOTE” type.

Please find here below the test I have made. This is the XLS form of the test:

This is the form as seen in the browser:

And this is the outcome when trying to print:

So no calculated field with the “NOTE” type comes out right, never mind if is contains dates or not.

Hope this helps clarify the error. Best regards,


Hello @jborruel,
As far as I know, a note (label) should NOT be combined directly with a calculation, as in your example…
You should first create a calculate type variable and then reference it inside the label of the note ( as ${…}).
A calculation does not work on a label, but on the value of the variable.
A note only with a calculation, but without a label or hint, gives an error in preview and deployment. So, one of both must be in your example. Could you provide your original note code and a screenshot from the UI?

That I did’t know,… that it could NOT be used directly with a calculation… But it does sound weird, since it does show up right while filling the FORM, but it shows wrong while printing (see images above in previous message).

Moreover when it has been working before, as we have been using it ok in a label field in previous releases.

It is ok with me if you say it shouldn’t be used directly… I have changed the type of the field (although it is then editable, and we don’t want it to be)

Best regards

Hello @jborruel
Sorry, I corrected my previous post. Maybe you can adapt your answer too.
Could you provide your original note code and a screenshot from the UI?
You can set the text field to read_only = true (or yes)… But it seems that there is again the problem with the KoBo print-out.
But the better solution might be first calculate variable, then ${…) reference it in the note label.

My bad, I am not expert in designing forms, and as it worked in the first place, then I assumed it posed no problem.

This is the design i have used for the tests:

type name label hint required appearan calculation default relevant $given_name
begin_group TestDate Test Date Group false w4
select_multiple tipo_r R_type Select multiple Type false w4 horizontal TYPE1
select_multiple tipo_ R_code Select multiple ORG false w4 horizontal ORG1
date R_date Date false w2 now()
text CODE1 Text Full Calculated field false w2 concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code})
text CODE2 Text Calculated field - only date false w2 concat("–",format-date(${R_date},"%Y%m%d"),"–")
note CODE3 Note Calculated field false w2 concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code})
note CODE4 Note Calculated field - no date false w2 concat(${R_code},"-",${R_type},"-",${R_code})
note CODE5 Note Calculated field - only date false w2 concat("–",format-date(${R_date},"%Y%m%d"),"–")

So the whole calculated field I’m using is: concat(${R_code},"-",format-date(${R_date},"%Y%m%d"),"-",${R_type},"-",${R_code})

The screenshots of this examples is in my previou posts (DateTestForm)

Thank you for your interest and support.

There are no calculated fields for R_type and R_code, it was a failure in the table copy/pasted, they are the default values… Sorry

Hello @jborruel,
If you use a Note with a label and a calculation, like you do, KoBo transforms it as a read_only text field. You can see the difference in the UI in preview.
There seems to be bug in KoBo print probably. It doesn’t show the calculated value, if a note or a text field is read_only (and has a calculation) But it seems to works ok with integer and date type.
Here are examples to illustrate:
Note_01.xlsx (10.2 KB) .
and the screenshot (Preview)
and the print-out

A reported the print problem now: Print form loses calculated value for note and read_only text type