Discussion :

[olkis]

Bonjour à tous,

j'ai fais un programme qui me trace des courbes (sur un canvas, logique) et j'aimerais pouvoir permettre à l'utilisateur de pouvoir enregistrer le canvas en image (jpg, bmp ou n'importe quoi).

Alors je sais qu'il n'existe pas de classe de base de Java permettant de faire ça... si vous connaissez une astuce, ou un programme qui permet de le faire...... !

[bouye]

Mais si ca existe ca s'appelle javax.imagio.ImageIO. Regarde la doc pour voir les formats supportés.
Et si tu as une JVM ancienne sans ImageIO, tu as quand même un encodeur JPEG fournis avec.

Basiquement, tu crée une BufferedImage et tu passe le Graphics de cette image à la méthode paint() de ton canvas. Puis tu sauvegardes l'image avec ImageIO au format approprié.

[bouye]

Et pour des format autres que ceux supportés par ImageIO, tu peux essayer le Java Advanced Imaging de Sun, Batik ou FreeHep.

[olkis]

ok, j'obtient :

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
 
class ....
 
static JButton Sauver = ...;
static Image img;
 
Sauver.addActionListener(...
 
try{
Rectangle r = RepereCartesien.getBounds();
img = RepereCartesien.createImage(r.width,r.height);
Graphics g = img.getGraphics();
ImageIO.write((RenderedImage)img,"png",new File("c:\\temp.png"));
}
catch(..){...}
 
class Cartesien extends Canvas
{
Cartesien(){}
 
public void paint (Graphics g)
{
...
...
g.drawImage(img,0,0,this);
}
}

il m'enregistre bien mon png, mais c une image blanche (de bonne dimension) avec rien dedans (ce qu'il y a de tracé dans le canvas)...[/quote]

[Gfx]

Tu ne dis nulle part de peindre ton canvas. Apres Graphics g = img.getGraphics(); rajoute RepereCartesien.paint(g).

[bouye]

Je cherche à exporter le graphique obtenu pour l'imprimer ou l'enregistrer (format JPG, PNG, BMP) et surtout l'enregistrer en PostScript pour une utilisation sous LaTeX. Si vous avez des idées !

Si tu es sous UNIX/Linux tu peux rajouter facilement un export PostScript en rajoutant la possibilite d'imprimer a ton programme. En effet sous UN*X, la boite de dialogue d'impression te donne le choix de generer un fichier PS.

Il te faudra creer un objet implementant l'interface Printable dans lequel tu feras les translations et rotations appropriees pour mettre l'origine du Graphics recut par la methode int print(Graphics graphics, PageFormat pageFormat, int pageIndex) au bon endroit (en fonction de la taille, marges et de l'orientation de la feuille de papier). Puis tu passes ce Graphics a la methode print() ou paint() de ton Canvas (exactement comme pour l'export en image). Attention alors que pour l'image tu crees une bitmap a la bonne taile, la taille de la page, elle, ne sera bien evidement pas a la meme taille que le Canvas. Des ajustement seront donc necessaires.

Ensuite l'impression basique est assez simple.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
import java.awt.print.*;
 
...
 
if (printable != null) {
 PrinterJob printJob = PrinterJob.getPrinterJob();
 printJob.setPrintable(printable);
 if (printJob.printDialog()) {
   printJob.print();
 }
}

Mais en regardant l'API d'impression tu verras qu'il t'es possible de specifier toi-meme le format de la page (taille, orientation, taille des marges, ....). Tu peux nottement te definir un nouveau Paper a la taille du Canvas, n'ayant pas de marge et en orientation PORTRAIT. ... Evidement pas question d'essayer d'imprimer sur l'imprimante avec.......

Code :

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

1
2
3
4
5
6
 
Paper paper = new Paper(); 
paper.setImageableArea(0, 0, width, height); 
PageFormat format = new PageFormat(); 
format.setPaper(paper);
...

Sinon pour unes gestion du support du PostScript plus classique et dans la lignee des formats d'images habituels voit avec la bibliotheque VectorGraphics du projet FreeHep.

[olkis]

Tu ne dis nulle part de peindre ton canvas. Apres Graphics g = img.getGraphics(); rajoute RepereCartesien.paint(g).

nikel ça marche merci, j'ai simplement du rajouter

Code :

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

1
2
3
4
5
 
...
RepereCartesien.paint(g);
ImageIO.write((RenderedImage)img,"png",new File("c:\\temp.png"));
img = null;

sinon il me gardait en mémoire l'image sur le canvas, cad qd je mettais à jour le canvas, img se superposait dessus. donc un grand merci !

bouye, je vais regarder ça demain !

[bouye]

sinon il me gardait en mémoire l'image sur le canvas, cad qd je mettais à jour le canvas, img se superposait dessus.

Non : sinon rien n'etait dessine dans l'image (qui restait vide). L'image creee par createImage() n'est en rien liee au Canvas ; c'est juste un reliquat de l'AWT du temps ou il n'y avait pas de methodes directe pour creer et manipuler des images ni de classe BufferedImage (Java 1.0 et 1.1). Il faut donc dessiner dedans manuellement (ce que l'appel a paint() fait).

Quand le canvas se met a jour et bien il est dessine sur l'ecran quand paint() est appelee par le repaint manager de Swing/AWT (qui appelle lui-meme paint() avec sa propre instance de Graphics qui correspond grosso-modo a l'ecran). En simplifiant beaucoup et en oubliant un peu l'arborescence formee par les composants...

bouye, je vais regarder ça demain !

Et puis d'abord moi je suis deja demain na ; et gfx il est hier (puisque aux USA)...

EDIT - Pfff encore lu trop vite pour pas changer moi... dans ton paint(), enleve cette ligne-la g.drawImage(img,0,0,this);. Ce que tu veux faire c'est peindre le Canvas dans l'image, pas peindre l'image dans le Canvas.

Quand a la variable img elle peut rester une variable locale a la methode de sauvegarde dans un fichier, pas la peine d'en faire un membre. Tu ne l'utilises pas ailleurs cette image ?

Egalement es-tu sur que ton bouton a vraiment besoin d'etre static ?

[olkis]

oui tu as raison, img suffit à etre en local.
mais l'histoire des static, mon JButton fé parti d'une class, faisant elle mm parti d'une autre class (c ds cette derniere que je déclare mes variables, elles ont donc besoin d'etre en static.. non?)

[bouye]

Pas forcement non, les classes internes n'ont pas toujours besoin d'être statiques.

Par contre avoir trop de classe internes imbriquées les unes dans les autres ça peut annonce un pb dans l'architecture. Egalement plutôt que de faire des classes dans des classes dans des classes, dans ..... tu peux probablement deplacer toute ou une partie du code dans des fichiers séparés avec visibilité restreinte au package (dans ce cas ne pas mettre de mot-clé de visu (public/protected/private) devant le descriptif de la classe) et/ou en fusionnant des classes qui ne servent qu'à implémenter des interfaces (puisqu'une classe peut implementer plusieurs interfaces).