Comparações entre ficheiros em formatos HTML e PDF
J'ai procédé à quelques expériences simples. Peut-être utile pour ceux
qui voudraient publier intégralement en html.
D'abord, un fichier de 50 à 60 pages de texte en html (100.000 signes
environ) me prend 100 ko, le même en pdf: 500 ko. La différence n'est
pas une surprise, évidemment. Pas vraiment gênant au niveau du "client"
pour télécharger un pdf de 300 p par exemple avec l'adsl (quelques
dizaines de seconde en fonction de la connexion). Mais la différence de
taille au niveau d'un serveur qui distribue un grand nombre de ces
fichiers pourrait faire réfléchir. Tout dépend de la finalité. Se
place-t-on dans la perspective d'un fichier uniquement visionable pour
lecture ou d'un fichier par surcroît imprimable? Pour l'avenir du livre
électronique, la possibilité d'impression est-elle fondamentale ou
faut-il se polariser sur la seule lecture par écran interposée? Si on
choisit cette seconde optique (qui répond tout de même à la définition
du livre électronique), la solution lourde d'un fichier pdf ne se
justifie plus, on doit pouvoir trouver des solutions plus légères et
plus souples. C'est sans doute le cas pour les versions Mobypocket, Sony
reader(?) D'ailleurs, le même fichier odt de 50 pages prend 70 ko au
lieu de 100 pour le html avec une mise en page plus élaborée. Et on doit
pouvoir faire sans doute encore mieux. Seulement, ces format ne sont pas
libres comme le html et les machines n'ont sont pas pourvues
automatiquement. La puissance du html est qu'il est utilisé pour des
centaines de millions de documents et on se demande si le livre
électronique ne gagnerait à s'accorder à cette forme générale. Et
l'avenir est peut-être plus un enrichissement de l'html plutôt qu'un
langage spécifique pour le livre électronique. En second lieu, je
considère qu'un navigateur est le logiciel obligatoire de toute machine
(à ma connaissance), ce qui n'est pas totalement vrai en ce qui concerne
un lecteur de pdf, encore moins oru les autres formats propriétaires
cités plus haut. Ensuite il existe une norme universelle, un format
libre de droit pour l'html En dernier lieu, il faut considérer
l'approche des lecteurs. La lecture dans le futur (et même actuellement)
consiste (ou consistera)-elle essentiellement en un gros volume que l'on
télécharge et que l'on lit entièrement? C'est fonction du type d'ouvrage
et des habitudes de lecture. La tendance est de plus en plus au zapping,
qu'on le veuille ou non. De ce point de vue, l'accès direct à des pages
html par le web est beaucoup plus souple, agréable et facile que
l'ouverture d'un pdf (si on est en ligne, bien sûr). L'internaute ne
supporte même plus les "versions html" minimales que nous sert google à
partir des pdf et il évite les pdf, qu'il supporte encore moins
d'ouvrir. Entre l'ouvrage proprement dit et le document web, la
différence tend à s'estomper sur le plan de l'utilisation, alros la
spécificité d'un format de livre électronique se justifie-t-elle?
Toujours dans cette optique, la structure de l'html facilite le
consultation fragmentaire et topique de l'ouvrage par le système des
liens, ce que ne fait pas le pdf. Bien sûr, d'autres formats très légers
autres que l'html peuvent assurer cette navigation souple sans problème.
Tout cela peut être discuté évidemment. Sur le plan programmation, c'est
vrai que le html, ce n'est pas toujours génial. Pour ce qui me concerne
personnellement (et cela peut concerner d'autres personnes dans le même
cas), je pense que mes ouvrages seront plus facilement accessibles et
lus s'ils sont proposés en html en petits fichiers que l'on peut suivre
par un lien "suite". Le problème du css peut être résolu en intégrant
les styles dans la partie head de tous les fichiers. 1ko pour une
dizaine de styles, cela ne vaut pas le coup de s'en priver pour le cas
où ces fichiers ne seraient pas lus en ligne, ce qui est et restera sans
doute encore longtemps le cas général pour le livre électronique. Dans
ce cas on peut télécharger facilement. Pour la mise en forme à partir
d'un fichier de traitement de texte, je la fais à la main, mais je pense
qu'un script peut résoudre le problème assez facilement pour un grand
nombre d'ouvrages, ceci pour les ouvrages présentant du texte sans mise
en page élaborée (la grande majorité des textes littéraires). Voilà
quelques pistes de réflexion.
qui voudraient publier intégralement en html.
D'abord, un fichier de 50 à 60 pages de texte en html (100.000 signes
environ) me prend 100 ko, le même en pdf: 500 ko. La différence n'est
pas une surprise, évidemment. Pas vraiment gênant au niveau du "client"
pour télécharger un pdf de 300 p par exemple avec l'adsl (quelques
dizaines de seconde en fonction de la connexion). Mais la différence de
taille au niveau d'un serveur qui distribue un grand nombre de ces
fichiers pourrait faire réfléchir. Tout dépend de la finalité. Se
place-t-on dans la perspective d'un fichier uniquement visionable pour
lecture ou d'un fichier par surcroît imprimable? Pour l'avenir du livre
électronique, la possibilité d'impression est-elle fondamentale ou
faut-il se polariser sur la seule lecture par écran interposée? Si on
choisit cette seconde optique (qui répond tout de même à la définition
du livre électronique), la solution lourde d'un fichier pdf ne se
justifie plus, on doit pouvoir trouver des solutions plus légères et
plus souples. C'est sans doute le cas pour les versions Mobypocket, Sony
reader(?) D'ailleurs, le même fichier odt de 50 pages prend 70 ko au
lieu de 100 pour le html avec une mise en page plus élaborée. Et on doit
pouvoir faire sans doute encore mieux. Seulement, ces format ne sont pas
libres comme le html et les machines n'ont sont pas pourvues
automatiquement. La puissance du html est qu'il est utilisé pour des
centaines de millions de documents et on se demande si le livre
électronique ne gagnerait à s'accorder à cette forme générale. Et
l'avenir est peut-être plus un enrichissement de l'html plutôt qu'un
langage spécifique pour le livre électronique. En second lieu, je
considère qu'un navigateur est le logiciel obligatoire de toute machine
(à ma connaissance), ce qui n'est pas totalement vrai en ce qui concerne
un lecteur de pdf, encore moins oru les autres formats propriétaires
cités plus haut. Ensuite il existe une norme universelle, un format
libre de droit pour l'html En dernier lieu, il faut considérer
l'approche des lecteurs. La lecture dans le futur (et même actuellement)
consiste (ou consistera)-elle essentiellement en un gros volume que l'on
télécharge et que l'on lit entièrement? C'est fonction du type d'ouvrage
et des habitudes de lecture. La tendance est de plus en plus au zapping,
qu'on le veuille ou non. De ce point de vue, l'accès direct à des pages
html par le web est beaucoup plus souple, agréable et facile que
l'ouverture d'un pdf (si on est en ligne, bien sûr). L'internaute ne
supporte même plus les "versions html" minimales que nous sert google à
partir des pdf et il évite les pdf, qu'il supporte encore moins
d'ouvrir. Entre l'ouvrage proprement dit et le document web, la
différence tend à s'estomper sur le plan de l'utilisation, alros la
spécificité d'un format de livre électronique se justifie-t-elle?
Toujours dans cette optique, la structure de l'html facilite le
consultation fragmentaire et topique de l'ouvrage par le système des
liens, ce que ne fait pas le pdf. Bien sûr, d'autres formats très légers
autres que l'html peuvent assurer cette navigation souple sans problème.
Tout cela peut être discuté évidemment. Sur le plan programmation, c'est
vrai que le html, ce n'est pas toujours génial. Pour ce qui me concerne
personnellement (et cela peut concerner d'autres personnes dans le même
cas), je pense que mes ouvrages seront plus facilement accessibles et
lus s'ils sont proposés en html en petits fichiers que l'on peut suivre
par un lien "suite". Le problème du css peut être résolu en intégrant
les styles dans la partie head de tous les fichiers. 1ko pour une
dizaine de styles, cela ne vaut pas le coup de s'en priver pour le cas
où ces fichiers ne seraient pas lus en ligne, ce qui est et restera sans
doute encore longtemps le cas général pour le livre électronique. Dans
ce cas on peut télécharger facilement. Pour la mise en forme à partir
d'un fichier de traitement de texte, je la fais à la main, mais je pense
qu'un script peut résoudre le problème assez facilement pour un grand
nombre d'ouvrages, ceci pour les ouvrages présentant du texte sans mise
en page élaborée (la grande majorité des textes littéraires). Voilà
quelques pistes de réflexion.
Claude Fernandez
Fonte: Post de Claude Fernandez no grupo do Yahoo ebooks Gratuits
Sem comentários:
Enviar um comentário