Reprise du message précédent :
Faut la faire signer par d'autre personne

Ouais mais j'ai pas encore eu l'occasion de participer à une "Debian key signing party"

Bon çà y est : ripdvd a une "documentation officielle".
 
Elle est là : http://ripdvd.wiki.sourceforge.net/Documentation

Voila, j'ai uploadé ma clé publique GPG sur le serveur subkeys.pgp.net. Pour éviter le message de warning d'apt à propos de la clé GPG durant l'update ou l'installation de paquets depuis mon dépôt :
 

 
Normalement ça devrait marcher. N'hésitez pas à me signaler des erreurs/warnings éventuels.

 
Super boulot Fafane
 
J'ai remarqué un truc par contre ... tu n'as pas les droits sur /dev/sr1 ?
 
 

Oui je n'ai pas bien compris.
 
En plus /dev/sr1 n'est que le raccourci de /dev/scd1
 
Quand aux permissions, les voilà :  
 

 
Mais bon çà marche tout de même, alors...

Proposition:
 
RIPDVD a deux modes, semble t-il.
Un "simple" et un "compliqué"
 
Pourquoi, quand on lance ripdvd en terminal ne pas décider qui s'agit du mode "simple/beginner" et quand on tape ripdvd --advanced, qu'il s'agit du mode plus complet ?
 
La question est bizarrement amenée, je sais.
L'idée est juste de créer une version complete du script (toujours interactive) a partir de l'option --advanced

En fait, le mode "simple" dispose déjà d'une commande propre: --user-menu
 
Pour le mode "compliqué", il s'agit tout simplement des options disponibles en ligne de commande et à passer à la commande ripdvd
 
Ajouter une option --advanced ne servirait à rien, étant donné que le mode "compliqué" n'est justement pas interactif
 
Mais la question reste intéressante

Ceci dit, ça pourrait être une bonne idée de passer par défaut en mode --user-menu si l'utilisateur ne donne aucun argument.

 
Ouaip, j'y avais pensé au moment de créer cette option, mais je me suis rappelé que j'ai la sombre habitude de tester une commande que je ne connais pas dans l'ordre suivant:

 
Ne me demandez pas pourquoi, c'est comme ça ...
 
Un utilisateur qui n'aurait pas l'habitude de taper -h ou --help voit actuellement tout de suite l'aide, alors qu'avec cette proposition, l'aide disparait pour n'être disponible que quand les options kivonbien sont utilisées.
 
A discuter aussi ...

à noter que le comportement actuel est le comportement de beaucoup de programmes, donc autant le laisser comme ça

'lut touss

Nouvelles releases, beaucoup de correctifs

Version testing:
1.7.1 - 19/06/2007

• mise à jour des fichiers de langue (j'avais oublié les messages de l'option 14 de la fonction modify_conf()
• voir le changelog de la version stable 1.6.2 pour les mises à jour communes

Version stable
1.6.2 - 19/06/2007

• correction de la fonction create_dest_dir(), la variable est placée entre quotes. Un grand merci à Arghbis pour ses rapports de bug !
• mise à jour des fichiers de langue, et plus précisément des traductions correspondant à l'option --help qui n'était pas aussi claire qu'elle l'aurait dû à propos des options --aud/--aud-id, --sub/--sub-id et --aud-format. Merci à Arghbis pour l'info
• correction de l'option --dest-dir ... j'avais oublié un ";" après l'appel à la fonction create_dest_dir() ...
• mise à jour de la page de man (voir la mise à jour des fichiers de langue)
• NOTE: Un magnifique tutoriel a été mise en place par Fafane84 et est désormais disponible sur le wiki officiel de ripdvd. Il vous explique comment utiliser ripdvd pas à pas, incluant même de petites vidéos de démonstration. Ce tuto est actuellement en français uniquement, mais je ne doute pas que même les Francophobes apprécieront le travail
• NOTE: Comme certains l'ont peut-être remarqué, je suis actuellement en train de travailler sur un site officiel pour ripdvd (hébergé par googlepages). C'est en travaux (très lents les travaux, tout comme la progression de ripdvd cette semaine ... 'tain de boulot ). J'essayerais de le rendre le plus interactif possible avec les pages de sourceforge afin que les mises à jour se fassent automatiquement. Si quelqu'un veut me donner un p'tiot coup de main, ça sera avec grand plaisir
• NOTE: La section de téléchargement de sourceforge.net a été complètement modifiée. Etant donné que ça n'a été discuté que sur le topic ripdvd du forum de hardware.fr, voici quelques explications. A cause du nombre de packages disponibles (je ne remercierais jamais assez Franceso et Grozdan poour leur magnifique travail sur les packages .deb et .rpm), et le fait que ripdvd fonctionne désormais sur 2 modes (stable/testing), la section téléchargements était devenue un peu brouillon. Désormais, les sections ressembleront à ça:

Chaque packager devra "éditer/modifier" la release actuelle pour uploader ses packages, et ne jamais "créer" une nouvelle release (qui cacherait la release actuelle et les fichiers disponibles). Etant donné que j'upload toujours les fichiers pour Slackware en même temps que les sources, la release binaire visible sera toujours la dernière (et donc la bonne). Si jamais (qui sait ?), un package avait besoin d'être refait pour une distrib, le packager devra "éditer/modifier" et (bien entendu), poster une news pour en informer la Terre entière . La suppression des anciens fichiers est laissée à sa désicion ...

J'espère que vous apprécierez

Super.
 
J'aime bien cette nouvelle organisation. Ce sera beaucoup plus clair pour les utilisateurs !

Les paquets Debian/Ubuntu sont disponibles.
 
stable - 1.6.2

• Téléchargement sur sourceforge
• Dépot apt : deb http://francesco.ovh.org/debian/ testing main

dev - 1.7.1

• Téléchargement sur sourceforge
• Dépot apt: deb http://francesco.ovh.org/debian/ sid main

 
Je rappelle que pour éviter le message de warning d'apt à propos de la clé GPG durant l'update ou l'installation de paquets depuis mon dépôt, vous pouvez lancer la commande suivante :
 

la 1.6.2 s'installe sans problème à partir du paquet debian.

'lut tout le monde
 
De retour en pleine forme avec une nouvelle version tout fraiche    
 
Version stable
1.8.0 - 05/08/2007

• fusion du code "testing" de la version 1.7.2 contenant le code "skip 1st minute" et tout ce qui l'accompagne, permettant de ne pas encoder la 1ere minute du dvd (pour certains dvds mal formatés, ça fait planter mencoder et donc ripdvd )
• l'option --user-menu est désormais obsolète. Elle fonctionne toujours, mais je trouvais son nom un peu inapproprié. Elle s'appelle désormais --automatic  
• modification de la fonction find_dvd_reader() demandant à l'utilisateur de spécifier le périphérique du lecteur dvd si aucun n'est trouvé. Ca ne semble pas grand chose, mais ça modifie le fonctionnement "automatic" (le nouveau petit nom du mode "user menu" ). Ca permet d'utiliser une image ISO montée en loopback comme périphérique. Il suffit de monter l'image ISO (i.e.: mount -o loop dvd.iso /mnt/loop), ejecter les dvds présents dans les lecteurs, répondre à la question en spécifiant le point de montage "/mnt/loop" au lieu de "/dev/dvd" et hop  
• ajout d'un test dans la fonction user_interrupt() permettant de ne pas chercher à supprimer les fichiers si le nom du film est vide
• ajout de la fonction fps_autodetect() qui cherche à détecter automatiquement le FPS d'entrée et configure automatiquement le FPS de sortie avec cette valeur
• ajout des fonction set_vf_opt() et set_vid_opt() qui créent les variables correspondant aux filtres vidéos et aux options d'encodage vidéo
• modification des fonctions preview(), encode() et print_cmd() pour qu'elles utilisent ces nouvelles fonctions
• amélioration de la fonction guess_crop_values() qui utilise désormais une 2e méthode de détection des valeurs de cropping si la première échoue. Si jamais cette deuxième méthode échoue aussi, les valeurs sont fixées à 0
• ajout de la fonction set_video_size() qui récupère la largeur et la hauteur de la vidéo depuis les informations du dvd
• modification des fonctions set_conf() et clean_conf() qui n'ont désormais plus besoin de la variable WIDTH
• modification de la fonction set_vf_opts() afin qu'elle utilise ces nouvelles valeurs WIDTH et HEIGHT provenant de set_video_size ou bien de guess_crop_values()
• correction de la fonction print_track_list() qui n'utilisait pas la variable DVD_DEV pour récupèrer la liste des pistes et utilisait le périphérique dvd par défaut de lsdvd. Désolé pour cet oubli !
• mise à jour des scripts xripdvd et ripdvd.Desktop
• mise à jour des fichiers de langue et de la page de man
• NOTE: Je suis actuellement en train de travailler sur un code prenant en compte le bpp (Bit Per Pixel) et surtout comment l'intégrer à ripdvd, tout en conservant l'esprit "ripdvd". Vous le savez peut-être, plus la valeur du bpp est importante et plus la qualité de la vidéo est bonne. Pour augmenter cette valeur, 2 choix sont possibles: augmenter le bitrate (et obtenir un fichier plus gros) ou diminuer la taille de la vidéo (largeur/hauteur). Le problème principal est que le bpp n'est pas une valeur fixée, elle dépent énormément du type de vidéo (i.e.: un film noir&blanc aura une bonne qualité avec bpp=0.1 alors qu'un film d'action nécessitera peut-être bpp>0.2)  

 
1.6.3 - 27/07/2007  

• ajout de la fonction check_dvd_dev() qui vérifie si le périphérique indiqué avec l'option --dvd-dev est éjectable. Si ce n'est pas le cas, on affiche un message et on active automatiquement l'option --no-ejec
• ajout d'un appel à la fonction check_dvd_dev() dans le script ripdvd
• modification de la fonction set_sub_opts() permettant à l'utilisateur de "vider" son choix préalable de sous-titre. Dans l'option 3 du mode "modification des options", s'il laisse la réponse vide ou 0, aucun sous-titre n'est sélectionné
• ajout de l'autocropping dans le fonction user_menu() afin que ceci soit lancé automatiquement si l'utilisateur le souhaite
• mise à jour des fichiers de langue

 
Wala wala

Les paquets Debian/Ubuntu sont disponibles.
 
stable - 1.8.0

• Téléchargement sur sourceforge
• Dépot apt : deb http://francesco.ovh.org/debian/ sid main

A propos du bpp, tu pourrais aussi ajouter un test de compression qui te permet d'avoir une idée du bpp utile sur le film considéré pour avoir une bonne qualité, comme le fait tuxrip.
 
Jo

Yep, c'est justement ce sur quoi je suis en train de plancher

Mes soucis, c'est d'intégrer tout ça dans le "style ripdvd" (placer un max de choses par défaut, en prenant en compte que le user peut être totalement nioub sur ce genre de choses), et aussi le fait que le bpp est fortement dépendant du type de film

Salut à tous
 
Une nouvelle version est disponible
 
1.8.1 - 09/08/2007

• ajout de la fonction calc_bpp() qui calcule le Bit Per Pixel en fonction du bitrate vidéo, du fps, de la largeur et de la hauteur du film
• ajout de la fonction print_bpp() qui affiche la valeur du Bit Per Pixel ainsi qu'un score correspondant (sur 5) et un petit smiley. J'ai supposé ici que le bpp était indépendant du type de film (noir&blanc, film "sombre", film d'action avec beaucoup d'éclair etc ...). Il faut donc faire très attention au score et au smiley !
• modification de la fonction set_vid_opts() par l'ajout d'un appel à la fonction calc_bpp()
• modification de la fonction fps_autodetect(). Il semblerait que l'utilisation de l'option -ofps ne soit pas aussi facile que je le pensais. Quand il s'agit d'encodre des vidéos au format PAL/SECAM, tout fonctionne bien, mais les formats NTSC et NTSC Progressif peuvent poser problème s'ils sont mal fichus. J'ai donc ajouté un warning et une question dans ces cas. Dans les prochaines releases, j'ajouterais les filtres Pulldown Reversal/Inverse Telecine et Hard Telecine/3:2 Pulldown pour corriger ces cas, mais j'ai d'abord besoin de comprendre ce que ça fait, quand c'est nécessaire et comment l'utilise . Merci à Grozdan pour son aide !
• correction de la fonction check_dvd_dev() afin qu'elle utilise le code retour $? de la commande eject plutôt que la commande directement
• correction de la fonction set_vf_opts() qui n'utilsait pas les bonnes informations WIDTH et HEIGHT pour le scaling. WIDTH est toujours utilisé, mais je réutilise désormais l'autodétection pour HEIGHT car le résultat est bien meilleur. Autre chose à ce propos: Mencoder calcule la hauteur en utilisant la largeur fixée et l'aspet vidéo (16/9 la plupart du temps) afin que la taille de la vidéo soit fixée avec les bonnes valeurs de scaling, mais, si ces valeurs ne sont pas correctes, Mplayer fixe alors la hauteur pour calculer la bonne largeur à partir de ça lorsque l'on regarde la vidéo !! (et c'est génant car la vidéo affichée aura une largeur plus importante que celle désirée)
• ajout de la fonction aspect_autodetect() qui détecte automatiquement l'aspect vidéo, 4/3, 16/9 etc ... (cette fonciton n'est pas utilisée actuellement dans ripdvd, mais elle sera très utile dans un futur assez proche )
• mise à jour des fichiers de langue
• NOTE: l'option --aspect ne fonctionne plus à cause des fonctions set_video_size() et set_vf_opts(). Je pense que la prochaine release corrigera tout ça. Il faut juste que je trouve une façon élégante de calculer les valeurs de cropping sur les largeurs/hauteurs réduites. En effet, l'autocropping est toujours calculé sur les valeurs non réduites
• NOTE: Je pense aussi supprimer la question à propos de l'autocrop dans le mode --automatic. Si ça gène quelqu'un, merci de me prévenir avant que je ne le fasse !
• NOTE: on s'approche lentement d'une grande amélioration dans ripdvd qui contiendra une autodétection de la meilleure taille (largeur/hauteur) en fonction du BPP

En espérant que ça vous plaira

Salut tout le monde

Petit information pour vous dire qu'un paquet Slackware (eh voui, encore un ) est désormais disponible sur le repository "officiel" de Slacky: http://www.slacky.eu/repository/

Je doute que Loris Vincenzi ("aka" Slacky) vienne lurker sur HFR, mais je veux quand même lui dire un grand merci

edit: tant que j'y suis, une release 1.10.0 intégrant plein de nouvelles fonctionnalités sera sans doute uploadée en cours de semaine

Justement, le test de compression sert à déterminer quel est l'ordre de grandeur qu'il faut choisir comme bpp pour ton film.
Ce test est implémenté dans Tuxrip et le principe provient de GordianKnot (soft de compression divx windows).
 
L'idée est d'encoder 5 ou 10% du film (également réparti dans tout le film pour capter les différentes scènes) en qualité max (une seule passe, q constant = 2, pas utile de mettre 1). Ensuite tu en déduis le bpp max avec la taille du fichier obtenu et la durée. Tu calcules enfin le bpp que tu dois choisir pour ton encodage final : par exemple 50% du bpp max.  
 
Cette technique marche très bien.
 
Jo

Hello
 
Une nouvelle version est disponible
 
1.10.0 - 15/08/2007

• correction de la fonction print_crop_values() qui affiche désormais le ratio du film (4/3, 16/9 et ...) et la résolution non redimensionnée de la vidéo (utile pour le cropping manuel)
• modification de la fonction guess_crop_values(). Deux nouvelles variables ont été ajoutées: CROPPED_WIDTH et CROPPED_HEIGHT, qui contiennent les valeur de largeur et hauteur du film non redimensionné  
• modification de la fonction calc_bpp() qui calcule désormais le Bit Per Pixel en utilisant les valeurs réelles de largeur et hauteur. Ces valeurs réelles sont calculées à partir des largeur/hauteur originales, redimensionnées, du ratio original et du ratio réel. Le résultat est la valeur réelle du BPP, la valeur calculée dans la version 1.8.1 n'était pas correcte !
• renommage de la fonction set_video_size() en original_size_autodetect(). Les variables WIDTH et HEIGHT ont aussi été préfixées par ORIGINAL_ afin d'être plus explicites
• modification de la fonction print_header() afin d'afficher le BPP. Cet affichage se faisait jusqu'à présent dans la fonction calc_bpp() et n'avait rien à faire là ...  
• modification de la fonction print_bpp. Suppression du "score" qui n'était pas une très bonne chose
• ajout de la fonction calc_scaling_val() qui calcule les valeurs de redimensionnement à partir d'une largeur de départ (croppée ou originale), la hauteur correspondante et le ratio. La largeur de départ est tout d'abord corrigée pour être divisible par 16. Ensuite, on passe dans une boucle "pour" qui commence avec la largeur de départ et qui s'arrête à 560 en diminuant de 16 à chaque pas. Un menu de sélection est affiché, proposant de choisir les valeurs de redimensionnement
• modification de la fonction modify_conf(). Ajout d'une nouvelle option (n°15) qui permet de choisir des valeurs de redimensionnement
• modification de la fonction calc_bpp() pour utiliser les valeurs de redimensionnement, si elles existent
• modification du script ripdvd. La variable WIDTH de l'option --width a été renommée USER_WIDTH
• modification de la fonction set_vf_opts() afin qu'elle utilise les valeurs de redimensionnement provenant de la fonction calc_scaling_val(). Ajout d'un test pour vérifier si l'utilisateur a choisi une largeur "personelle" avec l'option --width de la ligne de commande. Cette valeur sera par la suite écrasée si l'utilisateur choisit une valeur de redimensionnement provenant de la fonction calc_scaling_val()
• ajout de la fonction print_movie_res() qui affiche les valeurs réelles de redimensionnement et le ratio réel (affiché sous la forme X,YYY/1)
• modification de la fonction print_header() afin qu'elle appelle la fonction print_movie_res() après print_bpp()
• modification de la fonction user_menu(). La question sur l'autocrop a été supprimée, celui ci est devenu automatique
• modification de la fonction preview(). Une option a été ajoutée au menu, permettant à l'utilisateur de relancer la prévisualisation directement. Ca peut être utile dans le cas de rip avec sous-titres et qu'aucun dialogue n'avaient eu lieu dans la prévisualisation précédente, pour s'assurer que la piste sous-titre est correcte ... en fait, c'est juste plus rapide que d'utiliser l'option "2" puis l'option "p" du menu "Modification d'option"
• mise à jour des fichiers de langue
• mise à jour de la page de man

Wala

 
@Franceso:  
l'option en ligne de commande --user-menu est obsolète et a été remplacée par --automatic.
Un user debian (ou ubuntu, je sais plus) m'a dit que lorsqu'il utilisait la commande depuis le menu (gnome/xfce/kde), il avait un message lui disant que --user-menu était obsolète (logique, je fais afficher ce message quand l'option est utilisée).
Traduction: il faudrait que tu fasses la mise à jour du (x)ripdvd.desktop et que tu remplaces par la bonne option
 
Marchi

Ouais, à la sortie de 1.8.0, j'avais zappé cette partie du changelog. Normalement, j'ai corrigé ça dans la 1.8.1 (du moins en ce qui concerne le menu Debian ; je ne suis pas très sûr en ce qui concerne le .desktop). Je vais vérifier ça pour le package de la 1.10.
 

OKi
 
Tiens, j'en profite pour vous dire que j'ai mis à jour le site ouaib: http://wedge.ant.googlepages.com/home
 
C'est pas du grand art, mais c'est au minimum explicatif

Le code de cette page est horrible. Avec quoi t'as fait ça ?

Et ça va de soi que si tu veux de l'aide pour corriger ce code je peux t'aider.

Je vais prendre la défense de WedgeAnt sur ce coup.
 
Je lui avais déjà fait part, en privé, du code infâme généré par l'assistant de googlepages.com.
 
Vous ne le savez peut-être pas, mais WedgeAnt n'a pas de connexion Internet @t home et administre le site de son boulot (pendant ses pauses café, cela va de soit).
 
Le problème est qu'à son boulot il a un accés restreint à Internet et le seul hébergeur qu'il est pût trouver a été googlepages.com.
 
Je lui avais fait les mêmes suggestions que vous au sujet du code et même proposé de l'héberger sur un me des comptes free (si PHP/MySQL) ou sur Orange (si HTML).
 
Mais il a décliné mon offre, et je le comprend tout à fait, préférant garder la main sur son site.  
Ce qui est parfaitement légitime.
 
Reste plus qu'à espérer qu'un beau jour l'ADSL frappe à sa porte    
 
Voilà pour la petite histoire.

Autant pour moi je ne savais pas. Faire partie des gens qui n'ont pas l'ADSL faut vraiment être très pommé quand même c'est pas de chance.

Pas la peine de prendre sa défense : de toutes façons on l'aime bien notre Wedge (et c'est pas du HTML pourri qui va changer ça !)
 

 
Peut-être qu'une bonne solution serait d'utiliser l'hébergement proposé par sourceforge : tu crées ton site chez toi tranquillement et tu peux le tester localement. Quand c'est prêt, un petit coup de SCP permet de l'uploader sur le site (et il y a des clients SCP sous windows pour pouvoir le faire même depuis les postes du ministère)
 
EDIT: je viens de me rendre compte que ce qui pose problème, c'est sans doute le proxy du taf qui doit bloquer tous les ports sauf 80... Dans ce cas, effectivement, je ne vois pas d'autre solution que googlepages.  
 
Sinon, peut-être qu'un petit SGC léger pourrait faire l'affaire. Une fois installé sur SourceForge, plus besoin d'accès FTP/SCP : en général un éditeur est prévu pour ajouter directement du contenu en ligne...
 
En tous cas, vivement que l'ADSL arrive dans la campagne !  

Avec googlepages

Pour résumer, Fafane (qui, vous l'avez sans doute compris, est très au courant de ma situation professionnelle ... ) et Franceso ont très bien analysé la situation:
- pas de net @home (pas d'adsl et oui j'habite à la cambrousse )
- net très restreint @work (proxy fonctionnant par whitelist et ne laissant passer que le http, https et ftp sur un nombre très restreint de sites)
- installation/utilisation de logiciels "externes" interdits (enfin, vaut mieux pas se faire prendre ... )
- hébergement sur sf: euh, si vous voulez, mais c'est vous qui gèrez le site hein (leur système est chiatique et non, y'a pas d'éditeur Franceso, il faut tout uploader à chaque fois ... tu t'es jamais demandé pourquoi si peu de monde utilisait leur hébergement ? )
- hébergement chez quelqu'un d'autre: oui, ça serait l'idéal, mais il faut à la fois que je puisse y avoir accès depuis le taf sans limitation et que ça ne soit pas la croix et la bannière à gèrer ...

Bref, googlepages est mon ami, il fait ça vite et bien et même si son code est pourrave, le principal est sauf: avoir un site à peu près potable pour présenter le soft  

edit: koukou atouss
et merki de vous préoccuper comme ça de ce projet

re tout le monde
 
Une nouvelle version est disponible, voici le Changelog:

1.10.1 - 19/08/2007

• correction de la fonction set_vf_opts(). Les filtres dering/deblock ont été supprimés et j'ai ajouté un filtre denoise à l aplace. Ces filtres (dering et deblock) sont inutiles lors de l'encodage d'un DVD tandis que denoise permet de ne pas encoder le "bruit" du film et donc de gagner un peu de place. Merci à Grozdan pour le coup de main ! (la suppression de ces filtres devrait entrainer une augmentation de la vitesse d'encodage d'environ 5 à 10 fps, dépendant de votre CPU ...)
• modification de la fonction guess_crop_values(). La version "hardcore" de l'autodéction des valeurs de cropping tourne désormais sur une vidéo de 3s, plutôt que 10s qui était trop long. L'appel à la fonction original_size_autodetect() a aussi été supprimé pour être placé directement dans le script ripdvd, pour éviter un plantage lors de l'utisation de valeurs de cropping manuelles
• modification de la fonction user_menu(). Ajout d'un appel à la fonction original_size_autodetect()
• correction de la fonction print_crop_values(). Si les valeurs de cropping sont fournies par l'option en ligne de commande, alors les variables CROPPED_WIDTH et CROPPED_HEIGHT sont renseignées avec les valeurs fournies
• mise à jour des fichiers de langue

Wala  

Je sais bien que SF ne propose pas d'éditeur, mais par contre il me semble qu'ils autorisent le PHP. Du coup, tu peux peut-être uploader une bonne fois pour toutes un petit SGC léger qui te permettra de gérer ton site correctement uniquement par accès HTTP.
 
Il y a plein de CMS pas mal foutus et légers, comme par exemple Itseasy (liste très complète sur OpenSourceCMS.com).
 
C'est peut-être une bonne solution, non ?

J'y avais pensé aussi, demander à quelqu'un de le faire etc ...
Mais euh, il faut uploader tous les fichiers un par un ... pour un CMS, même léger, ça doit amener dans les 100 fichiers environ    
 
Mais si tu veux le faire ...

Attention au code des CMS.
 
Ils sont très souvent de la même trempe que les googlepages.
 
Perso, j'utilise Xoops pour mon site de DivX, mais cela a été un boulot de titan pour qu'il soit valide XHTML 1.0 Strict.
 
Car il ne suffit pas toujours d'avoir des templates bien codé, il faut en plus modifier le core du CMS (voir même certaines fonctions PHP).
 
Et çà pour chaque modules.
 
Sinon pourquoi ne pas utiliser DotClear ou Plume qui sont super bien codés ?
 
Pour le transfert, je veux bien m'en occuper.
 
 
 

Je veux bien le faire : un petit coup de rsync et rulez ! (simplement, je suis pas sûr d'avoir les accès suffisants au projet...)
 

J'ai testé aussi ItsEasy, qui produit du code valide XHTML 1.0 Strict.
C'est vrai que Plume et DotClear ont l'air pas mal aussi...

Ok les zamis
Pour le moment, vous prenez pas la tête, googlepage produit du code immonde mais fait à peu près ce que je veux: afficher 5 pauvres pages avec les infos importantes
 
Si j'ai besoin de passer à la catégorie supérieure, je n'hésiterais pas à vous mettre à contribution

En tout cas le jour où t'as l'ADSL préviens-nous on te fera quelque chose de plus propre et accessible.

 
Le jour où j'ai l'adsl, j'héberge moi même le site que j'aurais codé moi même avec mes petites mains
 
Mais merci quand même