Fiabiliser le positionnement des images entre aperçu, pagination et impression

Reliodas commented

2026-07-16 16:53:55 +00:00

Owner

Contexte

Le positionnement d'une illustration n'est pas cohérent entre l'éditeur et le rendu final.

Sur les créatures, une image ajoutée par URL peut se déplacer à l'impression par rapport au cadrage choisi dans l'aperçu. La cause probable est la différence entre le rendu interactif de shared.js, fondé sur object-position et scale, et les styles reconstruits dans les snapshots imprimés.

Pour les classes et sous-classes paginées, seul le recto de la première carte reçoit l'identifiant card-art et le comportement de glisser-déposer. Les autres rectos sont déjà rendus avec un snapshot statique : un changement de cadrage effectué sur la première carte n'est donc pas reflété immédiatement sur toutes les cartes générées.

Enfin, le glisser-déposer utilise actuellement un déplacement inversé sur les axes et le geste tactile peut faire défiler la page au lieu de déplacer uniquement l'image.

Modifications à faire

Définir une représentation partagée du cadrage image (URL, position X/Y et zoom) utilisée à l'identique dans l'aperçu, les cartes paginées, le panier et l'impression.
Remplacer les formules de transformation divergentes entre shared.js, creatures.html, classes.html et subclasses.html par un helper de rendu commun ou un contrat unique.
Mettre à jour tous les rectos générés d'une classe ou sous-classe lorsqu'un cadrage change, sans limiter l'interaction au premier élément card-art.
Corriger le sens du glisser-déposer pour que l'image suive le geste de façon intuitive sur les deux axes.
Empêcher le scroll de la page pendant un glisser tactile actif, sans bloquer le défilement normal hors interaction.
Vérifier le comportement avec une image distante par URL et avec plusieurs cartes générées.
Ajouter une couverture Playwright ciblée pour comparer le cadrage aperçu, panier et impression.

Critères d'acceptation

Une image de créature conserve exactement le même cadrage entre l'aperçu, le panier, l'impression classique et le recto-verso aligné.
Modifier le zoom ou la position d'une classe ou sous-classe met à jour tous ses rectos générés.
Glisser vers la droite, la gauche, le haut ou le bas déplace visuellement l'image dans le sens attendu.
Sur écran tactile, déplacer l'image ne fait pas défiler la page ; le scroll normal reste disponible une fois le geste terminé.
Les snapshots déjà placés dans le panier restent stables après une modification ultérieure de l'éditeur.
Les smoke tests et la validation Playwright passent, avec au moins un scénario créature et un scénario classe ou sous-classe multipage.

## Contexte Le positionnement d'une illustration n'est pas cohérent entre l'éditeur et le rendu final. Sur les créatures, une image ajoutée par URL peut se déplacer à l'impression par rapport au cadrage choisi dans l'aperçu. La cause probable est la différence entre le rendu interactif de shared.js, fondé sur object-position et scale, et les styles reconstruits dans les snapshots imprimés. Pour les classes et sous-classes paginées, seul le recto de la première carte reçoit l'identifiant card-art et le comportement de glisser-déposer. Les autres rectos sont déjà rendus avec un snapshot statique : un changement de cadrage effectué sur la première carte n'est donc pas reflété immédiatement sur toutes les cartes générées. Enfin, le glisser-déposer utilise actuellement un déplacement inversé sur les axes et le geste tactile peut faire défiler la page au lieu de déplacer uniquement l'image. ## Modifications à faire - Définir une représentation partagée du cadrage image (URL, position X/Y et zoom) utilisée à l'identique dans l'aperçu, les cartes paginées, le panier et l'impression. - Remplacer les formules de transformation divergentes entre shared.js, creatures.html, classes.html et subclasses.html par un helper de rendu commun ou un contrat unique. - Mettre à jour tous les rectos générés d'une classe ou sous-classe lorsqu'un cadrage change, sans limiter l'interaction au premier élément card-art. - Corriger le sens du glisser-déposer pour que l'image suive le geste de façon intuitive sur les deux axes. - Empêcher le scroll de la page pendant un glisser tactile actif, sans bloquer le défilement normal hors interaction. - Vérifier le comportement avec une image distante par URL et avec plusieurs cartes générées. - Ajouter une couverture Playwright ciblée pour comparer le cadrage aperçu, panier et impression. ## Critères d'acceptation - Une image de créature conserve exactement le même cadrage entre l'aperçu, le panier, l'impression classique et le recto-verso aligné. - Modifier le zoom ou la position d'une classe ou sous-classe met à jour tous ses rectos générés. - Glisser vers la droite, la gauche, le haut ou le bas déplace visuellement l'image dans le sens attendu. - Sur écran tactile, déplacer l'image ne fait pas défiler la page ; le scroll normal reste disponible une fois le geste terminé. - Les snapshots déjà placés dans le panier restent stables après une modification ultérieure de l'éditeur. - Les smoke tests et la validation Playwright passent, avec au moins un scénario créature et un scénario classe ou sous-classe multipage.

Reliodas added this to the 1.0.0-beta milestone

2026-07-16 16:53:55 +00:00

Reliodas added the

Kind/Bug

Priority

High

labels

2026-07-16 16:53:55 +00:00

Reliodas referenced this issue

2026-07-16 17:22:54 +00:00

Fiabiliser les illustrations distantes des préréglages #92

Reliodas commented

2026-07-16 17:25:49 +00:00

Author

Owner

Complément issu de l'audit

Le problème de divergence de cadrage dépasse les seuls cas créature/classe :

l'aperçu partagé applique object-position puis scale ;
creatures.html, origins.html, equipment.html, feats.html et subclasses.html reconstruisent une formule scale + translate ;
classes.html n'applique que scale, sans la translation utilisée ailleurs ;
les tests visuels ne couvrent actuellement aucun cadrage, glisser-déposer ou chargement d'image.

Le correctif doit donc fournir un helper commun à tous les éditeurs avec illustration. Il doit aussi attendre que les images du panier soient chargées ou décodées avant d'ouvrir le dialogue d'impression, avec un comportement explicite en cas d'échec, en coordination avec #92.

## Complément issu de l'audit Le problème de divergence de cadrage dépasse les seuls cas créature/classe : - l'aperçu partagé applique object-position puis scale ; - creatures.html, origins.html, equipment.html, feats.html et subclasses.html reconstruisent une formule scale + translate ; - classes.html n'applique que scale, sans la translation utilisée ailleurs ; - les tests visuels ne couvrent actuellement aucun cadrage, glisser-déposer ou chargement d'image. Le correctif doit donc fournir un helper commun à tous les éditeurs avec illustration. Il doit aussi attendre que les images du panier soient chargées ou décodées avant d'ouvrir le dialogue d'impression, avec un comportement explicite en cas d'échec, en coordination avec #92.

Reliodas commented

2026-07-16 17:28:12 +00:00

Author

Owner

Autre cas confirmé pendant la revue : species.html affiche les mêmes contrôles de zoom et de position que les autres éditeurs, mais captureSnapshot() ne conserve ni imgX, ni imgY, ni imgZoom, et renderSpeciesCardPairHtml() rend seulement object-fit: cover. Le cadrage choisi est donc perdu dans le panier et à l'impression. Ce cas doit faire partie des scénarios de non-régression de #87.

Rows
Columns

Fiabiliser le positionnement des images entre aperçu, pagination et impression #87

Contexte

Modifications à faire

Critères d'acceptation

Complément issu de l'audit