Newsgroup: it.comp.grafica
Titolo: domanda stupida...

devo stampare a intaglio degli adesivi (con dei numeri di
telefono)...ho preparato il file in illustrator CS 2 ma suppongo di
dover prima trasformare la scritta in oggetto...qual'è il comando?
grazie nicole

 
menů testo / crea contorno
oppure
mela (ctrl)/o
ciao

grazie mille...

 dover prima trasformare la scritta in oggetto...
Sono curioso: perché pensi di dover convertire? Te lo ha chiesto il
fornitore?
giordano

no, ma mi hanno consigliato di farlo per non avere problemi quando
darò il materiale alla serigrafia...



 giordano
Trattandosi di intaglio, e non di documento con una mole considerevole di
testo, io consiglio la conversione in tracciato.
Se fornisci il PDF, il grafico lo deve importare; se fornisci il font, il
grafico deve installarlo. Se fornisci semplici tracciati (e generalmente i
driver per plotter ad intaglio flattano tutto in eps, se non erro), vai
liscio come l'olio e l'operatore è felice.
Per lo meno, quando lavoravo in un'azienda che faceva questo genere di
lavoro, funzionava così.
Non sono un amante della conversione in tracciato, ma quando si tratta di
un intaglio con una decina di numeri telefonici, non riesco a trovare un
vantaggio nel non farlo.
-- 
Thunor
"Tutti noi discendiamo dall'uomo delle caverne. Quasi tutti.
Alla base del mio albero genealogico c'è l'uomo delle taverne:
a volte socievole, altre volte asociale;
a volte euforico, altre cupo come il cielo prediluvio."
A.G.P. 

 vantaggio nel non farlo.
Tutto chiaro. Lavorando di rado con la serigrafia, e fornendo in quei
casi le pellicole, mi chiedevo nella mia ignoranza se la conversione in
tracciato fosse una prassi diffusa.
Personalmente avrei fornito un pdf o al limite una eps con font
inserite, ma capisco che per i soggetti serigrafici molto spesso non ci
sia differenza in termini qualitativi e neppure sotto altri aspetti. 
Terrņ presente, grazie mille.  :)
giordano

 giordano
Grazie a te ;-]


 flattano tutto in EPS.
Il Jaguar che ho visto io è un HP-GL sicché, stampando ad esempio da
CorelDraw, mi aspetto che il driver riceva GDI e lo converta in HP-GL
senza vedere PostScript di sorta, ma può essere che esistano rip
PostScript come per i plotter ink-jet.
giordano

 PostScript come per i plotter ink-jet.
Idem come sopra, anzi, se mi erudisci mi fai un grosso piacere ;-]


 Un plotter ad intaglio è visivamente molto simile ad un plotter da stampa
[super-cut]
La *domanda* del post sarà anche *stupida...*, ma la risposta NON lo è di
certo ,)
Ti ringrazio davvero... il tuo argomentato e chiarissimo post è pieno di
utili info ^^
TNX :D 
bye
-- 
maurob [elimina 123 per rispondere]

 utili info ^^
Mi fa molto piacere ;-]


 davvero non so di cosa sto parlando...;-]
Mi sono spiegato di vacca, al solito. Vediamo se riesco a fare meno
peggio.
La prova in Photoshop serve a dare un'idea di quanto la rasterizzazione
di una determinata font differisca da quella del corrispondente
tracciato quando il testo ha una determinata dimensione in punti e la
rasterizzazione avviene ad una determinata risoluzione.
Come si è più volte discusso in passato, una font sia PostScript che
TrueType contiene informazioni (in genere denominate 'hints') che
vengono utilizzate per la rasterizzazione alle basse risoluzioni (cioè
quando i pixel contenuti nello spessore dei caratteri sono pochi):
quando il testo viene rasterizzato (in ambito PostScript ciò avviene nel
rip) il software che realizza la conversione 'aggiusta' preventivamente
il tracciato "nudo e crudo" producendone una versione ottimizzata che
minimizza gli effetti negativi della bassa risoluzione.
Un esempio della differenza tra le due rasterizzazioni si ha
visualizzando, in software come Acrobat e Illustrator, un pdf o una eps
nella quale un testo si trovi giustapposto alla sua versione tracciata:
dal momento che la risoluzione del monitor è molto bassa, la differenza
risulta più marcata; zoomando lo è molto meno e al limite scompare.
Incidentalmente, la conversione automatica in tracciato prodotta
dall'appiattimento della trasparenza (flattening) quando, per esempio,
si esporta un pdf di livello inferiore a 1.4, può generare problemi
proprio per via di questa differente resa del testo rispetto al relativo
tracciato, in particolare quando solo parte del testo viene convertito
(e per questo motivo può capitare che il software offra l'opzione,
apparentemente bislacca, di convertire in outline *tutto* il testo).
Questo è uno dei motivi per cui con i miei clienti io lavoro a livello
1.4 e non 1.3, come sarebbe invece consigliabile per altri motivi.
Il test in Photoshop consente ovviamente niente più che una valutazione
di massima, in quanto ciò che penso accada quando si utilizza eps con
Windows per stampare su un plotter da taglio è che l'applicativo (per
esempio CorelDraw) converte il vettoriale PostScript (font o tracciato
che sia) in vettoriale GDI che il driver di stampa converte a sua volta
in vettoriale HP-GL che il plotter trasforma infine in pixel (spero di
non scrivere boiate).
giordano

 non scrivere boiate).
Deduco quindi che la finale conversione in pixel è imprescindibile.
E' che mi pare un passaggio in più... perchè non commutare semplicemente le
coordinate dei punti e dei vettori nei valori sugli assi cartesiani del
plotter (li chiamo così arbitrariamente, intendendo la corsa della testina
da intaglio con un asse, e la rotazione del rullo con l'altro)?


 da intaglio con un asse, e la rotazione del rullo con l'altro)?
Non sono sicuro di capire questa tua perplessità: puoi provare a
spiegarmela?
Quello che scrivo io è che dal lato software si ha il solito piano
cartesiano (quindi nessuna griglia e nessuna risoluzione) con coordinate
reali (o meglio gestite da numeri floating point con precisione
assegnata dalla singola implementazione dell'interprete PostScript/HP-GL
in uso) mentre dal lato dispositivo, ovvero a livello di interpretazione
del layout e di sua traduzione in istruzioni di stampa comprensibili al
dispositivo, si ha una griglia rettangolare di pixel con coordinate
intere nella quale il processo di rendering decide per ogni elemento
della griglia e per ogni inchiostro se quel determinato pixel va
stampato o no. In altre parole, la parte stampante del dispositivo, per
quanto di alta fascia possa essere, ragiona solo in termini di pixel e
in tali termini devono esprimersi le istruzioni di stampa che vengono
prodotte da un qualsivoglia interprete/driver che riceva in input un
layout espresso nel relativo linguaggio di descrizione della pagina. È
chiaro che nel caso dei protocolli di stampa più primordiali i pixel
possono già essere il modo in cui si esprime l'applicativo (se non
ricordo male così era per una roba chiamata Proprinter che ho
programmato quando facevo meno schifo).
Btw, scrivendo 'output' intendo il termine in senso esteso: gli stessi
ragionamenti valgono paro paro per i monitor, sia quando sono gestiti da
routine grafiche vecchie come le QuickDraw di MacOS e le GDI+ di
Windows, sia quando costituiscono il page device di sistemi DPS (Display
PostScript) o analoghi (tipo OSX).
giordano