Concours Photo Le Vendredi 4 Décembre 2009, le café photo exposera les
lauréats de son concours annuel. Pour cette 5ème édition c'est le public qui
a voté parmis 5 propositions du collectif Café PHOTO, et c'est le thème de
"la folie" qui a été retenue. Afin d'avoir une exposition de qualité et
surtout une unitée le thème de folie devra être pris sous l'angle de la
maladie mental c'est à dire un "trouble du comportement et/ou de l'esprit,
considéré comme l'effet d'une maladie altérant les facultés mentales du
sujet".
Réception de 1 à 5 photos au format 30/40 cm en 300 dpi entre le 1 et le 10
Novembre 2009. Chaque fichier devra porter le nom et prénom de l'auteur du
cliché.
FiLH wrote: > Ofnuts wrote: > >> YouDontNeedToKnowButItsNoëlle wrote: >>> est très bien supporté partout. Ce n'est pas l'avenir, c'est le présent. >>> Le seul inconvénient à ma connaissance est qu'un encode 16 bits utilise >>> 2 fois plus d'octets qu'un encodage 8 bits...Même en rtc ça ne fait pas >>> lourd. >> En fait c'est beaucoup moins lourd que ce que tu crois. En UTF-8, les >> caractères ASCII d'origine sont codés sur un octet, l'essentiel des >> caractères latins complémentaires (lettres accentuées pour l'essentiel, >> ainsi que la grosse majorité des alphabets (grec, cyrillique, >> phonétique, indiens divers) sur deux octets, > > Attention, et hélas, il existe deux codages pour les caractères > accentués, un des codages est un accentuage postifxe (on a un e suivi du > code accent). > Les deux codages sont autorisés, et... bien entendu tout le monde > n'utilise pas le même (ce qui peut donner des choses très très amusantes > dans certains cas quand deux mots - des noms de fichiers au hasard - > identiques en termes de glyphes, sont codés par des chaines d'octets > différentes :)
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et "circonflexe diacritique combinable".
Ben si justement : http://fr.wikipedia.org/wiki/Normalisation_Unicode http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Ofnuts <o.f.n.u.t.s@la.poste.net> wrote:
FiLH wrote:
> Ofnuts <o.f.n.u.t.s@la.poste.net> wrote:
>
>> YouDontNeedToKnowButItsNoëlle wrote:
>>> est très bien supporté partout. Ce n'est pas l'avenir, c'est le présent.
>>> Le seul inconvénient à ma connaissance est qu'un encode 16 bits utilise
>>> 2 fois plus d'octets qu'un encodage 8 bits...Même en rtc ça ne fait pas
>>> lourd.
>> En fait c'est beaucoup moins lourd que ce que tu crois. En UTF-8, les
>> caractères ASCII d'origine sont codés sur un octet, l'essentiel des
>> caractères latins complémentaires (lettres accentuées pour l'essentiel,
>> ainsi que la grosse majorité des alphabets (grec, cyrillique,
>> phonétique, indiens divers) sur deux octets,
>
> Attention, et hélas, il existe deux codages pour les caractères
> accentués, un des codages est un accentuage postifxe (on a un e suivi du
> code accent).
> Les deux codages sont autorisés, et... bien entendu tout le monde
> n'utilise pas le même (ce qui peut donner des choses très très amusantes
> dans certains cas quand deux mots - des noms de fichiers au hasard -
> identiques en termes de glyphes, sont codés par des chaines d'octets
> différentes :)
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou
plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre
de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en
créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et
"circonflexe diacritique combinable".
Ben si justement :
http://fr.wikipedia.org/wiki/Normalisation_Unicode
http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
FiLH wrote: > Ofnuts wrote: > >> YouDontNeedToKnowButItsNoëlle wrote: >>> est très bien supporté partout. Ce n'est pas l'avenir, c'est le présent. >>> Le seul inconvénient à ma connaissance est qu'un encode 16 bits utilise >>> 2 fois plus d'octets qu'un encodage 8 bits...Même en rtc ça ne fait pas >>> lourd. >> En fait c'est beaucoup moins lourd que ce que tu crois. En UTF-8, les >> caractères ASCII d'origine sont codés sur un octet, l'essentiel des >> caractères latins complémentaires (lettres accentuées pour l'essentiel, >> ainsi que la grosse majorité des alphabets (grec, cyrillique, >> phonétique, indiens divers) sur deux octets, > > Attention, et hélas, il existe deux codages pour les caractères > accentués, un des codages est un accentuage postifxe (on a un e suivi du > code accent). > Les deux codages sont autorisés, et... bien entendu tout le monde > n'utilise pas le même (ce qui peut donner des choses très très amusantes > dans certains cas quand deux mots - des noms de fichiers au hasard - > identiques en termes de glyphes, sont codés par des chaines d'octets > différentes :)
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et "circonflexe diacritique combinable".
Ben si justement : http://fr.wikipedia.org/wiki/Normalisation_Unicode http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Ofnuts
FiLH wrote:
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et "circonflexe diacritique combinable".
Ben si justement : http://fr.wikipedia.org/wiki/Normalisation_Unicode http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air d'être assez croquignolet comme résultat vu que plein d'autres parties du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-) -- Bertrand
FiLH wrote:
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou
plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre
de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en
créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et
"circonflexe diacritique combinable".
Ben si justement :
http://fr.wikipedia.org/wiki/Normalisation_Unicode
http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme
clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air
d'être assez croquignolet comme résultat vu que plein d'autres parties
du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-)
--
Bertrand
On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et "circonflexe diacritique combinable".
Ben si justement : http://fr.wikipedia.org/wiki/Normalisation_Unicode http://fr.wikipedia.org/wiki/Équivalences_unicode
Les macs sont je crois en nfd (à vérifier)
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air d'être assez croquignolet comme résultat vu que plein d'autres parties du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-) -- Bertrand
filh
Ofnuts wrote:
FiLH wrote:
>> On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou >> plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre >> de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en >> créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et >> "circonflexe diacritique combinable". > > Ben si justement : > http://fr.wikipedia.org/wiki/Normalisation_Unicode > http://fr.wikipedia.org/wiki/Équivalences_unicode > > Les macs sont je crois en nfd (à vérifier) >
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air d'être assez croquignolet comme résultat vu que plein d'autres parties du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-)
Voilà c'est le bordel.
Surtout par exemple quand se passe la chose suivante : on crée un fichier avec accent mettons via SMB dans un codage, pis on les relis avec AFP. Le Mac affiche bien les accents et voit le bon fichier, mais il crée un petit fichier de méta données avec son codage : résultat les deux fichiers ne sont pas nommés pareil :)
Bon... d'ici quelques années cela sera peut-être réglé. Vu la vitesse où les choses avances...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Ofnuts <o.f.n.u.t.s@la.poste.net> wrote:
FiLH wrote:
>> On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou
>> plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre
>> de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en
>> créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et
>> "circonflexe diacritique combinable".
>
> Ben si justement :
> http://fr.wikipedia.org/wiki/Normalisation_Unicode
> http://fr.wikipedia.org/wiki/Équivalences_unicode
>
> Les macs sont je crois en nfd (à vérifier)
>
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme
clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air
d'être assez croquignolet comme résultat vu que plein d'autres parties
du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-)
Voilà c'est le bordel.
Surtout par exemple quand se passe la chose suivante : on crée un
fichier avec accent mettons via SMB dans un codage, pis on les relis
avec AFP. Le Mac affiche bien les accents et voit le bon fichier, mais
il crée un petit fichier de méta données avec son codage : résultat les
deux fichiers ne sont pas nommés pareil :)
Bon... d'ici quelques années cela sera peut-être réglé. Vu la vitesse où
les choses avances...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
>> On a aussi eu ça à l'époque avec des noms de fichiers contenant un ou >> plusieurs "backspace". On peut bien sûr forger de toutes pièces ce genre >> de chaînes, mais quelqu'un qui tape sur un clavier(*) ne peut pas en >> créer. Par exemple, e^, c'est "e" et "circonflexe", et pas "e" et >> "circonflexe diacritique combinable". > > Ben si justement : > http://fr.wikipedia.org/wiki/Normalisation_Unicode > http://fr.wikipedia.org/wiki/Équivalences_unicode > > Les macs sont je crois en nfd (à vérifier) >
Certains filesystems OSX listent les noms de fichiers en NFD. mais comme clavier sort du NFC, et donc que les scripts sont en NFC, ça a l'air d'être assez croquignolet comme résultat vu que plein d'autres parties du système ne connaissent pas les subtilités de la normalisation.
Les expressions régulières en NFD doit être assez sportif:-)
Voilà c'est le bordel.
Surtout par exemple quand se passe la chose suivante : on crée un fichier avec accent mettons via SMB dans un codage, pis on les relis avec AFP. Le Mac affiche bien les accents et voit le bon fichier, mais il crée un petit fichier de méta données avec son codage : résultat les deux fichiers ne sont pas nommés pareil :)
Bon... d'ici quelques années cela sera peut-être réglé. Vu la vitesse où les choses avances...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Stephane Legras-Decussy
"Pierre Pallier" a écrit dans le message de news: 4aa3aec0$0$23486$
J'en connais un qui va passer un peu de temps à désinfecter sa machine, après avoir cherché "double accent circonflexe" sur Google. C'est vieux comme truc, en plus.
ah bien vu...j'avais meme pas cherché, visiblement j'ai chopé bugbearB...
pas grave puisque j'ai pas de carnet d'adresse en local, ça n'emmerde que moi ...
"Pierre Pallier" <mon_reply_to@nest-pas.invalid> a écrit dans le message de
news: 4aa3aec0$0$23486$ba4acef3@news.orange.fr...
J'en connais un qui va passer un peu de temps à désinfecter sa machine,
après avoir cherché "double accent circonflexe" sur Google.
C'est vieux comme truc, en plus.
ah bien vu...j'avais meme pas cherché,
visiblement j'ai chopé bugbearB...
pas grave puisque j'ai pas de carnet d'adresse
en local, ça n'emmerde que moi ...
"Pierre Pallier" a écrit dans le message de news: 4aa3aec0$0$23486$
J'en connais un qui va passer un peu de temps à désinfecter sa machine, après avoir cherché "double accent circonflexe" sur Google. C'est vieux comme truc, en plus.
ah bien vu...j'avais meme pas cherché, visiblement j'ai chopé bugbearB...
pas grave puisque j'ai pas de carnet d'adresse en local, ça n'emmerde que moi ...
