Largeur de colonne en points V3.0

[Katido]

Katido a soumis une nouvelle ressource:

Largeur de colonne en points - Comment fixer la largeur des colonnes en utilisant une unité pratique (points ou centimètres)

Pour fixer la largeur des colonnes d'une feuille Excel avec VBA, on doit utiliser la propriété ColumnWidth (car Width appliquée à une plage de cellules est en lecture seule)
Malheureusement, la valeur que doit prendre la propriété ColumnWidth doit être exprimée en "nombre de caractères de la police par défaut". Non seulement ce nombre dépend donc de cette police, mais il n'est même pas proportionnel à la largeur souhaitée.
D'où l'intérêt de faire un petit développement pour contourner ce...

En savoir plus sur cette ressource...

 

[TooFatBoy]

Bonjour,

J'ai téléchargé ton fichier et suis en train de le lire. C'est très bien écrit, en bon français, et c'est tellement rare qu'il faut le signaler.
La lecture est donc agréable, et en plus j'y apprends des choses super intéressantes.
Rien que pour ça déjà, félicitations et merci !

---

Je n'ai pour l'instant lu que le paragraphe 1, mais j'ai deux petits soucis.


D'abord ligne 27, je pense qu'il y a une petite coquille de copier/coller :

En lecture, ColumnWidth fonctionne comme Width dans le cas ou l'objet Range ne comporte qu'une seule ligne et ramène donc la largeur de cette ligne, mais exprimée en caractères

Il me semble que "ligne" devrait être remplacé par "colonne".


En suite, ligne 36, tu écris ceci :

Or un pixel correspond exactement à 0,75 points.

Ce qui me gêne ici n'est bien sûr pas la petite faute de frappe, mais le fait de dire qu'un pixel correspond exactement à 0,75 point.
Comme tu le dis ligne 9 : 1 point = 1/72 pouce = 2,54/72 cm
Donc 1 point = 0,03527 cm. OK.
Mais je ne comprends pas pourquoi tu dis qu'un pixel est égal à 0,75 point.

 

[Katido]

Bonjour Marcel32,

Merci de l'intérêt porté à mon fichier.
Merci aussi de tes remarques.

1) Il y a effectivement une erreur de copier/coller, il faut bien remplacer "ligne" par "colonne" dans le paragraphe :
"En lecture, ColumnWidth fonctionne comme Width dans le cas ou l'objet Range ne comporte qu'une seule ligne et ramène donc la largeur de cette ligne, mais exprimée en caractères".

2) Quant au "1 pixel = 0.75 point" :
• Le point est une unité typographique définie aujourd'hui comme 1/12 pica, 1 pica valant 1/6 pouce. C'est donc une mesure de longueur (à la mode anglo-saxonne). Rien à voir avec l'informatique.
• Le pixel (picture element) est au contraire lié à la résolution des écrans.

Dans le cas de mon petit ordi, quelle que soit la résolution écran, j'ai toujours ce fameux rapport 0.75.
Sous Excel on retrouve ce rapport par exemple en cliquant en bas d'un numéro de ligne (quand les en-têtes sont affichés), comme si on voulait modifier la hauteur de la ligne ; un commentaire s'affiche alors comme par exemple "Hauteur: 15,00 (20 pixels)" ou "Hauteur: 18,75 (25 pixels)".

Peut-être qu'avec des machines et écrans de course ce rapport serait différent ??? Mais ceci ne remettrait pas en cause les paragraphes 2. et 3.


Je dois ici rappeler que mon but est de remédier à un fonctionnement parfois déroutant d'Excel, qui ne permet pas de fixer la largeur des colonnes (comme il le fait très bien avec la hauteur des lignes) en utilisant une unité de longueur "parlante".
Ce palliatif est particulièrement utile si on doit afficher à la fois des formes, icônes ou images, et des données dans des cellules, en positionnant tout ce petit monde proprement et en utilisant une même unité (par exemple les propriétés .Left, .Top, .Width et .Height appliquées aux formes sont exprimées en points).


En te souhaitant bon courage pour attaquer les paragraphes 2. et 3.

 

[TooFatBoy]

2) Quant au "1 pixel = 0.75 point" :
• Le point est une unité typographique définie aujourd'hui comme 1/12 pica, 1 pica valant 1/6 pouce. C'est donc une mesure de longueur (à la mode anglo-saxonne). Rien à voir avec l'informatique.
• Le pixel (picture element) est au contraire lié à la résolution des écrans.

Nous sommes bien d'accord là-dessus.

Dans le cas de mon petit ordi, quelle que soit la résolution écran, j'ai toujours ce fameux rapport 0.75.
Sous Excel on retrouve ce rapport par exemple en cliquant en bas d'un numéro de ligne (quand les en-têtes sont affichés), comme si on voulait modifier la hauteur de la ligne ; un commentaire s'affiche alors comme par exemple "Hauteur: 15,00 (20 pixels)" ou "Hauteur: 18,75 (25 pixels)".

Tu viens de me faire découvrir quelque chose que je ne connaissais pas !

En revanche, même si j'ai effectivement la même chose affichée que chez toi, c'est-à-dire "Hauteur: 15,00 (20 pixels)", je ne crois pas que ça veuille dire qu'un pixel fait 0,75 point.
(la résolution de mon écran n'est probablement pas la même que celle de ton écran, et pourtant j'ai le même message...)
La taille d'un point étant fixe, ça voudrait dire que tous les pixels ont la même taille, quelle que soit la résolution, ce qui est totalement absurde car illogique.
Cela doit avoir une autre signification.

Je dois ici rappeler que mon but est de remédier à un fonctionnement parfois déroutant d'Excel, qui ne permet pas de fixer la largeur des colonnes (comme il le fait très bien avec la hauteur des lignes) en utilisant une unité de longueur "parlante".
Ce palliatif est particulièrement utile si on doit afficher à la fois des formes, icônes ou images, et des données dans des cellules, en positionnant tout ce petit monde proprement et en utilisant une même unité (par exemple les propriétés .Left, .Top, .Width et .Height appliquées aux formes sont exprimées en points).

Oui, et c'est bien pour cela que ça m'intéresse.

En te souhaitant bon courage pour attaquer les paragraphes 2. et 3.

Oui, ça a l'air d'être un peu costaud pour moi, mais je vais tout de même essayer. Merci.

 

[Katido]

Rebonjour,

En revanche, même si j'ai effectivement la même chose affichée que chez toi, c'est-à-dire "Hauteur: 15,00 (20 pixels)", je ne crois pas que ça veuille dire qu'un pixel fait 0,75 point.
(la résolution de mon écran n'est probablement pas la même que celle de ton écran, et pourtant j'ai le même message...)
La taille d'un point étant fixe, ça voudrait dire que tous les pixels ont la même taille, quelle que soit la résolution, ce qui est totalement absurde car illogique.
Cela doit avoir une autre signification.

Sans trop vouloir m'avancer, je pense qu'un "pixel Excel" correspond simplement à la résolution qu'Excel offre pour les cellules, shapes et autres objets graphiques.
Par exemple, quand on déplace une forme (un rectangle par exemple) à la main (avec les flèches →↑↓← une fois la forme sélectionnée), cette forme se déplace par pas de 0,75 point.
De même depuis VBA, si après avoir sélectionné la forme on exécute selection.left = selection.left + 0.25 dans la fenêtre d'exécution, la forme ne se déplace réellement qu'une fois sur 3 et alors de 0,75 point ! (la position imposée par selection.left est mémorisée dans la forme, mais le positionnement réel à l'écran n'est possible que par pas de 0,75 point)

Il faudrait vérifier avec un écran de course, mais je pense que le résultat serait le même (positionnement/taille des objets graphiques et taille des cellules par pas de 0,75 point soit 0,2646 mm et pas mieux). En revanche, un écran de course devrait permettre d'afficher un espace plus grand.

Pour info, la résolution de mon écran est 1366 x 768, sa taille est de 34,5 x 19,5 cm et application.Width et application.Height ramènent 1036,5 x 558 points (tiens tiens, 1036,5 / 1366 = 0,7588 et 558 / 768 = 0,7266, on n'est pas loin du 0,75 !)

Ceci dit, 0,75 point soit 0,2646 mm, c'est quand même très correct dans la plupart des applis de bureautique.

En te souhaitant bon courage pour attaquer les paragraphes 2. et 3.

Oui, ça a l'air d'être un peu costaud pour moi, mais je vais tout de même essayer. Merci.

Le paragraphe 2. n'est pas très difficile, c'est simplement un fonction qui convertit des points vers cette unité ésotérique qu'est la "largeur du caractère 0 dans la police normale".
Sans savoir quelle est la police normale ni quelle est la largeur réelle du "0" dans cette police, on impose une largeur de 20 caractères "0" à une colonne, puis une largeur de 40 caractères "0" à cette même colonne,
en relevant à chaque fois la largeur réelle (en points) obtenue. Un petit calcul permet d'obtenir la valeur des constantes recherchées. Puis on rétablit la largeur initiale de la colonne qui a servi de test. Enfin on renvoie le résultat du calcul appliqué à la valeur passée en paramètre.
Ceci est basé sur le postulat suivant, établi d'après mes constatations personnelles mais vérifié avec différentes polices normales et différentes largeurs (très grandes et très petites) :
La largeur réelle w (exprimée en points) d'une colonne imposée par myColumn.ColumnWidth = c est égale à :
w = K1 × c si c ≤ 1
w = K2 × c + K3 si c ≥ 1


Le paragraphe 3. est facultatif.

 

[patricktoulon]

bonsoir
c'est un soucis connu bien courageux et beni celui qui trouvera la formule ramenant la dimension réelle
1 les bordures ne sont pas prises en compte même en xlnone alors quelle sont visibles autrement c'est pire
2 le zoom 100% de excel ne dimensionne pas de la même manière qu'une autre fentre d'une autre application
3 le zoom encore!!! excel resize la grille en centrifugeant le rattrapage (bordure et autres )
plus on va vers le centre plus les dimentions sont tronquées

4 le font size qui joue des vilains tours aussi la cellule s'adapte (celui qui connais la règle je lui mage dans la main )

en pixel
alors là c'est la bérézina
mais on arrive a faire a peu près juste avec les api ou diverses astuces (dont la mienne)
je parlerais pas des dpi intermediare de windows ne gere pas du tout
pour info les seuls dpi que windows gère nativement 100 , 120, 144 et encore le dernier les api windows l'exclu donc walouh!! pour les calculs toutes les autre intermediares ou persos ben vous oubliez

pour les calcule et positionnement
j'ai lu plus haut 0.75 le coeff pixel oui si on veut soit 4/3 mais ca c'est pour le zoom 100% dpi 100% soit 96

bref il est pas né celui qui arrivera a chopper le truc et pour cause c'est une question d'ecran
regardez si on zoom inférieur ce que l'on vois par exemple vous verrez des lignes moins epaisses que d'autres et si je zoom fort 200 ou 250 là on commence avoir vraiment des différentes taille de largeur et hauteur cellule
Regarde la pièce jointe 1129882

je parlerais même pas de l'arrondi VBA sur les décimales (bien connu aussi) 0.25 ou 0.7 ou 0.5 ou 0.4
(va savoir pourquoi)

conclusion celui qui cherche a lire ou écrire les vraies dimensions devrait chercher le DAHU

tiens pour la route
je met des bordures et je prend en lecture le width avant et apres les bordures
une image parle bien plus que des mots

conclusion tu n'aura qu'une approximation qui variera selon la qualité de ta carte graphique et de ton écran
mais en aucun cas jamais tu pourra les mesure réelle
ca fait des années que je travaille la question et je suis pas le seul que ce soit ici ou sur DVP et je peux affirmer à 100% que personne n'a trouver quelque chose de concret
si vous voulez essayer ne vous gênez pas
et ce n'est que le sommet de l'iceberg

Private Sub CommandButton1_Click()
    With [d7,d9]
        [D2] = .Width
        .BorderAround 1, 4, 3
        [D3] = .Width
    End With
End Sub

Private Sub CommandButton2_Click()
[d7,d9].Clear
End Sub

 

[TooFatBoy]

Sans trop vouloir m'avancer, je pense qu'un "pixel Excel" correspond simplement à la résolution qu'Excel offre pour les cellules, shapes et autres objets graphiques.

Je ne comprends pas ce que tu veux dire là, mais ce que je peux dire, c'est que quand Excel dit qu'une cellule fait 20 pixels de haut, elle fait vraiment 20 pixels de haut.
C'est ce que j'avais vérifié après ton message #3, avec le Bureau de Windows en zoom 100 % et la feuille Excel en zoom 100 %.

Ton constat sur le ratio de 0,75 me semble tout à fait exact. Je constate la même chose chez moi.

Donc, pour moi, tout ce qu'on peut dire, c'est que 1 pixel = 0,75 point Excel.
(autrement dit, 4 pixels = 3 points Excel)
Et donc 1 point Excel n'a rien à voir avec un point typographique, puisque le point typographique a une taille fixe alors qu'un point Excel a une taille variable.

Pour info, la résolution définition de mon écran est 1366 x 768, sa taille est de 34,5 x 19,5 cm et application.Width et application.Height ramènent 1036,5 x 558 points (tiens tiens, 1036,5 / 1366 = 0,7588 et 558 / 768 = 0,7266, on n'est pas loin du 0,75 !)

Quand tu dis 34,5 cm de large et 19,5 cm de haut pour ton moniteur, tu parles bien de la dalle (la partie affichage) en elle-même et non du moniteur ?
C'est bizarre, on n'a pas le même ratio L/H pour la taille en cm (1.769230) que pour le nombre de "points" (1.85752688172043010).


Pour l'instant je n'ai pas encore attaqué le paragraphe 2 car je buttais sur l'histoire de point typographique, et de pixels qui auraient la même taille chez tout le monde.

Maintenant j'ai compris que c'est en fait l'inverse :
1 pixel c'est 1 pixel (il a une taille variable selon le moniteur), et ça vaut toujours 0,75 point Excel (donc le "point Excel" n'a pas une taille fixe).

Je vais pouvoir tenter d'aborder le paragraphe 2.

Merci pour tes explications.

 

[Katido]

Bonjour,

J'avais simplement fait une petite remarque sur les valeurs en points ramenées par les propriétés .Width et .Height qui sont multiples de 0.75 sans penser que cela susciterait autant d'intérêt !

Pour ma part, je n'utilise jamais le zoom qui a effectivement un comportement parfois bizarre.
Mon étude n'a du reste rien à voir avec le zoom, sachant que le zoom n'est pas censé modifier la taille réelle des objets, mais seulement leur apparence (une maison apparaît plus grosse vue dans des jumelles, mais elle n'est pas plus spacieuse pour autant). De même une colonne de 30 points de large fait toujours 30 points de large avec un zoom de 400%.

J'en resterai donc avec la correspondance 0,75 point = 1 pixel, sachant qu ledit pixel est sans rapport avec l'écran (sans parler de la taille de ce qui sort des imprimantes)

La suite (les paragraphes 2. et 3.) est applicable indépendamment du zoom et des systèmes d'affichage. Elle ne concerne que la largeur des colonnes, bordures ou pas.

Quand tu dis 34,5 cm de large et 19,5 cm de haut pour ton moniteur, tu parles bien de la dalle (la partie affichage) en elle-même et non du moniteur ?
C'est bizarre, on n'a pas le même ratio L/H pour la taille en cm (1.769230) que pour le nombre de "points" (1.85752688172043010).

Oui, ce n'est que la dalle. Que le ratio L/H soit différent ne me surprend pas, sachant qu'une partie de l'affichage est utilisée par la barre des tâches que j'affiche en bas de l'écran et qui est hors Excel. Si je place la barre des tâches à gauche par exemple, application.height ramène 588 et le rapport 1036,5 / 588 est alors 1,7628 CQFD

 

[patricktoulon]

re
sans vouloir t’offenser @kadido
si tu ne prends pas en compte les autres paramètres a quoi bon utiliser ses fonctions
a quoi ça pourrait bien te servir
exemple tu a une feuille tu veux voir simplement un tableau dans son entier
comment pourrais tu bien faire sans les autres paramètres pour calculer le rowheight
autant ne pas se casser la tète et utiliser le zoom sur sélection qui fera cela automatiquement

 

[patricktoulon]

re
tiens pour @kadido

Sub test()
    Application.ScreenUpdating = False
    Set r = ActiveCell
    Set plage = [A1:I35]
    'chez moi je ne vois que [A1:V29] de la feuille  en zoom 100
    'il me manque donc dans le visuel la plage[A30:I35]
    'donc
    plage.Select
    ActiveWindow.Zoom = True
    coeff = ActiveWindow.Zoom / 100
    ActiveWindow.Zoom = 100
    r.Select
    MsgBox "il ne vous reste plus qu'a redimensionner au multiple ( * " & coeff & _
         ")  le rowheight et columnheight de vos cellules"
End Sub

 

[TooFatBoy]

Mon étude n'a du reste rien à voir avec le zoom, sachant que le zoom n'est pas censé modifier la taille réelle des objets, mais seulement leur apparence (une maison apparaît plus grosse vue dans des jumelles, mais elle n'est pas plus spacieuse pour autant). De même une colonne de 30 points de large fait toujours 30 points de large avec un zoom de 400%.

J'en resterai donc avec la correspondance 0,75 point = 1 pixel, sachant que ledit pixel est sans rapport avec l'écran

C'est également ce que j'ai constaté.

Oui, ce n'est que la dalle. Que le ratio L/H soit différent ne me surprend pas, sachant qu'une partie de l'affichage est utilisée par la barre des tâches que j'affiche en bas de l'écran et qui est hors Excel. Si je place la barre des tâches à gauche par exemple, application.height ramène 588 et le rapport 1036,5 / 588 est alors 1,7628 CQFD

Ah oui, je n'avais pas pensé que la hauteur de la Barre des tâches jouait un rôle là-dedans (d'autant que chez moi elle se rétracte automatiquement ). Bien vu.
Merci pour ton explication.


ps : on a créé un sujet dans le salon XLD, pour discuter de cela sans continuer de polluer ta ressource.

Calculer la taille d'une cellule

Voilà un vaste sujet...

www.excel-downloads.com

 

[Katido]

Pour Patricktoulon,

On n'est pas du tout sur la même longueur d'onde...

si tu ne prends pas en compte les autres paramètres a quoi bon utiliser ses fonctions
a quoi ça pourrait bien te servir
exemple tu a une feuille tu veux voir simplement un tableau dans son entier
comment pourrais tu bien faire sans les autres paramètres pour calculer le rowheight
autant ne pas se casser la tète et utiliser le zoom sur sélection qui fera cela automatiquement

• Quels paramètres ?
• Le but n'est pas de voir des cellules hors de la zone d'affichage, mais uniquement de faciliter l'utilisation de ColumnWidth (et non RowHeight). Voir plus haut.
• Le zoom est hors de propos, puisqu'il ne modifie pas la taille réelle des objets (ce qui est recherché) mais seulement la taille de leur apparence, et que cette apparence est modifiée de la même manière (ou presque) pour tous les objets de la fenêtre (cellules, images, etc.)

 

[patricktoulon]

je reconnais que c'est très proche mais sur mes deux pc les résultats sont différents
sur un ça se joue au 2d chiffre après la virgule sur l'autre tant le 1er tant le 2d
et ça dépend du décimal aussi

Sub test2()
    Dim a&, i#, X#, texte$
    With [A1]
        For i = 10 To 15 Step 0.2
            .ColumnWidth = CDec(i)
            X = PointsToChars(.Width)
            texte = texte & "i =" & i & "  columnwidth =" & CDec(.ColumnWidth) & "  PointsToChars =" & X & "   le width " & CDec(.Width) & vbCrLf
            .ColumnWidth = X
            texte = texte & "    rattrapage à " & X & " donc le colwidth est de " & .ColumnWidth & vbCrLf
        Next
        MsgBox texte
    End With
End Sub

 

[Katido]

C'est bien cette histoire de valeur approchée. Par exemple tu vois bien qu'après ColumnWidth=10.2, la lecture de ColumnWidth donne 10,14. Et après ColumnWidth=10.142857, la lecture de ColumnWidth donne encore 10,14.
Mais ceci n'est pas gênant puisque la largeur réelle en points est de toute façon approchée à un multiple de 0,75

En réalité, la fonction PointsToChars() est faite pour être utilisée dans l'autre sens, comme dans ce cas :

Sub test3()
Dim w!, texte$
With [A1]
For w = 0 To 20 Step 0.5
.ColumnWidth = PointsToChars(w)
texte = texte & "largeur souhaitée =" & w & " largeur obtenue =" & .Width & vbCrLf
Next
MsgBox texte
End With
End Sub

C'est toujours un multiple de 0,75, mais il ne faut pas être plus royaliste que le roi, la fonction PointsToChars() n'est pas en cause
Avec les lignes, donc sans la fonction PointsToChars(), on a aussi toujours une hauteur multiple de 0,75 :

Sub test4()
Dim w!, texte$
With [A1]
For w = 0 To 20 Step 0.5
.RowHeight = w
texte = texte & "hauteur souhaitée =" & w & " hauteur obtenue =" & .Height & vbCrLf
Next
MsgBox texte
End With
End Sub

 

[patricktoulon]

re
Bonjour Kadido
a tu essayé un autre multiple pour voir à la place de 20/40
ta fonction points to char ne fonctionne qu'en font size 11