John Warnock, PostScript & PDF: Come i documenti sono diventati digitali

Perché una volta la coerenza dei documenti era così difficile

Prima di PostScript e PDF, “inviare un documento” spesso significava inviare un suggerimento. La stessa pagina poteva apparire diversa a seconda del computer, della stampante, dei font installati o persino delle caratteristiche meccaniche della stampante all'altro capo.

Alcuni fattori rendevano i documenti particolarmente fragili:

• I font non erano garantiti. Se il destinatario non aveva il tuo carattere, il sistema ne sostituiva un altro—cambiando interruzioni di riga, numero di pagine e allineamenti curati.
• Le stampanti parlavano lingue diverse. Una stampante poteva capire un certo insieme di comandi, mentre un'altra li interpretava diversamente—o non li capiva affatto.
• La grafica era incoerente. Un grafico che appariva nitido a schermo poteva stampare frastagliato, spostato o parzialmente mancante, specie passando tra software diversi.
• "Quello che vedi" non era "quello che ottieni." I primi schermi avevano risoluzioni basse rispetto alle stampanti, quindi le anteprime erano spesso fuorvianti.

Questo è il problema su cui si è concentrato John Warnock: output di pagina affidabile. Non “abbastanza vicino”, ma prevedibile—così una pagina progettata su un sistema poteva essere stampata su un altro mantenendo le stesse forme, spaziature e tipografia.

Una rapida anteprima: PostScript vs PDF

Per semplificare:

• PostScript è un linguaggio di descrizione della pagina—un modo per dire a una stampante, passo dopo passo, come disegnare una pagina.
• PDF è un formato di file—un contenitore che impacchetta la descrizione finale della pagina (più font, immagini e altri dettagli) in modo che viaggi bene.

Cosa otterrai da questo articolo

Questa guida è per lettori non tecnici che vogliono la storia dietro i documenti moderni: come l'editoria e la stampa sono diventate affidabili, perché il comando “salva come PDF” funziona così spesso e cosa ci insegnano ancora PostScript e PDF sulla creazione di file che si comportano allo stesso modo ovunque.

John Warnock: la persona dietro l'idea di descrizione della pagina

John Warnock era un informatico che ha passato gran parte dei suoi primi anni a pensare a un problema sorprendentemente pratico: come descrivere una pagina in modo che si stampi sempre nello stesso modo, su qualsiasi macchina.

Prima di Adobe, lavorava in ambienti di ricerca dove le idee venivano esplorate molto prima che esistessero prodotti. Al Xerox PARC negli anni '70, i team sperimentavano con stampanti in rete, interfacce grafiche e modi per rappresentare pagine complesse. Stampare non era solo “inviare testo a una stampante”—significava mescolare caratteri, linee, forme e immagini, e farlo in modo affidabile.

Il problema di stampa su cui si è concentrato

La questione centrale era la discrepanza. Un documento creato su un sistema poteva sembrare corretto sullo schermo ma rompersi quando veniva stampato su un altro dispositivo con risoluzione, font o capacità differenti. Per aziende, editori e designer, quell'incoerenza si traduceva direttamente in costi: ristampe, ritardi e correzioni manuali.

“Device-independent” in parole semplici

Output device-independent significa che non descrivi come una stampante specifica dovrebbe disegnare qualcosa; descrivi cosa è la pagina. Per esempio: “posiziona questo paragrafo qui con questo font”, “disegna una linea da 0,5 punti”, “riempi questa forma con questo colore.” La stampante (o un altro interprete) converte poi quella descrizione nei punti che può effettivamente produrre.

Warnock aiutò a portare questo approccio dalla ricerca agli strumenti di tutti i giorni. Co-fondando Adobe nel 1982, lui e i colleghi confezionarono le idee di descrizione della pagina in software che poteva girare su sistemi diversi e pilotare stampanti differenti. Il significato non stava in una singola invenzione isolata—starebbe nel trasformare un concetto tecnico in un ponte affidabile tra computer e pagine stampate.

PostScript spiegato senza gergo

PostScript è un linguaggio di descrizione della pagina—un modo per descrivere una pagina finita così che qualsiasi stampante compatibile possa disegnarla nello stesso modo.

Un'analogia semplice: se un file di word processor è come una bozza nella tua cucina (modificabile, piena di note, stili e impostazioni), PostScript è la ricetta che consegni a uno chef professionista. Non dice “fallo bello.” Dice esattamente cosa mettere dove, in quale ordine e con quali misure.

Cosa descrive effettivamente PostScript

PostScript può descrivere i componenti fondamentali di una pagina stampata:

• Testo: quale font usare, quale dimensione e dove vanno le righe.
• Forme e linee: riquadri, curve, righe e altra grafica.
• Immagini: come posizionare una foto sulla pagina e come mappare i suoi pixel.
• Posizionamento: coordinate precise, così margini, colonne e allineamenti restano costanti.

Pensalo come istruzioni per un robot disegnatore molto letterale. Se le istruzioni sono le stesse, il risultato dovrebbe essere lo stesso—sia che l'output sia una stampante da ufficio o un imagesetter di fascia alta.

Perché le descrizioni vettoriali erano importanti

Una grande ragione per cui PostScript fu una svolta è che molto del suo contenuto è basato su vettori: descrive la grafica come matematica (linee, curve, riempimenti) piuttosto che come una griglia fissa di pixel.

Questo significa che un logo, un titolo o un diagramma possono essere ingranditi per un poster o rimpiccioliti per un biglietto da visita rimanendo nitidi—niente bordi sfocati dovuti allo “stretch” dei pixel.

Cosa PostScript non è

PostScript non è un formato di word processor. Non è pensato per la collaborazione, per il tracciamento delle modifiche o per il riformattare agevolmente il testo. È più vicino a una descrizione finale di output—ottimizzata per la stampa affidabile più che per la scrittura e la revisione quotidiana.

Come PostScript ha permesso il desktop publishing e una stampa migliore

Prima di PostScript, “quello che vedi è quello che ottieni” spesso significava “quello che vedi è una speranza.” La svolta fu un modo condiviso di descrivere una pagina così che il computer e la stampante potessero concordare sulle stesse istruzioni.

La catena del desktop publishing, end to end

Il desktop publishing formò rapidamente una catena prevedibile: authoring → impaginazione → output.

Un autore scriveva il testo in un word processor. Un designer lo inseriva in un'app di impaginazione, scegliendo colonne, spaziature e immagini. Poi il layout veniva inviato a una stampante PostScript (o a un service bureau) dove la stessa descrizione di pagina veniva interpretata per disegnare la pagina finale.

Poiché PostScript descriveva la pagina in modo device-independent—forme, testo, posizioni e curve—le stampanti non dovevano più “indovinare” come approssimare lo schermo. Eseguivano un insieme preciso di comandi di disegno.

Perché le stampanti PostScript rendevano credibile il WYSIWYG

Una stampante abilitata PostScript diventava di fatto un piccolo motore di pubblicazione. Poteva rendere grafiche vettoriali in modo pulito, posizionare gli elementi con precisione e produrre pagine coerenti da un lavoro all'altro.

Quella coerenza rese le decisioni di layout più affidabili: se un titolo stava sullo schermo, era molto più probabile che stesse sulla carta. Questa affidabilità rese il desktop publishing praticabile per brochure, newsletter, manuali e pubblicità.

I font: il dettaglio silenzioso che fa la differenza

La tipografia è centrale per la pubblicazione professionale e PostScript supportava font outline scalabili che si stampavano nitidi a molte dimensioni.

Ma gli errori succedevano ancora:

• Font mancanti potevano causare brutte sostituzioni e rientri di testo.
• Alcune stampanti avevano memoria limitata, bloccandosi con pagine complesse o immagini ad alta risoluzione.
• Diverse implementazioni di stampanti potevano esporre casi limite, specialmente con font insoliti.

Anche con questi problemi, PostScript ridusse la fonte principale di caos: la stampante non “interpretava” più il tuo documento a modo suo—seguiva la descrizione di pagina.

Stampa e prepress: perché la prevedibilità contava

La stampa commerciale non è solo “invia un file e premi stampa.” Il prepress è il passaggio in cui un documento viene controllato, preparato e convertito in qualcosa che una pressa può riprodurre in modo affidabile. La priorità principale è la prevedibilità: lo stesso lavoro deve apparire uguale oggi, domani e su una macchina diversa.

Di cosa aveva bisogno il prepress dai documenti digitali

Le tipografie si preoccupavano di alcuni risultati pratici:

• Separationi: separare la pagina per inchiostri (tipicamente CMYK) così ogni lastra stampa le parti corrette dell'immagine.
• Proof: anteprime veloci e affidabili che approssimano il risultato finale, così da individuare errori prima di sprecare lastre e tempo sulla pressa.
• Output coerente: testo sempre nitido, immagini nella posizione giusta e colori che non cambiano inaspettatamente.

Queste esigenze spinsero tutti verso formati che descrivevano le pagine in modo device-independent. Se la descrizione della pagina è completa—font, vettori, immagini e istruzioni colore—allora la stampante non deve “indovinare” come renderla.

Il workflow classico: PostScript → RIP → lastre

Per anni uno schema comune era: un'app di design generava PostScript, e la tipografia lo eseguiva su un RIP. Un RIP (Raster Image Processor) è software o hardware che converte le descrizioni di pagina in dati a pixel che una stampante o un imagesetter può outputtare.

Quello step intermedio contava perché centralizzava l’“interpretazione”. Invece di affidarsi al driver della stampante o al dispositivo d'ufficio usato, il fornitore di stampa poteva eseguire i lavori attraverso un RIP controllato, tarato per la loro pressa, carta, metodo di retinatura e inchiostri.

Quando la prevedibilità è l'obiettivo, la ripetibilità diventa un vantaggio competitivo: meno ristampe, meno contestazioni e tempi di consegna più rapidi—proprio quello che richiede la stampa professionale.

Perché è stato creato il PDF e cosa ha cambiato

PostScript fu una svolta per la stampa, ma non era progettato per essere un formato “da mandare a chiunque”. Un file PostScript è essenzialmente un programma che descrive una pagina. Questo funziona bene quando una stampante (o un tipografo) ha l'interprete giusto, ma è scomodo per la condivisione quotidiana: la visualizzazione poteva essere incoerente, l'output variare a seconda del dispositivo e il file non si comportava naturalmente come un documento autosufficiente che si può aprire su qualsiasi computer.

Il problema che il PDF voleva risolvere

PDF è stato creato per rendere i documenti portabili nel senso pratico: facili da distribuire, facili da aprire e prevedibili nel modo in cui vengono renderizzati. L'obiettivo non era solo “si stampa”, ma “appare uguale ovunque”—su schermi diversi, su stampanti diverse e su sistemi operativi diversi.

PDF come pacchetto, non solo descrizione

Un cambiamento chiave fu trattare il documento come un unico pacchetto. Invece di dipendere da pezzi esterni, un PDF può includere (o riferirsi in modi controllati) ciò che serve per riprodurre le pagine:

• Il contenuto e il layout della pagina (testo, grafica vettoriale, immagini)
• I font (spesso incorporati, così i font mancanti non cambiano gli a capo)
• Informazioni colore e intenti di output
• Metadati (autore, titoli, tag per l'accessibilità e altro)

Quell'impacchettamento è il motivo per cui un PDF può preservare impaginazione, spaziature e dettagli tipografici anche anni dopo.

Un formato che funziona per schermo e stampa

PDF fa da ponte tra due mondi. Per la visualizzazione a schermo supporta rendering veloce, ricerca, collegamenti ipertestuali e annotazioni. Per la stampa conserva geometria precisa e può portare le informazioni richieste dai flussi professionali (font, colori spot, box di taglio e altre impostazioni orientate alla stampa). Il risultato: un file che si comporta come un documento finale, non come un insieme di istruzioni che potrebbe essere interpretato diversamente a seconda di dove viene aperto.

PostScript vs PDF: il confronto pratico più utile

PostScript e PDF sono spesso citati insieme perché entrambi descrivono pagine. Ma sono stati costruiti per lavori diversi.

PostScript: un programma che disegna una pagina

PostScript è un linguaggio di descrizione della pagina—un insieme di istruzioni come “usa questo font”, “disegna questa curva”, “posiziona questa immagine qui” e “stampala a questa esatta dimensione.” Una stampante compatibile PostScript (o un software chiamato “RIP”) esegue quelle istruzioni per produrre l'output finale.

Per questo PostScript si adattava storicamente al mondo della stampa: non è solo un contenitore di contenuti, è una ricetta precisa per come la pagina dev'essere resa.

PDF: un file pensato per essere condiviso e letto

PDF è un formato di file progettato affinché un documento possa essere visualizzato, scambiato, annotato e archiviato con aspetto coerente su dispositivi diversi. Invece di essere “eseguito” come un programma, un PDF viene tipicamente interpretato per la visualizzazione da un visualizzatore (Acrobat, un browser, un'app mobile) e può anche essere stampato.

In termini pratici: PostScript è più vicino a “istruzioni per la stampante”, mentre PDF è più vicino a “il documento che invii”.

Quando si usano oggi (livello alto)

PostScript è ancora presente dietro le quinte nei flussi di stampa professionale e nel prepress, specialmente dove RIP dedicati e server di stampa gestiscono i lavori in ingresso.

PDF è il formato di default per la condivisione di documenti finali—contratti, manuali, moduli, proof—perché è facile da aprire ovunque e preserva il layout.

Un confronto semplice

Se vuoi ricordare una cosa: PostScript è stato creato per produrre la pagina; PDF per consegnarla.

Come il PDF ha plasmato i flussi digitali moderni

PDF è diventato silenziosamente la “forma finale” di un documento: la versione che invii quando vuoi che l'altra persona veda esattamente ciò che vedi. In molti ambienti, i file Word e le presentazioni sono ancora strumenti di bozza, ma il PDF è il checkpoint—ciò che viene approvato, allegato a una mail, caricato su un portale o archiviato come documento ufficiale.

Il file di consegna universale

Un grande motivo è la prevedibilità. Un PDF mette insieme layout, font, grafica vettoriale e immagini in un pacchetto che di solito si comporta allo stesso modo su dispositivi e app diversi. Questo lo rese ideale per il passaggio di consegne tra team che non condividevano la stessa configurazione—o addirittura lo stesso sistema operativo.

Collaborazione cross‑platform senza sorprese

Con l'uso misto di Mac e PC (e poi Linux su server e in università), il PDF ridusse i problemi del tipo “sul mio computer è diverso”. Puoi creare il documento in uno strumento, rivederlo in un altro e stamparlo altrove con meno cambiamenti indesiderati.

Questo rese anche più semplice standardizzare i flussi di lavoro:

• I team legali potevano distribuire contratti per la revisione senza spostamenti di layout.
• I designer potevano inviare proof a clienti che non possedevano software di design.
• IT poteva distribuire un visualizzatore e supportare un formato per molti casi d'uso.

Automazione dei flussi documentali (dove valgono ancora le vecchie lezioni)

La stessa idea di “output prevedibile e portabile” si ritrova oggi in app interne che generano documenti on demand—preventivi, fatture, report di audit, etichette di spedizione, pacchetti di onboarding.

Se il tuo team costruisce questi sistemi, conviene trattare la generazione PDF come un flusso di lavoro di prima classe: template coerenti, font incorporati, impostazioni di esportazione ripetibili e un modo per tornare indietro quando un aggiornamento di template rompe un layout. Qui entra naturalmente una piattaforma come Koder.ai: i team possono vibe-code un portale documentale interno o un microservizio di generazione PDF da un'interfaccia chat, iterare in sicurezza usando la modalità di pianificazione e snapshot/rollback—pur esportando il codice sorgente quando vogliono la piena proprietà.

Modulistica su larga scala: governo, istruzione, aziende

PDF aiutò istituzioni che gestiscono molti moduli e avvisi. Governi adottarono PDF per domande e documenti pubblici; scuole li usarono per programmi, pacchetti e consegne; aziende li usarono per fatture, manuali e registri di conformità. La aspettativa condivisa divenne: “Se è importante, c'è un PDF.”

La raccomandazione: accessibilità e moduli richiedono cura extra

Un PDF non è automaticamente accessibile. I lettori di schermo spesso hanno bisogno di una struttura taggata correttamente, di un ordine di lettura significativo e di testo alternativo per le immagini. Anche i moduli richiedono impostazioni attente—campi compilabili, validazione e test di compatibilità—altrimenti diventano difficili da compilare o impossibili da inviare. Il PDF può preservare perfettamente un documento, inclusi i suoi problemi, a meno che tu non lo progetti per essere usabile.

Font, colori e immagini: i dettagli nascosti che contano

La maggior parte dei problemi “il mio file appare diverso nel tuo computer” non riguarda il layout—ma gli ingredienti invisibili: font, definizioni colore e dati immagine. PostScript e poi PDF hanno reso questi dettagli più controllabili, ma solo se li impacchetti correttamente.

Font: perché l'incorporamento ha cambiato tutto

I font erano un incubo perché un documento spesso faceva riferimento a un font invece di portarselo dietro. Se la stampante (o un altro computer) non aveva la stessa versione del font, il testo poteva riformattarsi, cambiare a capo o venire sostituito.

PDF risolse molto di questo permettendo il font embedding: il carattere (o solo i glifi necessari) può essere incluso nel file. L'idea chiave è semplice: se il font viaggia col documento, il documento resta stabile.

Colore: RGB vs CMYK in parole semplici

Gli schermi miscelano luce, quindi usano RGB (rosso, verde, blu). La stampa mescola inchiostri, quindi di solito usa CMYK (ciano, magenta, giallo, nero). Un colore brillante su schermo potrebbe non esistere in inchiostro, quindi convertire da RGB a CMYK può smorzare o spostare le tonalità.

Quando il flusso è prevedibile, decidi quando e come avviene quella conversione, invece di lasciarla fare automaticamente all'ultimo momento.

Immagini: risoluzione e compromessi di compressione

Per la stampa, le immagini devono avere dettagli sufficienti alla dimensione finale. Troppo basse e risultano morbide e sgranate; troppo alte e i file diventano pesanti e lenti.

La compressione è simile:

• JPEG mantiene i file piccoli ma può aggiungere artefatti.
• Opzioni lossless preservano la qualità ma aumentano la dimensione.

Checklist pratica pre-stampa

Prima di inviare un file in stampa, controlla: font incorporati, modalità colore prevista (RGB vs CMYK), risoluzione delle immagini alla dimensione finale e che non ci siano artefatti di compressione visibili in foto o gradienti critici.

Standardizzazione e archiviazione a lungo termine

Se PostScript dimostrò che una pagina può essere descritta con precisione, PDF portò l'idea oltre: un documento può anche portare le regole per interpretarlo in modo coerente. La standardizzazione è la differenza tra “si apre sul mio computer” e “si può fidare che appaia uguale tra anni.”

Perché gli standard contano per l'affidabilità

Uno standard è fondamentalmente un contratto condiviso: come devono essere referenziati i font, come si definiscono i colori, come si incorporano le immagini e quali funzionalità sono ammesse. Quando tutti seguono lo stesso contratto, i documenti superano i passaggi—tra app, sistemi operativi, stampanti e fornitori—senza trasformarsi in congetture.

Quella prevedibilità è particolarmente importante quando l'autore originale, la versione del software o la libreria dei font non sono più disponibili.

Casi d'uso di archiviazione e conformità (in parole semplici)

Le organizzazioni spesso devono conservare registri che restino leggibili e visivamente stabili nel tempo: moduli firmati, report, manuali tecnici, fatture, etichette di prodotto o comunicazioni regolamentate. Gli standard non "garantiscono la conformità", ma possono ridurre l'ambiguità rendendo i file autosufficienti e più facili da validare.

PDF/A, in termini generali

PDF/A è una versione di PDF pensata per l'archiviazione. Pensala come un insieme di regole che privilegiano la leggibilità a lungo termine rispetto alle funzionalità appariscenti. In termini pratici richiede cose come l'incorporamento dei font, l'uso di definizioni colore affidabili e l'evitare elementi che dipendono da risorse esterne o comportamenti dinamici.

Quando considerare PDF standardizzati

Pensa a un approccio PDF standardizzato quando:

• Scambi file con tipografie, agenzie o partner esterni e vuoi meno sorprese del tipo “cosa è cambiato?”.
• Conservi documenti per anni e vuoi sicurezza che si renderizzino uguali.
• Hai bisogno di passaggi di revisione/approvazione ripetibili (preflight, impostazioni di esportazione coerenti).

Un passo pratico successivo è definire una checklist interna di esportazione e testarla su alcuni documenti reali prima di applicarla a tutta l'azienda.

Errori comuni e come evitarli

I PDF sembrano “definitivi”, ma la maggior parte dei problemi nasce da pochi punti prevedibili: immagini, geometria di pagina, impostazioni colore e font. Individuarli presto risparmia tempo, ristampe ed edit dell'ultimo minuto.

Bloat del file (condivisione lenta)

Un PDF enorme è di solito causato da immagini non compresse o da duplicati incorporati accidentalmente.

• Esporta con un preset “Press Quality” solo quando necessario; altrimenti usa un preset bilanciato.
• Ridimensiona le foto a un obiettivo sensato (spesso 300 ppi alla dimensione finale per la stampa; molto meno per lo schermo).
• Evita di inserire la stessa immagine ad alta risoluzione più volte se l'app di impaginazione può collegarla una sola volta.

Immagini sfocate o pixelate

La sfocatura è quasi sempre opera di immagini a bassa risoluzione ingrandite.

• Non ingrandire immagini piccole nel layout—sostituiscile con originali ad alta risoluzione.
• Mantieni loghi e icone come vettori quando possibile (SVG/AI/EPS posizionati correttamente), non come screenshot.

Dimensione pagina sbagliata (il problema “perché è tagliato?”)

I box di pagina possono confondere: un PDF può apparire corretto a schermo ma avere impostazioni di taglio/abbondanza sbagliate.

• Conferma che la TrimBox del PDF corrisponda alla dimensione finale.
• Aggiungi bleed (di solito 3 mm / 0,125 in) solo se richiesto dalla tipografia.
• Non affidarti a “adatta alla pagina” nelle finestre di stampa—esporta la dimensione corretta.

Sorprese in stampa: bleed, colore e font mancanti

• Confusione bleed/taglio: Assicurati che colori di sfondo/immagini si estendano nell'area di bleed.
• Cambi di colore: Sai se il lavoro richiede CMYK o RGB; converti in modo coerente e prova un soft proof se disponibile.
• Font mancanti: Incorpora i font all'esportazione o convertili in contorni solo quando necessario (l'outlining può compromettere la chiarezza del testo e la ricercabilità).

Checklist di diagnosi rapida

• Il PDF si apre con la dimensione e orientamento corretti?
• Le immagini sono nitide allo zoom 100%?
• I font sono incorporati (e non sostituiti)?
• Ci sono colori spot imprevisti o artefatti di trasparenza?
• TrimBox/BleedBox corrispondono a quanto richiesto dalla tipografia?

Per una checklist passo-passo di esportazione riutilizzabile, vedi /blog/pdf-export-checklist.

Cosa ci insegnano ancora oggi PostScript e PDF

PostScript e PDF non sono mai stati solo “formati file.” Erano promesse: se descrivi una pagina in modo abbastanza chiaro, può essere riprodotta fedelmente—su stampanti diverse, computer diversi e decenni dopo.

Cosa conta ancora

Due idee hanno invecchiato particolarmente bene: device independence (non legare i documenti a una sola macchina) e fedeltà (quello che approvi è quello che gli altri vedono e stampano). Anche quando tutto è “digitale”, quelle garanzie riducono costosi scambi di e-mail, rifacimenti e incomprensioni.

Dove stanno andando i documenti

Molti contenuti sono ora web-first: layout reattivi, aggiornamenti continui e collaborazione. Allo stesso tempo, le aspettative crescono per l'accessibilità (testo reale, struttura taggata, ordine di lettura) e per contenuti strutturati riutilizzabili across canali.

Questo non sostituisce il PDF—cambia quando lo usi.

Perché il PDF non sparirà

PDF convive con strumenti moderni perché è un formato di consegna affidabile: approvazioni, contratti, record regolamentati, confezionare un progetto finale o inviare un file a una tipografia. Le pagine web sono ottime per leggere e condividere; i PDF sono ottimi per congelare l'intento.

Guida pratica: scegli in base allo scopo

• Usa web/HTML quando hai bisogno di reattività, aggiornamenti frequenti e rintracciabilità.
• Usa file sorgente editabili (documenti, file di design) quando la collaborazione e la revisione sono prioritarie.
• Usa PDF quando hai bisogno di un “finale” stabile, stampa coerente o conservazione a lungo termine—specialmente se puoi esportare un PDF taggato e accessibile.

Se non sei sicuro, scegli il formato che meglio corrisponde al “momento”: bozza, collaborazione, approvazione, pubblicazione, archiviazione. Questa semplice inquadratura è la lezione duratura dell'eredità di Warnock sulla descrizione della pagina.