Print a step

In this article, you will learn:

How to print all your data when an app is completed
How to design a step that is properly formatted for printing
How to accommodate printing custom widgets on a step

As your company begins automating paper processes and digitizing forms on your Shop Floor, you still may need to print the results of different operations in order to share data properly.

Print app steps

If you want to print data from a Tulip app in real-time (or save to a local PDF), there are four things that you need to do:

Configure a Step (or multiple steps) to match the desired print size.
Design a step that will look organized and understandable when it is printed.
Add a button with a "Print" Trigger.
Customize print settings so that the size of the step fills up as much of the page as possible.

With the "Print Steps" trigger Action, you can print either a single step or an entire Step Group at once. Each step will be printed on a separate page.

Configure step resolution

To start, many users prefer to create a step group called "Reports" and add all the steps that they would like to print at once to that step group.

It looks like this:

Then, it's important to appropriately configure the steps in this group to be printed in the desired resolution. In the app, navigate to the Step Tab in the Side Pane and choose Step Resolution.

Within the side pane, select the desired resolution to match the paper size desired.

In PDF cases, letter portrait is often best to use. Matching the size of the paper will ensure the app view is printed out as a full page.

Design a Step

You may be using a Base Layout in your app with many solid colors. Although this works well for communicating information to an operator, you likely don't want to waste printer ink on colorful Steps.

Instead, you will want to remove all Base Layout elements from the Report steps, and focus on text instead.

Here's an example of a step that is optimized for printing:

This step includes 7 pieces of data from the app, as well as 5 test results. The Print and Menu buttons in the top left and bottom right have a white background so that they do not require colored ink.

It utilizes the following features within Tulip:

Grid widget to create a simple visual layout
Variable text to embed the values of different variables on the step
Button with custom coloring

Add a print button

A print button requires one Trigger Action. It is often combined with an app Completion, but this cannot happen in the same Trigger. You must create a separate button to trigger the app completion.

So, here is an example of a trigger that allows an operator to print a step and go to the step after the "Reports" step group, where they can complete the app:

"Print Steps" "Reports"
"Go To Step" "Next"

You can also place the "Print" button on a normal Step, and use it to print an entire group of steps without even showing them to the operator.

This will open the computer's default print options.

Customize print settings

Print dialogue

Operators use the Tulip Player on screens of all sizes. So, you will need to do the following on each computer that is running the Tulip Player and requires a step to be printed or saved:

Change the page layout to match the resolution of the Steps to be printed. Ex. Letter Portrait.
Save these settings locally as a "preset" so that operators can easily select it in the future:

In order to check that the app will print correctly, you should use the Preview option in the print dialog to see what the app will look like before you print.

Fill in fields on a PDF

You can also print out a "filled in" PDF by embedding the PDF on a Step, and then placing Variable text Widgets on top of the PDF in the appropriate places. The step will print as displayed in the Tulip Player.

Here's how to do that:

Embed a PDF on a step that is sized to the appropriate resolution.
Add Variable text widgets on top of the appropriate fields from the PDF. These will be dynamically filled in when the app is used in the Player.
If the PDF has multiple pages, add a new step in Tulip for each page in the PDF and repeat the pattern above.

Save the app data locally in a PDF

The print dialog is also the best way to save app data on a local computer in a PDF. Rather than pressing Print in the system dialog, select Save as PDF to save the step and live data in a local file.

Technical notes

Rules for which app content will not work well when printed.

Any references to Current Step in a Variable text widget will only work on the step that is open when the Print button is pressed.
On Step Enter triggers do not fire on any printed steps, so you should ensure that the correct data is already added before pressing Print.
Machine Attribute Widget: These will rarely work properly. A better pattern for a report that wishes to capture the last known output is to have a trigger on machine output that stores the output into a local variable, which is then displayed via a custom widget.
Videos: For Youtube videos, the banner image will not load.

Print custom widgets

When you print a Player step, each custom widget is included as a static snapshot of its current content. When you capture a snapshot, the widgets print reliably even when the browser cannot print their embedded frame directly.

Widget snapshot behavior

The snapshot reflects the widget's state at the moment printing begins, including the text, layout, colors, form values, images, and standard two-dimensional canvas content that are on screen.
If the same custom widget is placed more than once on a step, each widget placement prints its own snapshot.
The printed snapshot is static: the widget's JavaScript does not run again while printing. Any change that depends on a beforeprint handler or other print-time JavaScript will not appear. Changes that are made to the widget before printing begins are kept.
To keep the print view static, the snapshot is cleaned up. Inline scripts, inline event-handler attributes (such as onclick, onerror, and onload), and javascript: URLs are removed. This does not affect ordinary text, layout, styling, images, or form values.
The widget's own stylesheets are captured and reapplied, so its styling is preserved. Direct CSS, including @media print rules, affects the printed snapshot, so use CSS for any presentation changes you want to see in print.

The printed widget is rendered in isolation: just as it does on screen, it neither affects the styling of the rest of the printed page nor inherits styling from it. The print view also starts from a clean style baseline, so if your widget depends on specific fonts or colors, set them explicitly in the widget's own CSS rather than assuming a default.

What to expect

Printing aims to reproduce what the widget displays with best effort.

For the most predictable output:

Keep essential printed content in the widget's main document
Use direct CSS for print styling
Make sure important images and data are visible before printing starts
Ensure essential printed information does not depend on print-time
JavaScript, inline event handlers, video or WebGL frames, nested webpages, or externally imported styles.

Limitations

The printed custom widget is not a perfect capture, and content that depends on external resources or browser-specific rendering may differ.

Only content in the widget's main document is captured: Widgets that render their visible UI through Web Components, custom elements, or shadow DOM (for example, Lit) are not captured and will print blank, even though they appear correctly on screen. Widgets built with the common libraries (e.g. Chart.js, D3, and jQuery) render into the main document and are unaffected. Nested iframes are likewise not captured.
Directly readable CSS, including @media print rules, is preserved. External stylesheets and CSS @import rules are best effort and may not load.
The widget snapshot is loaded by the Player's print page and must comply with its security policy:
- A resource (e.g. an image, font, style, background image, or media file) that loads inside the widget's own frame can therefore be blocked when printed.
- Authentication tied to the widget's frame, mixed-content rules, expiring URLs, and relative URLs can also prevent a resource from loading.
Slow external resources may be missing: Printing waits briefly for assets, but it does not guarantee that every resource has finished loading.
Two-dimensional canvases print when their pixels can be captured: Cross-origin (tainted) canvases may be blank, and WebGL canvases generally do not capture.
The current frame of a video is not captured: Video, audio, nested webpages, animations, text selection, focus, hover state, and scroll position are not guaranteed to appear.
If a current snapshot cannot be captured, the widget prints using its initially configured HTML and CSS instead of its current state.

The table below summarizes common printed widget differences and their likely causes:

Printed widget result	Likely cause
An external style or font is missing	The resource may be blocked by the Player's security policy, unreachable from the print page, or still loading when printing began.
Print-specific JavaScript changes are missing	JavaScript does not run in the static print view. For presentation changes, use direct print CSS instead.
Behavior tied to an inline handler is missing	Inline scripts and event handlers (e.g. a `onerror` image fallback) are removed from the static print view. Use direct print CSS instead.
An image is missing	The URL may require authentication that is only available inside the widget, may have expired, may be blocked, or may not have finished loading.
A canvas is blank	Two-dimensional canvases print only when their pixels can be safely captured; cross-origin canvas content cannot be captured, and WebGL canvases generally do not capture.
Video, WebGL, or embedded webpage content is blank	These dynamic or embedded surfaces are not guaranteed to be captured.
A Web Component / shadow-DOM widget prints blank	Only content in the widget's main document is captured. Widgets built with Web Components, custom elements, or shadow DOM (e.g. Lit) are not captured. The common libraries (Chart.js, D3, jQuery) render into the main document and are unaffected.
The printed widget looks like its initial state	A current snapshot could not be captured, so the printed widget used its initially configured HTML and CSS.