Cause racine (reproduite et verrouillee par test) : l'insertion PDF
demandait la police integree Helvetica tout en fournissant un fichier
de police — PyMuPDF ignore alors le fichier, et Helvetica n'a aucun
glyphe arabe : chaque lettre persane devenait un '?', et ces '?'
debordaient les boites d'origine (les nombreux « [translation
overflow] »). Defaut present dans toutes les versions deployees.
- le nom de police est desormais Personnalise quand un fichier de
police est fourni : le fichier est reellement integre
- reproduction complete avant/apres : 0 '?', 0 debordement, persan
rendu avec la police resolue
- test de non-regression : la page traduite ne contient PAS Helvetica
et le texte extrait n'a aucun '?'
- bouton « Reconstruire » de la relecture : une infobulle explique
desormais pourquoi il est grise (aucun segment approuve ni modifie),
dans les 13 langues
Persan -> francais : le document traduit restait en lecture de droite a
gauche, heritee de la source. Trois causes :
- PDF : regression du renommage precedent — le choix d'alignement
testait la fonction is_rtl (toujours vraie) au lieu du parametre :
tout texte traduit s'alignait a droite, quelle que soit la cible.
Corrige + test epinglant l'alignement gauche pour une cible latine.
- Word : les marques RTL heritees (bidi, rtl, bidiVisual, notes et
commentaires compris) sont desormais retirees quand la cible est
latine ; retrait fait sur une liste figee (l'iterateur lxml sautait
des elements pendant la suppression).
- Excel : les feuilles heritees d'un affichage droite-a-gauche sont
remises en lecture gauche-a-droite pour une cible latine.
- PowerPoint : les attributs rtl herites sont retires pour une cible
latine (alignements visuels conserves).
3 tests de bout en bout nouveaux : document RTL traduit vers le
francais ressort en lecture gauche-a-droite dans les trois formats.
- Word: sous w:bidi, w:jc est logique (left=dbut=droite visuelle,
right=fin=gauche visuelle) ; forcer jc=right alignait donc les
paragraphes a gauche et crasait le centrage hrit du style.
Dsormais le RTL pose w:bidi et w:rtl sans jamais toucher w:jc,
comme le fait Word lui-mme pour un document RTL.
- PowerPoint: algn n'est plus crit quand le paragraphe n'en dfinit
pas, afin de respecter l'alignement hrit du masque (titres centrs) ;
algn=l explicite reste converti en r (algn est visuel en DrawingML).
- tests: centrage par style Word prserv, aucun w:jic crit, algn
absent non cras côté PowerPoint
- source unique RTL_LANGUAGES/is_rtl dans core/languages.py (fin des 3 copies)
- Word: bidi partout (corps, tableaux bidiVisual, notes/fin/commentaires,
zones de texte, 6 zones d'en-tetes/pieds), insertion OOXML ordonnee,
polices cs elargies aux 11 langues
- PowerPoint: alignements explicites preserves, notes du presentateur,
indice de police <a:cs> insert a sa place
- Excel: feuilles affichees de droite a gauche, feuilles graphiques ignorees
- PDF: faconnage bidi (arabic-reshaper + python-bidi), polices par ecriture
(arabe/hebreu), TTF enregistree pour le PDF recompose
- 46 tests nouveaux (tests/test_translators/test_rtl_layout.py), 253 au total
