Profile

Cover photo
Hadrien Gardeur
Works at Feedbooks
Lives in Paris
736 followers|98,716 views
AboutPosts

Stream

Hadrien Gardeur

Shared publicly  - 
 
Aldiko 3.0 has a great new Holo design and truly feels like the first next generation OPDS client.
I'll do a full post here about why this is a major step forward for OPDS.
 
Aldiko 3.0 is here! The Adiko 3.0 is a re-imagined version of the Aldiko Book Reader. It's built on a modern design, following closely the design guidelines of Holo. It features a whole new user interface, great catalog integration and easy and powerful library organization for users with lots of books. More details: http://www.aldiko.com/blog/aldiko-3-0-is-here
3
2
Olivier Guéry's profile photo
 
Hé, hé, on va tester ça :)
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Just posted my comment to Dave Cramer's post about a lightweight version of EPUB.
1
1
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Not sure how I feel yet about this new layout. It feels designed for shorter posts and content/link sharing.
This is probably due to how posts are now displayed (like a chat).

I previously used Google+ strictly for longer posts (almost as a replacement for a blog) and presentations (the image viewer worked great for that). We'll see if there's a good fit or not for this redesign.
1
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Translated a recent presentation about OPDS
6
2
Créatnum's profile photo
 
toujours aussi clair !
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Kobo et la FNAC ne vendent pas de l'EPUB

Depuis quelques jours, les bruits circulent sur la toile vis à vis de nombreux problèmes de compatibilité sur les fichiers EPUB vendus par Kobo et donc par la FNAC.

En vrac, pour ne donner que deux exemples:
http://www.teamalexandriz.org/forum/index.php?topic=12820.0
http://www.mobileread.com/forums/showthread.php?t=157772

Les problèmes notés sont graves, et concernent potentiellement quasi l'ensemble des lecteurs EPUB (en dehors de ceux de Kobo).
Pour l'utilisateur les effets sont:
- une police beaucoup trop grandes et dont on ne peut pas changer la taille
- des interlignages trop importants
- absence de marge

Bref une expérience de lecture dégradée qui rend le fichier quasi inutilisable sur un lecteur concurrent.

Côté code

Il suffit d'ouvrir un des titres pour comprendre l'étendue du problème:
- ajout d'un kobo.css qui écrase des propriétés du CSS éditeur et insiste en plus via l'utilisation de "!important"
- ajout de "kobostylehacks" dans les headers HTML
- ajout de Javascript
- pas de déclaration des ajouts CSS et JS dans l'OPF

Bref, ces fichiers ne sont pas des fichiers EPUB valides (entre autre à cause des ressources non déclarées dans l'OPF) et semblent "bidouillés" par Kobo pour leurs propres lecteurs, excluant au passage tout le reste du marché.

On remarquera qu'à aucun moment, ni la FNAC ni Kobo n'indique que leurs fichiers sont en fait modifiés, leurs sites respectifs ne parlant que d'EPUB (et non de KEPUB, voir plus bas).

KEPUB et non EPUB ? EPUB3 ?

Mobileread dispose d'une page intéressante présentant le "KEPUB": http://wiki.mobileread.com/wiki/Kepub

A première vue, il ne s'agit pas du problème rencontré ici, mais plutôt de leur propre DRM ainsi que d'une base SQLite.

La page indique quand même au passage que:
"Kobobookstores can also sell standard ePub books which can be read on any device that supports ePub. The user will need to ensure which formats are available for a particular book."

Il appartient donc à l'utilisateur de vérifier si chaque livre est disponible en EPUB ?

En France, la réaction de la FNAC est un peu différente:
- ils répondent à leurs clients que la FNAC vend bien de l'EPUB, mais de l'EPUB3 et que c'est du coup la faute des autres lecteurs
- ils indiquent que le problème est connu et remboursent systématiquement l'utilisateur
- ils demandent à l'utilisateur de ne plus acheter de titres

Désinformation donc de leur part: EPUB3 n'a rien à voir la dedans, le problème vient du fait des modifications faites par Kobo au niveau du CSS. Simple incompétence ou tentative de désinformation à l'égard des autres lecteurs sur la marché ?

En conclusion

On savait déjà que Amazon ajoutait des DRMs sur les titres sans DRM (http://readingandraytracing.blogspot.com/2011/11/insatisfait-par-les-reponse-amazon.html), et que leurs titres étaient de moindre qualité étant donné qu'ils s'appuient sur des conversions EPUB vers Mobipocket (http://www.ebouquin.fr/2011/11/25/amazon-une-offre-numerique-a-la-qualite-inegale/).

Pour Kobo, on savait qu'ils forcent aussi des DRMs sur les titres sans DRM (https://twitter.com/#!/sebbago/status/147681485221150722). On sait maintenant qu'en plus d'imposer des DRMs, ils rendent les titres inutilisables sur d'autres lecteurs que le leur.

A titre de comparaison, sur Feedbooks:
- on ne force pas de DRM
- on indique clairement si un titre comprend un DRM ou un watermark
- on permet aux utilisateurs de filtrer les titres selon la nature du DRM
- on vend exclusivement de l'EPUB (et non un format propriétaire comme Amazon), sans ajouts de CSS ou autres modifications empêchant l'utilisation sur un autre appareil (contrairement à Kobo/FNAC)

A chacun de choisir sa librairie, mais il est clair que tout le monde ne traite pas le client de la même manière...

Mise à jour

Immatériel vient de publier un billet assez accablant sur les pratiques de Apple/Amazon/Kobo/FNAC vis à vis des DRMs, je vous laisse lire: http://blog.immateriel.fr/2011/12/22/drm-sociaux-circuits-proprietaires/

01net reprend le sujet sur sa une et confirme le problème: http://www.01net.com/editorial/551422/gare-aux-livres-en-version-electronique-sur-fnac-com/

Les anglo-saxons constatent aussi le même problème: http://td.typepad.com/treeweaselweekly/2011/12/how-not-to-win-ebook-friends-and-influence-people.html
18
17
Hadrien Gardeur's profile photoAudrey Keszek's profile photo

Hadrien Gardeur

Shared publicly  - 
 
Major update to the OPDS Validator

+Benoît Larroque (from Feedbooks) recently updated the OPDS Validator (https://github.com/zetaben/opds-validator) and its online version available at http://opds-validator.appspot.com

While the previous version was strictly based on the Relax NG already available in the 1.0 and 1.1 versions of the specification, this is a major update which includes the following new features:
- validation based on the requirements extracted from the specification (see http://groups.google.com/group/openpub/browse_thread/thread/743a17d975b15540#) that are not already expressed in the Relax NG
- view source and links between errors/warnings and the source (web version)
- direct input (web version)
- file input (web version)
- links to validation results (web version)

While this version doesn't check for the requirements marked as low or very low priority yet (from http://groups.google.com/group/openpub/browse_thread/thread/743a17d975b15540#) it should be more than enough to test an OPDS catalog.
I strongly advise anyone with an OPDS catalog either in development or production to check the output of the validator.

Based on a first run through a dozen catalogs, the most common errors are:
- catalogs using the wrong rel value for images
- catalogs not implementing search correctly (stuck with a Stanza catalog rather than an OPDS catalog)
For example: http://opds-validator.appspot.com/?uri=http://www.smashwords.com/atom

The most common warnings are:
- missing profile or kind parameters (the kind parameter was added to 1.1 and I expect very few catalog to use it yet) on an Atom media type
- missing link to the top catalog
For example: http://opds-validator.appspot.com/?uri=http://bookserver.archive.org/catalog/

While the warnings found on catalogs are not that big of a deal, errors are far more problematic and it would vastly improve the state of the ecosystem if we managed to get rid of them as much as possible.

Keep in mind that this is still a work in progress and the validator will continue to improve over time and check more and more things in OPDS feeds. Feel free to send any feedback about the validator here or on the mailing list (http://groups.google.com/group/openpub).
Open Publication Distribution System. Unofficial Validator. Validate by URI; Validate by Direct Input. Validate by URI. Validate a feed online: Address: More Options. OPDS Version. 1.0, 1.1 (current)....
3
3
Nicolas Robaux's profile photoDavid Pierron's profile photoHadrien Gardeur's profile photo
6 comments
Add a comment...
Have him in circles
736 people
Nicolas Robaux's profile photo
Cyrille Sidjouo's profile photo
Bernard Prost's profile photo
christophe wocial's profile photo
Mike Cane's profile photo
David Morrell's profile photo
Marc Hébert's profile photo
Gary Wayne Clark's profile photo
Jose Afonso Furtado's profile photo

Hadrien Gardeur

Shared publicly  - 
 
Brand new page for OPDS on Wikipedia with less duplicated information, an example, compatibility for multiple clients and new resources. #opds  
urn:uuid:433a5d6a-0b8c-4933-af65-4ca4f02763eb ...
2
1
Hadrien Gardeur's profile photoSameer Verma's profile photoOlivier Nyssen's profile photo
6 comments
 
J'ai ajouté un lien dans le wiki Tizen https://wiki.tizen.org/wiki/Application_Development
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Un DRM standard pour le format EPUB ?

+Bill McCoy annonçait clairement depuis quelques mois que l'IDPF souhaitait s'emparer de la question difficile des DRMs, afin de favoriser une solution standard qui permettrait de diminuer la fragmentation actuelle du support EPUB (avec d'une part des titres sans DRM, et de l'autres des fichiers EPUB protégés par ACS4 de Adobe ou Fairplay d'Apple).

En publiant un premier document expliquant les choix retenus pour le moment, on obtient une idée un peu plus clair de ce que pourrait être ce "Lightweight Content Protection" : http://idpf.org/epub-content-protection

Un DRM poids plume ?

Une grosse partie de ce document consiste à décrire ce que l'IDPF propose comme étant une solution DRM souple/légère, en opposition à une solution plus lourde comme celle d'Adobe.

Le raisonnement retenu est le suivant :
- même les solutions les plus complexes et avancées ne garantissent jamais que le contenu ne soit pas piraté, et tout DRM finit pas être cracké
- l'objectif d'un DRM n'est donc pas d'empêcher le piratage, mais plutôt de décourager le partage excessif et systématique des fichiers, en rendant ces opérations un minimum plus contraignantes pour l'usager moyen
- dans de nombreux pays il est de toute façon illégal de supprimer un DRM d'un fichier
- ... ce qui n'est pas le cas de la suppression d'un watermarking (tatouage/filigrane), argument utilisé par l'IDPF pour défendre l'interêt d'un DRM standard vis à vis de ces solutions
- en dehors des usages grand public des DRMs, de nombreuses entreprises auront de toute façon besoin de protéger leurs documents EPUB de la même manière qu'ils le font aujourd'hui avec des fichiers PDF

Une vague impression de déjà vu

La solution retenue par l'IDPF est donc d'utiliser une protection par mot de passe : le document est chiffré en utilisant ce mot de passe en guise de clé de chiffrement symétrique.

Cette solution a comme avantage d'être beaucoup plus simple à implémenter qu'une solution asymétrique comme celle d'Adobe, et surtout de ne pas nécessiter de connexion ou d'un tiers de confiance pouvant à tout moment disparaître, pour que le fichier soit ouvert.

Par contre, on est en droit de se poser de vraies questions sur la facilité à l'usage d'un tel DRM. Que se passe-t-il si j'oublie un mot de passe ? Est-ce vraiment plus facile de devoir retenir un nombre important d'identifiants (chaque libraire ou bibliothèque pouvant demander des identifiants différents) ? Un mot de passe est-il vraiment un plus grand frein qu'un watermark à la diffusion d'un fichier ?

Un autre exemple de DRM nous vient directement en tête: la solution employée par Barnes & Noble, qui se base sur un nom d'utilisateur et un mot de passe (le numéro de carte de crédit du client), qui a d'abord été utilisée pour le format eReader, puis par la suite sur les fichiers EPUB vendus par ce libraire.
Si les détails d'implémentation diffèrent, dans l'idée on est tout de même très proche de l'objectif de l'IDPF.

Ce que beaucoup de monde ignore, c'est que la solution d'Abobe (ACS4+RMSDK) est capable de supporter le DRM de Barnes & Noble depuis plusieurs versions maintenant, même si mis à part Barnes & Noble, aucun libraire ou distributeur n'utilise cette option. Etant donné qu'il faut absolument une version relativement récente de RMSDK sur son système de lecture, personne n'a fait le pas pour le moment en dehors de B&N: ce serait fermer la porte aux utilisateurs de périphériques plus anciens (les précédentes générations des liseuses de Sony ou de Bookeen par exemple).

Trop tard ? Pourquoi préférer une solution DRM au watermarking ?

Le cas du DRM de Barnes & Noble illustre bien les obstacles auxquels cette solution DRM devra se confronter : il est très difficile de faire évoluer un parc de machines vers une nouvelle solution DRM. Même si l'IDPF accouche en 2012 d'une spécification en plus d'un document d'intention, il faudra attendre un certain temps avant de voir arriver les premières implémentations. Idéalement, cette question aurait du être abordée en 2007 lors de la publication d'EPUB 2.0, ce qui aurait permis à Adobe et B&N de potentiellement adopter celle-ci, et non leur solution propriétaire.

Etant donné que d'une part, les utilisateurs possèdent des périphériques qui ne supporteront probablement jamais ce DRM, et de l'autre que leur bibliothèque est constituée de fichiers protégés par une des solutions propriétaires actuelles (Adobe, Apple ou B&N), il faudra certainement plusieurs années avant que cette solution DRM devienne véritablement utile. En attendant, les acteurs de la chaîne du livre (éditeurs, distributeurs, libraires et systèmes de lecture) resteront dépendants des solutions d'Adobe (70k$ par an pour une licence RMSDK, 10k$ pour ACS4 ainsi qu'un coût par transaction) pendant de nombreuses années, le temps que la transition s'opère.

Cette initiative de l'IDPF représente certes un vrai pas en avant, mais il est déjà trop tard pour que celle-ci vienne vraiment résoudre le sac de noeud actuel, et si on veut favoriser un vrai marché ouvert, le watermarking reste une solutions bien plus efficace.
Ce qui n'empêche en aucun cas de soutenir l'IDPF dans leurs efforts en la matière : à défaut d'une vraie alternative pour le consommateur, nous avons besoin d'une moyen simple de protéger un fichier EPUB par mot de passe pour certains des usages décrits par ce document (échange de fichier EPUB entre deux entreprises par exemple).

En dehors des arguments habituels qui viennent sur la table quand on débat de la question des DRMs (complexité d'utilisation pour les utilisateurs, inefficacité face au piratage, coûts importants, favorise l'émergence de plateformes qui limitent la portabilité et les usages), le coût le plus important reste celui de l'innovation. Si au lieu d'être limité par un plus petit dénominateur technologique commun (la solution RMSDK d'Adobe), nos périphériques et nos logiciels s'appuyaient sur des moteurs de rendus Web modernes (que ce soit Webkit, Gecko, Presto ou Trident), on pourrait continuer de tirer par le haut l'innovation: que ce soit par un meilleur support du format EPUB 3.0 ou en réinventant nos modes de lecture. Faire le choix d'abandonner les DRMs, c'est aussi faire ce pari d'un véritable écosystème, où l'innovation serait moins bridée par une main mise d'un ou deux acteurs sur le domaine.
Prepared for IDPF by Bill Rosenblatt, GiantSteps Media Technology Strategies (edited by IDPF mgmt.) Publication Date: May 18, 2012. Introduction. This document is an initial statement of requirements ...
6
4
Hervé Bienvault's profile photoNicolas Robaux's profile photo
2 comments
 
Merci, une fois de plus, pour cette très instructive analyse. Tu devrais en écrire plus souvent !
Sinon, la question du chiffrement entre entreprises peut tout à fait se résoudre sans faire appel à un mécanisme de DRM : il existe déjà des tonnes de façon de chiffrer un fichier, de façon fiable, ouverte et contrôlée par la communauté (les premières idées qui me viennent : les archives .7z chiffrées, truecrypt, le chiffrement de fichiers avec GnuPG, etc…). En matière de sécurité, je préfère d’ailleurs mille fois chiffrer un PDF avec GnuPG qu’avec la solution boîte-noire d’Adobe…
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Designing for Android 4.0

For the last three months, I've been running ICS on my phone. While it really represents a huge step forward in terms of design and user experience for Android, very few apps have been updated yet to fully embrace these new best practices.

Based on the Android Design Guidelines (http://developer.android.com/design/index.html) and my own experience with ICS, I've decided to start a little project of my own: taking a popular Android 2.x app, and creating mockups of its Android 4.x equivalent.
With over 5 million users, +Aldiko is one of the most popular reading application on Android, and the perfect target for this exercise.

Keep in mind that my Photoshop skills are incredibly bad, and these screenshots don't represent anything final at all.
This whole project is about thinking out loud how an Android 4.0 application should behave, and how Android devs might redesign their own apps in the future.

I'll update this post after each new screen is posted.

Bookshelf

Aldiko's bookshelf is what people would associate the most with this app. It was adopted before Apple released their own iBooks app.

For this first screen, I mostly spent time redesigning the top of the screen.

Android 3.x introduced an UI element called the action bar (http://developer.android.com/design/patterns/actionbar.html).
I adopted the dark holo theme for this action bar (it's also available in white).
Unlike the 2.x app with its brown gradient, in ICS the action bar is never displayed using a gradient and no separators are displayed between the actions.

In the upper left corner of the action bar, the icon of the application is displayed instead of a home button.
The "Up" caret displayed next to the icon means that this is not the top-level element of the application.
"Up" is an important navigation element in ICS (http://developer.android.com/design/patterns/navigation.html).

For the text ("Bibliothèque" means "Bookshelf" in France), I adopted the new convention: left alignment and Roboto for the typeface.

Instead of a basic text element, I decided to turn the text into a spinner (http://developer.android.com/design/building-blocks/spinners.html).
The 2.x version displayed a non-standard button on the shelf itself to re-order books.
Using a spinner to re-order books make much more sense here. The user would instantly recognize the element as a spinner due to the triangle, and this use case fits the guidelines for spinners in the action bar ("Spinners are useful when changing the view is important to your app, but not necessarily a frequent occurrence").

The "action overflow" element (three dots in the upper right corner), where we display all the actions that used to be displayed using the menu hardware button is now displayed in the action bar. On a device with hardware buttons, this action could be hidden.

Finally, while the bookshelf with its faux-wood looks is really popular with users, it feels too skeuomorphic for ICS. This is more in line with what Apple does on iOS. An alternate option, with more minimalistic looks might fit better with the Android guidelines.
4
1
Kevin Wu's profile photoHadrien Gardeur's profile photoAlex Kuiper's profile photo
4 comments
 
I'm interestied to see where this goes... I develop PageTurer, an open source e-reader, and I haven't used the action bar so far. I think it's time to enter the ICS era though, so I hope you don't mind if I steal some of your ideas :)
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Nouvelle présentation en français pour expliquer les fondamentaux d'OPDS. Volontairement non technique mais assez abstrait afin de pouvoir pleinement saisir les concepts clés.
 ·  Translate
4
4
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
NISO/IA Meeting in San Francisco

Several people have already posted extensive notes about this meeting. Among them I recommend reading +Peter Brantley article in PW (http://blogs.publishersweekly.com/blogs/PWxyz/?p=7780), +marc jahjah for an excellent analysis (in French, but worth translating for anyone) based on the tweets that were published during the meeting (http://www.sobookonline.fr/livre-enrichi-social-interactif/livre-social/books-in-browsers-annotations-et-lecture-sociale/) along with the EtherPad that was shared by the attendees (http://ietherpad.com/ep/pad/view/ro.cpCnwYD9oW6/rev.769).

While a similar meeting was also organized during the Frankfurt Book Fair, it seems that the SF meeting was overall much more technical, and the round table organized at the end of the day was a good way to kickstart the project.
For this post, I'd like to focus on these discussions and provide an overview of the things we discussed and decided during this round table.

Scope

Many issues were raised during the first half of the day. Among other things, to have a fully standard way of sharing annotations we would need to deal with:
- a way to point precisely in the text
- a standard model (OAC ?)
- metadata associated to the annotation
- a serialization format
- an exchange protocol
- privacy issues
- copyright issues
- identifiers for the publications
... and this list could go on and on forever.

In order to be as pragmatic as possible about what we should do first, we raised hands to vote and decide what the most pressing issue would be. A vast majority voted for the pointers/locators. If we can't associate an annotation to its original text, what's the point of working on anything else ?

Strong/Weak Linking

During his presentation, +Bill McCoy (IDPF) mentioned that one of the things that the EPUB3 Working Group identified while working on annotations was the need for two types of links between an annotation and its source:
- a strong link that will point very precisely in a text but might easily break if the source is modified
- a weak link (also called a fuzzy link) that won't point as precisely in a text but should be less affected by potential updates

While the EPUB3 WG didn't completely solved this problem, and struggled with a good way to group/package this information together, a strong linking specification was still published under the name of Canonical Fragment Identifier (http://idpf.org/epub/linking/cfi/epub-cfi.html).
Unlike similar specifications (XPath, Xpointer), CFI solves a few problems that are specific to an EPUB publication (such as pointing to the right file in the container, and not just the right XML element and character).

Context is essential

During our debates, Aaaron Miller (ReadSocial) insisted several times that context is essential.
If we create annotations and link them back to the text strictly with a strong link, such annotations would be almost useless without the original source.

On the other hand, if the annotation includes additional information that would also be relevant to a human (such as the highlighted text or the position in the book), these annotations could easily be displayed and used on their own.
Services such as ReadMill or Findings are entirely built on such annotations.

No perfect solution, the right one is a mix of strong/weak linking

Luckily, what we call context here seems very similar to the idea of a weak link. Not only would this information allow third-party services to add value to these annotations, but they would also be potentially less prone to turn into orphans as the text is updated.

Since there is no perfect way to link an annotation to its source, the right solution would be a mix of strong/weak links. We must also realize that even with such a combination, an annotation could still turn into an orphan if the text is heavily updated, which means that context is even more essential. We need context to make such annotations useful on their own, even when they can't be linked back to their original source.

Strong link ?

While CFI was the only strong linking solution officially presented during the day, everyone around the table used something equivalent.

Some of them were counting paragraphs and then characters (which is clearly limited since we could also annotate a video or an image thanks to media fragments), others relied on DOM Selectors, XPath or even their own ways of selecting an XML element and then down to the character level.

It'll take some time and efforts for everyone to agree on the right solution and we might need to allow several options. The following requirements have been identified so far:
- we need to be able to sort these links easily
- we need to select an XML document in a package (CFI for EPUB is an example of this need)
- we need to be able to select any element in an XML tree and not just paragraphs (annotations on an image, video, audio file)
- we need to have character level precision in text
- for other media we can adopt the Media Fragments URI 1.0 (http://www.w3.org/TR/media-frags/)
- the spatial dimension (from Media Fragments URI 1.0) need to be extended to support non-rectangular shapes

Weak link ?

Aside from providing a better context, everyone around the table also used one or more weak links to improve the accuracy of their annotations. Such links were not strictly used for context, everyone agreed that using them with different heuristics clearly helped, and a few services even mentioned that with the same annotation/links they managed to improve accuracy over time.

These links were all either positions or text strings.

For the position, everyone either used a character count (seems very fragile to me without a total character count too) or a % (which would be equivalent if this is provided with a long float).
Rules would need to be clearly defined for both. Do you count blank characters too ? Do you count XML elements as characters ? Would a total character count provide more information than a % (could be an indication that the text has been updated) ?

For text, everyone had their own rules too. It seems that most of them stored the highlighted text, but many services also stored text before and after the highlighted portion.
Processing rules were also different between services. What would be the ideal length of the stored text before/after the highlight ? How do you deal with blank characters ? Is it better to have an offset rather than the text right before/after the highlight ?

All of these questions need to be answered before we can rely on this information for something more than context, but overall these were mostly details and all agreed on the major points.

Other links and a container

Aside from these examples, a few domain specific publishers raised an interesting point: for some publications such as the Bible, legal documents or scientific papers, other units exist as a standard way to reference the source document.
We'll need to provide basic extensibility to allow these specific references.

Since we'll need several links and various metadata to create an annotation, a container is also an absolute requirement. Even if we don't tackle issues like a protocol for annotation sharing, we do need to define a few rules on how this container and these core links/locators (which concepts/words should we adopt ?) should be serialized.

Moving forward

We're only getting started, and it'll take time and effort to tackle and solve all of the various points that we raised (see the scope section of this document).
If we can agree on how we link annotations to their source though, we'll have the most important requirement solved. The real work will start on January, when the working group is officially launched. In the meantime, we could make a real step forward if each service documented its own links/locators (the IDPF went through a similar step before the Taiwan meeting about Fixed Layout, see http://code.google.com/p/epub-revision/wiki/TaipeiFixedLayoutWorkshop)
4
Hadrien Gardeur's profile photomarc jahjah's profile photo
3 comments
 
Ok, cool, merci.
Add a comment...
People
Have him in circles
736 people
Nicolas Robaux's profile photo
Cyrille Sidjouo's profile photo
Bernard Prost's profile photo
christophe wocial's profile photo
Mike Cane's profile photo
David Morrell's profile photo
Marc Hébert's profile photo
Gary Wayne Clark's profile photo
Jose Afonso Furtado's profile photo
Work
Occupation
Entrepreneur
Employment
  • Feedbooks
    Co-Founder, 2006 - present
Basic Information
Gender
Male
Birthday
February 1
Story
Tagline
Entrepreneur, Tea Addict & Music Geek
Introduction
I'm the co-founder of Feedbooks, and as an engineer and entrepreneur, my goal is to contibute to the Open Web through standards for digital reading.
Bragging rights
Created the first EPUB files (widely adopted standard for ebooks) on the Web
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Paris
Links
Contributor to