Découverte à la mesure : l'EAN-2 est DÉSACTIVÉ par défaut dans zbar. Il ne
suffisait donc pas de cesser de le filtrer — il n'était jamais produit.
Vérifié sur un EAN-13 + EAN-2 rendus en canvas : un symbole par défaut,
deux après setConfig(ZBAR_EAN2, ZBAR_CFG_ENABLE, 1).
L'EAN-5 reste désactivé : il porte un prix, pas un numéro.
Ce qui reste non vérifié — que les magazines réels y mettent bien leur
numéro de parution — est dit à l'utilisateur : le numéro est proposé dans
un champ modifiable, sous une invitation à le comparer à la couverture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'ISBN 9782846391009 n'était pas décodé par l'application, alors qu'il
l'était par une application d'essai utilisant zbar, sur le même livre et
le même appareil.
⚠️ Le raisonnement qui avait écarté cette piste était faux : CLAUDE.md
concluait que « le décodeur n'y est pour rien » à partir de mesures de
VITESSE (4-6 ms/frame). La vitesse ne dit rien du taux de réussite.
Le décodage quitte donc le C# pour zbar compilé en WebAssembly, dont les
assets viennent du paquet ZBar.Blazor.
Ce que la bascule apporte, au-delà du code lu :
- plus aucun pixel ne traverse le pont JS→C# (un byte[] par frame avant),
seule la valeur décodée le fait ;
- l'image ENTIÈRE est analysée, à 960 px, là où l'ancienne version
recadrait sur la bande centrale à 640 px pour alléger ce transfert —
c'était la seconde cause possible des codes non lus, elle disparaît ;
- zbar.wasm est chargé À LA DEMANDE, à la première ouverture du scanner.
⚠️ Le composant ZBarCamera du paquet n'est PAS utilisé : il ouvre la
caméra lui-même et avale les erreurs. On y perdrait les messages qui
distinguent permission refusée, absence de caméra, caméra occupée et
contexte non sécurisé, ainsi que facingMode environment (caméra arrière)
et l'indication de résolution. Seuls zbar.js et zbar.wasm sont empruntés.
Poids, comparaison de deux publish Release complets (somme brotli) :
_framework 3 281 558 → 2 978 700 o (−296 Kio au démarrage)
total 3 281 558 → 3 125 541 o (−152 Kio)
L'écart vient de la traîne que ZXing imposait au trimmer :
System.Text.RegularExpressions retombe de 98 374 à 7 137 o, et
System.Runtime.Numerics disparaît.
⚠️ Coût assumé : six tests de décodage disparaissent avec IsbnScanner,
le décodeur n'étant plus en C#. Le décodage a été vérifié dans le
navigateur sur un EAN-13 rendu en canvas — 9782846391009 ressort bien en
ZBAR_EAN13 — mais cela reste une vérification, pas un garde-fou.
À confirmer avec le livre en main.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le piege que CLAUDE.md signale : en Blazor WebAssembly le code tourne dans le
navigateur alors que SQLite vit sur le serveur, et le service worker ne met en
cache que les assets. Sans travail explicite, l'application demarre hors-ligne
et affiche une bibliotheque vide.
- js/cache-hors-ligne.js : instantanes JSON dans IndexedDB, et surveillance des
bascules online/offline. Aucune logique metier.
- CacheHorsLigne / EtatReseau : lecture-ecriture des instantanes, et etat reseau
combinant navigator.onLine (fiable seulement par sa negation) avec le sort
reel des appels HTTP.
- ServiceLivresApi : les lectures retombent sur le cache, les ecritures sont
refusees. Le catalogue entier est memorise, pas les reponses filtrees : c'est
ce qui rend la recherche hors-ligne possible sur tout le fonds.
- FiltreLivresLocal : pendant navigateur de FiltreLivres, avec un test qui
confronte les deux implementations sur les memes donnees.
- Interface : pastille et bandeau d'etat avec la date de synchronisation, et
actions d'ecriture desactivees avec leur raison plutot que boutons morts.
- js/mise-a-jour.js : les empreintes WASM etant desactivees, le service worker
est le seul cache-busting du projet. L'enregistrement journalise desormais ses
echecs, et un bandeau propose la nouvelle version sans attendre la fermeture
de tous les onglets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux defauts ont ete constates en executant reellement l'application, pas par
relecture :
1. L'import du module JS partait en 404 en developpement. L'import map generee par
Blazor reecrit « ./js/scanner-camera.js » vers un nom empreinte que l'API hote ne
sert pas (UseStaticFiles ignore les points d'entree empreintes). Une chaine de
requete sur le specifieur empeche la reecriture ; en publication rien n'est
reecrit pour ce fichier, le comportement est donc identique dans les deux modes.
2. Les messages d'erreur camera etaient tous generiques. Une DOMException perd son
« name » en traversant le pont JS vers C# : un refus de permission arrivait sous
la forme « Permission denied undefined ». Le JS attrape donc l'erreur et renvoie
un code de statut stable, que le C# traduit en message utile.
CLAUDE.md est mis a jour avec les mesures reelles obtenues en WASM, qui manquaient :
la performance de decodage (l'estimation de 5-10 ms/frame est confirmee, l'AOT reste
inutile) et le surcout de payload, nettement superieur aux 192 Ko documentes une fois
comptees les assemblies BCL que ZXing empeche le trimmer de retirer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le decodage EAN-13/EAN-8 est fait en C# par ZXing.Net (IsbnScanner), conformement
a la decision actee dans CLAUDE.md : le JavaScript ne fournit que les pixels de la
camera, aucune logique de decodage ne lui est confiee.
Le scan se greffe en amont du flux d'ajout par ISBN existant : des qu'un code est
lu et reconnu comme ISBN-13 valide, la recherche de notices est declenchee sans
que l'utilisateur ait a retaper quoi que ce soit. La saisie manuelle reste
accessible en permanence, y compris quand la camera echoue.
Points traites explicitement :
- camera arriere par defaut (facingMode "environment", en "ideal" pour ne pas
echouer sur un PC sans camera arriere) ;
- liberation de la camera a l'annulation, au succes et au demontage du composant ;
- cadence limitee a ~12 images/s et decodage restreint a la bande centrale
reduite a 640 px de large : inutile de decoder chaque frame en pleine taille ;
- messages distincts pour permission refusee, absence de camera, camera occupee
et contexte non securise (getUserMedia exige HTTPS ou localhost : une IP de
reseau local en http ne marchera jamais, c'est une source de confusion garantie).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
