Google Groupes n'accepte plus les nouveaux posts ni abonnements Usenet. Les contenus de l'historique resteront visibles.

[Un peu HS] Histoire de «Pixels per inch» et «Dots per inch» pas très claire

21 vues
Accéder directement au premier message non lu

Francois Lafont

non lue,
19 août 2011, 10:03:3819/08/2011
à
Bonjour � tous,

J'aimerais bien comprendre certaines choses par rapport � ces histoires
de PPI (Pixels per inch) et de DPI (Dots per inch). C'est un peu HS,
mais � la fin, j'ai quand m�me un lien avec LaTeX et le package graphicx.

Je suis sous Debian Squeeze et en voulant des informations sur la
r�solution de mon �cran, j'obtiens �a :

#--------------------------------------
$ xdpyinfo | grep -C 1 resolution

dimensions: 1920x1080 pixels (508x285 millimeters)
resolution: 96x96 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
#--------------------------------------

1) �a ne serait pas �96�96 *pixels* per inch� (et non �*dots* per inch�)
? Quelles sont les diff�rences entre pixels et dots exactement ?

2) Avec les �l�ments donn�s par la commande, si j�applique mes petites
r�gles de proportionnalit�s (sachant que 1 inch = 2,54 cm), je tombe sur
un �cran de 50,8�28,575 cm ce qui correspond � peu pr�s � ce que donne
la commande ci-dessus en millim�tres.

Mais le probl�me, c�est que si je mesure mon �cran avec mon bon vieux
m�tre de couturier, je tombe sur environ 48�27 cm (je mesure la zone
d�affichage de l'�cran uniquement sans l�armature en plastique qui
l'entoure bien s�r). C'est quand m�me assez diff�rent de ce que donne la
commande ci-dessus. Comment ce se fait-il ?

3) J'ai une image jpeg (que je m'appr�te � ins�rer dans un document
LaTeX, voir plus loin) et si je souhaite obtenir des informations dessus
avec la commande display (qui fait partie du package debian
imagemagick), j'obtiens �a :

#--------------------------------------
$ display -verbose -identify image.jpg

#Je coupe la sortie pour mettre l'essentiel

Format: JPEG (Joint Photographic Experts Group JFIF format)
Class: DirectClass
Geometry: 478x360+0+0
Resolution: 300x300
Print size: 1.59333x1.2
Units: PixelsPerInch
#--------------------------------------

Je ne comprends pas trop la signification du �300x300 PPI� (pixels par
unit� de surface, sa densit� de pixels en somme). Pour moi, la densit�
de pixels n'a pas de sens au niveau d'un fichier image (je n'y connais
rien dans le domaine), elle a un sens au niveau de son *affichage* sur
un �cran d'ordinateur et donc d�pendra de la r�solution de mon �cran,
non ? C'est pas tr�s clair pour moi.

4) D'apr�s la commande ci-dessus, l'image fait 1,59333x1,2 Inch ce qui
donne environ 4x3 en centim�tre. Si j'inclus l'image dans un document
LaTeX (compil� via pdflatex) comme ceci :

\includegraphics[scale=1]{image}

l'image fait nettement plus que 4x3 cm de superficie sur ma feuille A4.
Est-ce normal ?

Au d�part, sachant que mon �cran a une r�solution de 96x96 PPI, je me
suis dit que LaTeX affiche mon image avec une densit� de pixels par Inch
de 96x96, mais que comme mon image fait 478x360 pixels, �a donne (petite
proportionnalit�) une dimension d'environ 12.65x9.52 cm. Mais en fait,
m�me pas. En compilant le source ci-dessous, je me suis rendu compte que
mon image �tait assez nettement plus grande que �a ?

%--------------------------------------
\documentclass[french,a4paper,12pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage[scale=0.9]{geometry}
\usepackage{graphicx}
\usepackage{babel}

\setlength{\parindent}{0cm}

\begin{document}

\includegraphics[scale=1]{image}

\bigskip

\rule{12.65cm}{9.52cm} % ne fait pas la m�me taille

\end{document}
%--------------------------------------


Merci d'avance pour vos lumi�res.

--
Fran�ois Lafont

Alain Ketterlin

non lue,
19 août 2011, 11:13:2719/08/2011
à
Francois Lafont <francoi...@nospam.invalid> writes:

> #--------------------------------------
> $ xdpyinfo | grep -C 1 resolution
>
> dimensions: 1920x1080 pixels (508x285 millimeters)
> resolution: 96x96 dots per inch
> depths (7): 24, 1, 4, 8, 15, 16, 32
> #--------------------------------------
>

> 1) Ça ne serait pas «96×96 *pixels* per inch» (et non «*dots* per inch»)
> ? Quelles sont les différences entre pixels et dots exactement ?

Aucune à mon avis. A mon avis on utilise plutôt pixel pour parler d'un
point affiché, avec une position, une couleur, etc.

> 2) Avec les éléments donnés par la commande [...] un écran de
> 50,8×28,575 cm [...] le problème [...] mon écran [...] environ 48×27cm

Ce n'est pas une très grande différence (ça fait 101x101dpi). C'est lié
au procédé de fabrication de la dalle. C'est aussi lié au fait que X
fait ce qu'il peut. Voir :

https://wiki.archlinux.org/index.php/Xorg#Display_Size_and_DPI

> 3) J'ai une image jpeg [...]

> Format: JPEG (Joint Photographic Experts Group JFIF format)
> Class: DirectClass
> Geometry: 478x360+0+0
> Resolution: 300x300
> Print size: 1.59333x1.2
> Units: PixelsPerInch
> #--------------------------------------
>

> Je ne comprends pas trop la signification du «300x300 PPI» (pixels par
> unité de surface, sa densité de pixels en somme). Pour moi, la densité


> de pixels n'a pas de sens au niveau d'un fichier image

C'est indicatif uniquement. Tu peux afficher ta jpeg sur un écran avec
des pixels de 1m de coté, il n'y a pas de problème. Pour une ilage
bitmap, la notion de résolution n'a pas de sens, comme tu l'as
pressenti.

En général, les DPI c'est pour les dispositifs d'affichage (écran et
imprimantes). Les PPI c'est pour les dispositifs d'acquisition. L'info
que tu as sur ton image est donnée par le machin qui l'a produite, et
j'imagine que la taille est calculée d'après la taille en pixels et le
PPI. A toi de te débrouiller pour afficher cette image avec un DPI
proche du PPI (tu vois l'idée ?)

> \includegraphics[scale=1]{image}
>
> l'image fait nettement plus que 4x3 cm de superficie sur ma feuille A4.
> Est-ce normal ?

Là je donne ma langue au chat. C'est pdftex qui décide. Ce que je
sais, c'est que dans le cas des fichier ps/pdf, la taille (en points)
est dans le fichier, et qu'il ne devrait donc pas y avoir de différence.

> Au départ, sachant que mon écran a une résolution de 96x96 PPI, je me
> suis dit que LaTeX affiche mon image avec une densité de pixels par Inch
> de 96x96,

LaTeX n'a pas la moindre idée de la résolution de ton écran. D'ailleurs,
il arrive à LaTeX de s'exécuter sans même qu'il y ait d'écran.

Dans le résultat de LaTeX, en postscript/pdf, ton image aura une
certaine taille fixée, et l'imprimante/écran se débrouillera pour
répartir sur la surface le nombre de pixels dont elle dipose.

-- Alain.

Damien Wyart

non lue,
19 août 2011, 11:59:2519/08/2011
à
* Alain Ketterlin <al...@dpt-info.u-strasbg.fr> in fr.comp.text.tex:

> Aucune à mon avis. A mon avis on utilise plutôt pixel pour parler d'un
> point affiché, avec une position, une couleur, etc.

Oui, pixel est pour un écran et point pour une imprimante (restitution)
ou un scanner (acquisition).

> C'est indicatif uniquement. Tu peux afficher ta jpeg sur un écran avec
> des pixels de 1m de coté, il n'y a pas de problème. Pour une ilage
> bitmap, la notion de résolution n'a pas de sens, comme tu l'as
> pressenti.

Voilà. Des explications complémentaires assez claires et détaillés par
exemple ici :

http://fr.wikipedia.org/wiki/Point_par_pouce
http://www.gdesroches.com/formation/fnumerbase.htm
http://en.wikipedia.org/wiki/Dots_per_inch
http://en.wikipedia.org/wiki/Pixels_per_inch

--
DW

Francois Lafont

non lue,
19 août 2011, 13:10:3319/08/2011
à
Le 19/08/2011 17:13, Alain Ketterlin a écrit :

>> 2) Avec les éléments donnés par la commande [...] un écran de
>> 50,8×28,575 cm [...] le problème [...] mon écran [...] environ 48×27cm
>
> Ce n'est pas une très grande différence (ça fait 101x101dpi).

Je trouve qu'au delà de 1 cm d'écart, ça fait quand même pas mal.

> C'est lié
> au procédé de fabrication de la dalle. C'est aussi lié au fait que X
> fait ce qu'il peut. Voir :
>
> https://wiki.archlinux.org/index.php/Xorg#Display_Size_and_DPI

Ah, j'ai peur de ne pas avoir tout compris dans le lien donné. J'avoue
que j'ai du mal à comprendre comment je peux avoir un affichage correct
sur mon écran alors que mon système évalue mal (avec plus de 1 cm
d'écart) la taille de mon écran.

>> 3) J'ai une image jpeg [...]
>
>> Format: JPEG (Joint Photographic Experts Group JFIF format)
>> Class: DirectClass
>> Geometry: 478x360+0+0
>> Resolution: 300x300
>> Print size: 1.59333x1.2
>> Units: PixelsPerInch
>> #--------------------------------------
>>
>> Je ne comprends pas trop la signification du «300x300 PPI» (pixels par
>> unité de surface, sa densité de pixels en somme). Pour moi, la densité
>> de pixels n'a pas de sens au niveau d'un fichier image
>
> C'est indicatif uniquement. Tu peux afficher ta jpeg sur un écran avec

> des pixels de 1m de coté, il n'y a pas de problème. Pour une image


> bitmap, la notion de résolution n'a pas de sens, comme tu l'as
> pressenti.

Ok, là au moins je n'étais pas trop dans les choux. :-)
Mais alors un PPI de 300x300 est impossible à atteindre sur mon écran vu
qu'il fait 96x96 PPI ?

En fait ce qui me gêne, c'est là notion de pixel. Par exemple dans :
- Image de 478x360 pixels
- Écran de 96x96 pixels per inch
Le mot «pixels» n'a pas la même signification dans les deux phrases, non
? Dans un cas, c'est une sorte de donné numérique atomique (insécable)
et dans l'autre c'est la taille d'un micro rectangle qui dont est
physiquement composé mon écran. Bon là, je marche sur des œufs.

> En général, les DPI c'est pour les dispositifs d'affichage (écran et
> imprimantes). Les PPI c'est pour les dispositifs d'acquisition. L'info
> que tu as sur ton image est donnée par le machin qui l'a produite, et
> j'imagine que la taille est calculée d'après la taille en pixels et le
> PPI.

Oui, c'est de la proportionnalité. On connaît le nombre de pixels et la
densité (qui est donc purement indicative) de pixels par pouce^2, on en
déduit alors la taille de l'image. Mais la taille est donc purement
indicative elle aussi, non ?

> A toi de te débrouiller pour afficher cette image avec un DPI
> proche du PPI (tu vois l'idée ?)

Oui je crois, mais sachant que mon écran fait 96x96 PPI, il me semble
que je ne peux pas aller au delà de cette limite physique, non ?

>> \includegraphics[scale=1]{image}
>>
>> l'image fait nettement plus que 4x3 cm de superficie sur ma feuille A4.
>> Est-ce normal ?
>
> Là je donne ma langue au chat. C'est pdftex qui décide. Ce que je
> sais, c'est que dans le cas des fichier ps/pdf, la taille (en points)
> est dans le fichier, et qu'il ne devrait donc pas y avoir de différence.

Là, je ne comprends pas. Pour moi, dans l'image jpep, seule la taille en
pixels est réelle. La résolution en PPI, et donc la taille aussi, sont
purement indicatives. Donc comment la taille est choisie par LaTeX,
c'est toute la question.

>> Au départ, sachant que mon écran a une résolution de 96x96 PPI, je me
>> suis dit que LaTeX affiche mon image avec une densité de pixels par Inch
>> de 96x96,
>
> LaTeX n'a pas la moindre idée de la résolution de ton écran. D'ailleurs,
> il arrive à LaTeX de s'exécuter sans même qu'il y ait d'écran.

Oui en effet.

> Dans le résultat de LaTeX, en postscript/pdf, ton image aura une
> certaine taille fixée, et l'imprimante/écran se débrouillera pour
> répartir sur la surface le nombre de pixels dont elle dipose.

Merci bien pour la réponse Alain.


--
François Lafont

moi-meme

non lue,
19 août 2011, 14:14:0619/08/2011
à
Le Fri, 19 Aug 2011 17:13:27 +0200, Alain Ketterlin a écrit :

>> Je ne comprends pas trop la signification du «300x300 PPI» (pixels par
>> unité de surface, sa densité de pixels en somme). Pour moi, la densité
>> de pixels n'a pas de sens au niveau d'un fichier image

Une image peut représenter un document scanné (une feuille A4 par exemple)
sans cette info comment la reproduire à l'échelle 1 ?

moi-meme

non lue,
19 août 2011, 14:25:0019/08/2011
à
Le Fri, 19 Aug 2011 19:10:33 +0200, Francois Lafont a écrit :

> Donc comment la taille est choisie par LaTeX, c'est toute la question.

la taille de l'image est fixée par LaTeX (la taille de la boite
correspondante) : xfoislargeur de la ligne, xfoislargeur la page,
proportionnalité hauteur/largeur, etc.

Une règle de trois ensuite pour calculer les points sur l'imprimante ou
l'écran.
Qui le fait ? Je crois que c'est l'imprimante (ou le driver graphique)
car le pdf lui donne toutes les infos dimensionnelles (nb pixels image,
taille image).

Je rebondis : comment cela se passe pour le vectoriel ?
Il y doit avoir la même démarche sans les pixels.

(c'est vendredi + départ en vacances. Dommage pour la suite)

Alain Ketterlin

non lue,
19 août 2011, 14:25:4719/08/2011
à
Francois Lafont <francoi...@nospam.invalid> writes:

>>> 2) Avec les éléments donnés par la commande [...] un écran de
>>> 50,8×28,575 cm [...] le problème [...] mon écran [...] environ 48×27cm
>>
>> Ce n'est pas une très grande différence (ça fait 101x101dpi).
>
> Je trouve qu'au delà de 1 cm d'écart, ça fait quand même pas mal.

N'oublie pas que le cm de différence est réparti sur 2000 pixels.

>> https://wiki.archlinux.org/index.php/Xorg#Display_Size_and_DPI
>
> Ah, j'ai peur de ne pas avoir tout compris dans le lien donné. J'avoue
> que j'ai du mal à comprendre comment je peux avoir un affichage correct
> sur mon écran alors que mon système évalue mal (avec plus de 1 cm
> d'écart) la taille de mon écran.

En fait, l'affichage ne sera pas correct pour tout programme qui
raisonne en cm (ou pouces, ou...). Pour ton JPEG, si un programme
décidait de l'afficher en "taille réelle" (quitte à mélanger plusieurs
pixels de l'image dans un pixel de l'écran), il n'afficherait pas la
bonne taille (en cm).

Il y a beaucoup de programmes qui raisonnent encore en pixels ("le panel
fait 24 pixels de haut"), mais aussi de plus en plus qui raisonne en
cm/points/... (par exemple les systèmes de gestion des fontes).

[...]


> Mais alors un PPI de 300x300 est impossible à atteindre sur mon écran vu
> qu'il fait 96x96 PPI ?

Exactement. Si tu veux le voir avec sa vrai taille (en cm) et aussi
finement que possible, alors il vaut mieux l'imprimer. Si par contre tu
veux voir tous les pixels c'est possible aussi, mais cela utilisera
trois fois plus de surface sur ton écran.

(Moralité : le papier "affiche" beaucoup plus finement que l'écran.)

> En fait ce qui me gêne, c'est là notion de pixel. Par exemple dans :
> - Image de 478x360 pixels
> - Écran de 96x96 pixels per inch
> Le mot «pixels» n'a pas la même signification dans les deux phrases, non
> ? Dans un cas, c'est une sorte de donné numérique atomique (insécable)
> et dans l'autre c'est la taille d'un micro rectangle qui dont est
> physiquement composé mon écran. Bon là, je marche sur des œufs.

C'est juste, d'ailleurs en général on utilise pixel pour le contenu de
l'image bitmap, et dot ou point pour la résolution.

>>> \includegraphics[scale=1]{image}
>>>
>>> l'image fait nettement plus que 4x3 cm de superficie sur ma feuille A4.
>>> Est-ce normal ?
>>
>> Là je donne ma langue au chat. C'est pdftex qui décide. Ce que je
>> sais, c'est que dans le cas des fichier ps/pdf, la taille (en points)
>> est dans le fichier, et qu'il ne devrait donc pas y avoir de différence.
>
> Là, je ne comprends pas. Pour moi, dans l'image jpep, seule la taille en
> pixels est réelle. La résolution en PPI, et donc la taille aussi, sont
> purement indicatives. Donc comment la taille est choisie par LaTeX,
> c'est toute la question.

Ma phrase était mal tournée. Ce que tu dis est juste. Tu peux modifier
la résolution (PPI) dans le fichier JPEG sans rien toucher au pixels de
l'image. Cela n'affectera que les programmes qui lisent le fichier, y
trouvent 478*360 pixels et se demandent quelle taile (en cm) cela doit
prendre.

Ce que je disais : je ne sais pas comment pdftex fait ce calcul, comment
il décide de la taille (en cm) à partir de l'image JPEG. Et je disais
que, PAR CONTRE, les fichiers ps et pdf contiennent des dimensions en cm
(enfin en 1/72 de pouce).

-- Alain.

Francois Lafont

non lue,
19 août 2011, 17:07:2619/08/2011
à
Le 19/08/2011 17:59, Damien Wyart a écrit :

> Voilà. Des explications complémentaires assez claires et détaillés par
> exemple ici :
>
> http://fr.wikipedia.org/wiki/Point_par_pouce
> http://www.gdesroches.com/formation/fnumerbase.htm

Ah, il est vraiment bien ce dernier lien. Merci beaucoup Damien. Je cite :

%-------------------------------------
« [...] je vous propose trois images identiques de 250x392 pixels. La
première a une résolution de 10 dpi; la seconde de 72 dpi et la
troisième de 300 dpi. Voyez-vous une différence à l'écran ?

Notez au passage que le poids des fichiers est rigoureusement le même :
288 ko [...], ce qui corrobore bien le fait que les "dpi" ne jouent
aucun rôle. Sous chaque image sont indiquées les dimensions qu'elle aura
à l'impression - c'est là, et *uniquement* *là*, que la différence sera
sensible car la différence de résolution est de taille. »
%-------------------------------------

Donc dans une image jpeg, si je comprends bien, le dpi est une sorte
d'attribut du fichier, totalement modifiable, qui n'est utiliser que
pour l'impression de l'image : pour une image de x*y pixels (ce qui
détermine la taille du fichier en bytes), la donnée de l'attribut dpi
permettra de déduire la taille de l'image quand elle est imprimée sur
papier mais n'a aucune influence sur la taille du fichier en bytes.

J'imagine qu'avec un logiciel pour visualiser les images, mettre le zoom
à 100% veut dire afficher l'image en faisant en sorte qu'1 pixel du
fichier image = 1 pixel de l'écran.

Merci encore Damien.


--
François Lafont

Francois Lafont

non lue,
19 août 2011, 17:42:2019/08/2011
à
Le 19/08/2011 20:14, moi-meme a écrit :

> Une image peut représenter un document scanné (une feuille A4 par exemple)
> sans cette info comment la reproduire à l'échelle 1 ?

Ok et j'imagine qu'une image jpeg obtenue via un scan d'une feuille A4
aura une définition (x*y pixels) et une résolution (en dpi) qui fera que
la taille de l'image si l'on veut l'imprimer sera celle d'une feuille
A4. Mais si j'ai bien compris, on pourra parfaitement augmenter la
résolution dpi de l'image sans pour autant changer la taille en bytes du
fichier. L'impression sera juste plus petite.

> la taille de l'image est fixée par LaTeX (la taille de la boite
> correspondante) : xfoislargeur de la ligne, xfoislargeur la page,
> proportionnalité hauteur/largeur, etc.
>
> Une règle de trois ensuite pour calculer les points sur l'imprimante ou
> l'écran.

Là, je n'ai pas compris. Comment \includegraphics{image} détermine la
taille de la boîte à insérer, là ce n'est vraiment pas clair pour moi.


--
François Lafont

Francois Lafont

non lue,
19 août 2011, 17:50:2519/08/2011
à
Le 19/08/2011 20:25, Alain Ketterlin a écrit :

> En fait, l'affichage ne sera pas correct pour tout programme qui
> raisonne en cm (ou pouces, ou...). Pour ton JPEG, si un programme
> décidait de l'afficher en "taille réelle" (quitte à mélanger plusieurs
> pixels de l'image dans un pixel de l'écran), il n'afficherait pas la
> bonne taille (en cm).
>
> Il y a beaucoup de programmes qui raisonnent encore en pixels ("le panel
> fait 24 pixels de haut"), mais aussi de plus en plus qui raisonne en
> cm/points/... (par exemple les systèmes de gestion des fontes).

Ok, donc mon système n'évalue pas tout à fait correctement les
dimensions en cm de mon écran.

1) si un programme raisonne en cm, je n'aurai pas quelque chose d'exact.
2) si un programme raisonne en pixels-d'écran, là j'aurai quelque chose
d'exact.

2) est donc mieux que 1) mais le problème c'est que le rendu dépendra de
la résolution de l'écran dans 2) alors que dans 1), même si le rendu
n'est pas exact, il dépendra moins (voire pas du tout) des changements
de résolutions d'écran.

> Ce que je disais : je ne sais pas comment pdftex fait ce calcul, comment
> il décide de la taille (en cm) à partir de l'image JPEG. Et je disais
> que, PAR CONTRE, les fichiers ps et pdf contiennent des dimensions en cm
> (enfin en 1/72 de pouce).

Ok.

Merci bien.


--
François Lafont

Manuel Pégourié-Gonnard

non lue,
20 août 2011, 09:31:5920/08/2011
à
Francois Lafont scripsit :

> Le 19/08/2011 20:25, Alain Ketterlin a écrit :
>
>> En fait, l'affichage ne sera pas correct pour tout programme qui
>> raisonne en cm (ou pouces, ou...). Pour ton JPEG, si un programme
>> décidait de l'afficher en "taille réelle" (quitte à mélanger plusieurs
>> pixels de l'image dans un pixel de l'écran), il n'afficherait pas la
>> bonne taille (en cm).
>>
>> Il y a beaucoup de programmes qui raisonnent encore en pixels ("le panel
>> fait 24 pixels de haut"), mais aussi de plus en plus qui raisonne en
>> cm/points/... (par exemple les systèmes de gestion des fontes).
>
> Ok, donc mon système n'évalue pas tout à fait correctement les
> dimensions en cm de mon écran.
>
> 1) si un programme raisonne en cm, je n'aurai pas quelque chose d'exact.
> 2) si un programme raisonne en pixels-d'écran, là j'aurai quelque chose
> d'exact.
>
> 2) est donc mieux que 1) mais le problème c'est que le rendu dépendra de
> la résolution de l'écran dans 2) alors que dans 1), même si le rendu
> n'est pas exact, il dépendra moins (voire pas du tout) des changements
> de résolutions d'écran.
>

Faut voir quand même qu'on a rarement besoin d'un rendu à l'écran avec
une dimension exacte en centimètres. Imagine par exemple qu'au lieu d'un
écran tu utilises un vidéoprojecteur. La taille exacte (en cm) de
l'image dépend de la distance entre le projo et le mur ; dans quelle
situation est-ce que ça pose le moindre problème ?

L'information sur la taille physique de l'écran est surtout uilisée par
le système pour choisir des tailles de fontes (en pixels) par défaut.
Par exemple, on estime qu'une taille de caratères de 3 mm est suffisante
pour la lisibilité. Si la résolution de l'écran est de 96 ppp, 11 pixels
font 2,9 mm et 12 pixels font 3,2 mm (environ). Donc pour rendre des
caractères d'à peu près 3 mm de haut, on utilisera 11 ou 12 pixels. Que
la résolution soit de 96 ppp ou 101 ppp, ça ne change pas grand chose au
fait que pour afficher environ 3 mm on sera entre 11 et 12 pixels.
Bref, pour cette usage (choix d'une taille de fonte par défaut), une
erreur de 5% sur la résolution réelle de l'écran est loin d'être
gênante.

--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/

0 nouveau message