Improving the print results of custom widgets

Product Suggestions
, ,
1

When printing app steps from Tulip Player (using the “Print Steps” trigger and the “Microsoft Print to PDF” print option), custom widgets are not displayed correctly in the PDF document.

I noticed this issue with two widgets from the Tulip Library:

Example

View in player:

image
image1727×962 85 KB

Print step in editor:

image
image810×739 27.2 KB

View in PDF document after printing in the player:

image
image395×554 1.46 KB

2

Hello,

It seems this issue is still on going.
Is there any chance it could be resolved?

Best regards,
Rémi Bayon

3

The print seems to re-render the step what makes the state of the data different, to the actual appearence.

Have you tried using the newer screenshot trigger and print that one?

4

Hello Thorsten,

The screenshot trigger is fine for the landscape screenshot but for a step in portrait A4, the final quality is a bit bad.

I guess that on a very big screen it is possible to get an acceptable result.

image
image1920×729 62.7 KB

5

To be honest, I don’t see your issues with portrait, but I find other issues, as the custom widgets are also kind of broken and it does not work on step level triggers so you have to use a button and will see the spinner in the screenshot as well.

6

It would be very helpful for us if the Pass/Fail widget could be printed correctly.

The Pass/Fail widget looks much better in a report. Furthermore, it clearly shows three states: Pass, Fail, and Not Processed. This isn’t possible with a checkbox.

We would be very grateful if this issue could be resolved.

7

If we capture as a screenshot we can save as a variable, but how do I print the screenshot as I would have done with the Print Step action?

9

Quality is very poor using screenshot method

10

Hi everyone,

I wanted to provide a quick update on this topic.

I recently received a final response from Tulip Support regarding this issue. After review by Product and Engineering, I was informed that there are currently no plans to implement a fix for the reported behavior. The internal ticket has been closed, although it will remain available for tracking purposes.

First of all, I appreciate the transparency and the clear answer. While this is not the outcome many of us were hoping for, it helps to understand the current status and allows us to plan accordingly.

Based on my experience, there is unfortunately no direct solution available at this time. I also do not consider the screenshot approach to be a complete replacement for “Print Steps”, as several community members have already pointed out concerns regarding print quality and suitability for professional PDF documentation.

For anyone facing the same challenge, possible workarounds could be:

  • Display the underlying value of the custom widget as text in the printed step (for example: “Passed: Yes / No / Not Processed”)
  • Use native Tulip components such as checkboxes or toggles where a printed record is required
  • Use shapes, colors, icons, or other standard elements to visually represent the status in a print-friendly way

From my perspective, this limitation mainly affects use cases where printed or archived records are required, such as quality inspections, audits or production documentation.

Thank you to everyone who contributed feedback and examples over the years.

If anyone discovers additional workarounds or alternative approaches, I would be very interested to hear about them.