Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



Introduction to devices and formats

Onofre Pouplana

on 7 December 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of E-books

STANZA Plataformes Comercials Barnes & Noble Amazon Apple .EPUB (DRM ContentServer 4)
.PDF (DRM ContentServer 4) .EPUB (DRM FairPlay)
.PDF (DRM FairPlay) ID d' Adobe Digital Editions ID d'Amazon ID d'Itunes Kindle EPUB, iPad and Content Interoperability
By Dave Dickson on January 27, 2010 4:56 PM | No Comments

We're anticipating that the eBook functionality on the newly announced Apple iPad will spur further consumer interest in eBooks and we welcome the decision Apple has made to standardize on the EPUB format. With export support from professional publishing tools like Adobe InDesign, EPUB allows publishers to streamline the authoring workflow by reducing the number of formats to which they output.

However, in a recent study commissioned by the Book Industry Study Group, the number one complaint consumers noted about the e-reader experience is that "certain e-books [are] specific to certain e-readers." (Book Industry Study Group. "Consumer Attitudes Toward E-book Reading" Jan. 2010, p. 28). Clearly, consumers value content interoperability as a key feature of the digital reading experience, preferring to not have their content specific to one device. Although Apple has standardized on the EPUB format, because it employs its own DRM to protect eBooks consumers will lose out on much of the benefit of an interoperable format simply because they won't be able to transfer content across devices.

For example, EPUB content protected with Apple DRM won't work on numerous eReaders like the Barnes & Noble nook and the Sony Reader, not to mention future, forthcoming models. Similarly, protected EPUB eBooks obtained from thousands of online booksellers (including Barnes & Noble) and most public libraries (including The New York Public Library)—are unreadable on the iPad.

In the coming months, we'll see a plethora of tablets besides the iPad hit the market. Before investing in a library of eBook content, readers should consider how they'll be able to access their content across the range of devices—eReaders, tablets, desktop PCs, and smartphones—that they use on a daily basis. The Adobe eBook Platform—including the thousands of online booksellers and libraries using Content Server 4 to protect PDF and EPUB eBooks and the 30+ device manufacturers building compatible eReaders—allows consumers to download, transfer and read EPUB eBooks across PCs, smartphones, and dozens of dedicated eReader devices. The result is a reading experience not limited to a specific platform, but tailored to the consumer—whenever and wherever they wish to read. Apple says no to Adobe’s e-book DRM, prefers its own FairPlay
Feb. 18, 2010 (5:02 pm) By: Christian Zibreg

Apple logo with DRM lock (FLickr user shift_ctrl)Apple will use its own content protection technology to prevent e-book pirating, instead of Adobe’s more wide-spread technology. As a result, you won’t be able to transfer iPad books on other e-readers or use an iPad to read e-books purchased from other digital stores.

E-books sold via the iPad’s iBook store will be wrapped with FairPlay, Apple’s propriatory digital rights management (DRM) software that protects every type of iTunes content from unauthorized copying, except music which is DRM-free. Adobe’s senior business development manager Nick Bogaty told Computerworld that Apple will stick with its own FairPlay DRM to protect e-book purchases on the iPad:

Apple has not licensed Adobe Content Server for their iBookstore. They appear to be doing something else.

The confirmation came following a Monday piece by the Los Angeles Times that first asserted that Apple was offering publishers its FairPlay DRM to protect iPad books. Apple originally developed FairPlay DRM at the request of music labels. As Apple added more content types to the iTunes Store, it continued using FairPlay DRM to protect those purchases from unauthorized copying.

Apple is currently using FairPlay DRM to enforce the use of movies, TV shows, audiobooks, ringtones, and iPhone applications to up to five computers
authorized with the same iTunes Store account and any number of iPods and iPhones (soon iPads, too) that sync with those computers.

Read more at Computerworld. platypope.org
Worse-is-better in e-book formats
posted on April 03, 2009

It is the year 2009 and the most popular electronic book format in the world consists of HTML 3.2 in a Palm database. Why?

For those of you who aren't total e-book wonks, I'm talking about the Mobipocket format. The eponymous controlling company first debuted in 2000, proved the most successful of the initial crop of PDA-centric e-book format vendors, and was acquired by Amazon in 2005. The format is now not only the most popular "device independent" commercial e-book format, but is also the format used for the vast majority of Kindle e-books. More devices support Mobipocket than any other commercially-sold format, and although we don't have any actual sales data, I don't think there's much doubt that Amazon is selling more devices and books than any other vendor, at least in the US.

A lot of technical detail follows, but here's most of the conclusion: I think that Mobipocket has managed to hit a sort of technology/complexity engineering/usability sweet-spot. It uses (an albeit bastardized) HTML for markup, which gives it an edge over eReader; it uses an extremely simple container format, which gives it an edge over LIT; and it uses an appallingly simple rendering model, which gives it an edge over EPUB. This is kind of difficult to explain without going into loads and loads of detail about the e-book formats, so bear with me if I get long-winded.

Here's a summary of how Mobipocket stacks up technically against the other commercial reflowable formats:

* Mobipocket: Container is a Palm database, providing primarily a mapping between a numeric identifier and "record" content. Book text is a single stream of HTML 3.2-ish with proprietary extensions (mostly formatting-oriented), no separate style language, and proprietary compression in 4k chunks. Images are GIF and JPEG, which some viewers limit to 64k in size.
* eReader: Container is a Palm database. Book text is a single stream of "PML," a proprietary, non-SGML, primarily formatting-oriented markup language. Images are PNG, limited to 64k.
* Microsoft LIT: Container is an MS "ITOL/ITLS" HTML Help 2.0 file, providing all sorts of exciting features like LZX compression, binary representation of markup content, and arbitrary optional auxiliary data associated with each content stream. Book text is an arbitrary number of OEBPS 1.0 markup streams (essentially HTML 4.0 as well-formed XML) plus a subset of OEBPS 1.0 CSS (no contextual selectors). Images are GIF, JPEG, and PNG.

1 Or technically DTBook, although I've never seen one in the wild and don't know which — if any — viewers support it.
* EPUB: Container is a ZIP file with some extra JAR-like metadata. Book text is an arbitrary number of XHTML 1.0 streams1 with CSS 2 styling. Images are JPEG, PNG, and SVG.

Mobipocket and eReader are near the same level technically, but Mobipocket's success — and eReader's continued existence — in the face of LIT and EPUB I think is quite interesting. EPUB is still very new, but Microsoft first released Microsoft Reader in 2000, the same year that Mobipocket incorporated. LIT is a closed format which relies on quite a bit of MS-specific technology, but EPUB is an open standard and composed mostly of other existing and well-supported open standards. Cross-comparison is far from free of contaminating historical/environmental factors, but I think there is something to be learned from Mobipocket — that worse is still better.

Mobipocket and eReader were founded around the same time (eReader in 1998 as Peanut Press) and with essentially the same constraints. Both primarily targeted PDAs running PalmOS and thus needed a format which they could easily render on (by today's standards) woefully under-powered devices. EReader chose to create their own simple, easy-to-parse markup language called PML (Peanut Markup Language). Even after 10 years, the core language remains comparatively elegant, containing only a few dozen tags and no redundancy outside of deprecated features. It simply and directly supports most of the formatting features possible on a Palm PDA with no pretence of semantic connotation.

2 Although there is evidence some of these were added later. For example, if the Mobipocket file header indicates one the earliest version of the format then the <hr> tag induces an explicit page break.

In contrast, Mobipocket chose to extend the existing HTML 3.2 markup language. It's somewhat difficult to understand all the reasons for this decision without knowing the politics involved or the existing state of HTML rendering on the Palm platform at the time, but certain things are clear. First, rendering HTML 3.2 is more difficult than rendering a PML-like language — HTML is much more complicated, is harder to parse, and contains many redundancies in the formatting-wise interpretation of its elements. HTML 4 and CSS 2 were the cutting-edge standards in 2000, so choosing HTML 3.2 didn't provide much coherence with existing Web standards, a problem furthered by the addition of proprietary features implementing such things as page breaks and paragraph indentation.2

It is unclear to me how much Mobipocket's similarity to HTML aids strict interoperability, but the perception that they are iteroperable clearly exists, and for quick-and-dirty case, for interpretation of texts with no fancy formatting, the correspondence is simply good enough. The correspondence between HTML semantics and Mobipocket formatting is sufficiently weak that when I wrote Mobipocket-generation support for calibre I opted to treat "MobiML" as a completely distinct pure-formatting language. This approach allows for a higher degree of formatting fidelity (although not complete — Mobipocket's formatting limitations are many and baroque), but in 99% of cases, throwing some HTML at the Mobipocket renderer will render well enough to actually read the text.

One of the big simplicity wins a language like PML has over HTML is that it has an explicitly "flat" rendering and markup model. Tags intoducing paragraphs completely determine the paragraph-level formatting of their contained text, the renderer either disregarding or disallowing any previously active formatting state. In contrast, all versions of HTML allow some degree of arbitrary block-level nesting in which the active formatting state combines and merges with the new state. This means that to start accurately rendering at some arbitrary point — at the destination of a hyperlink, or just where the user left off the last time they were reading — a reader application needs to be able to figure out the current formatting state at that point. There are a few solutions to this problem.

3 That is to say, Microsoft Reader.

One is to do what Microsoft LIT does and put lots of extra information in the container. The LIT container is compressed in 64k chunks, which allows full compression with random seeking to anything in the container with minimal decompression overhead. LIT contains indices of all the hyperlink target elements and all page-breaking elements which specify the positions of all their ancestor elements. These combined with LIT's simplified contextless CSS mean a full LIT renderer3 can figure out the formatting state of anywhere in the book with a minimum amount of extraneous processing. Accurate rendering is just a few index lookups away!

4 In fact, AFAIK I was the first person to even bother reverse-engineering them when I implemented LIT generation for calibre.

The downside is that all this is very complicated. Microsoft is able to piggy-back off of their HTML Help support libraries, but third-party implementations would need to read the whole mulilayered ITOL/ITLS archive goodness from scratch and incorporate the indices into their renderers. There are many third-party reader applications which can handle Mobipocket, but very few which handle LIT, and none that I know which actually use all the extra information in the LIT container format.4

Another solution to the problem is to do what EPUB does and depend on having fast enough hardware that figuring out the appropriate rending isn't an issue. EPUB is conceptually very simple — XHTML in a ZIP archive. On contemporary hardware with contemporary embedable HTML renderers like WebKit this is almost trivial to implement — I believe Kovid Goyal put together the first version of the calibre EPUB viewer in about a week.

The downside is that your cellphone or e-ink display reader isn't quite so powerful. The EPUB specification places no limitation on CSS complexity or XHTML flow size, allowing for example a CSS sibling selector applied over 100MB XHTML file. Not to mention that you have to decompress that 100MB flow all at once and keep the whole thing around in memory while rendering it. Ouch. There are a few ways to keep processing time generally sane while still rendering most markup correctly, but Adobe's implementation on the Sony Reader of simply refusing to render any flow larger than 300k has forced that simple expedient as the most common method.

And then there's Mobipocket's solution — don't render the markup correctly. Yep, you heard me correctly. The text still displays, but if that hyperlink drops you in the markup right after the italics tag, then the text which was supposed to be in italics won't be. Oh, it has chunked compression LIT so it can seek anywhere with minimal decompression overhead, but when it gets there it just starts rendering with what it's got.

When I first realized this I was completely aghast. "It's wrong! They're letting text be rendered wrong!" But the more I thought about it, the more I came to feel that this was actually a brilliant decision. It means that rendering is always instantaneous, no matter where the user jumps to in the book. Although book-producers have to do some extra work if they want all their links to point to Mobipocket-sensible places in the markup, if they don't then the book is still readable. Pathological cases merely degrade rendering, not disrupt it. Contrast this with the EPUB experience-thus-far, where books which cannot be read on the Sony Reader are an unfortunately common occurrence.

Of course, I still completely detest the Mobipocket format and hope it dies in a fire. Seriously, a Palm database in 2009? What I'd like to see is a new version of the EPUB standard which takes the lessons learned from other formats more to heart. With a reduction in complexity, standardization of certain necessary size limits, and at least reader application guidelines for imposing user stylesheets, I think that EPUB can still be the format to beat going forward. .AZW (Amazon Mobypocket)
.MOBI STANZA Adobe Digital Editions Adobe Reader® Mobile 9 software Adobe Digital Editions® Windows Mac Bebook Cybook Cooler Eco Reader Sony PRS Papyre Leqtor Read without paper CoolerBooks LeerE ReaderStore Nook Barnes & Noble https://www.luarna.com/Paginas%20comunes/PrevencionPirateria.aspx o ID+password de B&N .pdb 1998 SoftBook "Availability of titles isn’t the only problem. Pricing is another. Given the marginal cost of publishing a book electronically, you would expect that eBooks would be somewhat cheaper than real paper books, especially given your up-front investment in the reader. Well, it seems they are a bit cheaper, maybe 20% on average; but in some cases they are actually more expensive! Take Oprah Winfrey Speaks, which sells for $11.86 on B&N.com. Well, the digital edition costs $13.56. "

Daniel Chvatik. But Barnes & Noble faces deep-pocketed technology titans. Charlie Wolf, a senior analyst at Needham & Co., estimates that Apple will sell 5.5 million iPads in 2010, while Amazon will sell 3 million Kindles and Barnes & Noble will sell 1 million Nooks. US Trade Wholesale Electronic Book Sales 2002-2010 Kindle 1 International
Kindle II Nook Kindle II Ipad ADEPT (Adobe Digital Experience Protection Technology) Adobe Digital Editions En papel leemos más rápido que en un e-reader

Redacción de Baquía

4 comentarios · escribe el tuyo

Un experimento ha analizado el tiempo que se tarda en leer un mismo relato en un iPad, un Kindle o el libro de papel de toda la vida. El resultado: en los lectores electrónicos vamos más lentos.
Entre las muchas ventajas que aporta un libro electrónico sobre el de papel, se supone que se incluye la agilidad en la lectura. Sin embargo, un pequeño experimento deja en entredicho esta presunta superioridad.

La prueba ha sido elaborada por Jakob Nielsen, reconocido gurú de la usabilidad y el diseño web. Para ello pidió a 24 personas que leyeran un relato corto de Ernest Hemingway en cuatro soportes: un PC, un iPad, un Kindle 2 y un libro.

El tiempo medo de lectura fue de 17 minutos y 20 segundos, una cantidad intermedia entre lo que se tarda en leer una página web y un relato largo. Si hablamos de agilidad en la lectura, el clásico libro impreso es imbatible: los usuarios tardaron en leer el cuento un 6,2% más de tiempo en el iPad y un 10,7% en el Kindle.

Según explica el propio Nielsen, esto no significa que se lea más rápido en el tablet de Apple que en el dispositivo de Amazon, debido a que la muestra era muy pequeña y el resultado no es estadísticamente significativo. Sin embargo, sí queda probado que la lectura sobre soporte electrónico es más lenta que sobre papel.

En la prueba también se pidió a los participantes que puntuaran la experiencia de lectura en cada uno de los formatos. La valoración de iPad, Kindle y el libro es similar: sobre un total de 7 puntos los valoraron con 5.8, 5.7 y 5.6, respectivamente. Todos muy por encima del PC, que con una nota de 3,6 queda reflejado como el peor soporte de lectura.

Por último, se incluyen algunos comentarios sobre la experiencia de lectura: los usuarios se quejaron del peso del iPad y de la claridad del texto en el Kindle. Tampoco les gusta la forma de paginar, pero sí la forma en que una aplicación del iBook muestra el texto restante en cada capítulo.

Otros comentarios fueron más predecibles: leer un libro impreso es más relajante que utilizar un dispositivo electrónico. Y leer en el PC no es agradable porque recuerda al trabajo.

Y todo esto, claro, sin contar instalaciones y/o actualizaciones del software, quedarse a media lectura sin batería o estar en un lugar sin cobertura... Problemas que no suele tener el libro impreso. http://www.consumer.es/web/es/tecnologia/hardware/2005/07/15/143752.php Adobe Digital Editions IBooks El DRM de Mobipocket y el Kindle

Publicado por Krigan en 17 Mayo 2009

El formato nativo de elibro (ebook) del Kindle es el Mobipocket, lo cual no es de extrañar si tenemos en cuenta que Amazon compró la empresa Mobipocket antes de lanzar el Kindle. En los elibros desprotegidos no hay diferencia entre los mobipockets que son para el Kindle y los que no, y por eso la publicidad del Kindle señala que soporta mobipockets desprotegidos (¿cómo no los va a soportar si Mobipocket es su formato nativo?). En los elibros protegidos, sin embargo, hay un flag que está activado para los que son para el Kindle, y desactivado para el resto.

Ese flag es la única diferencia entre un elibro protegido del Kindle y cualquier otro mobipocket protegido. Además de esto, la extensión en el nombre de fichero para los elibros protegidos del Kindle es .azw en lugar de las tradicionales .prc o .mobi de los mobipockets. En efecto, cambiando ese flag y la extensión es posible transformar un mobipocket protegido “normal” en un elibro para el Kindle, y viceversa.

Ahora bien, ¿cómo funciona el sistema de protección (DRM) de los mobipockets? El contenido del elibro está encriptado con una clave aleatoria de 128 bits usando el algoritmo Pukall (también llamado PC1), y esa clave, que es específica de cada elibro, está incluida en el mismo, encriptada (también mediante PC1) con una clave que se obtiene del PID del dispositivo o programa lector que esté autorizado a leer ese elibro.

Un PID de Mobipocket es una secuencia de 8 letras o números que está asociada a cada lector. Las letras son siempre las mayúsculas del alfabeto inglés. En los programas lectores para PC el último carácter es siempre “$”, y en los Kindle es siempre “*”. En mi iLiad este octavo carácter es “K”, pero ignoro si en el resto de los iLiad es igual. A veces los 8 caracteres del PID se complementan con otros 2 caracteres posteriores (un total de 10), pero estos 2 caracteres extra son sólo un checksum o código de comprobación que se obtiene de los 8 principales.

El proceso normal de compra de un mobipocket protegido consiste en registrar el PID de tu lector (puedes registrar un máximo de 4), y la web que te vende el elibro te devolverá un mobipocket encriptado, que (en teoría) sólo tu lector (o lectores) podrá leer. Como ya hemos dicho, el contenido del elibro está encriptado con una clave aleatoria, y esta clave a su vez está encriptada con una clave que se obtiene del PID. Hay un máximo de 4 copias de la clave aleatoria contenidas en el elibro, cada una de ellas encriptada a partir de un PID diferente.

Para complicar un poco las cosas, la clave aleatoria no está directamente encriptada con el PID, sino con una clave (llamada Clave Temporal) que se obtiene de encriptar el PID con la llamada Clave Secreta. Esta Clave Secreta es siempre el mismo número. La ingenuidad de los creadores de DRMs es siempre la misma, el pensar que una Clave Secreta, contenida en millones de aparatos lectores, y en millones de programas lectores para PC, seguirá siendo secreta durante mucho tiempo.

En efecto, la Clave Secreta ya no es secreta desde hace un par de años. Concretamente es este número hexadecimal:

72 38 33 B0 B4 F2 E3 CA DF 09 01 D6 E2 E0 3F 96

Así pues, el proceso normal de desencriptado, el proceso que usa todo aparato lector y todo programa lector (y también todo programa rompedor de la protección como MobiDeDRM), consiste en encriptar su propio PID con esta clave universal, y usar la clave temporal resultante para desencriptar la clave aleatoria, la cual a su vez se usa para desencriptar el contenido del elibro.

Los detalles pueden variar de un sistema DRM a otro, pero la esencia es siempre la misma. Siempre hay alguna clave secreta escondida por algún lado del aparato o programa reproductor (no sólo elibros, también películas, canciones, o lo que sea). Y siempre romper la protección consiste en la misma cosa, en obtener esta clave secreta de algún modo, y desencriptar el contenido como se hace normalmente.

Todo lo cual plantea una cuestión. Cuando uso mi iLiad para leer un mobipocket protegido que he comprado, mi iLiad usa esta clave secreta y su propio PID (que es un dato que muestra el propio iLiad) para desencriptar tal y como ya hemos explicado. Y cuando uso MobiDeDRM para desencriptar ese mismo mobipocket que he comprado, este programa usa esta misma clave secreta y este mismo PID de mi iLiad para desencriptarlo exactamente de la misma forma que lo hace el iLiad, siguiendo exactamente los mismos pasos matemáticos.

Sin embargo, en el primer caso es legal hacerlo, y en el segundo es ilegal, simplemente porque el “autor” (que nunca es el autor) ha tenido a bien el “autorizar” a mi iLiad (decir que le parece bien que mi aparato lector desencripte el elibro), y sin embargo no ha “autorizado” a MobiDeDRM para hacer exactamente la misma cosa. Y lo mismo para cualquier otro DRM.

He comprado 2 mobipockets protegidos, porque no los venden desprotegidos, y no pienso comprar ningún otro en toda mi vida. Sencillamente, estoy harto de esta tomadura de pelo en que se han convertido los derechos de autor. Si quiero guardar una copia desprotegida de lo que he comprado, compatible con cualquier lector del futuro, sin tener que depender de una web “autorizadora” que podría cerrar mañana mismo (ya pasó con un DRM de Microsof), resulta que infrinjo la ley. A mí no me parece que eso sea razonable.

Luego se quejarán de que no compremos, pero ¿pagar para ser ilegal? No gracias, para eso mejor me lo bajo del p2p, que me sale gratis. Tal vez en el futuro ilegalicen el p2p, pero puestos a elegir entre ser ilegal de una forma y serlo de otra, prefiero que me salga gratis.

¿Es usted autor? ¿No le gusta que me baje sus libros del p2p? Pues ya sabe lo que tiene que hacer, no venda con DRM. Si pone usted fuera de la ley a sus propios clientes, ¿acaso espera tener clientes? Amazon IBookStore Google
Editions Barnes &
Noble Nook Com comprar llibres digitals? Digital Rights Management ADEPT FAIRPLAY EXEMPLI GRATIA:
AMAZON DRM Això no és nou... Any 2000. Rocket eBook Pro RocketBook Altres opcions? El dispositu no deixa de ser una mera finestra,
l'important és el paisatge. Sony PRS-500 Irex ilyad 2006 2010 http://www.feedbooks.com/ http://books.google.es/ On descarregar? "El Ipad y las pantallas retroiluminadas te destrozan los ojos y la tinta electronica no, esa es la gran ventaja..."
-Comentario anónimo en Internet Any 2000. Rocket eBook Pro Portables Tinta electrònica
Millor pes, autonomia
i capacitat Botiga Integrada
Pantalles de color
Conectivitat 3G Kindle 2 Nook Ipad Formats editorials a Espanya. Previsió Fuente: Encuesta sobre el libro digital 2009. Federación de Gremios de Editores de España. P2P
Blogs especialitzats
etc PRINCIPALS FORMATS DIGITALS PDF EPUB MOBIPOCKET Sense DRM Sense Descàrrega http://www.todoebook.com/ http://www.leqtor.com/ http://www.popularebooks.com/ InterCompatible

DRM específics en
alguns casos Mac Intercompatible

antic format PDB Nook Windows Barnes & Noble eReader Compra mitjançant web+eReader o descàrrega directa al dispositu+eRader. Adobe
Editions Mac Ipod Touch Apple Itunes® Només es pot comprar a través de la aplicació IBooks Apple IBooks Windows Iphone Ipad Intercompatible IBooks para IOS Ipad Iphone / Ipod Touch BlackBerry Prèstec QUE Pro Reader Compra mitjançant llibreria Intercompatible Iphone / Ipod Touch Android Ipad Windows BlackBerry Mac Compra mitjançant web+Reader o descàrrega directa al dispositu kindle. Kindle Amazon Kindle Kindle Reader Taller Visualització
Adquisició / Càrrega
Anotacions i marcadors Kindle 2 i DX
Irex Iliad 1000-S
Papyre 6.1 Dispositius El llibre electrònic a la UOC Mòduls didàctics
Prèstec E-Readers La biblioteca a mà E-Books Dispositius
Mercats El millor dispositiu http://www.fnac.com/telecharger-ebook.asp?bl=head REVISTES DIGITALS ZINIO MAGCLOUD WIRED LIBRANDA http://vimeo.com/13412179 "Libranda nace escasa de títulos y utilidades" - Elcultural.es

"Libranda, la abominación hecha tienda de ebooks" -Alt1040.com

"Comprobado personalmente. Comprar libro en libranda es el purgatorio [de e-commerce], leerlo es el infierno [de Adobe DRM]. Fracaso seguro." - Ricardo Galli Proba personal: el proccés de selecció i compra d'un llibre de temàtica molt concreta es va demorar 35 minuts fins a la lectura. EYE STRAIN? E-INK vs PAPER vs LCD Michael Bove, director of the Consumer Electronics Laboratory at the M.I.T. Media Lab, says different screens make sense for different purposes.

“It depends on the viewing circumstances, including the software and typography on the screen,” said Mr. Bove. “Right now E Ink is great in sunlight, but in certain situations, a piece of paper can be a better display than E Ink, and in dim light, an LCD display can be better than all of these technologies.”
iPad DemoJim Wilson/The New York Times Apple’s iPad with a full-color LCD display.

E Ink has a very low contrast ratio. Although it can offer an excellent reading experience in bright sunlight, the screens can become uncomfortable to use in dark settings because of the lack of contrast and backlighting on the screen.

LCD screens, meanwhile, have long struggled to offer good viewing angles for reading. Apple’s latest IPS LCD screens include extremely wide viewing angles, but the reflective glass on the screen could be a hindrance in brightly lit situations.

Professor Alan Hedge, director of the Human Factors and Ergonomics Laboratory at Cornell University, said that reducing eye fatigue is less a matter of choosing a specific display than of taking short breaks from looking at the screen.

When we read, Dr. Hedge explained, a series of ocular muscles jump around and can cause strain, regardless of whether we are looking at pixels or paper. “While you’re reading, your eyes make about 10,000 movements an hour. It’s important to take a step back every 20 minutes and let your eyes rest,” he said.

Today’s screens are definitely less tiring to look at than older displays, which refreshed the image much less frequently, causing a flicker. Carl Taussig, director of Hewlett-Packard’s Information Surfaces Lab, said the 120 Hz refresh rate typical of modern screens is much quicker than our eyes can even see.

“The new LCDs don’t affect your eyes,” Mr. Taussig said. “Today’s screens update every eight milliseconds, whereas the human eye is moving at a speed between 10 and 30 milliseconds.”

Mr. Taussig said consumers will pick the type of screen that makes sense on an individual basis. “I don’t think there is a single technology that will be optimum for all the things we want to do with our devices. For example, H.P. sells 65 million displays a year, and they are all used in a different way.” http://librosenlanube.blogspot.com/2010/07/bajo-la-piel-de-libranda.html COSTOS EDICIÓ Autoedició? IBOOKSTORE BiblioCore
Book Baby
Smashwords Agregadors oficials AMAZON Digital Text Plataform BARNES&NOBLE Pubit! Itunes Connect Realitat és que:

-la vista cansada depen de l'activitat i el temps, no del dispositiu. Cal deixar reposar l'ull cada 20 minuts.

-La elecció de pantalla depén més dels usos: exterior, lectura diurna o nocturna, que de la seva idoneitat per a l'ull.

-El que els estudis oftalmologics demostren es que mirar intensament una pantalla (o paper!) durant hores sense descans redueix el llagrimeig i els parpallejos naturals de l'ull, provocan molesties i en casos extrems lesions. Cal descansar la vista en tots els casos.

Full transcript