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:
View in player:
Print step in editor:
View in PDF document after printing in the player:
Hello,
It seems this issue is still on going.
Is there any chance it could be resolved?
Best regards,
Rémi Bayon
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?
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.
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.
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?
Quality is very poor using screenshot method
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:
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.
If someone is interested in testing this, CSS allows to apply styling based on the type of media the web page is rendered to. For printing, the syntax is the following:
@media print
{
/* any ruleset written here will only be applied when the page is printed */
}
Note that this won’t be of any help if the widget’s state isn’t properly taken into account by the player though 
Also, I had previously asked the Tulip support about the player’s behavior regarding custom widget printing. They gave me the following answer (dating back to 29th December 2025; CW=custom widget, wrt = widget runtime I guess?):
- Tulip waits for a minimum of 3s + (0.25s x number of steps to print) before starting the print
- There is no coordination with the state of the CW wrt to printing, more broadly, we don’t have coordination with any widget wrt to printing
- Past the 3s+ wait, Tulip simply waits for all images in the steps to load before starting the print
This is a bit of a pity that we don’t have a more elegant solution (such as allowing the custom widget to announce when it is ready to be printed).