Tuto: Exploiter n'importe quelle police dans vos pages HTML avec FLIR

Hello world

Vraiment j'aime beaucoup la dernière phrase de ce tutoriel:

polices-exotiques-avec-flir-et-php.html

Il faudrait commencer par là je pense... et en rester là...
... Quand j'imagine qu'il faut encore expliquer (sans chance d'être entendu)
certaines directions d'entreprises ou d'institutions de ne pas mettre en pdf
des documents scannés, pour cause d'absence de sélection, et ne parlons
pas de recherche

Donc sexy et pas si mal vu bien sur... Mais non, encore non.

Désolé

Hello,

Je n'ai pas compris le fond de ta pensée, ni si tu étais ironique ou pas.
Et "non" par rapport à quoi ?

Je pense que c'est par rapport au texte qui n'est pas sélectionnable. Pour 4/3 il aurait fallu le mentionner dès le départ.

Mais personnellement, je ne vois pas où est le mal à ne pas pouvoir sélectionner du texte dans certains cas... Exemple, le slogan d'un site, les titres, les menus,.. Et puis, pourquoi pas du contenu également ? Si le responsable du site part du principe que son texte n'as pas besoin d'être copié, ca ne pose aucun problème.

a écrit :
Quand j'imagine qu'il faut encore expliquer (sans chance d'être entendu) certaines directions d'entreprises ou d'institutions de ne pas mettre en pdf des documents scannés, pour cause d'absence de sélection

Et dans ce cas, que fais tu alors ? Tu envoies simplement une image ? La solution pdf est bien plus acceptable...

pixelb a écrit :

Et dans ce cas, que fais tu alors ? Tu envoies simplement une image ? La solution pdf est bien plus acceptable...

Ce qui doit être fait est très simple:
Au lieu de scanner le document, exporter
le fichier d'origine au format pdf.
Si le fichier d'origine n'existe pas ou n'existe plus,
et bien faire l'effort de tout ressaisir.


A Raphael
Non aucune ironie

Mon "non" est "non à l'utilisation de cette solution"
même si je la trouve séduisante. Tous les principes de
qualité web s'y opposent, tout travail de réalisation de
sites orientés utilisateurs s'y oppose.

4/3 a écrit :

Si le fichier d'origine n'existe pas ou n'existe plus,
et bien faire l'effort de tout ressaisir.

Les documents avec lesquels on travaille ne sont pas forcément issus de notre société/entreprise. Lorsque tu reçois un courrier ou un fax que tu souhaites transmettre à tes collègues, tu ne vas pas le retaper complètement. C'est inutile et c'est une perte de temps.

Acrobat dispose d'une fonction OCR pour avoir des pdf scan+texte.

De plus, pas mal de logiciel de scan sont capable de sauver en pdf texte+image grâce aussi à un OCR incorporé.

Mais on s'éloigne du sujet.


Pour moi le tuto est intéressant mais à l'heure de @font-face je ne vois pas trop l'intérêt, à part peut-être pour certaines polices avec des licences spécifiques.

Sinon pour ce qui est de la recherche, il n'y a pas de problèmes, puisque le code html de base est sans image.
Modifié par Patidou (18 Jun 2010 - 13:30)

Patidou a écrit :
Pour moi le tuto est intéressant mais à l'heure de @font-face je ne vois pas trop l'intérêt, à part peut-être pour certaines polices avec des licences spécifiques.

Deux gros problèmes avec @font-face:
1. Problèmes de licence pas compatible @font-face (c'est pas «certaines polices avec des licences spécifiques» qui posent problème, c'est juste la quasi-totalité des polices commerciales).
2. Problèmes de qualité du rendu, qui peut rendre le texte moche et/ou illisible dans certains cas de figure.

Le premier problème peut se régler en changeant de police (pas toujours possible ou souhaitable). Le deuxième peut se régler en testant, testant, et parfois en changeant de police (même combat).
La solution proposée dans le tutoriel, qui est une génération d'images assez simple côté serveur (et un peu de JS pour l'appliquer à la volée sans toucher à la source HTML côté serveur), a ses propres défauts mais évite en grande partie ces deux problèmes. C'est pas négligeable.

Patidou a écrit :
Sinon pour ce qui est de la recherche, il n'y a pas de problèmes, puisque le code html de base est sans image.

Moteurs de recherche: ok.
Recherche dans la page (navigateur): pas ok.

Pour information, avec un bon navigateur, si on sélectionne une image qui a un texte alternatif, quand on copie ça copie le texte alternatif. J'ai lu récemment que Firefox est le seul à faire ça correctement (de même qu'il est le seul à gérer décemment l'affichage des images manquantes); pourvu que ça change...

Florent V. a écrit :


Moteurs de recherche: ok.
Recherche dans la page (navigateur): pas ok.

Je parlais bien de la recherche utilisateur via user agent.

Vous le savez bien, tout cela est important, exigeant,
frustrant et, en toute rigueur, sans compromis.


Pour revenir à la question de Raphael a propos de l'ironie,
mais comme déjà dit il ne s'agit pas de ça, mais plutôt de
cruauté de situation. Ce qui m'impressionne dans le tutoriel
de FranckHTML c'est que la dernière phrase, très lapidaire et
très honnête, rend tout l'exposé qui précède caduc et,
à nouveau en toute rigueur, inapplicable, inexploitable.
Et cela sans doute du point de vue même de l'auteur...
Quel hiatus n'est ce pas?

Ce n'est en rien une critique d'ailleurs, juste une constatation
abrupte que je faisais partager.
Modifié par 4/3 (18 Jun 2010 - 15:57)

Il y a plein de site qui titraille en images, sans FLIR, faut juste ne pas abuser de la technique pour ne pas alourdir le chargement de la page. En plus c'est accessible : l'attribut alt est renseigné.
Modifié par Patidou (18 Jun 2010 - 16:15)

4/3 a écrit :
la dernière phrase, très lapidaire et très honnête, rend tout l'exposé qui précède caduc et, à nouveau en toute rigueur, inapplicable, inexploitable.
Et cela sans doute du point de vue même de l'auteur...

Du point de vue de l'auteur? Je vois pas comment tu peux l'affirmer.
Cette dernière phrase précise un inconvénient de la solution. Toi tu estimes que ça rend la solution inexploitable, mais l'auteur ne l'écrit pas. Je crois que si c'était le point de vue de l'auteur, il n'aurait pas pris la peine d'écrire cet article.