svg correction

SVG_CONTENT_ARCHITECTURE.md

@@ -67,6 +67,48 @@ Le validateur doit refuser ou signaler :
 
 Le premier filet de sécurité est disponible dans `backend/tools/validate_svg_quality.py`.
 
+## Règles anti-chevauchement globales
+
+Les retours sur les 8 supports fractions montrent que valider une fraction isolée ne suffit pas.
+Chaque expression mathématique doit réserver une boîte complète avant d'être placée dans la card.
+
+Règles obligatoires :
+
+- toute `fraction-g` doit porter un `data-box="x y width height"` couvrant le numérateur, la barre, le dénominateur et la marge pédagogique ;
+- aucun texte, opérateur, figure, point, disque, bande ou autre fraction ne peut intersecter cette boîte ;
+- dans une expression, le curseur horizontal avance de la largeur réservée de la fraction plus un espacement minimal de 28 px pour du texte courant et 34 px pour les signes visibles ;
+- les signes `+`, `-`, `=`, `<`, `>` sont centrés sur l'axe de la barre de fraction, pas sur la ligne de base des chiffres ;
+- les signes de comparaison sont placés au milieu de l'espace entre les deux boîtes de fractions ;
+- une fraction posée près d'une figure utilise une zone mathématique dédiée au-dessus, en dessous ou à côté de la figure ; elle ne flotte jamais dans la zone de dessin ;
+- les lignes d'équations sont espacées d'au moins la hauteur réservée de la plus grande fraction de la ligne plus 18 px ;
+- une fraction inline dans une phrase garde un espace réservé avant et après, même si le texte semble court ;
+- les titres de card, légendes et encadrés `À retenir` sont des zones séparées : une fraction ne doit pas empiéter dessus.
+
+En pratique, chaque card doit être pensée en zones :
+
+1. zone titre ;
+2. zone mathématique ;
+3. zone figure ;
+4. zone légende ou explication.
+
+Une génération est rejetée si une boîte mathématique traverse une autre zone. C'est la règle qui évite les cas vus dans les captures : fractions collées aux mots, fractions sur les figures, signes décentrés, et lignes de fractions qui passent sous les schémas.
+
+## Règles de composition des expressions
+
+Les expressions doivent être générées par un layout horizontal, jamais par coordonnées libres.
+
+Le layout prend une liste de tokens :
+
+- `fraction(n, d, size)` ;
+- `operator("+")`, `operator("=")`, `operator("<")` ;
+- `text("est juste après 1")`.
+
+Chaque token expose sa boîte. L'expression calcule ensuite les positions.
+Les opérateurs ne sont pas des textes décoratifs : ils ont une boîte propre et une position centrée entre deux tokens mathématiques.
+
+Pour les équations sur plusieurs lignes, on compose chaque ligne séparément, puis on empile les lignes avec une hauteur constante.
+On ne réduit jamais l'interligne après coup pour "faire rentrer" une card ; si ça ne rentre pas, on change la disposition.
+
 ## Architecture cible courte
 
 À court terme :
@@ -95,4 +137,3 @@ L'architecture actuelle est acceptable pour afficher et relire des supports déj
 Elle n'est pas suffisante pour produire régulièrement des contenus mathématiques propres.
 
 La bonne direction n'est pas de remplacer SVG, mais de déplacer l'intelligence avant le SVG final : composants mathématiques, contraintes géométriques, validation automatique, puis rendu.
-