Ca a l'air sympa, mais il faudrait aussi convertir l'encodage, ce qui est plus délicat...

Je me suis toujours demandé à quoi on pouvait reconnaître l'encodage d'un fichier sans BOM ni autre indication que le fichier lui-même...

Quitte à utiliser Firefox, autant prendre l'extension DownloadHelper, qui je suppose utilise le même genre de principe(regarder le mime-type).

Boh sinon ca devait être un bon exercice d'utilisation de CURL...

Salut, bel exemple d'utilisation GD ;)

Quelques petits commentaires:
$phy le decalage: -90(ou 270) : départ d'en haut, +-180 de la gauche, 0 de la droite et 90 d'en bas.

Il y a déjà des fonctions de conversion d'angle : deg2rad et rad2deg
et pour le carré, c'est plus simple d'écrire directement $x*$x

Sinon, joli l'atan pour trouver l'angle, mais tu prends en compte la diagonale(d'un X en plus), or juste la largeur importe, vu que la hauteur est orientée dans la direction du rayon.
Donc moi je dirais plutôt:
$len = $lenX * 1.5 , Ce qui revient presque au même.
Le 1.5 pour recréer l'espacement entre les lettres, et qui pourrait être configurable ;)
Le problème reste que les lettres n'ont pas toutes la même largeur, mais ça ajouterait évidemment qqs lignes de code...(Sans cet espace entre les lettres, on voit bien plus l'erreur des largeusr variables des lettres)
Mais visiblement, c'est beaucoup plus simple et beau en gardant la même largeur :)

Contrairement à Malalam, j'ai d'abord regardé le résultat ... que j'apprécie (malgré que je soit Belge ...)

Quand au code, il me semble fort tourné vers cette seule utilité, donc si tu dois refaire du SVG, tu peux tout recommencer la fois prochaine...

une petite amélioration, je pense(de logique):
if ($content===false) throw new Exception('<b>'.__FUNCTION__.'() : erreur lecture "'.$file.'"</b>');
=>
if ($content===false) throw new Exception('<b>'.__METHOD__.'() : erreur de lecture du fichier "'.$file.'"</b>');

__METHOD__ plutôt que __FUNCTION__, vu qu'on est dans une classe ;)

Quand au choix des animations, c'est bien dommage que ff ne gère pas <animate>, et le JavaScript n'est pas vraiment une solution "propre" (ce n'est plus vraiment du xml).

En conclusion, je pense que c'est un ptit truc sympa, qui montre un peu ce qu'est le SVG, mais à un niveau basique(juste des lignes...) Allez je te met 8/10 :)

Et ça me donne envie de poster ma classe SVG tient....

Ok, je n'ai rien dit pour l'appli.

Néanmoins je trouve ce genre de commentaires /* * * */ encombrants et ça double souvent le nombre de lignes.

Quand à phpDoc, j'ai l'impression que sa réputation est surtout basée sur son utilité en Java(d'après ce que j'ai lu phpDoc en dérive). Car je pense que le module pourrait lui même remarquer les "private,public,protected" devant les fonctions.

Mais je dévie du sujet, et comme je me heurte probablement à tous les utilisateurs de phpDoc, je ne vais pas continuer. Néanmoins, pour moi, la meilleure documentation est faite main en commentaires dans le code ou si plus complexe dans des fichiers à part.
Quand à l'utilité de détecter le hiérarchie des classes, perso je l'indique toujours en début de script.

Donc je comprends l'attrait de phpDoc, mais la notation dans un code me semble exagérée pour certaines propriétés.

J'ai dit  que je préférais une autre notation, donc j'apprécie les codes commentés, et je ne lis pas ceux qui le sont trop peu.

Je sais que c'est une convention, mais je ne vois pas l'intérêt des @access et certaines autres propriétés.

Si certains pensent que ça facilite de faire les commentaires avec une appli, je ne pense pas que les descriptions et types(en php) puissent être générés automatiquement... Donc les seules propriétés intéressantes sont celles qu'on entre soi-même.(C'est mon avis)
Alors autant le faire soi même...

J'ai commencé une classe de création d'image à partir de GD (40 de méthodes et 500lignes),
et donc je ne peux qu'approuver l'idée.

Sauf que l'on voit assez vite le défaut de GD quand on travaille sur l'épaisseur...
Impossible de modifier celle des ellipses, incohérences graves lors d'une épaisseur supérieure à 2 à proximité des angles 45°+k90°
Pour faire simple:
http://eregon.franceserv.com/tmp/q1gd.php.png

J'ai donc complètement changé d'optique pour passer en SVG. Plus besoin d'extension...
La classe est beaucoup plus orientée objet(car SVG, c'est du xml...).
Qualité infinie, calcul chez l'utilisateur donc pas d'explosion de mémoire...
http://eregon.franceserv.com/tmp/test.png

Je rentre un peu trop dans un débat, donc revenons à ta classe:
-Le code est assez clair, et les fonctions explicites
-Les fonctions sont de 2 types: il y a de la gestion globale d'image(recadrage, constraste) et puis interne(texte).
=>J'avais plus approfondi le texte car on peut voir que ttfbox ne renvoie pas souvent le même valeur pour l'ordonnée du point haut gauche et haut droite. De même avec la rotation, il faut modifier différemment l'ordonnée.

...
Je sens que je vais poster ma classe ... Trop de choses à dire ...
...

Pour les commentaires, je déteste ce genre à la /* * */, surtout avec les @access public, alors qu'il suffit de savoir lire qqs lignes plus bas. Il est parfois utile de préciser le type, mais je trouve plus simple de mettre des noms explicites et de mettre ça en une ligne en dessous de la première ligne de fonction:
public function fill_arc(Point $p, $w, $h, $start, $end, $color, $style)
{//filled arc(Point $origin, int $width, int $height, float $start_angle, float $end_angle, color $color, IMG_ARC_ CONSTANT(PIE,CHORD,NOFILL,EDGED) $style)

Pour les types d'images, en 1 switch:
switch(strtolower(substr($name, -3, 3)))
{
case 'jpg':
case 'peg':
ImageJpeg($this->img, $name, 100*$quality);
break;
case 'gif':
ImageGif($this->img, $name);
break;
case 'png':
ImagePng($this->img, $name, 9*(1-$quality));
break;
}

Quand aux idées de factory, p-e si les librairies sont proches, mais entre SVG et GD, ce n'est pas vraiment possible, le style est défini de manière bien différente.

Bon dès que j'ai le temps de commenter un peu, je poste ma classe ;)

Pour ceux qui sont trop fainéants pour tester ça , ça donne:
0111

Donc, la variable $a n'est incrémentée qu'après son affichage.

En simple(juste pour retenir), lisez de gauche à droite^^.
echo $a++; = echo $a; $a++;
tandis que
echo ++$b; = $b++; echo $b;

Moi je dit vive l'indent personnel^^
Car il y a toujours des exceptions, genre des conditions qu'on veux à peine mentionner et qu'on met sur une ligne, un texte que l'on met directement contre le bord(toujours le cas en heredoc), un saut à la ligne pour repérer des CR ou LF, une arborescence où l'on veut l'élément racine contre la marge, ...

Mais sinon ça doit surement être un bon exercice de parsing :p
Bon codage
P.S.:'deux paramètres la directoire et le nom du fichier' -> '2 paramètres : le dossier et le fichier' ;) (pourquoi séparer ces paramètres?)

Mon problème est qu'en fait j'ai une boucle basée sur les degrés de rotation. Voici le code,ce sera plus simple:

deg=valeur d'un degré
rotation = cmb de degrés de l'angle ont été faits

function rotate(sens)
{
for( var rotation = 0; rotation <= angle; rotation += deg )
{
//modification des attributs top et left des images avec comme parametre externe: rotation(pour els fonctions sin et cos)
->>>sleep(250);//la j'aimerait attendre environ .25s ou 250ms
}


}