FusionForge de l'ADULLACT: openMairie - Framework : [#8255] Edition: Sous-états, éviter la hauteur de ligne double sur les cellules dont le texte entre dans la largeur

Date :
23/05/2016 18:04

Priorité :
3

État :
Closed

Proposé par :
Laurent Groleau (lgroleau)

Confié à :
Nobody (None)

Sévérité :
normal

Version cible :
none

Version concernée :
none

Résumé :
Edition: Sous-états, éviter la hauteur de ligne double sur les cellules dont le texte entre dans la largeur

Description détaillée
Dans OM 4.5 r 3456, on a toujours une hauteur de ligne dans les sous-états qui est trop généreuse. Cette hauteur "cellule_hauteur" ne peut pas être inférieure à celle de la police "cellule_fontaille" dans le formulaire des sous-états, et est trop généreuse avec le code actuel. Par exemple on voit dans le sous-état en PJ le résultat avec 10 pour chacune des 2 valeurs (Avant.PNG). Dans le code PHP de .:core/fpdf_etat.php, dans la fonction sousetatdb() on utilise les comportements de hauteur de cellule par défaut suivant: -si le texte de la cellule rentre dans 1 ligne: $multi_height = $sousetat['cellule_hauteur'] -sinon on prend un multiple du nombre de lignes $max_ln: $multi_height = $max_ln$sousetat['cellule_hauteur']1/2 Pour openMarchéForain, pour les sous-états avec des données sur une ligne de texte, ça ne permet pas de mettre 30 tickets sur une page. Nous avons donc modifié le code comme suit sans régression ailleurs, pour initialiser $multiheight à la moitié de la hauteur de cellule quand on a une seule ligne de texte: ligne 746: $multi_height=$sousetat['cellule_hauteur']/2; (cf Apres.PNG) Je propose : -soit de faire de même dans le framework -soit avec une valeur à 0.6 -soit d'enlever le contrôle de validation dans le formulaire des sous-états entre hauteur de ligne et de police -soit de de remplacer cellule_hauteur, par cellule_hauteur_ratio_font pour indexer la hauteur de cellule sur celle de la police.
Dans OM 4.5 r 3456, on a toujours une hauteur de ligne dans les sous-états qui est trop généreuse. Cette hauteur "cellule_hauteur" ne peut pas être inférieure à celle de la police "cellule_fontaille" dans le formulaire des sous-états, et est trop généreuse avec le code actuel. Par exemple on voit dans le sous-état en PJ le résultat avec 10 pour chacune des 2 valeurs (Avant.PNG). Dans le code PHP de .:core/fpdf_etat.php, dans la fonction sousetatdb() on utilise les comportements de hauteur de cellule par défaut suivant: -si le texte de la cellule rentre dans 1 ligne: $multi_height = $sousetat['cellule_hauteur'] -sinon on prend un multiple du nombre de lignes $max_ln: $multi_height = $max_ln$sousetat['cellule_hauteur']1/2 Pour openMarchéForain, pour les sous-états avec des données sur une ligne de texte, ça ne permet pas de mettre 30 tickets sur une page. Nous avons donc modifié le code comme suit sans régression ailleurs, pour initialiser $multiheight à la moitié de la hauteur de cellule quand on a une seule ligne de texte: ligne 746: $multi_height=$sousetat['cellule_hauteur']/2; (cf Apres.PNG) Je propose : -soit de faire de même dans le framework -soit avec une valeur à 0.6 -soit d'enlever le contrôle de validation dans le formulaire des sous-états entre hauteur de ligne et de police -soit de de remplacer cellule_hauteur, par cellule_hauteur_ratio_font pour indexer la hauteur de cellule sur celle de la police.

Commentaires (2)
Pièces jointes (2)
Modifications (5)

Message
Date : 09/03/2017 16:02 Expéditeur : Thierry BENITA Ce point est abandonné en comité de pilotage : la logique de calcul des hauteurs de cellules nécessiterait d'être totalement revue ; nous clôturons le ticket car il faut plutôt aller vers une refonte des sous-états sur une base HTM.
Date : 27/12/2016 19:26 Expéditeur : francois raynaud Le CP du 09/12/2016 pense qu il faut envisager pour la 4.6 une refonte des sousetats pour profiter du html. Cette modification n est pas bloquante pour la sortie de la 4.5.0

Pièces jointes :

Taille	Nom	Date	Par	Télécharger
90 Kio	Avant.PNG	23/05/2016 18:04	Laurent Groleau	Avant.PNG
110 Kio	Apres.PNG	23/05/2016 18:04	Laurent Groleau	Apres.PNG

Champ	Ancienne valeur	Date	Par
status_id	Open	09/03/2017 15:58	Thierry BENITA
close_date	Aucun(e)	09/03/2017 15:58	Thierry BENITA
Version cible	4.5.0 [FUTURE VERSION]	27/12/2016 19:26	francois raynaud
File Added	3380: Avant.PNG	23/05/2016 18:04	Laurent Groleau
File Added	3381: Apres.PNG	23/05/2016 18:04	Laurent Groleau

Powered By FusionForge Collaborative Development Environment

Charte d'utilisation / Nous contacter / Mentions légales

Haut de page