Produzione sotto controllo con TERA Printing System

Il TERA Printing System (TPS) è stato sviluppato per rispondere
alle esigenze di controllo e analisi della produzione che ogni giorno di
più diventano importanti in tutte le imprese editoriali nella fase
tecnologica attuale caratterizzata dal tentativo di realizzare flussi di
lavoro completamente digitali, di impiegare macchine CTP e di ottenere un
maggiore controllo dei siti remoti. L’idea alla base del progetto è quella
di raccogliere in un database SQL il maggior numero possibile di
informazioni generate durante il processo di uscita, dal momento in cui
l’applicativo di impaginazione produce il file PostScript di una pagina
fino a quando quest’ultima, passando eventualmente per le fasi di page
pairing e inclusione delle immagini OPI, viene processata dal RIP.
Interrogando il database è quindi possibile monitorare le attività di
stampa e ottenere informazioni come il numero dei lavori in fase di spool,
conoscere lo stato dei lavori accodati e generare report statistici, ad
esempio per sapere quante volte una certa pagina è stata bozzata.
Il TPS si basa sui servizi offerti dal sistema operativo Microsoft Windows
NT 4.0 e dal database Microsoft SQL Server 6.5, un’architettura di base
robusta, performante e flessibile per un sistema che deve necessariamente
integrarsi in realtà produttive del tutto eterogenee. In questo senso, è
fondamentale la connettività di NT 4.0 verso ambienti DOS, Windows,
Macintosh e Unix, nonché la possibilità di interfacciare qualsiasi
dispositivo di stampa utilizzando i più diffusi protocolli di
comunicazione. Le funzioni di interrogazione e reporting vengono realizzate
interfacciando con tecnologia Active Server Pages il server SQL
all’Internet Information Server 3.0 compreso in Windows NT 4.0, in questo
modo è possibile collegarsi al TPS con un browser WEB (Netscape o
Iexplorer) e quindi effettuare interrogazioni via Intranet/Internet e da
qualsiasi piattaforma software supportata dal WEB.
Il TPS è un sistema composto da una serie di moduli e script che
interfacciano le varie componenti al database SQL e che consentono di
integrare le funzionalità di tracking in diversi sistemi con configurazioni
estremamente personalizzate. Per quanto riguarda l’OPI e il page pairing,
TPS utilizza i due prodotti consolidati che TERA ha sviluppato per
l’assolvimento di queste funzioni, TOPIC e PagP.

}Il database
Il database contiene una tabella principale nella quale viene inserita una
nuova riga per ciascun lavoro inviato in stampa. Le colonne previste per
questa tabella nella configurazione standard sono:
Il nome del database, della tabella principale e di ognuna delle colonne
può essere facilmente personalizzato dall’utente, consentendo di registrare
i dati di tracking all’interno di database già esistenti. Inoltre, è
possibile aggiungere altre colonne, per esempio in installazioni dove le
pagine vengono inviate a centri stampa remoti si aggiungono colonne per
registrare gli orari di inizio e fine trasmissione.

Interfacciamento al database
I moduli del TPS alimentano il database utilizzando due diversi sistemi:
direttamente tramite connessioni ODBC e indirettamente tramite servizi
Windows NT che ricevono una descrizione ASCII degli eventi e aggiornano il
database di conseguenza.
Il primo metodo, la connessione ODBC, viene utilizzato da una estensione
del server OPI TOPIC che genera informazioni ogni volta che lo spooler di
Windows NT invia un lavoro ad un device di stampa, aggiornando in questo
modo le colonne startsendtime e endsendtime.
Il secondo metodo viene utilizzato dalle applicazioni client e dai RIP, ed
è aperto per la connessione con altri sistemi. Si basa su di un servizio
NT, denominato Piper, che legge da una pipe la descrizione ASCII di un
evento, per esempio quella generata dal RIP all’inizio dell’elaborazione di
un lavoro, e aggiorna il database di conseguenza. Se le applicazioni client
o i RIP operano in ambienti Unix o Macintosh, è necessario introdurre un
ulteriore passaggio, quello di generare dall’applicazione un file su disco
nella directory monitorata dal modulo MacPipe, che legge il file di
descrizione dell’evento e lo invia al Piper. In questo modo è possibile
realizzare delle configurazioni estremamente flessibili e potenti, in grado
di alimentare il database in base al contenuto di semplici file ASCII
provenienti da qualsiasi applicazione.
Il primo momento in cui il TPS agisce è quello dell’arrivo del file di
stampa (in formato PostScript) sul server NT, il punto di ingresso può
essere una normale coda di stampa NT o il server FTP a seconda che
l’applicativo di impaginazione operi in ambiente Windows oppure Unix. Nel
primo caso, il modulo Includer, che lavora come print processor della coda
di stampa, riceve il lavoro e nel mentre raccoglie le informazioni relative
al nome dell’utente che ha stampato il lavoro, al titolo e alla data di
creazione del lavoro, al nome della coda e del server su cui il documento è
stato stampato. Nel secondo caso, quello di sistema editoriale basato su
Unix, il lavoro di stampa viene ricevuto via FTP e quindi letto dal
programma SPOOLF che interpreta i commenti standard DSC (Document
Structuring Convention) raccogliendo le informazioni relative al nome
dell’utente che ha stampato il lavoro, al titolo PostScript e alla data di
creazione del lavoro. SPOOLF è quindi in grado di indirizzare il lavoro
verso una nuova coda di stampa o di una pipe, nel qual caso è di nuovo un
modulo del TPS, denominato PIPER, a ricevere le informazioni sotto forma di
file ASCII codificato e alimentare il database.

Alla partenza Piper si pone in stato di attesa per un comando proveniente
dalla pipe di ingresso, ogni volta che un nuovo comando viene ricevuto
Piper esegue il comando SQL corrispondente e restituisce tramite la pipe
quanto ritornato dal comando. Piper supporta connessioni multiple, e cioè
più client possono connettersicontemporaneamente a Piper.
I comandi gestiti da Piper sono costituiti da semplice testo ASCII,
suddiviso su più righe, separate da una qualsiasi combinazione di caratteri
CR e LF. Questo conferisce al sistema grande flessibilità e possibilità di
integrazione praticamente illimitate. Sulla prima riga deve comparire il
nome del comando, sulle seguenti i vari parametri da questo richiesti nella
forma =. Segue l’elenco dei comandi attualmente
supportati:

}Tramite un applet del pannello di controllo di Windows NT è possibile
specificare il nome del database e della tabella nella quale Piper deve
registrare i dati ricevuti, e la struttura della tabella stabilendo per
ciascuna delle variabili interne il nome della colonna corrispondente.
Dopo essere passato opzionalmente per la fase di page pairing il lavoro,
tramite una coda di stampa NT o comandi FTP, viene trasmesso al RIP. Anche
in questa fase si possono creare percorsi differenti a seconda delle
necessità del Cliente e della piattaforma hardware sulla quale il RIP
opera. Il caso ottimale è senza dubbio quello in cui il RIP è basato
sull’interprete Harlequin per Windows NT, il livello di integrazione
offerto dal TPS è infatti estremamente completo. In primo luogo, i dati
vengono inviati al RIP utilizzando una connessione socket su protocollo
TCP/IP gestita dal TERA SocketMonitor, un print monitor per Windows NT
realizzato per sfruttare al massimo la banda di rete. Il primo risultato
tangibile è una velocità di trasmissione da server a RIP, su rete fast
ethernet, di 3/4 mega byte al secondo, a cui si aggiunge la robustezza del
protocollo tcp/ip e la possibilità di stampare via SocketMonitor su
qualsiasi device visibile sull’Internet. Grazie all’estrema flessibilità
del RIP Harlequin è stato inoltre possibile sviluppare delle estensioni che
consentono al TPS di monitorare lo stato dei RIP, nonché di raccogliere i
dati statistici di inizio e fine dell’interpretazione e l’esito da questa
avuto. Le estensioni al RIP Harlequin generano in effetti dei file ASCII
che il servzio PIPER, visto in precedenza, legge e trasforma in comandi SQL
di aggiornamento del database.

Horus
Horus è il modulo di monitoraggio e controllo delle code di stampa.
Attualmente è disponibile nella versione per sistemi operativi Microsoft a
32 bit, Windows NT e Windows 95, a breve verrà rilasciato anche nella
versione per Power Macintosh.
Horus si collega al server specificato in fase configurazione tramite una
connessione socket su protocollo tcp/ip, e consente quindi di eseguire
tutte le funzioni di gestione e amministrazione del server di stampa in
maniera remota con una interfaccia utente semplice ed intuitiva. L’uso
della connessione socket su tcp/ip implica la possibilità di sfruttare
collegamenti intranet/internet tra HORUS e il server TPS.
Grazie ad Horus, gli utenti possono sospendere, e riprendere, la stampa di
un lavoro, mettere in pausa una coda di stampa, spostare lavori da una coda
ad un’altra, o anche cancellarli. Alcune di queste funzioni, ad esempio la
cancellazione dei lavori, sono subordinate ai privilegi dell’utente che ne
richiede l’esecuzione. I privilegi devono essere specificati tramite lo
User Manager di Windows NT. Horus consente inoltre di monitorare l’attività
dei RIP interfacciati al sistema e visualizza la connessione tra coda di
stampa e RIP nel caso di installazioni con più code di stampa dirette verso
lo stesso RIP.
Una tipica videata di Horus:
Oltre alle possibilità di controllo interattivo dei lavori di stampa, Horus
fornisce dettagliate informazioni di riepilogo sull’andamento della
produzione:
Tutte le funzioni di report sono implementate tramite degli script IDC,
file di comandi residenti sul server NT che vengono lanciati da Horus con
gli opportuni parametri e ritornano il risultato della query SQL sotto
forma di testo HTML. Segue un esempio di script IDC:
Datasource: Tps
UserName: sa
Expires: 2
DefaultParameters: namep=%%, names=%%
Template: JobName.htx
SQLStatement:
+declare
+@names varchar(255),
+@namep varchar(255)
+select @names=’%names%’, @namep=’%namep%’
+select
+ ripname, pagenumber, printtime, startsendtime, endsendtime, startriptime,
endriptime, riperror, username
+from
+ printlogtable
+where
+ printername like @namep
+and
+ servername like @names
+order by
+ printtime desc, pagenumber, ripname

In questo esempio, Horus fornisce come parametri il nome della stampante
namep e del server names per i quali si vuole effettuare la ricerca nel
database dei campi elencati subito dopo il comando select, ordinando il
risultato della ricerca secondo i campi specificati dopo la frase order by.
Le potenzialità di questo sistema sono senza dubbio evidenti e risultano
ancora di più estese vista la possibilità offerta agli utenti di realizzare
i propri script IDC che vengono aggiunti al menu “comandi” di Horus e che
quindi possono essere eseguiti direttamente dall’applicazione.
I moduli del TPS

TOPIC – OPI
· applicazione nativa a 32 bit, architettura multithreaded
· gestione tutti i formati immagine più diffusi
· genera basse risoluzioni EPS per Mac, Pc e Unix
· genera alte risoluzioni compresse (sia LZW che Jpeg) per lo sfruttamento
ottimale della banda di rete e dei RIP Level2
· ottimizza la separazione CMYK generando immagini DCS, con sub-sampling
del master file per una più veloce uscita in bozza
· riassemblaggio dei piani DCS in fase di stampa
· basse risoluzioni estremamente ottimizzate, i.e. TIFF RGB compressi, con
palette di 256 colori
· totale integrazione con il sistema di spooling di Windows NT
· wizard per la creazione automatica delle code dalle postazioni client
· interfaccia utente semplice e intuitiva

Estensioni a Topic (OPI)
Si tratta di una DLL, che viene caricata dall’Includer e che tramite una
connessione ODBC alimenta il database con le informazioni relative al
passaggio dei lavori nelle code di stampa dello spooler di Windows NT.

Page^Pairer – accoppiamento pagine
· applicazione nativa a 32 bit, architettura multithreaded
· separazione CMYK di file PostScript compositi
· più configurazioni di pairing attive contemporaneamente
· inversione selettiva dei piani colore
· testatine di stampa configurabili
· inclusione di file EPS per l’inserimento degli elementi di riferimento
· wizard per la creazione automatica delle coppie in base alla segnatura
· interfaccia utente semplice e intuitiva

Estensioni a PagP
Dal punto di vista del tracking il PagP si comporta come un RIP: genera
informazioni ogni volta che una pagina viene accodata e ogni volta che,
essendo state accodate entrambe le pagine componenti una coppia questa
viene composta e inviata alla coda, o directory, specificata. Queste
informazioni vengono inviate come comandi ASCII al modulo Piper che
aggiorna il database.

Piper
Lettura comandi di aggiornamento del database via pipe.

MacPipe
Trasferimento dati da file a pipe.

Estensioni al RIP Harlequin
File PostScript letti dal RIP Harlequin al momento dell’avvio e che
generano informazioni di tracking ogni volta che il RIP elabora un lavoro.
Queste informazioni vengono memorizzate in file ASCII, quindi lette dal
modulo MacPipe e tramite il modulo Piper registrate nel database.

HORUS
Monitoraggio e controllo delle code di stampa, reporting.

Il sistema TPS è attualmente installato presso “Il Corriere della Sera”
integrato con ATEX EdPage, “La Padania” e l’ “International Herald Tribune”
dove è collegato al sistema editoriale GoodNews.