In questo articolo imparerai:
- Come stampare tutti i dati al completamento di un’app
- Come progettare una fase correttamente formattata per la stampa
- Come consentire la stampa di widget personalizzati in una fase
Man mano che la vostra azienda inizia ad automatizzare i processi cartacei e a digitalizzare i moduli in officina, potrebbe comunque essere necessario stampare i risultati delle diverse operazioni per condividere correttamente i dati.
Stampa dei passaggi dell’app
Se si desidera stampare i dati da un'app Tulip in tempo reale (o salvarli in un PDF locale), è necessario eseguire quattro operazioni:
- Configurare una fase (o più fasi) in modo che corrisponda alle dimensioni di stampa desiderate.
- Progettare una fase che risulti organizzata e comprensibile una volta stampata.
- Aggiungere un pulsante con un trigger "Stampa".
- Personalizzare le impostazioni di stampa in modo che le dimensioni del passaggio occupino il più possibile la pagina.
Con l’azione trigger “Stampa passaggi”, è possibile stampare un singolo passaggio o un intero gruppo di passaggi in una sola volta. Ogni passaggio verrà stampato su una pagina separata.
Configurazione della risoluzione dei passaggi
Per iniziare, molti utenti preferiscono creare un gruppo di passaggi denominato "Report" e aggiungere a tale gruppo tutti i passaggi che desiderano stampare contemporaneamente.
Il risultato è il seguente:

Successivamente, è importante configurare correttamente i passaggi di questo gruppo affinché vengano stampati con la risoluzione desiderata. Nell’app, accedi alla scheda "Passaggio" nel pannello di contesto e seleziona " Risoluzione del passaggio".

Nel riquadro laterale, selezionare la risoluzione desiderata in base al formato carta desiderato.

Nel caso dei PDF, spesso è preferibile utilizzare il formato Letter verticale. Adattando le dimensioni alla carta si garantisce che la visualizzazione dell’app venga stampata a pagina intera.
Progettare una fase
Potresti utilizzare un layout di base nella tua app con molti colori a tinta unita. Sebbene questo funzioni bene per comunicare informazioni a un operatore, probabilmente non vorrai sprecare l'inchiostro della stampante su passaggi colorati.
È invece consigliabile rimuovere tutti gli elementi del layout di base dai passaggi del report e concentrarsi invece sul testo.
Ecco un esempio di passaggio ottimizzato per la stampa:

Questo passaggio include 7 dati provenienti dall’app, oltre a 5 risultati di test. I pulsanti “Stampa” e “Menu” in alto a sinistra e in basso a destra hanno uno sfondo bianco, in modo da non richiedere inchiostro colorato.
Utilizza le seguenti funzionalità di Tulip:
- Widget "Griglia " per creare un layout visivo semplice
- Testo variabile per incorporare i valori di diverse variabili nel passaggio
- Pulsante con colorazione personalizzata
Aggiungi un pulsante di stampa
Un pulsante di stampa richiede un'azione di trigger. Spesso viene combinato con il completamento dell'app, ma ciò non può avvenire nello stesso trigger. È necessario creare un pulsante separato per attivare il completamento dell'app.
Ecco quindi un esempio di trigger che consente a un operatore di stampare un passaggio e passare al passaggio successivo al gruppo di passaggi "Reports", dove potrà completare l’app:

- "Stampa passaggi" "Report"
- "Vai al passaggio" "Successivo"
È anche possibile posizionare il pulsante "Stampa" su un normale passaggio e utilizzarlo per stampare un intero gruppo di passaggi senza nemmeno mostrarli all'operatore.
In questo modo si apriranno le opzioni di stampa predefinite del computer.
Personalizza le impostazioni di stampa
Finestra di dialogo di stampa
Gli operatori utilizzano Tulip Player su schermi di tutte le dimensioni. Pertanto, sarà necessario eseguire le seguenti operazioni su ogni computer su cui è in esecuzione Tulip Player e che richiede la stampa o il salvataggio di una fase:
- Modificare l’impaginazione in modo che corrisponda alla risoluzione delle fasi da stampare. Es. Letter Verticale.
- Salvare queste impostazioni localmente come "preimpostazione" in modo che gli operatori possano selezionarle facilmente in futuro:

Per verificare che l’app venga stampata correttamente, è consigliabile utilizzare l’opzione Anteprima nella finestra di dialogo di stampa per visualizzare l’aspetto dell’app prima di procedere alla stampa.

Compilare i campi in un PDF
È anche possibile stampare un PDF “compilato” incorporando il PDF in un passaggio e posizionando poi i widget di testo variabile sopra il PDF nei punti appropriati. Il passaggio verrà stampato così come visualizzato in Tulip Player.
Ecco come procedere:
- Incorpora un PDF in uno Step con dimensioni adeguate alla risoluzione appropriata.
- Aggiungere widget di testo variabile sopra i campi appropriati del PDF. Questi verranno compilati dinamicamente quando l’app viene utilizzata nel Player.
- Se il PDF ha più pagine, aggiungere un nuovo passaggio in Tulip per ogni pagina del PDF e ripetere la procedura sopra descritta.
Salvare i dati dell’app localmente in un PDF
La finestra di dialogo di stampa è anche il modo migliore per salvare i dati dell’app su un computer locale in un PDF. Anziché premere “Stampa” nella finestra di dialogo di sistema, seleziona “Salva come PDF” per salvare il passaggio e i dati in tempo reale in un file locale.

Note tecniche
Regole relative ai contenuti dell’app che non funzionano correttamente una volta stampati.
- Qualsiasi riferimento a "Passaggio corrente" in un widget di testo "Variabile" funzionerà solo sul passaggio aperto al momento in cui si preme il pulsante "Stampa".
- I trigger "All'ingresso della fase" non si attivano su nessuna fase stampata, pertanto è necessario assicurarsi che i dati corretti siano già stati inseriti prima di premere " Stampa".
- Widget "Attributi macchina": questi funzionano raramente correttamente. Un approccio migliore per un report che desideri acquisire l’ultimo output noto consiste nell’impostare un trigger sull’output della macchina che memorizzi l’output in una variabile locale, la quale viene poi visualizzata tramite un widget personalizzato.
- Video: per i video di YouTube, l’immagine del banner non verrà caricata.
Stampa di widget personalizzati
Quando si stampa un passo Player, ogni widget personalizzato viene incluso come istantanea statica del suo contenuto corrente. Quando si acquisisce un’istantanea, i widget vengono stampati in modo affidabile anche quando il browser non è in grado di stampare direttamente il frame incorporato.
Comportamento dell’istantanea del widget
- L’istantanea riflette lo stato del widget nel momento in cui inizia la stampa, inclusi il testo, il layout, i colori, i valori dei moduli, le immagini e il contenuto standard della tela bidimensionale visualizzati sullo schermo.
- Se lo stesso widget personalizzato è posizionato più di una volta in un passo, ogni posizionamento del widget stampa la propria istantanea.
- L’istantanea stampata è statica: il codice JavaScript del widget non viene eseguito nuovamente durante la stampa. Qualsiasi modifica che dipenda da un gestore
beforeprinto da altro codice JavaScript eseguito al momento della stampa non verrà visualizzata. Le modifiche apportate al widget prima dell’inizio della stampa vengono mantenute. - Per mantenere statica la vista di stampa, l’istantanea viene ripulita. Gli script inline, gli attributi dei gestori di eventi inline (come
onclick,onerroreonload) e gli URLjavascript: vengono rimossi. Ciò non influisce sul testo normale, sul layout, sugli stili, sulle immagini o sui valori dei campi del modulo. - I fogli di stile propri del widget vengono acquisiti e riapplicati, in modo da preservarne lo stile. Il CSS diretto, comprese le regole
@media print, influisce sull’istantanea stampata; pertanto, utilizzare il CSS per qualsiasi modifica di presentazione che si desideri vedere nella stampa.
Il widget stampato viene renderizzato in modo isolato: proprio come avviene sullo schermo, non influisce sullo stile del resto della pagina stampata né ne eredita lo stile. Anche la visualizzazione di stampa parte da una base stilistica pulita, quindi se il widget dipende da font o colori specifici, è necessario impostarli esplicitamente nel CSS del widget stesso anziché fare affidamento su quelli predefiniti.
Cosa aspettarsi
La stampa mira a riprodurre al meglio ciò che il widget visualizza.
Per ottenere un risultato il più prevedibile possibile:* Mantieni i contenuti essenziali da stampare nel documento principale del widget* Usa CSS diretto per lo stile di stampa* Assicurati che le immagini e i dati importanti siano visibili prima che inizi la stampa* Assicurati che le informazioni essenziali da stampare non dipendano da elementi generati al momento della stampa* come JavaScript, gestori di eventi inline, frame video o WebGL, pagine web annidate o stili importati esternamente.
Limiti
Il widget personalizzato stampato non è una riproduzione perfetta e i contenuti che dipendono da risorse esterne o da un rendering specifico del browser potrebbero risultare diversi.
- Viene acquisito solo il contenuto presente nel documento principale del widget: i widget che rendono la propria interfaccia utente visibile tramite Web Components, elementi personalizzati o shadow DOM (ad esempio, Lit) non vengono acquisiti e verranno stampati vuoti, anche se appaiono correttamente sullo schermo. I widget realizzati con le librerie più diffuse (ad es. Chart.js, D3 e jQuery) vengono visualizzati nel documento principale e non subiscono alcuna modifica. Allo stesso modo, gli iframe annidati non vengono acquisiti.
- Il CSS direttamente leggibile, comprese le regole
@media print, viene conservato. I fogli di stile esterni ele regoleCSS@importvengono gestiti al meglio, ma potrebbero non caricarsi. - L’istantanea del widget viene caricata dalla pagina di stampa del Player e deve rispettare la relativa politica di sicurezza:
- Una risorsa (ad esempio un'immagine, un font, uno stile, un'immagine di sfondo o un file multimediale) che viene caricata all'interno del frame del widget stesso può quindi essere bloccata al momento della stampa.
- Anche l’autenticazione legata al frame del widget, le regole sui contenuti misti, gli URL con scadenza e gli URL relativi possono impedire il caricamento di una risorsa.
- Le risorse esterne lente potrebbero non essere presenti: la stampa attende brevemente le risorse, ma non garantisce che il caricamento di ogni risorsa sia stato completato.
- Le tele bidimensionali vengono stampate quando i loro pixel possono essere acquisiti: le tele cross-origin (tainted) potrebbero risultare vuote, mentre quelle WebGL generalmente non vengono acquisite.
- Il fotogramma corrente di un video non viene acquisito: non è garantita la visualizzazione di video, audio, pagine web annidate, animazioni, selezione di testo, focus, stato di passaggio del mouse e posizione di scorrimento.
- Se non è possibile acquisire l’istantanea corrente, il widget viene stampato utilizzando l’HTML e i CSS configurati inizialmente anziché il suo stato attuale.
La tabella seguente riassume le differenze comuni nei widget stampati e le loro probabili cause:
| Risultato del widget visualizzato | Causa probabile |
|---|---|
| Manca uno stile o un font esterno | La risorsa potrebbe essere bloccata dalla politica di sicurezza del Player, non raggiungibile dalla pagina di stampa o ancora in fase di caricamento all’avvio della stampa. |
| Mancano le modifiche JavaScript specifiche per la stampa | JavaScript non viene eseguito nella vista di stampa statica. Per le modifiche alla presentazione, utilizzare invece i CSS di stampa diretta. |
| Manca un comportamento legato a un gestore inline | Gli script inline e i gestori di eventi (ad es. un'immagine di fallback in caso di errore ) vengono rimossi dalla vista di stampa statica. Utilizzare invece i CSS di stampa diretta. |
| Manca un'immagine | L'URL potrebbe richiedere un'autenticazione disponibile solo all'interno del widget, potrebbe essere scaduto, potrebbe essere bloccato o potrebbe non aver completato il caricamento. |
| Un canvas è vuoto | I canvas bidimensionali vengono stampati solo quando i loro pixel possono essere acquisiti in modo sicuro; i contenuti dei canvas cross-origin non possono essere acquisiti e i canvas WebGL generalmente non vengono acquisiti. |
| I contenuti video, WebGL o delle pagine web incorporate sono vuoti | Non è garantita l'acquisizione di queste superfici dinamiche o incorporate. |
| Un widget Web Component / shadow-DOM viene stampato vuoto | Viene acquisito solo il contenuto presente nel documento principale del widget. I widget realizzati con Web Component, elementi personalizzati o shadow DOM (ad es. Lit) non vengono acquisiti. Le librerie più diffuse (Chart.js, D3, jQuery) vengono renderizzate nel documento principale e non subiscono alcuna modifica. |
| Il widget stampato appare come nel suo stato iniziale | Non è stato possibile acquisire un’istantanea aggiornata, pertanto il widget visualizzato utilizza il codice HTML e CSS configurato inizialmente. |
Approfondimenti
{{snippet.Hai trovato quello che cercavi?}}
