[spip-dev] Branche 1.9.2

952025d4c0b44044bbfe · Septembre 6, 2007, 9:01

Stephane <stephane@rezo.net> écrivait :

Stanislas a écrit :

une pécadille : sauf erreur, j'ai eu à ajouter l'extension csv (common
separato value) dans la table types_documents

Probablement une erreur, car je ne vois rien dans
http://trac.rezo.net/trac/spip/browser/branches/spip-1.9.2/ecrire/base/typedoc.php
ou http://trac.rezo.net/trac/spip/browser/spip/ecrire/base/typedoc.php .

ah oui, bonne idée.
je le met bien en text/plain ?

En text/csv, cf. http://trac.rezo.net/trac/spip/ticket/376#comment:11
Et vous pouvez ajoutere les autrse formats manquants et indiqués
dans http://trac.rezo.net/trac/spip/ticket/376 dans la branche 1.9.3,
en « Documents varies » par défaut.

questions au passage :
pourquoi 'avi'=>'video/x-msvideo' ?
plutot 'avi'=>'video/avi', non ?

Parce que video/x-msvideo est le type envoyé par Apache,
et que video/avi n'est pas normalisé d'après
http://www.iana.org/assignments/media-types/video/
Rien n'empèche de copier le commentaire du type bmp, et faire

// Multimedia (peuvent utiliser le tag <embed>)
- 'aiff'=>'audio/x-aiff',
+ 'aiff'=>'audio/x-aiff', // pas enregistre par IANA
- 'asf'=>'video/x-ms-asf',
+ 'asf'=>'application/vnd.ms-asf', // Media Types

application/vnd.ms-asf
- 'avi'=>'video/x-msvideo',
+ 'avi'=>'video/x-msvideo', // pas enregistre par IANA
'flv' => 'video/x-flv',
'mid'=>'audio/midi',
afin d'etre explicite (ce diff corrige aussi le type asf);
ou même // pas enregistre par IANA, cf. Media Types

pourquoi 'mp4' => 'application/mp4',
et pas 'mp4' => 'video/mp4'

Je ne peux pas répondre pour cedric
(cf. http://trac.rezo.net/trac/spip/changeset/8732#file0
et http://trac.rezo.net/trac/spip/changeset/8832#file0 ),
mais c'est probablement parce que application/mp4 couvre à la fois audio/mp4 et video/mp4,
cf. rfc 4337 section 2 RFC 4337 - MIME Type Registration for MPEG-4

au passage, comment sont gérés les .mpeg

« 'mp3'=>'audio/mpeg' »
http://trac.rezo.net/trac/spip/browser/branches/spip-1.9.2/ecrire/base/typedoc.php?rev=8749#L134

et les .divx ?

Pas gérés actuellement.

fil · Septembre 6, 2007, 9:24

> et les .divx ?

Pas gérés actuellement.

Pour la partie "nouveaux formats" je propose qu'on s'en occupe
uniquement sur la branche trunk, car elle prévoit des choses plus
riches, notamment les aliases. Il me semble que divx est un cas
typique d'alias : il faut repérer son type et/ou extension, puis
changer l'extension en avi

-- Fil

3e5e4f242968084de82d · Septembre 6, 2007, 11:32

Nicolas Krebs a écrit :

pourquoi 'mp4' => 'application/mp4',
et pas 'mp4' => 'video/mp4'

Je ne peux pas répondre pour cedric (cf. http://trac.rezo.net/trac/spip/changeset/8732#file0
et http://trac.rezo.net/trac/spip/changeset/8832#file0 ), mais c'est probablement parce que application/mp4 couvre à la fois audio/mp4 et video/mp4, cf. rfc 4337 section 2 RFC 4337 - MIME Type Registration for MPEG-4

OK, merci pour les reponses et surtout les liens vers les bons tickets que je n'avais pas vu (!!! faut vraiment que je m'habitue au trac, mais j'ai du mal, pourquoi c'est pas indexé par google tous ces tickets ???)

au passage, comment sont gérés les .mpeg

« 'mp3'=>'audio/mpeg' »
http://trac.rezo.net/trac/spip/browser/branches/spip-1.9.2/ecrire/base/typedoc.php?rev=8749#L134

je parlais de .mpeg = .mpg => video...
comme .jpeg =.jpg

j'allais l'ajouter à corriger_extensions mais effectivement, c'est un probleme plus general d'alias qu'on ne va pas traiter dans la branche de maintenance.
enfin c'est un peu dommage qu'un .mpeg se retrouve zippé...

donc, pour la branche maintenance, je recapitule le ajouts / modif de typedoc:
- c'est amha une erreur de mettre les .psd dans un tag img (chez moi ca ne marche ni sous FF ni sous IE)
=> je le descend avec les documents variés (?)

ajout de :
.csv => text/csv
il y a deja la vignette...

klm => application/vnd.google-earth.kml+xml <http://www.iana.org/assignments/media-types/application/vnd.google-earth.kml+xml>
je suppose qu'il faut egalement :
.klz => application/vnd.google-earth.kmz <http://www.iana.org/assignments/media-types/application/vnd.google-earth.kml+xml>
=> manque la vignette pour pouvoir l'integrer (j'en bricole une pour les 2)

je propose d'ajouter également (parce que c'est un des rares formats libres en video et qu'il n'est pas dans spip !) :
.mkv => video/x-mkv (embed)
=> meme vignette que avi
(avec le plugin VLC chez moi ca a l'air de marcher mais je ne suis pas sur de mon fichier.)

.mka => audio/x-mka (embed)
=> meme vignette que mp3
(pas testé mais ca devrait marcher de la meme facon)

pour les .smi (smile), je passe...

sinon, pour http://trac.rezo.net/trac/spip/changeset/9293
report ou pas report ?

et inc/presentation :
89c89

+ return $ret . "</div>\n<div class='cadre-padding'>";
- return $ret . "</div>\n<div class='cadre-padding' style='overflow:hidden'>";

pas d'objection ?
j'ai retrouvé quand il a été mis, mais pas vraiment pourquoi :
http://trac.rezo.net/trac/spip/changeset/6860

je teste l'uprgade chez moi, si ca convient, je commite demain

@++

3e5e4f242968084de82d · Septembre 7, 2007, 12:16

Stephane a écrit :

klm => application/vnd.google-earth.kml+xml <http://www.iana.org/assignments/media-types/application/vnd.google-earth.kml+xml>
je suppose qu'il faut egalement :
.klz => application/vnd.google-earth.kmz <http://www.iana.org/assignments/media-types/application/vnd.google-earth.kml+xml>
=> manque la vignette pour pouvoir l'integrer (j'en bricole une pour les 2)

heu, je voulais dire kml et kmz bien sur...

RealET · Septembre 7, 2007, 6:59

* Stephane tapuscrivait, le 07/09/2007 01:32:

et inc/presentation :
89c89

+ return $ret . "</div>\n<div class='cadre-padding'>";
- return $ret . "</div>\n<div class='cadre-padding' style='overflow:hidden'>";

pas d'objection ?
j'ai retrouvé quand il a été mis, mais pas vraiment pourquoi :
http://trac.rezo.net/trac/spip/changeset/6860

Il me semble que c'était pour qu'une image très large ne casse pas l'interface privée mais soit masquée à droite (pour ne pas empiéter sur la colonne de droite).

fil · Septembre 7, 2007, 9:08

> j'ai retrouvé quand il a été mis, mais pas vraiment pourquoi :
> http://trac.rezo.net/trac/spip/changeset/6860
Il me semble que c'était pour qu'une image très large ne casse pas
l'interface privée mais soit masquée à droite (pour ne pas empiéter sur
la colonne de droite).

oui, mais c'est vrai que ça ennuie les puces automatiques. Avec les
nouveaux traitements, on devrait avoir la possibilité de mettre

reduire_image{520} dans les traitements_des_tables, ça devrait

résoudre le problème.

-- Fil

cerdic · Septembre 7, 2007, 10:38

Fil a écrit :

j'ai retrouvé quand il a été mis, mais pas vraiment pourquoi :
http://trac.rezo.net/trac/spip/changeset/6860


Il me semble que c'était pour qu'une image très large ne casse pas
l'interface privée mais soit masquée à droite (pour ne pas empiéter sur
la colonne de droite).

oui, mais c'est vrai que ça ennuie les puces automatiques. Avec les
nouveaux traitements, on devrait avoir la possibilité de mettre
>reduire_image{520} dans les traitements_des_tables, ça devrait
résoudre le problème.

attention !
en svn, reduire_image est depreciee (bien que supportee) et il est vivement souhaitable d'utiliser image_reduire pour profiter à plein du mecanisme de suppression des images temporaires.

La raison est que le compilateur reconnait les filtres image en cela qu'ils commencent par le prefixe image_ et des qu'il rencontre un filtre autre, il fixe l'image comme non temporaire. Du coup si tu utilise reduire_image, tu fixe une image intermediaire inutilse.
On devrait la passer en veilles_def d'ailleurs

Par contre, ce mecanisme est inclus au compilateur et si l'on appelle un filtre directement dans le code de l'espace privé, le resulatat est présumé temporaire. Il faut que l'on s'ajoute un point d'entree du type

function un_filtre_image($filtre,...) { return image_graver(image_filtrer($filtre,...));}

Ou alors qu'on squeletise tout
Cedric

3e5e4f242968084de82d · Septembre 7, 2007, 11:34

cedric.morin@yterium.com a écrit :

Fil a écrit :


j'ai retrouvé quand il a été mis, mais pas vraiment pourquoi :
http://trac.rezo.net/trac/spip/changeset/6860


Il me semble que c'était pour qu'une image très large ne casse pas
l'interface privée mais soit masquée à droite (pour ne pas empiéter sur
la colonne de droite).


oui, mais c'est vrai que ça ennuie les puces automatiques. Avec les
nouveaux traitements, on devrait avoir la possibilité de mettre
>reduire_image{520} dans les traitements_des_tables, ça devrait
résoudre le problème.


attention !
en svn, reduire_image est depreciee (bien que supportee) et il est vivement souhaitable d'utiliser image_reduire pour profiter à plein du mecanisme de suppression des images temporaires.

La raison est que le compilateur reconnait les filtres image en cela qu'ils commencent par le prefixe image_ et des qu'il rencontre un filtre autre, il fixe l'image comme non temporaire. Du coup si tu utilise reduire_image, tu fixe une image intermediaire inutilse.
On devrait la passer en veilles_def d'ailleurs

Par contre, ce mecanisme est inclus au compilateur et si l'on appelle un filtre directement dans le code de l'espace privé, le resulatat est présumé temporaire. Il faut que l'on s'ajoute un point d'entree du type

function un_filtre_image($filtre,...) { return image_graver(image_filtrer($filtre,...));}

Ou alors qu'on squeletise tout

bien bien, mais ma question était : est-ce que je le fais sauter pour la 1.9.2c ?
l'excuse c'est que ca gene les pucs de statut mais en fait, c'est surtout parce que je surcharge presentation juste pour ca avec spipcarto (car moi, si l'image fait 1024, je dois l'afficher pour pouvoir dessiner dessus...).
faut juste dire oui ou non...
et tant que vous y etes, dites moi aussi si vous etes OK pour les modifs de typedoc proposées et le report de 9293...

@++.