Discussion :

[zolotaya]

Bonjour à tous,

J'ai un problème et je ne sais pas trop comment m'y prendre. Je viens donc ici avant tout pour avoir des pistes de reflections et des idées pour la réalisation.

Je souhaite pouvoir associé des images à des mots dans un editeur de texte simple.
J'ai donc d'un coter un ensemble d'images dans un repertoire (ex : chat.jpeg, chien.png, java.jpg, duke.png); de l'autre ma jtextArea.

Ce que je souhaite faire c'est :

Quand un mot saisie dans la JTextArea est présent dans le repertoire (ex : chat) l'image du chat apparait au dessus du mot saisie.

Garder tous mots alignés de façon à pouvoir lire correctement le texte saisie

Pouvoir continuer à éditer mon texte "normalement"

Quelqu'un aurait'il une idée pour faire cela ?

Je vous remercie par avances pour vos idées.
Guillaume

[joel.drigo]

Salut,

Déjà, à mon avis, oublie le JTextArea : la gestion du document est associée à l'UI et ne laisse que peu de latitudes pour personnaliser. Opte plutôt pour JEditorPane, ou à la rigueur un JTextPane.

Il y plusieurs aspects à considérer :

1. Traiter la frappe au fur et à mesure (détecter les ajouts de mots, modifications ou suppressions) : voir la classe DocumentFilter
2. Repérer les mots et leur associer une image
   
   • le plus simple étant de faire de la concaténation entre un chemin de dossier et un mot, et de chercher si un fichier existe avec une extension dans une liste fixée (jpg, jpeg, png...)
   • mais si on doit associer au mot "chats" l'image "chat.jpeg", ceci ne fonctionne plus. Et encore moins si en tapant "canard", ou "colvert", on doit afficher "duck.png" !
     
     • On peut résoudre ça par exemple en ajoutant des mots clefs à l'image (dans les métadatas), ou dans un fichier à part (xml par exemple), et en indexant les chemins de fichier image en mémoire sur ces mots (dans des Map par exemple).
     • Plus overkill peut-être,, intégrer un moteur de recherche, style lucène (qui traitera facilement les pluriels, les genres, les synonymes...), ou elasticsearch (je n'ai jamais pratiqué, donc je ne sais pas si on peut l'embarquer facilement ?)...
3. Intégrer une image dans le texte, sans modifier la présentation du texte
   A priori, je ne sais pas quel est plus simple parmi les différentes options qui se présentent :
   
   • traiter le tout en StyledDocument : la difficulté étant de ne pas perturber l'alignement et la justification, donc à priori, déterminer la largeur du mot dans ses polices et styles, et faire que l'image ait cette largeur (y compris si le style ou la police change à posteriori).
   • utiliser le format HTML. Utiliser le format html peut peut-être aider à gérer automatiquement l'alignement : il faudrait que tu testes d'abord avec un fichier html fixe et des styles (en se limitant au niveau de css que le JEditorPane sait traiter naturellement, sinon tu seras obligé de le modifier, ou de prendre une API qui le traite). A partir du moment où tu réussi à le faire en html statique, tu pourras commencer à le faire avec un JEditorPane avec contenu text/html.
   • Personnellement, pour avoir fait des choses similaires, je partirais directement sur une solution avec JEditorPane, mes propres EditorKit et ViewFactory, pour gérer mon propre format, et utiliser mon propre javax.swing.text.View pour afficher et surtout dimensionner l'image par rapport au texte. Commence donc par regarder comment tout ça fonctionne et comment on peut le personnaliser
   
   A noter toutefois qu'un problème peut se poser pour les petits mots : l'image risque d'être très étroite (la solution peut être d'opter pour une autre solution (comme les tooltips par exemple), voire combiner plusieurs solutions).
4. Faire que çà ne dérange pas la frappe : ce n'est pas le plus difficile, à priori. Il faut juste replacer la vue pour que le curseur ne bouge pas à l'insertion d'une image: commencer par regarder JViewPort.scrollRectToVisible().

[zolotaya]

Bonjour Joel,

Merci pour ta réponse.
Je ne connaisais pas la classe DocumentFilter, je pense en effet qu'elle me sera fort utile!
Pour le point 2, je pense partir directement sur une map <mot> <image> avec soit mes imageIcon pré-chargé lors du lancement de l'application, soit les chemins vers les images. Je testerai et ferai mon choix en fonction de la mémoire utilisé et du nombre de mot chargés. Je pense qu'il ne devrait pas y en avoir des milliers. Dans tous les cas, je reseterai sur le cas classique : canard != canards != colvert ...

Je t'ai mis une image du résultat que je souhaiterai obtenir (pour être sur d'être bien compris).


L'idée est donc d'avoir une zone de saisie (la zone blanche) et une zone ou s'affiche les images (les images seront forcément de petite taille). Si l'image est plus large que le mot, l'image est centré dans sa zone, si le mot est plus large, c'est l'image qui est centrée.

L'avantage de partir sur du HTML est je pense la possibilié de personnalisation et le fait que ce soit "assez simple". J'ai juste encore un peu de mal à voir comment je peux traiter le texte à la volée à savoir transformer un mot genre "chat" en une structure HTML du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<div span=mot><div span=image><img src=chat.jpeg /></div><div span=texte>chat</div></div>

et à gérer les séparateurs de mots (ici espace, apostrophe, point, virgule ...).

Juste pour savoir si j'ai bien compris le principe, c'est bien cette partie de transformation du texte que je peux déporter dans mes propres EditorKit / ViewFactory ?

Guillaume.

[joel.drigo]

L'avantage de partir sur du HTML est je pense la possibilié de personnalisation et le fait que ce soit "assez simple". J'ai juste encore un peu de mal à voir comment je peux traiter le texte à la volée à savoir transformer un mot genre "chat" en une structure HTML du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<div span=mot><div span=image><img src=chat.jpeg /></div><div span=texte>chat</div></div>

et à gérer les séparateurs de mots (ici espace, apostrophe, point, virgule ...).

Juste pour savoir si j'ai bien compris le principe, c'est bien cette partie de transformation du texte que je peux déporter dans mes propres EditorKit / ViewFactory ?

En fait je parlais de EditorKit/ViewFactory pour faire ton propre format/modèle. Java fournit déjà un HtmlEditorKit : simplement il est limité (je ne sais plus quel version de html, la 3 peut être bien, et les css, la 1 à priori, et encore, ça marche surtout lorsque les styles sont dans l'attribut style il me semble) Mais on peut partir de HTMLEditorKit pour l'adapter et gérer la version de html/css qu'on veut (c'est une implémentation comme ça que j'utilise moi-même dans l'application que je développe professionnellement (un éditeur html en fait), et que j'étends justement pour traiter les tags object qui ne sont pas traités nativement ).

Le problème avec html/css (pour le coup, je maîtrise beaucoup moins - pas assez en tout cas pour savoir faire la présentation que tu recherches sans y réfléchir et faire des essais - et probablement que si j'avais à le faire professionnellement je le demanderais à mes collègues dont c'est le métier),

1. peut-on faire la présentation que tu souhaites (et avec quoi : html span, div, img ? css ? quelle version de css ? etc...)
2. est-ce que ce dont on a besoin est supporté directement par le HTMLEditorKit ou faut il l'étendre (ajouter des View) ? Peut-on étendre des View déjà existantes (mieux, et très probable), ou faut-il faire une vue à zéro (beaucoup de boulot pour tout bien gérer).

En tout cas tout ce qui est caractère est déjà traité par le HTMLEditorKit : les P, les SPAN, les DIV, les IMG c'est sûr. C'est surtout sur les attributs css d'alignement un peu particulier que je suis dans le doute.
Le plus simple étant de faire le doc HTML et de l'afficher dans un JEditorPane : tu verras tout de suite ce que ça donne. Ensuite, va voir le source de HTMLEditorKit.HTMLFactory.createView(Element) pour voir ce qui est géré en matière de tag html, ce qui te permettra de voir les classes utilisés pour le View, et de voir qu'est-ce qu'il manque et comment l'implémenter rapidement pour avoir la présentation que tu cherches à avoir.

[zolotaya]

Merci beaucoup pour ces précisions.
Je passe la discussion en résolu même si je commence tout juste à voir comment faire mais je pense avoir les informations et pistes princpales.
Je viendrai compléter quand j'aurai réussi à m'approcher du résultat souhaité ou j'ouvrirai une/des nouvelles discussions si je rencontre des problèmes lors de l'implémentation.

Guillaume.

[joel.drigo]

Salut,

J'ai fait un petit poc pour illustrer la solution à base de mon propre format (editorkit/viewfactory personalisé), en Java 8. Ce n'est pas complètement au point, mais c'est pour voir le principe.

[zolotaya]

Wahou, c'est bien à un résultat dans ce genre que je voulais arriver !

Merci beaucoup! Je vais commencer à étudier ça de plus pret.

Guillaume.

[joel.drigo]

Voilà une version du GlyphPainter avec un look plus proche que ce que tu recherchais et une correction du bug graphique de la sélection. Ne te reste plus qu'à faire tout l'aspect gestion des styles. Pour découper le texte en morceau indépendant, je découpe le texte en mot, et j'affecte une instance de style (AttributeSet) différent à chacun : c'est ça qui permet d'avoir des LabelView séparés pour chaque mot. Dans mon code, j'écrase les styles d'origine par les miens (à la frappe, via le DocumentFilter), en forçant la police d'ailleurs, donc si on voulait gérer des styles sur le texte, il faudrait faire la copie des attributs d'origine (ceux qui concernent les styles de texte, comme gras, italique, couleurs, attributs de police, etc...) dans le style d'écrasement.

[zolotaya]

Hello Joel,

Je reviens vers toi car j'ai un "bug" que je n'arrive pas à résoudre.
Quand je supprime un espace avant un mot (exemple avant le mot "chat") j'ai mes deux mots qui sont chacun dans leurs "panel".
Si je regarde au niveau de la classe ImageFlowEditor, j'ai bien ma liste de token de la bonne taille avec mon mot "unchat".
Dans le classe ImageFlowEditorViewFactory, je passe bien dans la méthode create avec les offsets suivant pour mon element : begin-> 7 end -> 11 ce qui est cohérent avec l'espace supprimé.

Cependant lors du dessin dans la classe ImageFlowGlyphPainter les elements suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int s0=imageFlowLabelView.getStartOffset();
int s1=imageFlowLabelView.getEndOffset();

vont me retourner les positions de "un" puis de "chat" séparément. J'ai donc le visuel de deux mots séparés.
J'ai l'impression qu'il essai de redessiner chacun de ces deux panel au lieu de les fusionner.

A noter que je n'ai pas de problème si je supprime sur l'action d'après je supprime le "n".
Je n'arrive pas à trouver comment corriger ce problème. Peux-tu me donner une piste stp ?
Merci par avance

Guillaume.

[joel.drigo]

Salut,

Ce bug vient d'une limite du fonctionnement du DefaultStyledDocument dû au fonctionnement standard. C'est un raccourci pris par ce qui ont écrit le composant : je ne leur jette pas la pierre, car le workaround que je vais te proposer est du même acabit...

En fait, le principe est que le StyledDocument :

• découpe le texte en éléments ;
• découpe le texte selon les différences de styles et les passages à la ligne (et éventuellement d'autres conditions, lorsqu'on a autre chose que du texte...image, composant, etc.).

J'ai utilisé ce mode de fonctionnement pour mettre en place mon découpage : à chaque élément correspond un LabelView. Donc je découpe de manière à avoir un style par mot. Par contre, ce qui n'est pas standard, c'est dessiner des trucs à gauche et à droite, et en particulier changer les marges. J'ai donc fait une bidouille en modifiant la taille du LabelView et en décalant pour dessiner les caractères au bon endroit, dans le LabelView. Je n'ai d'ailleurs rien fait pour l'affichage du curseur, et il d'affiche de façon bizarre lorsqu'on est entre 2 éléments.

En ce qui concerne le modèle (les éléments), le StyledDocument n'implémente que le découpage d'éléments en plusieurs éléments, lorsqu'on applique un style à une partie d'un élément, mais pas la fusion d'éléments lorsqu'on applique un seul style sur plusieurs éléments : dans ce cas, il découpe le style. Du coup, lorsqu'on supprime une espace entre 2 mots, là on devrait fusionner 2 éléments pour n'en faire plus qu'un (puisqu'on ne génère qu'un style), on se retrouve avec 2 éléments : en plus, comme on insère avant le second, on se retrouve toujours avec 2 éléments au lieu d'un, et on peut se retrouver avec plusieurs éléments de 1 caractère si on tape plusieurs caractères de suite.

Le HtmlDocument doit gérer la fusion, je pense, mais ce serait beaucoup de travail de tout refaire en HTML, même si c'est quand même la solution la plus propre globalement, et qui devrait nous permettre de gérer un curseur moins bizarre. Soit. Là, aussi, il y a une bidouille. Pour le stylage, j'ai déjà choisi de me faciliter le travail en restylant le document entier, plutôt que de déterminer comment fusionner/découper localement les styles de ce qu'on modifie dans le DocumentFilter. On va faire exactement pareil, mais pour l'insertion des caractères : on va tout supprimer, puis réinsérer ce qu'il faut. On aura juste à gérer la position de curseur (caret).

Donc voici le nouveau DocumentFilter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
((AbstractDocument)editor.getDocument()).setDocumentFilter(new DocumentFilter() {
 
			@Override
			public void insertString(FilterBypass fb, int offset,
					String text, AttributeSet attr)
					throws BadLocationException {
 
				StyledDocument doc = (StyledDocument) fb.getDocument();
				StringBuilder sb = new StringBuilder(doc.getText(0, doc.getLength()));
				sb.insert(offset, text);
 
				applyChanges(fb, doc, sb, offset+text.length());
 
				//super.insertString(fb, offset, text, null);
 
				//applyChanges((StyledDocument) fb.getDocument());
 
			}
 
 
			@Override
			public void remove(FilterBypass fb, int offset, int length)
					throws BadLocationException {
 
				StyledDocument doc = (StyledDocument) fb.getDocument();
				StringBuilder sb = new StringBuilder(doc.getText(0, doc.getLength()));
				sb.replace(offset, offset+length, "");
 
				applyChanges(fb, doc, sb, offset); // 
 
				//super.remove(fb, offset, length);
 
				//applyChanges((StyledDocument) fb.getDocument());
 
			}
 
			@Override
			public void replace(FilterBypass fb, int offset, int length,
					String text, AttributeSet attrs)
					throws BadLocationException {
 
				StyledDocument doc = (StyledDocument) fb.getDocument();
				StringBuilder sb = new StringBuilder(doc.getText(0, doc.getLength()));
				sb.replace(offset, offset+length, text);
 
				applyChanges(fb, doc, sb, offset+text.length() );
 
				//super.replace(fb, offset, length, text, null);
 
				//applyChanges((StyledDocument) fb.getDocument());
 
			}
 
			private void applyChanges(FilterBypass fb, StyledDocument doc,
					StringBuilder sb, int caretOffset) throws BadLocationException { 
				fb.remove(0, doc.getLength());
				fb.insertString(0, sb.toString(), null); 
				editor.setCaretPosition(caretOffset);
				applyChanges(doc);
			}
 
			private void applyChanges(StyledDocument doc) throws BadLocationException {
 
 
				String wholetext = doc.getText(0,doc.getLength());
				List<Token> tokens = parse(wholetext) ;
				int offset=0;
				for(Token token : tokens) {   
					setAttributes(doc, offset, token.length());
					offset+=token.length();
				}
 
			}
 
		});

[joel.drigo]

J'ai encore amélioré le rendu, en faisant que les lignes vides courent sur toute la largeur (y compris quand le texte est vide), ainsi qu'aucune ligne verticale ne s'affiche sur les lignes vides.

[zolotaya]

Bonjour Joel,

Merci pour ces précisions.
Je ne connaissais pas le fonctionnement du StyledDocument. Tu as trouvé ou ces infos ?

Guillaume.

[joel.drigo]

J'ai codéveloppé il y a 10 ans un éditeur de textes InCopy et j'intégre depuis 7 ans un éditeur html, fait à l'origine pour le web, pour la presse. Ça m'a conduit a étudier pas mal de documentations diverses dont j'ai totalement oublié les sources. Mais la majeur partie de ma compréhension du système vient de l'étude des sources Java. C'est souvent par ce moyen qu'on connais le mieux un composant. Aucune documentation parlera du GlyphPainter ou même du GapContent : il n'y a que la lecture du code qui permet de connaitre ces composants. Ainsi que la lecture du code écrit par d'autres.

Tiens, par ailleurs, je me suis amusé ce week-end à intégrer, d'une part, la possibilité d'avoir des GIF animés comme images, et d'autre part la possibilité de rendre scrollable le composant. J'ai également un peu changé le parsing, pour que les caractères de ponctuation soient regroupés : je ne trouve pas terrible d'avoir les points de suspension découpés entre 3 morceaux, ou même les espaces séparées, Je n'ai pas le source au boulot mais je le posterai depuis chez moi dès que possible (en fait, je voulais ajouter la gestion des styles dedans avant).

[joel.drigo]

La version avec gestion des gif animés, du scrolling et parsing différent.