Newsgroup: it.comp.macintosh
Titolo: Formati di input dei driver di stampa per OSX

Ciao
Questa è per un nobile scopo, ovvero un dubbio riguardante la faq 111.
Vorrei che qualche esperto mi dicesse dove posso acculturarmi seriamente
circa l'argomento in oggetto.
Per motivarvi vi elargisco il minestrone che attualmente alberga nella
mia scatola cranica:
1) Prima di OSX l'input dei driver di stampa per macintosh era QuickDraw
(eventualmente PostScript se venivano usati in modalità pass through
come da sempre accade con alcuni applicativi per il dtp).
2) Con OSX, ferma restando la possibilità di fare come prima, i
programmi più evoluti possono sfruttare le capacità di Quartz in ambito
pdf inviando al driver i dati in questo formato. In tal caso l'input può
praticamente coincidere (come era anche per QuickDraw) con ciò che
quegli stessi programmi inviano a Quartz per la visualizzazione.
Nel caso di stampa su un dispositivo fisico questo input pdf viene
trasformato in ciò che serve (dal più infimo rasterizzato per stampanti
ad aghi fino al PostScript più avanzato); quando invece si usa la
funzione "Save As PDF" esso viene intercettato da OSX e sistemato in
modo da costituire un documento .pdf fatto e rifinito.
L'enfasi è ovviamente sul caso "Save As PDF", e più precisamente su dove
si colloca l'intervento di OSX ovvero su quanta parte il driver continua
ad avere nell'elaborazione dell'output.
Accetto di buon grado piponi per programmatori esperti ma ditemi, per
favore, dove trovarli: non rimandatemi genericamente a qualche
knowledgebase che mi ci perdo e poi mi dovete venire a riprendere alla
cassa.  x:)
giordano

 ad avere nell'elaborazione dell'output.
Allora un qualunque NSView ha il metodo 
-(NSData*)dataWithPDFIndideRect:(NSRect)aRect
questo sostanzialmente invece che "disegnare" sullo schermo scrive
dentro un oggetto NSData (che poi puoi mandare per dire su file o farci
quello che vuoi) il coso pdf.
Se scrivi l'NSData su file del tipo [data writeToFile:@"name"
atomically:YES] hai un bel pdf con cui fare quello che vuoi.
Questo non č *esattamente* quello che hai chiesto. Ma mettendo insieme
il fatto che un oggetto PDF č pensato per essere indipendente dal device
(quindi schermo o carta, per dire), dovresti ottenere la tua risposta.
Se vuoi maggiori delucidazioni posso provarci, ma al momento non conosco
nei dettagli il sistema di stampa di MacOS X.
Dopo di che immagino che nella maggior parte dei casi non si passi per
degli NSView (nel senso che molti oggetti "da stampare" non
necessariamente hanno un "controllo gui" associato, anzi). O forse non
ho capito la tua domanda?
-- 
L'idiozia trascende il mezzo con cui viene espressa.

 ho capito la tua domanda?
Allora, mi completo.
Abbiamo già visto che NSView ha
-(NSData*)dataWithPDFIndideRect:(NSRect)aRect
Questo comando redirige l'output di (void)drawRect:(NSRect) dallo
schermo al coso NSData. Il metodo drawRect è quello che definiresti tu
a mano se ti facessi una NSView "personalizzata" [ un controllo, un
visualizzatore di qualcosa ]
Ora questo va grosso modo bene per stampare documenti che hanno già una
view associata per stamparli.
Nel caso il codice è banalmente roba del tipo
Immagina di volere stampare la view "aView".
________________________________________________________
| // ottieni le informazioni di stampa
| NSPrintInfo *printInfo = 
|            [NSPrintInfo sharedPrintInfo]; //default.
| NSPrintOperation *pop = [ NSPrintOperation 
|            printOperationWithView:theView]
| 
| /* some more code */
| [pop run];
\_______________________________________________________
Bene. A questo punto ci chiediamo... e se voglio stampare qualcosa che
non ha una view associata in grado di mostrarlo [ per esempio, se
abbiamo una base di dati e vogliamo stamparli, oppure se abbiamo un
editor HTML e vogliamo stampare non il codice, ma la pagina? ]
Semplice, subclassiamo una NSView [ che non manderemo mai a schermo ].
Questa view avrà un designed initializer diverso da initWithFrame [ se
non sei familiare con Cocoa, pensalo come un costruttore ] che prende i
dati da stampare (che disegnerà nella View) e l'oggetto print-info.
Questa ha le dimensioni del documento da stampare (le dimensioni del
foglio di carta si trovano nell'oggetto NSPrintInfo).
La view sarà larga quanto la carta e alta "altezza * n-pagine" (dove
n-pagine è calcolato in base ai dati).
Per gestire le diverse pagine la view avrà i ridefinito i metodi
(BOOL)knowsPageRange:(NSRange *)aRange
(NSRect)rectForPage:(int)pageNum
dentro a drawRect farai disegnare i tuoi dati dentro la view (qui
gestisci come suddividi i dati fra le diverse pagine).
A questo punto hai una "normalissima" view che puoi gestire con il
printOperationWithView: di un oggetto NSPrintOperation.
Sta volta spero di essere stato più chiaro.
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

 Sta volta spero di essere stato più chiaro.
Innanzitutto grazie mille.  :)
Credo però che stiamo parlando di due cose diverse. Vediamo se riesco a
essere più chiaro.
Se ho capito bene, quanto hai scritto conferma che esiste un'API per
realizzare output Pdf piuttosto generalizzati (btw, immagino sia
tacitamente confermata la possibilità di utilizzare come in passato
QuickDraw anche fuori da Classic) e fin qui ci siamo.
Ciò che mi interessa (per la verità anche al di fuori del caso in
questione) è capire come interagiscono, prima durante e dopo questo
output, l'applicativo, il driver di stampa e il sistema operativo, in
particolare quando si chiede il "Save As PDF". Credo sia ciò che si
chiama "architettura di stampa".
Esistono testi (anche a pagamento purché non si tratti di sganciare 500
e passa euro per l'accesso a qualche bibliografia integrale) dove si può
trovare una descrizione di questa architettura e di come le sue diverse
componenti interagiscono?
Chiarisco con qualche esempio a quale tipo di interazione mi riferisco:
- identificazione da parte dell'applicativo del tipo di stampante 
  (PS, QuickDraw, Quartz-Pdf; virtuale o meno) e delle relative 
  impostazioni correntemente selezionati nell'interfaccia di 
  stampa di OSX
- differenze nell'operato del programma a seconda del tipo di stampante
  utilizzato (come da elenco precedente)
- modalità di elaborazione dei dati da parte del driver (standard, 
  pass through, altro)
- ruolo del sistema operativo nel caso di 'stampa' in modalità 
  "Save As PDF".
L'ultimo punto è quello per me di maggior interesse e al riguardo mi
pongo le domande per me più importanti.
Il driver e l'applicativo devono essere implementati in modo da
riconoscere questa particolare situazione oppure la scelta è per loro
del tutto trasparente? Dove e come interviene, se pure interviene, OSX?
Ripeto che non cerco qui su icm le informazioni. Mi interessa solo
sapere dove posso trovarle.
Grazie.
giordano

 del tutto trasparente? Dove e come interviene, se pure interviene, OSX?
<
http://developer.apple.com/documentation/Cocoa/Conceptual/Printing/Task
s/CreatingPrintJob.html>
Qui ti spiega un po' di cose.
Qui qualcos altro:
<
http://developer.apple.com/documentation/Cocoa/Conceptual/Printing/Conc
epts/HowPrintInfoStored.html>
Qua dice di tutto di piů:
<
http://developer.apple.com/documentation/Printing/Conceptual/About_MacO
SX_Printing/index.html>
Sinceramente non ti avevo postato i link perchč credevo li avessi
trovati anche tu (io ho fatto una ricerca "standard" ed č saltato fuori
quello che cercavo).
Ma vedo che in effetti c'č scritto proprio quello che ti serve (o per lo
meno quello che io credo di aver capito ti serva).
In generale:
<
http://developer.apple.com/documentation/Cocoa/Printing-date.html#//app
le_ref/doc/uid/TP30000416-TP30000455>
Sono un po' di pagine in tutto, ma IMHO le puoi scorrere molto
velocemente alla ricerca delle informazioni che cerchi (assumendo che tu
sia familiare con Cocoa, per adesso non ho visto cose oltremodo
impestate, ma confesso che nel link "di tutto di piů" non ho
approfondito piů di tanto, e se qualcosa di impestato c'č, sta li).


 quello che cercavo)
Grazie mille.
No, non li avevo cercati in quanto mi occupo di prestampa e prima di
perdermi nel mare magnum della documentazione disponibile ho pensato di
farmi indirizzare nella giusta direzione: per fortuna ho trovato te.  ;)
Alcune cose le ho già localizzate dando una scorsa ai tuoi link, altre
(ad esempio QuickDraw) ho visto che sono altrove: adesso vado in digest
mode per un paio di lustri, poi se i flutti mi risparmiano torno a
rompervi le scatole.
Intanto grazie infinite.  :)
giordano

 Intanto grazie infinite.  :)
Ma figurati :)
