Ça marche comme avant : tu commences à taper et ça affiche immédiatement une liste mise à jour en temps réel, et tu appuies sur ↓ pour sélectionner une adresse. Sauf qu'en plus, il ajoute dans la barre d'URL ce qu'il pense être la meilleure solution. Comme ça tu as juste besoin d'appuyer sur « entrée » si tu es d'accord (mais ce qu'il ajoute est sélectionné donc si tu continues de taper ou si tu appuies sur ↓, tu remplaces ce qu'il a complété sans que ça te dérange).
Dans le menu contextuel de la liste des calques et dans le menu « Calques », tu as : « fusionner vers le bas » et « fusionner les calques visibles ». Ça me parait plutôt clair pour fusionner des calques…
Le problème avec les numéros de version de FF, c'est que les extensions ne peuvent plus s'appuyer sur le numéro de version pour dire si elles sont compatibles. Mozilla aurait du choisir une numérotation à deux chiffres: majeur.mineur et n'incrémenter le majeur qu'en cas de perte de la compatibilité ascendante. Tel que c'est fait aujourd'hui, la moitié des extensions cessent d'être « compatibles » à chaque nouvelle version jusqu'à ce que leur développeur sorte une « mise à jour » juste pour changer les infos de compatibilité (l'autre moitié des extensions tombera en panne sans rien dire le jour ou une mise à jour de FF cassera la compatibilité ascendante).
Et oui, je sais qu'il existe des moyens de forcer la compatibilité des extensions, mais ça revient juste à mettre toutes les extensions dans le deuxième cas.
Ça marchait même sous DOS :) mais il fallait activer la bonne option je ne sais plus ou (pour que les options en ligne de commande commencent par un - au lieu d'un /).
Mais de toutes façons, « cd c:/directory » c'est au niveau du shell, ce que font les fonctions est complètement indépendant. Et les fonctions ont toujours accepté le / comme séparateur de répertoires.
Bon, je sais que je répond un peu tard, mais tant pis.
Attention de ne pas confondre moyenne et médiane ! Avec une moyenne, l'écart entre les notes que tu donnes à deux candidats peut avoir un effet important sur les chances d'un troisième. Avec une médiane, seul le classement relatif (je préfère « A » plutôt que « B ») compte et il n'affecte pas les autres candidats.
D'ailleurs, il est peut-être plus simple d'expliquer en demandant aux électeurs de classer les candidats par ordre de préférence (ex-æquo autorisés), ce qui devrait être à peu près équivalent au jugement majoritaire tel que décrit dans la dépêche.
Ouais mais justement, sur de l'embarqué, je pense que le coût de lighttpd est très supérieur (CGI = un nouveau processus pour répondre à chaque requête) à celui d'ouvrir une socket INET.
Attention : fcgi ≠ cgi ! Dans le premier, il est possible de réutiliser un même processus pour plusieurs requêtes.
Mais sinon, c'est clair que je ne suis pas convaincu par le choix de JSON : rien que le coût de codage / décodage des données va bouffer plus que ce qui est économisé en se débarrassant du broker…
Il est possible de sauvegarder une sélection en ajoutant une piste de labels, et ensuite Ctrl-B (ou Tracks / Add Label At Selection) pour sauvegarder la sélection dans un nouveau label.
C'est génial, ça veut dire que si je veux que mon appli soit utilisable sous Weston, il faut que je dessine les décorations moi même, mais ensuite si l'utilisateur fait tourner l'appli sous KDE elle aura les décorations en double (les miennes plus celles de KDE). Trop cool!
Avec le javascript comme c'est fait actuellement, ça s'appelle une « VM Javascript ». La question n'est pas d'avoir ou non une « VM » dans le navigateur mais d'avoir ou non une « VM Dart » en plus de la VM Javascript.
Je suis plus familier avec Mercurial que Git, mais si je comprend bien ce que tu fais, c'est la bonne méthode. Svn gère très mal les merges donc pour aller du DVCS vers Svn, il faut faire un rebase (pour éviter le merge que Svn ne gèrerait pas).
En revanche, pour aller de Svn vers le DVCS, tu ne peux pas utiliser rebase, car rebase détruit l'historique mais comme cet historique est déjà présent dans le Svn tu risquerais d'avoir des ennuis la prochaine fois que tu synchroniserais. Note que l'impossibilité d'utiliser rebase vaut à partir du moment où les révisions sources proviennent d'un autre dépôt, que celui-ci soit un dépôt Svn ou non.
Bin justement, le principe c'est d'empêcher de modifier l'historique des commits publics. Aujourd'hui avec Git il y a un risque de les modifier accidentellement, d'autant plus que l'usage de rebase est beaucoup plus courant avec Git que Mercurial. Les phases permettent d'empêcher de modifier l'historique public involontairement en gardant une trace de quels commits sont publics (donc figés) et lesquels sont locaux (donc modifiables).
Je comprend pas pourquoi tu ajoutes le fichier au dépot si c'est de toutes façons pour ne jamais le comitter.
Pour avoir un fichier de configuration par défaut qui fonctionne pour le projet. Ça peut être un makefile générique ou un entête C. Ce fichier peut-être versionné. J'ai aussi plusieurs petit script où des mots de passe sont dans les sources.
Ce que je fais dans ce cas là, c'est d'avoir le fichier « foo.conf » versionné qui contient les valeurs par défaut et un fichier « foo-local.conf » ignoré qui contient les valeurs de remplacement locales. Ensuite les outils (scripts de compilation, applications, etc.) lisent les deux fichiers en donnant la priorité aux valeurs provenant de « foo-local.conf ».
Pour les scripts, ils peuvent vérifier la présence du fichier local et le sourcer le cas échéant.
Je comprend pas pourquoi tu ajoutes le fichier au dépot si c'est de toutes façons pour ne jamais le comitter. Pour gérer les fichiers de conf privés, je vois deux façons de faire utilisables :
Tu n'ajoutes pas le fichier au dépot (mais éventuellement tu le cites dans le .hgignore pour qu'il ne soit pas ajouté par erreur et pour qu'il n'apparaisse pas dans la commande status). Inconvénient : le fichier n'est pas versionné ;
Tu crées un patch mq pour contenir le fichier. Grâce aux phases, tu ne risques pas d'envoyer le fichier par erreur lors d'un push / pull / clone. Inconvénient : il faut se souvenir d'utiliser qpush et qpop (ou rebase) quand on se promène dans l'historique (y compris lors d'un pull), sinon le fichier disparait du répertoire de travail.
PS : en ce qui concerne l'option -X, tu peux toujours l'ajouter au hgrc du dépôt pour ne pas avoir besoin de penser à la spécifier à chaque commande...
Aucun de ces frameworks ne propose une taille de police correcte par défaut... Kickstart est le seul à proposer une taille relative, les autres donnent des tailles absolues en pixels -> selon la finesse de l'écran ces sites vont de « illisibles sans loupe » à « ridiculement gros ». Mais Kickstart utilise une taille trop petite.
Je rappelle que la seule taille acceptable pour le corps du texte est « medium » parce que c'est la taille qui correspond au réglage de l'utilisateur dans les préférences de son navigateur. Tout autre réglage est assuré d'être mauvais pour certains.
A ce propos, mauvais point pour LinuxFr qui serait illisible sans Stylish puisqu'il utilise « small » pour tous le texte des dépêches et des commentaires...
Kézako la colorimétrie en général? Imagine que tu vois un beau paysage. Tu sort ton appareil photo et tu appuies sur le bouton. Rentré chez toi, tu affiche la photo sur ton ordinateur et tu l'imprimes. Tu aimerais bien avoir la même image sur l'écran de l'appareil photo, sur l'écran de l'ordinateur malheureusement, les couleurs sont toutes pourries, pourquoi? Parce que ni ton écran ni ton imprimantes ne sont calibrés.
Un écran d'ordinateur peut émettre 3 couleurs "pures" (ou "primaires"): le vert, le rouge et le bleu. Il simule les autres couleurs en dosant plus ou moins les quantités de chaque couleur primaire. Cependant, d'un écran à l'autre, les couleurs primaires ne sont pas exactement les mêmes (1). De plus, la "réponse" n'est pas forcément la même non plus (c-a-d que si l'ordinateur demande 50% de rouge, il n'aura pas forcément moitié moins de lumière rouge que s'il avait demandé 100%). Les mêmes problèmes se posent à l'impression, sauf que là les couleurs primaires sont le cyan, le jaune et le magenta et que le résultat dépend aussi de l'éclairage et du papier... Tu imagines bien qu'en passant de l'écran à l'imprimante, comme on change de couleurs primaires, on a encore plus de problèmes qu'en passant d'un écran à un autre...
L'étalonnage consiste à demander à l'écran (ou à l'imprimante) d'afficher diverses couleurs bien définies, puis à mesurer le résultat avec un appareil spécial appelé un "colorimètre". Ensuite un logiciel spécialisé peut calculer des tables de conversion (appelées "profil colorimétrique" ou "profil ICC") qui permettent de compenser les écarts entre différents écrans ou imprimantes.
En as-tu besoin? Si tu poses la question, tu n'as probablement pas besoin d'acheter une sonde pour çà. Si tu veux te lancer dans la photo, et en particulier retraiter des photos sur ton ordinateur avant de les imprimer (ou de les faire imprimer par un magasin spécialisé), alors avoir un écran calibré peut éviter certains désappointements. Dans tous les cas, il peut être intéressant de calibrer la réponse de ton écran à l'œil grâce à un logiciel comme monica (2) sous Linux ou QuickGamma (3) sous Windows (désolé, je ne connais pas pour Mac, mais il existe forcément un équivalent, les Macs ont la réputation d'être plus avancés que les PCs sur la gestion des couleurs).
(1) Les couleurs primaires varient en fonction de la technologie (LCD, Plasma, CRT), des matériaux utilisés, du contrôle qualité, du rétroéclairage, de l'age du moniteur, de la température, etc.
La mire papier n'est pas très chère, le pb c'est que la photo dépend aussi de l'éclairage. Et trouver une source de lumière calibrée, çà c'est cher! C'est d'ailleurs la principale cause de la différence de prix entre les sondes pour écran (qui ont juste besoin de mesurer la lumière émise par l'écran) et les sondes pour imprimantes (qui ont besoin d'émettre de la lumière calibrée avant de mesurer sa réflexion).
[^] # Re: Sintel : préhistoire ???
Posté par jeberger (site web personnel) . En réponse à la dépêche Larmes d’acier : Tears of Steel. Évalué à 2.
« Médiéval fantastique » in french in ze texte…
[^] # Re: Explications ?
Posté par jeberger (site web personnel) . En réponse à la dépêche Firefox et Thunderbird, livrée 14. Évalué à 3.
Ça marche comme avant : tu commences à taper et ça affiche immédiatement une liste mise à jour en temps réel, et tu appuies sur ↓ pour sélectionner une adresse. Sauf qu'en plus, il ajoute dans la barre d'URL ce qu'il pense être la meilleure solution. Comme ça tu as juste besoin d'appuyer sur « entrée » si tu es d'accord (mais ce qu'il ajoute est sélectionné donc si tu continues de taper ou si tu appuies sur ↓, tu remplaces ce qu'il a complété sans que ça te dérange).
[^] # Re: Format
Posté par jeberger (site web personnel) . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à -1.
Et il faut flash pour les lire en ligne…
Et il faut désactiver flashblock globalement parce qu'on ne peut pas activer juste le lecteur sur la page…
[^] # Re: à titre personnel
Posté par jeberger (site web personnel) . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 1.
Et « tab » deux fois ?
[^] # Re: Encore un relou qui ne sera jamais content
Posté par jeberger (site web personnel) . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 10.
Bin heuh, comment dire…
Dans le menu contextuel de la liste des calques et dans le menu « Calques », tu as : « fusionner vers le bas » et « fusionner les calques visibles ». Ça me parait plutôt clair pour fusionner des calques…
[^] # Re: Nous y voilà…
Posté par jeberger (site web personnel) . En réponse à la dépêche Firefox 12 et Thunderbird 12 sont sortis ; Mobile est mis à jour. Évalué à 10.
Le problème avec les numéros de version de FF, c'est que les extensions ne peuvent plus s'appuyer sur le numéro de version pour dire si elles sont compatibles. Mozilla aurait du choisir une numérotation à deux chiffres: majeur.mineur et n'incrémenter le majeur qu'en cas de perte de la compatibilité ascendante. Tel que c'est fait aujourd'hui, la moitié des extensions cessent d'être « compatibles » à chaque nouvelle version jusqu'à ce que leur développeur sorte une « mise à jour » juste pour changer les infos de compatibilité (l'autre moitié des extensions tombera en panne sans rien dire le jour ou une mise à jour de FF cassera la compatibilité ascendante).
Et oui, je sais qu'il existe des moyens de forcer la compatibilité des extensions, mais ça revient juste à mettre toutes les extensions dans le deuxième cas.
[^] # Re: Calligra pour Windows
Posté par jeberger (site web personnel) . En réponse à la dépêche Calligra 2.4 est sortie. Évalué à 3.
Ça marchait même sous DOS :) mais il fallait activer la bonne option je ne sais plus ou (pour que les options en ligne de commande commencent par un - au lieu d'un /).
Mais de toutes façons, « cd c:/directory » c'est au niveau du shell, ce que font les fonctions est complètement indépendant. Et les fonctions ont toujours accepté le / comme séparateur de répertoires.
[^] # Re: Échelle pertinente ?
Posté par jeberger (site web personnel) . En réponse au journal Voter autrement. Évalué à 1.
Bon, je sais que je répond un peu tard, mais tant pis.
Attention de ne pas confondre moyenne et médiane ! Avec une moyenne, l'écart entre les notes que tu donnes à deux candidats peut avoir un effet important sur les chances d'un troisième. Avec une médiane, seul le classement relatif (je préfère « A » plutôt que « B ») compte et il n'affecte pas les autres candidats.
D'ailleurs, il est peut-être plus simple d'expliquer en demandant aux électeurs de classer les candidats par ordre de préférence (ex-æquo autorisés), ce qui devrait être à peu près équivalent au jugement majoritaire tel que décrit dans la dépêche.
[^] # Re: Comment ça marche ?
Posté par jeberger (site web personnel) . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 0.
Sérialisation binaire genre messagepack ou, justement, dbus.
[^] # Re: Comment ça marche ?
Posté par jeberger (site web personnel) . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 2.
Attention : fcgi ≠ cgi ! Dans le premier, il est possible de réutiliser un même processus pour plusieurs requêtes.
Mais sinon, c'est clair que je ne suis pas convaincu par le choix de JSON : rien que le coût de codage / décodage des données va bouffer plus que ce qui est économisé en se débarrassant du broker…
[^] # Re: un must-have
Posté par jeberger (site web personnel) . En réponse à la dépêche Audacity 2.0 est disponible !. Évalué à 4.
Il est possible de sauvegarder une sélection en ajoutant une piste de labels, et ensuite
Ctrl-B(ouTracks / Add Label At Selection) pour sauvegarder la sélection dans un nouveau label.[^] # Re: RSA dans le noyau
Posté par jeberger (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.3. Évalué à 1.
En quoi ces raisons ne s'appliquent-elles pas pour RSA ?
[^] # Re: juste une typo récurrente…
Posté par jeberger (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.3. Évalué à 3.
« compose » « . » « . » → « … »
Ce message a été écrit avec un clavier Azerty standard, avec l'option «
Option "XkbOptions" "compose:menu"» dans la config du serveur X…PS : Note que cette possibilité n'a rien de nouveau : je l'utilise depuis près de 15 ans !
[^] # Re: Fenêtre
Posté par jeberger (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à -6.
C'est génial, ça veut dire que si je veux que mon appli soit utilisable sous Weston, il faut que je dessine les décorations moi même, mais ensuite si l'utilisateur fait tourner l'appli sous KDE elle aura les décorations en double (les miennes plus celles de KDE). Trop cool!
[^] # Re: Le mode « 3 copies »
Posté par jeberger (site web personnel) . En réponse à la dépêche btrfs avance à grands pas. Évalué à 2.
Tu peux déjà mettre autant de disques que tu veux sur un RAID1 normal...
[^] # Re: Pas de VM
Posté par jeberger (site web personnel) . En réponse à la dépêche Petites brèves sur Dartium et l'utilisation de Redis sur Youporn. Évalué à 8.
Avec le javascript comme c'est fait actuellement, ça s'appelle une « VM Javascript ». La question n'est pas d'avoir ou non une « VM » dans le navigateur mais d'avoir ou non une « VM Dart » en plus de la VM Javascript.
[^] # Re: rebase ou merge
Posté par jeberger (site web personnel) . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 2.
Je suis plus familier avec Mercurial que Git, mais si je comprend bien ce que tu fais, c'est la bonne méthode. Svn gère très mal les
merges donc pour aller du DVCS vers Svn, il faut faire unrebase(pour éviter lemergeque Svn ne gèrerait pas).En revanche, pour aller de Svn vers le DVCS, tu ne peux pas utiliser
rebase, carrebasedétruit l'historique mais comme cet historique est déjà présent dans le Svn tu risquerais d'avoir des ennuis la prochaine fois que tu synchroniserais. Note que l'impossibilité d'utiliserrebasevaut à partir du moment où les révisions sources proviennent d'un autre dépôt, que celui-ci soit un dépôt Svn ou non.[^] # Re: M'étonnerait que ça arrive dans git.
Posté par jeberger (site web personnel) . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 4.
Bin justement, le principe c'est d'empêcher de modifier l'historique des commits publics. Aujourd'hui avec Git il y a un risque de les modifier accidentellement, d'autant plus que l'usage de
rebaseest beaucoup plus courant avec Git que Mercurial. Les phases permettent d'empêcher de modifier l'historique public involontairement en gardant une trace de quels commits sont publics (donc figés) et lesquels sont locaux (donc modifiables).[^] # Re: Versionnage de fichier de conf privé possible ?
Posté par jeberger (site web personnel) . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 3.
Ce que je fais dans ce cas là, c'est d'avoir le fichier «
foo.conf» versionné qui contient les valeurs par défaut et un fichier «foo-local.conf» ignoré qui contient les valeurs de remplacement locales. Ensuite les outils (scripts de compilation, applications, etc.) lisent les deux fichiers en donnant la priorité aux valeurs provenant de «foo-local.conf».Pour les scripts, ils peuvent vérifier la présence du fichier local et le sourcer le cas échéant.
[^] # Re: Versionnage de fichier de conf privé possible ?
Posté par jeberger (site web personnel) . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 1. Dernière modification le 18 février 2012 à 15:11.
Je comprend pas pourquoi tu ajoutes le fichier au dépot si c'est de toutes façons pour ne jamais le comitter. Pour gérer les fichiers de conf privés, je vois deux façons de faire utilisables :
.hgignorepour qu'il ne soit pas ajouté par erreur et pour qu'il n'apparaisse pas dans la commandestatus). Inconvénient : le fichier n'est pas versionné ;mqpour contenir le fichier. Grâce aux phases, tu ne risques pas d'envoyer le fichier par erreur lors d'unpush/pull/clone. Inconvénient : il faut se souvenir d'utiliserqpushetqpop(ourebase) quand on se promène dans l'historique (y compris lors d'unpull), sinon le fichier disparait du répertoire de travail.PS : en ce qui concerne l'option
-X, tu peux toujours l'ajouter auhgrcdu dépôt pour ne pas avoir besoin de penser à la spécifier à chaque commande...[^] # Re: pour quelques liens en plus …
Posté par jeberger (site web personnel) . En réponse à la dépêche Bootstrap 2.0, par Twitter. Évalué à 1.
Aucun de ces frameworks ne propose une taille de police correcte par défaut... Kickstart est le seul à proposer une taille relative, les autres donnent des tailles absolues en pixels -> selon la finesse de l'écran ces sites vont de « illisibles sans loupe » à « ridiculement gros ». Mais Kickstart utilise une taille trop petite.
Je rappelle que la seule taille acceptable pour le corps du texte est « medium » parce que c'est la taille qui correspond au réglage de l'utilisateur dans les préférences de son navigateur. Tout autre réglage est assuré d'être mauvais pour certains.
A ce propos, mauvais point pour LinuxFr qui serait illisible sans Stylish puisqu'il utilise « small » pour tous le texte des dépêches et des commentaires...
[^] # Re: back to pcsound
Posté par jeberger (site web personnel) . En réponse à la dépêche Petites brèves du Logiciel Libre. Évalué à 3.
Le nom de l'algorithme est écrit en haut à gauche...
[^] # Re: Domotique et énergie...
Posté par jeberger (site web personnel) . En réponse au journal Linux fait même le café, en open-source et open-harware. Évalué à 2.
C'est déjà le cas au niveau européen [1]: consommation limitée à 1W ou 2W en veille selon les appareils, sera abaissée à 0,5W ou 1W en 2013.
[1] http://ec.europa.eu/luxembourg/news/frontpage_news/307_fr.htm
[^] # Re: news de débutant....
Posté par jeberger (site web personnel) . En réponse à la dépêche La colorimétrie sous Linux, un pas de plus. Évalué à 10.
Kézako la colorimétrie en général? Imagine que tu vois un beau paysage. Tu sort ton appareil photo et tu appuies sur le bouton. Rentré chez toi, tu affiche la photo sur ton ordinateur et tu l'imprimes. Tu aimerais bien avoir la même image sur l'écran de l'appareil photo, sur l'écran de l'ordinateur malheureusement, les couleurs sont toutes pourries, pourquoi? Parce que ni ton écran ni ton imprimantes ne sont calibrés.
Un écran d'ordinateur peut émettre 3 couleurs "pures" (ou "primaires"): le vert, le rouge et le bleu. Il simule les autres couleurs en dosant plus ou moins les quantités de chaque couleur primaire. Cependant, d'un écran à l'autre, les couleurs primaires ne sont pas exactement les mêmes (1). De plus, la "réponse" n'est pas forcément la même non plus (c-a-d que si l'ordinateur demande 50% de rouge, il n'aura pas forcément moitié moins de lumière rouge que s'il avait demandé 100%). Les mêmes problèmes se posent à l'impression, sauf que là les couleurs primaires sont le cyan, le jaune et le magenta et que le résultat dépend aussi de l'éclairage et du papier... Tu imagines bien qu'en passant de l'écran à l'imprimante, comme on change de couleurs primaires, on a encore plus de problèmes qu'en passant d'un écran à un autre...
L'étalonnage consiste à demander à l'écran (ou à l'imprimante) d'afficher diverses couleurs bien définies, puis à mesurer le résultat avec un appareil spécial appelé un "colorimètre". Ensuite un logiciel spécialisé peut calculer des tables de conversion (appelées "profil colorimétrique" ou "profil ICC") qui permettent de compenser les écarts entre différents écrans ou imprimantes.
En as-tu besoin? Si tu poses la question, tu n'as probablement pas besoin d'acheter une sonde pour çà. Si tu veux te lancer dans la photo, et en particulier retraiter des photos sur ton ordinateur avant de les imprimer (ou de les faire imprimer par un magasin spécialisé), alors avoir un écran calibré peut éviter certains désappointements. Dans tous les cas, il peut être intéressant de calibrer la réponse de ton écran à l'œil grâce à un logiciel comme monica (2) sous Linux ou QuickGamma (3) sous Windows (désolé, je ne connais pas pour Mac, mais il existe forcément un équivalent, les Macs ont la réputation d'être plus avancés que les PCs sur la gestion des couleurs).
(1) Les couleurs primaires varient en fonction de la technologie (LCD, Plasma, CRT), des matériaux utilisés, du contrôle qualité, du rétroéclairage, de l'age du moniteur, de la température, etc.
(2) http://www.pcbypaul.com/software/monica.html (semble HS pour le moment)
(3) http://quickgamma.de/indexfr.html
[^] # Re: interessant
Posté par jeberger (site web personnel) . En réponse à la dépêche La colorimétrie sous Linux, un pas de plus. Évalué à 7.
La mire papier n'est pas très chère, le pb c'est que la photo dépend aussi de l'éclairage. Et trouver une source de lumière calibrée, çà c'est cher! C'est d'ailleurs la principale cause de la différence de prix entre les sondes pour écran (qui ont juste besoin de mesurer la lumière émise par l'écran) et les sondes pour imprimantes (qui ont besoin d'émettre de la lumière calibrée avant de mesurer sa réflexion).