Skip to content

(feat) O3-3190: Add print support to FormEngine#543

Open
MohamedAliMefteh wants to merge 4 commits intoopenmrs:mainfrom
MohamedAliMefteh:feat/add-support-for-print-functionality-to-forms
Open

(feat) O3-3190: Add print support to FormEngine#543
MohamedAliMefteh wants to merge 4 commits intoopenmrs:mainfrom
MohamedAliMefteh:feat/add-support-for-print-functionality-to-forms

Conversation

@MohamedAliMefteh
Copy link

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

This pull request introduces a new print feature to the FormEngine, allowing users to print the currently rendered form via a dedicated Print button.

Key enhancements include:

  • Print Functionality Integration: Utilizes the react-to-print library to reference the printable portion of the form.

  • Optimized Print View: Applies @media print rules to:

    • Hide non-essential UI elements.

    • Ensure a clean layout across multiple pages.

    • Prevent page breaks between related elements such as question labels and their corresponding inputs.

  • Cross-Mode Support: The feature works consistently across all FormEngine modes:

    • View Mode:

      • Renders a clean print view.

      • Empty forms hide placeholder elements.

      • Filled forms display answers as expected.

    • Enter Mode:

      • Filled forms print correctly.

      • Empty forms still display checkboxes and radio groups as-is. These should be updated to render as standard input placeholders for print.

      • Images and certain component types should ideally render as empty, or placeholder sections based on future design decisions.

This feature lays the foundation for a consistent and user-friendly print experience, with future improvements planned for component-specific print behaviour.

Screenshots

  • Form-Builder
    • Enter Mode:
formbuilder-entermode.mp4
  • View Mode:
formbuilder-viewmode.mp4
  • Patient-chart:
patientchart.mp4

Related Issue

https://openmrs.atlassian.net/browse/O3-3190

Other

Copy link
Member

@samuelmale samuelmale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MohamedAliMefteh I think rendering some controls like the "Add" button from the repeat section, isn't necessary while in "print mode"

kind="tertiary"
onClick={handlePrint}
size={responsiveSize}>
Print Form
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you localise text?

{t("printForm", "Print Form")}

@samuelmale samuelmale requested review from denniskigen and ibacher May 19, 2025 22:17
… Header with a custom hook for it, adjusted pages and certain elements to not break within the print view
@MohamedAliMefteh
Copy link
Author

@MohamedAliMefteh I think rendering some controls like the "Add" button from the repeat section, isn't necessary while in "print mode"

hey @samuelmale, yeah there is a lot to consider here, I think this works fine especially in 'view' mode, and in 'enter' mode when the form is filled it does the job but when the form is empty like in the form builder, it's not perfect especially in cases where there are questions that render conditionally.

I don't how this feature could be used in a real-life scenario but I would like any guidance so I can adjust it accordingly
and I am trying to see how this feature works in view-mode in the patient chart but I couldn't find where the FormEngine is being used in that mode.

@ibacher
Copy link
Member

ibacher commented May 20, 2025

So, I think we should probably push the discussion here to Slack or (even better) a Jira ticket. Before we leap to "what should the code do?" We really need to answer: "who is printing a form and why are they printing it?"

At a very minimum, I don't see any use for "interactive" widgets like "Upload an Image", "Add", or any boxes labelled "Choose an option". But specific requirements could push other decisions in different directions. Things like:

  • If I'm printing a blank form to fill out by hand, should I be able to select how many copies of expandable sections there are?
  • Should we try to enforce "page" breaks in the form itself when printed?
  • Can we render it in color, or do we need greyscale instead?
  • When should the "Print Form" button be visible? Where should it be? When should it be clickable?

I think without having those requirements clear, we'll never really get anywhere.

As-is, we cannot merge in anything like this without stuffing it behind a feature flag and I'm not sure we've gotten enough of the requirements yet to make it worthwhile doing so.

Thanks for the work on this though! It's definitely an important thing for us to address!

@MohamedAliMefteh
Copy link
Author

Yeah that does make sense, so should i close this for now ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants