Pagine pre-renderizzate da immagini
Questa tecnica è molto utilizzata all’interno delle riviste altamente interattive pubblicate utilizzando ambienti come Adobe Digital Solutions: esempi ben noti sono le riviste di Condé Nast (Wired è uno degli esempi più famosi).
Il modo in cui sono implementate queste riviste inizia con la suite dei ben noti strumenti di Adobe Digital Publishing (link), In Design in primis. Questi strumenti sono utilizzati da molti editori in tutto il mondo e le ultime versioni offrono la possibilità di esportare il progetto, oltre all’onnipresente formato Pdf, anche in un pacchetto adatto per la distribuzione attraverso iPad. Gli output di questi file possono essere testati utilizzando l’ App gratuita Viewer Adobe Content scaricabile da App Store, ma naturalmente l’applicazione finale, insieme con l’infrastruttura server necessaria per servire i contenuti, richiede una licenza di livello superiore (e costo…).

Ciò che caratterizza questo tipo di riviste è che al momento della creazione del progetto tutte le pagine vengono pre-renderizzate come jpeg o png e poi gli effetti speciali vengono sovrapposti successivamente.
Ciò significa che la sezione centrale (Core reader) del lettore rivista è essenzialmente un visualizzatore di immagini. Certo queste immagini si estenderanno per una superficie leggermente più grande dello schermo iPad, in modo che saranno inserite all’interno di una visione a scorrimento (scroll view), ma sono ancora solo immagini.
Tutto sommato la scelta tecnicamente non è male: l’iPad è molto veloce nel rendering delle immagini rispetto ai file PDF,  i calcoli necessari per trasformare i dati del  Pdf in bitmap non vengono fatti in questo caso, mentre la CPU sarà sufficiente veloce a decomprimere l’immagine e inviarla all’hardware grafico. Esattamente come abbiamo fatto nel caso PDF, possiamo applicare la tecnica di sovrapposizione e imporla su alcuni contenuti che richiedono l’interazione dell’utente sulla parte superiore dello strato di bottom-rendering.

Mentre questa tecnica è altamente efficiente dal punto di vista del tempo di rendering, ed è semplice da implementare in quanto tutte le complessità del layout di pagina sono state prese in considerazione e risolte con gli strumenti di desktop publishing, offre alcune forti limitazioni che devono essere prese in considerazione:

• ogni singola pagina richiede molto più spazio su disco e il tempo di download di questo tipo di riviste è aumentato  in confronto con una pagina pdf, lo spazio occupato è molto più grande e l’informazione di ogni pixel del testo deve essere fornita nel file e non possiamo neppure alleggerirlo forzando l’immagine con alti rapporti di compressione, se non vogliamo introdurre sfocatura nel testo. La pagina pdf, in particolare quelle pagine fatte di solo testo, è molto più leggera in quanto il testo non è pre-renderizzata e si presenta in formato vettoriale.

• lo zoom o il ridimensionamento dei font non è fattibile: invece, PDF e Core Text ridisegnano il testo utilizzando algoritmi vettoriali e rappresentano i font per dimensioni, questo ovvimente non si puà ottenere se si lavora su un’immagine jpg o png statica. Ciò significa che la rivista ha bisogno di essere disegnata con i tipi di carattere specifici e dimensioni prestabilite, i caratteri che sono adatti per la compressione jpeg (senza sfocatura) e per la risoluzione dello schermo (iPad 1 e 2 hanno 132 dpi, non è poi così alto; le cose andranno meglio con il prossimo iPad schermo retina !)

• Ricerca testo, con la rivista fatta d’ immagini non abbiamo la possbilità evidenziare il testo , e quindi la selezione del testo è impossibile, a meno che gli strumenti di pubblicazione digitale per fare le esportazioni  . insieme all’immagine forniscano anche uno schema  della pagina pre-renderizzata con una mappa completa delle coordinate del testo, qualcosa che non francamente non abbiamo ancora visto ma che noi stessi abbiamo implementato , su richiesta, per alcuni clenti del nostro sistema editoriale i3F Editorial.

Adobe non è il solo sistema con cui è possibile a pubblicare questo tipo di riviste con immagini statiche: ci sono diverse applicazioni personalizzate sul mercato che seguono esattamente lo stesso approccio.
Non è male, ma non sfruttano i grandi framework editoriali che Apple sta offrendo ai propri sviluppatori. Inoltre l’approccio basato sull’immagine ha anche molti altri limiti se confrontato con altre tecniche. Di sicuro un editore che è ha la padronanza degli strumenti dell’editoria digitale può trarre vantaggio da questo approccio, la qualità finale è indubbia e il time to market è il più breve, e al tempo stesso permette di fornire un contenuto adatto per l’iPad , e non solo un pdf adattato sullo schermo.

Ma vorremo raccomandare a tutti gli sviluppatori, che stanno facendo prodotti personalizzati e non stanno utilizzando speciali strumenti di composizione pagina (composition tools) di stare lontano da tale metodologia.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

Core Text  (in breve: CT) è un’altra di quelle tecnologie sviluppate per Mac e in seguito convertita per iOS.
Il framework Core Text è dedicato alla disposizione del testo e alla gestione dei font. Giusto per riassumere le capacità di questo framework, si consideri che è alla base della rivoluzione del desktop publishing che ha reso celebre il Mac in questo settore professionale.
Come Quartz Core Graphic (CG), anche CT (Core Text) ha un API basata su C, esistono comunque diversi wrapper open source di terze parti  che contengono le funzionalità più comuni con un alto livello d’interfaccia Objective-C.
Core Text (CT) non deve essere utilizzato per sostituire il rendering basato sul web a base di Html e Css, questo è un campo troppo complesso
che è meglio lasciare ai componenti di sistema dedicati, come la UIWebView che può essere utilizzata per rendere efficiente un rich text.
CT “comunica” con CG , infatti il rendering del testo è dato contemporanemente al rendering di una view basata su Quartz.
Le due API hanno convenzioni  e regole di gestione della memoria molto simili, per cui lo sviluppatore già abituato con un modello di programmazione “Core Foundation”  non trovera ostacoli nella comprensione della API Core Text.
Questo dà la possibilità allo sviluppatore di mescolare il rendering del testo e le immagini nella fase di rendering stesso (CT è limitata al solo testo, non ha capacità di disegnare l’immagine).

Il motivo principale per usare Core Text è perché questo esegue il rendering del testo direttamente sulla pagina, senza intermediari.
Si differenzia dai formati PDF che considerano ogni pagina come un’intero, si differenzia anche dalle tecniche web di base in quanto non possiede un linguaggio intermedio (come ad es. html) e nemmeno l’interpretazione del layout (css). Con CT si può scrivere direttamente nella pagina.

I componenti di base dietro CT sono oggetti del layout, che sono la traduzione diretta di caratteri in glifi (glyphs), “linee” di caratteri e di “frames”, che corrispondono ai paragrafi. La traduzione dei caratteri in glifi è fatto da “typesetters” e il testo da plottare viene dato attraverso l’utilizzo di stringhe di attributi, che sono stringhe comuni arricchite con informazioni attributo (dimensione del font, colore, ornaments).

Si decide di utilizzare Core Text per una rivista il cui schema sarà principalmente basato su un Testo con layout standard, in modo che si adatterà bene anche per i giornali. Probabilmente non è la scelta migliore per le riviste glamour, dove layout grafico cambia in ogni pagina e potrebbe essere piuttosto complesso.
Un chiaro vantaggio della soluzione basata su Core Text è che, con questo framework, non c’è bisogno di applicare la tecnica di sovrapposizione di cui abbiamo parlato nel paragrafo dedicato al Pdf. Con CT si divide direttamente la pagina in cornici (frames) e ciascuno di questi frames conterrà testo (reso da CT) o elementi multimediali.
Essenzialmente è possibile definire il layout della pagina, definendone la dimensione (che può andare bene per lo schermo iPad oppure può essere con scorrimento pagina verticale o orizzontale), poi si deciderà la dimensione e la posizione dei contenuti multimediali di questa stessa pagina e, infine, si definiranno i frames (diverse cornici rettangolari) che conterranno il testo.
L’organizzazione delle cornici di testo può essere di qualsiasi genere, una compatta struttura a singola colonna, due layout multicolonna o cornici di varie dimensioni. All’interno dei frames dovremo renderizzare il testo e Core Text vi aiuterà a gestire interruzioni di riga per questi paragrafi.
A questo punto si può facilmente fornire all’utente la possibilità di modificare il tipo e la dimensione di font  e lo stesso codice di rendering  può essere riutilizzato per riorganizzare rapidamente il testo all’interno dei frames (cornici).

La rappresentazione del layout di pagina può essere fornita in qualsiasi forma preventivamente decisa dallo sviluppatore assieme all’editore; la scelta migliore sarà il formato XML (tutto sommato è la base di qualsiasi formato di markup!) e che sarà inviato all’applicazione assieme con i testi (ancora in XML) e gli asset in un pacchetto zip file.

Una limitazione del Core Text è che si tratta di una tecnologia per il disegno di testo e non è ottimizzata per la modifica e l’interazione con l’utente, anche se non ne abbiamo bisogno in questa fase. Questo significa che se vogliamo , ad esempio, evidenziare il testo o selezionare e copiare le caratteristiche del testo stesso avremo bisogno di implementarle scrivendo codice.
Il framework ci fornisce alcune API per facilitare questo compito, ma in ogni caso il codice per implementare queste funzionalità deve essere scritto da uno sviluppatore in grado di gestire ogni singolo dettaglio. In ogni caso tutti questi compiti saranno notevolmente semplificati rispetto al PDF: qui, con CT,  si ha il controllo pieno del testo e la sua posizione di schermo, mentre fare quueste operazioni con il Pdf è ancora  piuttosto opaco poichè  il tutto è nascosto dietro una complessa struttura di dati che non si può controllare nella sua interezza.

Concludendo questa terza parte, la nostra raccomandazione è che se si deve implementare una rivista digitale, senza requisiti di layout estremo, con alcuni contenuti multimediali e un controllo veloce e potente di testo,  Core Text è la prima tecnologia da considerare.

Un ottimo tutorial su questo argomento è disponibile a questo link su Ray Wenderlich blog:
http://www.raywenderlich.com/4147/how-to-create-a-simple-magazine-app-with-core-text

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

NDR.
Per approfondimenti sul wrapper di Core Text segnaliamo un articolo: http://akosma.com/2010/07/08/core-text-objective-c-wrapper/

La Rivista / Magazine è un file PDF

Qualora vogliate  impegnarvi a sviluppare una magazine app per iPad, che vi piaccia o meno,  la rivista che avrete a disposizione dall’editore vi sarà consegnata – con molta probabilità -  un file PDF.
Poiché non c’è modo di “sfuggire” da esso, alla fine sarà necessario sviluppare il vostro proprio lettore pdf o integrare qualche libreria gratuita o commerciale esterno. i3Factory ha a questo proposito sviluppato un reader propietario che possiede tutte le caratteristiche necessarie per pubblicare una magazine app alquanto performante.

Il motivo per cui pdf è ancora il formato dominante nel mondo dell’editoria e quindi e-publishing  ci appare chiaro:
la maggior parte degli editori fanno semplicemente il porting delle loro pubblicazioni esistenti e stampate su carta per iPad e iPhone. Questo per sia per ragioni di bilancio, dato che è ovvio che desidera riutilizzare l’investimento fatto nella creazione delle proprie testate e sia perchè gli editori – tranne rare eccezioni -  non possiedono ancora un modello di produzione volto alla piena fruizione multimediale dei propri contenuti.

Pertanto, come sviluppatori, non sarete ancora in grado di sfuggire al formato Pdf con l’eccezione di due casi:
1) la pubblicazione è nuovo di zecca e solo digitale, quindi non ci sono precedenti inparamenti per guidare la scelta finale

2) L‘editore ha grandi budget e / o è una forte esperienza utente (UX), è quindi un reale possessore di capacità di vision futura e crede nella nostra visione  e accetta di allocare il budget extra per ricreare un formato diverso per le proprie pubblicazioni.

In entrambi i casi non sono così rari incontri con quegli editori che hanno già  fatto lo sforzo di portare i propri prodotti sul web (con la notevole eccezione di quelli che ha fatto in Flash!), ma la gran parte delle case editrici piccole e medie imprese sarà ancora bloccata con in formato Pdf.

Purtroppo il Pdf non è il modo migliore per portare un magazine su iPad o altri tablet. E questo per diverse ragioni:

• La pagina di una rivista stampata ha dimensioni solitamente più grande dello schermo iPad o di un Tablet tradizionale: questo significa che quando la pagina si adatta allo schermo, tutti i caratteri appaiono più piccoli e quindi qualcosa di leggibile nella carta stampata potrebbe diventare illeggibile senza zoom, ma lo zoom non è sempre efficiente ed in particolare non è amato da tutti i lettori che possono perdere il loro “orientamento” all’interno la pagina.

• Le pagine di riviste stampate  non hanno le stesse proporzioni dello schermo iPad: questo significa che una pagina che si adatta allo schermo sarà delimitata da righe vuote in alto / basso o destra / sinistra.

• I layout di una pagina stampata spesso sono ottimizzati per lunghezza, per esempio un immagine panorama che si sviluppa
tra due pagine, quando il dispositivo viene tenuto in orientamento verticale, i dettagli grafici andranno persi, invece se il dispositivo è tenuto in orizzontale si sarà in grado di apprezzare le due pagine di layout, ma i caratteri saranno troppo piccolo per essere letti comodamente.

• I file forniti dall’editore non sono ottimizzati per il digitale, normalmente i contorni (tabella dei contenuti) e le annotazioni (Collegamenti a pagine o risorse esterne) non vengono esportati; questo significa che anche se il vostro lettore Pdf è consapevole di queste informazioni, nella maggior parte dei casi non è disponibile e quindi è necessario definire un divero modo di fornirle.

• Il formato ufficiale PDF supporta contenuti multimediali; purtroppo l’IOS non è in grado di gestirlo, per cui  tutti i contenuti interattivi devono essere fornite al di fuori del file pdf e associati ad esso.

Il rendering delle pagine è realizzato in iOS (e anche in OSX) attraverso il Quartz 2D API, cono Core
Graphics framework (CG). Quartz 2D è il motore grafico bidimensionale su cui si basano molte (ma non tutte)  funzionalità di disegno di IOS. Il
PDF API è un sottoinsieme del grande CG API. Questa API è “vecchio stile “e non si basa su Objective-C, ma è in puro vecchio C; oltre a tutte le regole di gestione della memoria che seguirà il Core Foundation (CF) con regole che sono diverse da Obj-C:
questo significa che particolare attenzione deve essere fornita al fine di evitare perdite di memoria, come ad ogni manipolazione la pagina PDF può pesare diversi megabyte e può facilmente innescare il memory watchdog, in tal modo la vostra applicazione potrà crashare.

In ogni caso se si è abituati con i concetti Quartz 2D sarà semplice renderizzare una pagina PDF seguendo questi passaggi fondamentali:

1. Ottenere il riferimento CG alla pagina pdf da trarre;
2. Ottenere il contesto grafico corrente per la vista che contiene la pagina;
3. Istruire Quartz a disegnare la pagina Pdf per il contesto.

Come potete vedere, a parte le fasi necessarie per il disegno del modello Quartz, il rendering completo è compiuto dal sistema e non c’è bisogno di avere alcuna conoscenza del formato dei dati di un file pdf. Quindi per voi il processo di rendering Pdf  è solo una scatola nera, e questo è chiaro quando si nota che tutte le strutture dati CG sono infatti opache e il loro contenuto interno si può accedere solo tramite API.
Ma un reader valido per una rivista in Pdf non può limitarsi al rendering, per cui vi sarà richiesto di supportare ad esempio lo zoom;
ora, il livello massimo di zoom può essere teoricamente molto elevato (non dimenticate che i caratteri nel file Pdf sono come i font
nel computer, non potranno mai perdere in precisione, anche per estremi zoom-in), è impossibile rendere l’intera pagina ingrandita in un canvas molto più alto dello schermo del dispositivo:
Qui abbiamo pixel ,non  vettori, e sarebbe immediato il crash dell’applicazione, perché la memoria è esaurita per una sola pagina. Quindi saremo costretti a introdurre tecniche per limitare il rendering e renderlo efficace per la solo parte visibile della pagina, questo nonè  sempre un compito facile.

Più complessa è l’analisi del documento: questo è necessario se si desidera estrarre contorni,  annotazioni, fare qualche ricerca di testo
ed evidenziare. In tal caso a parte un paio funzioni per estrazione di meta-dati, quello che ti fornisce l’API è un insieme di funzioni che vi permetterà di esplorare le strutture dati all’interno del documento. Non saremo in grado di ottenere qualsiasi informazione dal file se non si esplora l’albero dati (data tree) correttamente e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni che le specifiche PDF hanno ottenuto negli anni e dal fatto che molti editori usano ancora del vecchio software che esporta il contenuto in vecchi formati.

Carlo ha sviluppato un generico PDF Explorer, questo è stato parte di un impegno per un cliente che ha chiesto di sviluppare un generale lettore PDF. E’ risulato davvero difficile applicare tutte le specifiche di riferimento ufficiale del formato PDF, il mio suggerimeto è di concentrarsi sulle funzionalità più utilizzate e test con molti documenti. Come ho detto prima, CG naviga l’albero dei dati (data tree), ma non la interpreta per noi!

L’ultima sezione di questa parte, la spiegazione lunga ma necessaria, data l’importanza del tema, è come fornire contenuti multimediali sulla cima di un file PDF: tutti in tutti i
iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra per la pagina stampata è possibile sfruttare le caratteristiche del dispositivo
e ancora in vantaggio per l’investimento fatto nella creazione rivista.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un messaggio pubblicitario stampato in grado di offrire un video al posto di un’immagine statica, o un link stampato su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o infine possiamo mostrare il tempo corrente utilizzando un widget HTML5. Come ho già detto non è consigliabile introdurre tutti questi contenuti all’interno del file pdf: non sarà reso da quarzo e sarà comunque
costretti ad attraversare la struttura dei dati per estrarre il riferimento all’oggetto CG per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o dei loro software di pubblicazione digitale è troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione”.
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) attirerò tutti sovrapposizioni ed è sensato touches.More utente difficile è l’analisi del documento: questo è necessario se si desidera estrarre contorni, le annotazioni, fare qualche ricerca di testo ed evidenziare. In tal caso a parte un paio di meta-funzioni di estrazione dei dati, che cosa ti dà l’API è un insieme di funzioni
che vi permetterà di esplorare le strutture dati all’interno
il documento. Non sarà in grado di ottenere qualsiasi informazione
dal file se non si esplora l’albero dati in modo corretto
e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni le specifiche PDF ottenuto
negli anni e dal fatto che molti editori usano ancora
vecchio software che esporta il contenuto in vecchi formati.
Ho sviluppato un generico PDF Explorer, questo è stato
parte di un impegno di un cliente che mi ha chiesto di sviluppare
un generale lettore PDF scopo, ma in quanto è davvero difficile
applicare tutte le specifiche di riferimento ufficiale in formato PDF, il mio suggerimento è di concentrarsi sulle funzionalità più utilizzate e test
con molti documenti. Come ho detto prima, CG naviga
l’albero dei dati, ma non la interpreta per noi!

L’ultima sezione di questa parte – la spiegazione lunga ma necessaria data l’importanza del tema – è come procurare i contenuti multimediali di un file PDF:
l’iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra alla pagina stampata è possibile sfruttare le caratteristiche del dispositivo.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un pubblicità in grado di offrire un video al posto di un’immagine statica, o un link su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o, infine, possiamo mostrare le previsioni meteo utilizzando un widget in formato HTML5.
Come abbiamo già detto ,  non è raccomandato introdurre tutti questi contenuti all’interno del file pdf:
non sarà reso da quartz e saremo comunque costretti ad attraversare la struttura dei dati per estrarre l’oggetto CG di riferimento per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o quelle loro software di pubblicazione digitale è spesso troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione” (overlay technique).
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il Rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) disegnerà le sovrapposizioni e sarà sensibile al tocco dell’utente.

Lo strato superiore di overlay è tipicamente costituito da componenti UIKit, quindi dovremo aggiungere un UIWebView html per i widget, si introducono una UIScrollView per visualizzare una galleria di immagini scorrevoli, o faremo aggiungere una vista Media Player per l’esecuzione video.
Di solito le descrizioni in sovrapposizione sono forniti da un file separato, ad esempio, uno di formato XML, JSON o plist, e sara inserito iinsieme  con il file pdf e tutte gli altri (filmati, immagini, file html, file musicali) in un unico file zip.
L’applicazione quindi scaricherà il file zip, lo scompattarà e  utilizzerà la pagina Pdf per riempire il rendering layer, aggungendo le informazioni associate in sovrapposizione a quella pagina per costruire un “overlay layer“.
Si noti che questa tecnica può essere applicata anche nelle altre tecniche di rendering  di cui parleremo nei prossimi articoli, in tal caso ciò permette di superare molti limitazioni del formato pdf.
Il requisito principale per lo sviluppatore è quello di definire un formato adatto, controllare tutte le pagine soggette a zoom e rotazioni con una trasformazione e corrispondente sovrapposizione e, infine, fornire alla casa editrice  gli strumenti e le linee guida necessarie per creare facilmente sovrapposizioni del genere.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

La piattaforma “i3f editorial” si poggia su 4 basi portanti:
- elaborazione e lettura di documenti in formato PDF
- l’utilizzo di web service e network queue
- l’infrastruttura Apple per l’In App Purchase
- i servizi web di ausilio all’editore

Vediamoli in dettaglio.

PDF Reader

Alla base della lettura dei documenti si trova il PDF Reader. Per capire il lavoro che si trova dietro questa tecnologia cominciamo col fare riferimento a quel che iOS fornisce ai propri sviluppatori.
Il supporto PDF e’ un supporto nativo all’interno del framework Quartz, il framework grafico 2D installato in Mac OS X e portato con successo in iOS. Per capire l’importanza del PDF all’interno dei sistemi operativi di casa Apple, basti sapere che il PDF non e’ visto come un qualunque formato di output, ma di fatto qualunque vista grafica all’interno di Mac OS X e iOS puo’ essere riprodotta come un PDF, che di fatto risulta essere il formato principe per la stampa basata su Quartz. Questo spiega perche’ sia in Mac OS X che in iOS il supporto al PDF, sia in ingresso che in uscita, e’ naturale e non richiede l’installazione di software esterni (come avviene per esempio in Windows, dove l’input richiede l’installazione di Adobe Reader, l’output richiede l’utilizzo di appositi plug-in).

Detto questo, cio’ non significa che le cose siano facili. Infatti il supporto fornito da iOS si limita sostanzialmente alla possibilita’ di “leggere” e capire un file PDF, ma limitatamente alle funzioni di rendering su carta o video, mentre l’interpretazione di tutti gli altri dati (outline, thumbnail, annotazioni, ecc.) e’ lasciata al programmatore.
Il PDF Reader fornito con le app prodotte tramite I3F Editorial e’ un continuo work in progress, soggetto a continui miglioramenti e supporto di nuove possibilita’. Attualmente esso offre le seguenti funzionalita’ di base:
- supporto di iPhone e iPad
- rendering veloce della pagina in formato portrait (orizzontale) e landscape (verticale, a due pagine affiancate), con caching per velocizzare le prestazioni
- nessun limite nel numero di pagine supportato (o comunque nessun limite in aggiunta a quelli eventuali forniti dalla piattaforma iOS)
- completamente basato sul motore di rendering di iOS, quindi nessuna sorpresa nel passaggio dell’applicazione tra diverse versioni del sistema operativo
- caricamento dei thumbnail in multi-threading
- mini-thumbnail (stile iBooks)
- funzione scrubbing della pagina (con visualizzazione del numero di pagina e/o del thumbnail)
- pre-caricamento di outline (il sommario con tutta la sua struttura gerarchica) e delle annotazioni (link)
- annotazioni intra-documento (salto di pagina), e verso link esterni
- oltre al supporto standard dei link esterni (http: e mailto: all’interno dell’applicazione, eventuali altri schemi url verso altre app installate dall’utente, esempio skype:) supportiamo dei link proprietari per lo streaming video direttamente dall’app e per la visualizzazione di gallerie fotografiche; cio’ significa che l’editore sara’ in grado di generare dei pacchetti multimediali (file PDF + contenuti multimediali) semplicemente definendo i link all’interno del suo strumento grafico di produzione dei PDF, senza dover appesantire e implementare tutte quelle complicazioni tecniche dovute all’inserimento dei file multimediali direttamente all’interno del PDF (ricordiamo infatti che Quartz non supporta questi tipi di file, di fatto scartando queste informazioni). Il supporto di questi link e’ via via in aumento.
- funzione di ricerca dei testi in multi-threading (ossia la fruizione del documento non viene bloccata)
- salvataggio dell’ultima pagina vista (auto-bookmark)

Gestione della libreria

L’interfaccia di libreria definita da I3F Editorial si basa su alcuni template standard comunemente riconosciuti (esempio: copertine su scaffale stile iBooks, oppure copertine in finestra stile App Store), sebbene I3F Editorial non sia un pacchetto software ma un team di designer e sviluppatori in grado di implementare qualunque richiesta provenga dall’utente. L’iPad e’ una formidabile piattaforma creativa, pertanto sono benvoluti gli editori che vogliono portare questa creativita’ anche all’interno delle applicazioni.
Quel che e’ comune invece e’ l’aspetto tecnico dietro questa approccio. Attualmente la composizione dell’archivio dell’editore, e della libreria utente, sono contenuti all’interno di file (di vario formato, a seconda della complessita’ dell’archivio, si va dal JSON all’XML a veri e propri database SQLITE per le configurazioni piu’ complesse). I file sono gestibili interamente dall’editore mediante la nostra piattaforma web e possono essere installati su server proprietari o in hosting presso i3factory (che si avvale a sua volta di provider di reputata affidabilita’). In ogni momento l’editore e’ in grado di variare la composizione del proprio archivio e renderla immediatamente operativa con un solo click, previo testing pre-pubblicazione possibile sempre mediante le nostre applicazioni.
Una volta che l’archivio viene definito, l’applicazione alla partenza cerca di aggiornarsi all’ultimo stato disponibile. Da questo momento ogni pubblicazione puo’ superare diversi stati: in negozio (se a pagamento), da scaricare (se gratis o gia’ acquistata), da installare, da leggere. Il passaggio di questi stati e’ effettuato in maniera sicura e interamente in multi-threading: cio’ significa che l’utente puo’ interagire con l’applicazione (o addirittura sospenderla nel caso di download) senza dover necessariamente attendere il download dell’intero pacchetto. Inoltre i file multimediali possono essere impacchettati in un unico file – in tal caso pero’ il tempo di download sara’ piu’ lungo – oppure possono essere scaricati su richiesta (questo quando i contenuti multimediali sono ritenuti opzionali alla fruizione del prodotto).

In App Purchase

Facendo seguito alle ultime novita’ introdotte da Apple nelle regole di approvazione delle applicazioni e dei contenuti a pagamento, noi forniamo come soluzione unica di acquisto quella dell’In App Purchase, ossia la possibilita’ di acquistare le pubblicazioni via App Store (ricordiamo che per queste transazioni Apple trattiene il 30% del prezzo applicato al cliente).
In ogni caso i3factory e’ disposto a fornire soluzioni di acquisto complementari all’In App Purchase, basate su pagine web esterne fornite dall’editore. Tali soluzioni non sono fornite come standard e vanno di volta in volta concordate, questo peche’ occorrera’ considerare di volta in volta tutte le complessita’ dovute alla sicurezza delle transazioni e dei pagamenti fatte via web. I3F non effettua alcun tipo di supporto su forme di pagamento diverso da App Store, che dovranno essere quindi curate dal cliente: in tali casi I3F si occupera’ esclusivamente dell’integrazione all’interno dell’applicazione.

I servizi web per l’editore

L’editore sara’ in grado di gestire l’archivio delle pubblicazioni via interfaccia web, basata su metodologie standard Web 2.0. Tale interfaccia consentira’:
- l’inserimento di nuove pubblicazioni
- la definizione dei link multimediali e il caricamento dei contenuti
- la gestione degli archivi (modifica, cancellazione, organizzazione in categorie e testate)
- la possibilita’ di rimuovere temporaneamente dalla vendita certe pubblicazioni
- transazioni cifrate anti-hacking
Ricordiamo che data la presenza dell’In App Purchase, eventuali contenuti in vendita e prezzi dovranno essere replicati all’interno del servizio iTunesConnect di Apple. Per regolamento non possiamo fornire soluzioni che automatizzino questa operazione.
L’intero pacchetto verra’ fornito in pacchetti auto-installanti basati su php e richiederanno da parte del server un supporto software minimo e che riteniamo sia standard nella gran totalita’ delle installazioni adatte a un editore.

Cari Editori,

finalmente abbiamo realizzato un sistema che permette di pubblicare riviste, libri, giornali o qualsivoglia pubblicazione senza alcun costo per ogni nuovo numero o per ogni nuovo lettore.

Ci rivolgiamo al piccolo editore come alla grande casa editrice; dopo aver collaudato i nostri prototipi, e dopo piu’ di un anno di sviluppo, i3Factory è lieta di presentare un sistema software che permette di pubblicare le proprie edizioni sull’App Store senza investimenti onerosi.

Attraverso l’App Store di Apple , l’Android Market e Amazon App store, il vostro mercato cartaceo diventerà il mercato online mondiale, con la possibilità quindi di raggiungere nuovi lettori in tutto il mondo.

I costi di stampa in carta sono sempre piu’ elevati e non permettono all’editore di pianificare tirature elevate e quindi di raggiungere un pubblico geograficamente piu’ vasto.

Con il nostro sistema editoriale per iPad , i costi di tiratura si annullano; i  lettori sfoglieranno la vostra pubblicazione sul tablet, iPad, iPhone o Smartphone e il costo per le nuove pubblicazioni sara’ sempre nullo con costo marginale tendente allo zero.

Notiamo che l’esperienza di lettura di un magazine su iPad e di gran lunga piu’ soddisfacente dell’esperienza di leggere la stessa pubblicazione su carta.
Oltre ad essere semplice da sfogliare, basta un gesto con la mano, la rivista diventa piu’ fruibile; basterà pensare alla possibilita’ di poter ingrandire i caratteri con un gesto e fare lo zoom anche su immagini e altri dettagli oltre alla possibilità di fruire di video o di seguire links e ipertesti, html5…

Nessun costo aggiuntivo. Si utilizzano le infrastrutture esistenti del cliente e l’applicazione viene distribuita da Apple, Google e Amazon.

Illimitati lettori potenziali allo stesso costo,

nessun impatto ecologico.,

..sono solo alcuni dei vantaggi dell’utilizzo del  sistema editoriale i3Factory.

Alcune delle principali caratteristiche del  sistema editoriale “i3F Editorial” per iPad , iPhone e Android :

• Pubblicazione e distribuzione Applicazione personalizzata per l’editore  su App Store

• Illimitate Pubblicazioni

• Illimitati Lettori e Utenti

• Distribuzione pubblicazioni su App Store sia gratuitamente che a Pagamento (inApp)

• Investimento Una Tantum: nessun costo di manutenzione

• Nessun costo nascosto: paghi una sola volta e il sistema funziona per sempre

• Dal pdf ad iPad senza costi

• Links ipertestuali sul pdf

• Support per Video e Multimedia

• Supporto Youtube

• Social Network: Facebook, Twitter, etc..
• Supporto HTML5 Nativo
• Supporto Pdf
• Supporto social networks (Facebook , Twitter, etc…)

• Nessuna infrastruttura necessaria, colleghiamo il sistema al vostro sito web senza alcun costo aggiuntivo per hardware.

Alcune caratteristiche Tecniche del sistema editoriale:

• php per la processione dei dati

• sqlite per db
• Interfaccia DB editor

• una singola pagina html con interfaccia in ajax

Funzioni

• autenticazione  utente

• caricamento dei dati realtivi a pubblicazioni

• modifica dei dati con un sistema a versioni

• output dei dati in formato json

• caricamento selletivo immagini per copertine riviste

• resize automatico di dimensioni predefinite delle copertine caricate

• caricamento file zip e pdf

• abbinamento pagina della rivista con video

• backup automatico del db
• Inserimento contenuti extra e Html5

Costi/Prezzi:

Evidentemente i prezzi varieranno rispetto all’esigenza dell’editore, che di norma richiede alcune “personalizzazioni”.

Il prezzo di partenza per la nostra soluzione parte da  500 euro per Autori indipendenti e appena 1000 euro per Piccoli Editori, a partire da 2000 euro  per Medi e Grandi Editori.

Domanda:
Ma se i prezzi sono cosi’ bassi allora la soluzione non è professionale?

Risoposta:
La soluzione proposta è teconologicamente ai massimi livellli di avangiardia e professionalità; le grandi bolle speculative dovrebbero avervi fatto capire che quando si ha a che fare con internet e le App il prezzo e il costo non hanno nulla a che vedere con la professionalità;
ci sono sul mercato soluzioni editoriali di gran lunga inferiori a quella da noi proposta che possono costare anche 100 volte la nostra.

La Nostra filosofia è:
Il prezzo di vendita deve essere sempre onesto!

Maggiori Informazioni sui pacchetti editoriali potete trovarli su questo in questa pagina:

Sistema editoriale per iPad, iPhone & Android.

o direttamente sul  i3F Editorial web site :

i3editorial.com

(http://i3factory.com/editorial)