Hello,
 
Je fais actuellement des graphiques dynamique en SVG (en C#...).
 
Comme SVG 1.1 ne supporte pas (encore) le word wrapping, je me demandais si qqn avait déjà eu ce genre de problème.
 
C'est à dire, si je veux faire des lignes de 15 caractères maximum, si un espace n'est pas trouvé dans cet interval, je coupe le mot, mais de façon correcte au niveau grammaticale
 
Voilà quoi si vous avez une idée

je dois pte avoir ca en stoc, donne moi un moyen de te contacter

je t'ai envoyé mon mail en privé. Mais tu pourrais en faire profiter tout le monde  

J'ai eu affaire à ça récemment pour mon projet: http://www.doomeer.com/plop/wc2.zip ...
J'ai codé ça à peu près comme ceci:
- si le texte n'est pas trop grand, on l'écrit
- sinon, on récupère (je crois avoir fait ça par recherche dichotomique) le dernier caractère affichable
- on recule ensuite pour trouver le dernier espace avant ce dernier caractère affichable (notons le DCA)
- si cet espace existe, on récupère la partie gauche
- si la partie gauche est vide (avec trim(s) = '' par exemple) alors tant pis, on dessine jusqu'à DCA inclus
- sinon on dessine la partie gauche
- si l'espace n'existe pas, on dessine jusqu'à DCA inclus
- on va à la ligne et on relance (récursivité par exemple?) pour la suite (à droite de DCA ou de l'espace)
 
Voilà j'ai ptet oublié quelques cas particuliers mais le principe est là.

On doit pouvoir raffiner un peu en cherchant le meilleur endroit pour couper si il n'y a pas d'espace : par exemple détecter les consonnes doubles, ou les enchainements consonne-voyelle...

bon la coupure de phrases c'est hypra simple. Moi je cherche plutôt un dictionnaire capable de COUPER les mots au bon endroits.  
 
Merci quand même

Knuth a fait une série de bouquins sur le traitement de textes quand il a fait TeX.
L'autre bonne nouvelle, c'est que TeX (avec les trucs additonnels qui vont bien) dispose d'un dico des mots chiants à couper.

Je confirme: tu regardes l'implem de Knuth dans TeX et tu l'adaptes a tes besoins. Ou tu vas voir ce qu'ont fait les gens de l'Irisa, par exemple dans le code de Amaya (si mes souvenirs sont bons).
A+,

Google non ?
 
http://www.unimedia.fr/homepage/di [...] pao_23.htm

Notamment cette partie :
 

A noter ça :
 

 
Mais là, ça demande un dictionnaire.
 
Par contre, celles-ci sont plus aisément applicables sans dico :
 

L'hyphenation ne se resume pas a quelques regles simples helas. J'ai un bouquin d'une cinquantaine de pages sur le sujet.
De plus tous les lexicographes ne sont pas necessairement d'accord entre eux.
Le systeme de Knuth, relativement bien efficace utilise des patterns (avec des poids?) pour calculer la meilleure coupure possible. De plus c'est complete par un dictionnaire pour des exceptions.
Je connaissais bien le sujet et l'algo il y a 10 ans, mais j'ai tout oublie depuis.
A+,

Je pense que dans un premier temps, les quelques règles du lien que j'ai trouvé devraient suffir. Y'a de quoi traîter 95% des cas.

Autrement dit, pourquoi se compliquer a comprendre un excellent algorithme qui a fait ses preuves quand on peut en hacker un qui aura 5% d'erreurs...
A+,

Bah je sais pas dans quel sens tu dis ça, mais grossomodo, pour moi, c'est bien simple :
-> Avec les règles ci-dessus, JagStang qui est loin d'être un cuistre doit pouvoir pondre une fonction basée sur des expressions régulières uniquement (donc très performant) en moins d'une heure.
-> Pour l'utilisation qu'il en a (juste couper des mots dans une image, quand, cas très improbable, il y a un mot de plus de 15 caractères dans l'image). La césure sera donc utilisée de façon très marginale. A partir de là, il est normal de ne pas y consacrer trop de temps, afin de se concentrer sur les parties importantes du programme.
-> Donc, en l'absence de mieu et tout fait, cet algo me semble un excellent compromis, car à la fois efficace dans la plupart des cas, et rapide à mettre en place.
 
Regarde simplement la fenête de Windows 2000 au chargement. T'as une jolie bande bleue dégradé qui se scroll pendant le chargement.
M$ avait deux choix pour faire ça :
-> Un super truc accéléré DPlay avec un moteur de rendu digne d'un jeu
-> Un pauvre BMP qu'on déplace sur le côté en boucle.
 
Ben vu que ce truc est utilisé uniquement à ce moment précis, ils ont opté pour la seconde solution. Elle est minable, mais a l'avantage d'être faisable en 2 minutes, exempte de risque de bug, et donne la même résultat (c'est vrai, quand on est en affichage 32bits, on voit que le dégradé n'est pas parfait )
 
Enfin voilà quoi Je pense que le premier boulot du développeur c'est de faire le compromis entre les outils qu'il a, afin de choisir le meilleur rapport efficacité/coût/complexité.
 
Evidement, s'il faisait un outils de mise en forme de documents en vue d'une impression, la césure serait bien plus importante. Mais là... L'utilisateur peut toujours contourner un éventuel bug en insérrant un espace là où il veut que la césure se fasse. Donc même dans le pire des cas, les éventuelles limitation de l'algo sont contournable.
 
A noter qu'à chaque fois que je bosse dans Word et que j'active la césure automatique, je passe mon temps à refaire des césures à la main, car même avec un moteur certainement bien plus poussé, c'est loin d'être parfait. Le sens du mot et son poids dans la phrase influent énorménent sur l'emplacement de la césure, donc quelque soit l'algo (mise à part un algo grammatical IA, mais c'est pas encore suffisament au point) il y aura toujours des imperfections.

 
Oui c'est clair, c'est juste un optimisation. Mais pas vital pour le moment
 
Merci à tous en tout cas

J'en deduis que MagicBuzz a bien compris l'evolution de l'architecture logicielle de ces dernieres années et en particulier la notion de refactoring...
 
Pourquoi faire un truc bien fait une fois pour toute et qu'on reutilisera, si on peut a la place hacker un truc qui marchotte et ne pourra pas etre reemployé le jour ou on aura besoin d'un truc un peu plus performant, dans un contexte different.
A+,

Je vois pas ce que viens faire ce troll ici.
 
A ce compte, t'as pas fini, y'a toujours mieu pour faire n'importe quoi. Sauf qu'à un moment faut savoir s'arrêter.
 
Si JagStang décide de faire un truc nickel, il pourra toujours le faire dans une V2. Pas la peine de passer 6 mois sur un truc qui sera jamais utilisé. Ce serait le corps du programme encore, je dis pas, mais là franchement, c'est comme passer 2 semaines pour faire un curseur de souris semi-transparent dans un OS. L'utilisateur final, il s'en bat les couilles, et le verra certainement peut-être jamais ! Pas la peine de perdre du temps là dessus. Quand on envoie une fusée dans l'espace, on passe pas 2 ans à choisir la couleur de la peinture. On se contente d'en rpendre une qui va résister aux conditions spaciale, c'est tout.

C'est clair qu'avoir un truc tip top en ordre serait l'idéal. Mais bon, c'est un peu hors cadre du projet. Je peux pas me permettre d'utiliser 20% ou 30% du temps du module dans ce genre d'optimisation.
 
Pour le moment ça suffit pour le client...
 
Toutefois, je garde l'idée et dès que j'ai un peu le temps de faire ça pour moi je m'y mettrais
 
 

Mais c'est vrai : "La bidouille commence là ou s'arrête le budget du projet"

Moi, les codeurs qui savent mieux que l'utilisateur final ce dont il a besoin  
J'ai pas dit qu'il avait a passer 6 mois a reecrire un algo nouveau, j'ai dit que ce qu'il cherchait ca existait deja, que ca avait ete largement teste par une foule d'utilisateurs depuis au moins 10 ans, qui en etaient satisfait, et qu'il avait qu'a aller en voir les implems existantes afin de voir ce qu'il pouvait reeutiliser.
 
Et la couleur de la fusée si elle est bien choisie (par exemple un drapeau ricain bien visible) ca peut influer sur le vote d'un senateur lors de la reconduction du budget de la NASA.
C'est donc quelque chose qui ne sera certainement pas base que sur des choix techniques.
[Si on se basait uniquement sur des choix techniques, le pont de Brooklyn serait de la meme couleur orangée que le golden gate, lequel emploie a qualite egale, la couleur la moins chere].
A+,

 
un des gros problème en info actuellement

Gilou m'a volé l'idée, mais je pensais aussi à l'algo de Knuth...qui pour rappel est celui de TeX...et qui est aussi présent dans OOo 1.1.0...
 
c l'algo le plus respectueux de la grammaire...et il est tweakable selon les langues...