@red man
Salut,

Non, aucun algo de dimensionnement dans ma lib.

Dans la librairie java standard, je vois 3 méthodes possibles (il y en a peut-être d'autres):
- utiliser Graphics2D en lui disant d'utiliser une interpolation bicubique (voir RenderingHints), probablement la meilleure solution
- la méthode getScaledInstance de Image qui a une qualité correcte avec SCALE_SMOOTH, le résultat plait à l'½il
- la classe AffineTransform, moche

voir aussi http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html notamment la partie multi steps

il y a certainement des librairies qui proposent des bonnes solutions.

Mis à jour. tu peux retenter le filtre FiltreColoriser.
Son résultat fait plus naturel et devrait conserver les blancs

@Audrey

Salut,

et ça fait un bail que j'ai codé ça ;)
Non, en effet, il n'y a pas de quoi faire ce que tu veux dans la source.

Je vais poster une mise à jour tout à l'heure ou demain, avec des nouvelles fonctions de conversion entre RGB/HSV, et rajouter des conversions RGB/HSL (les fonctions que j'avais écrite à l'époque ont l'air vraiment limite au niveau de la qualité).
Puis changer le filtre FiltreColoriser pour qu'il utilise le domaine HSL et non pas HSV. ça devrait donner un résultat bien plus utilisable et conserver les blancs.

si PrinterJob est devenu utilisable, oui, c'est 100x plus simple :)

J'ai comme un doute sur pourquoi j'avais fait ce programme, en voyant que pageDialog et printDialog existent depuis Java 1.4 :)
Je sais en tout cas qu'il me faisait des impressions dégueulasses et qu'il déconnait complètement pour les résolutions d'impressions alors que ça passait sans problème avec PrintJob...

@alex198710

Salut,
Non, je n'ai pas touché à ce code depuis 5 ans maintenant.
Je ne sais pas où en est Java pour les impressions 5 ans plus tard :)

Pour la taille des pages, j'imagine qu'il faudrait plutôt prévoir un dialogue "Mise en Page" dans l'application principale, et donner les dimensions et l'orientation du papier en argument à ce dialogue là...
De toute façon, il faudrait aussi refaire complètement le dialogue avec autre chose que GridBagLayout pour qu'il soit plus souple et plus facilement modifiable.

Je n'ai pas vraiment le temps de refaire ça, et je n'ai pas d'imprimante actuellement (encore pire, je n'ai pas de système d'impression sur ce pc :))

oups, oui, tu bosses côté client.
(c'est ça de poster aussi "tôt" un weekend :))

Enfin, c'est la même chose.

tu peux aussi créer des pseudos fichiers avec makefile,
en lecture et/ou en écriture suivant les arguments
(wfile = sock.makefile("wb", 0) par exemple pour un pseudo fichier en écriture)

pour HTTP 0.9 :
tu lis tant que tu peux, cad juste la méthode read du pseudo fichier, sans donner d'argument size, qui lira jusqu'à EOF

pour les autres,
tu lis ligne par ligne la version, code réponse, etc., puis les entêtes jusqu'à trouver une ligne blanche
et tu peux utiliser le champ content-length si il est là, ou sinon, tu lis aussi jusqu'au bout.

bonne prog.

ok.
j'espère que ce que je vais dire est juste, j'ai jamais testé et  :)


autant que je sache, la méthode readline qu'ils ont fait utilise son buffer pour faire abstraction des trames TCP.
ça doit être un truc du genre :
recv, regarde si il y a un \n (LF) dedans, si oui, coupe au \n, retourne la 1ère partie, conserve la 2nde
sinon, recv à nouveau.

donc 1er readline : commande HTTP, chemin, version
readlines suivant : tous les entêtes, jusqu'à rencontrer une ligne vide

puis lecture du corps de la requête (là, ça va dépendre de la version d'HTTP)


pour le test if not data: break,
il semble que quand le client ferme sa socket, recv retourne "", un paquet vide.
si tu ne gères pas les connexions persistantes, ça doit être bon.

ça doit fonctionner quelque soit le nombre de trames utilisées par le client :)


"car on veut éviter de faire appel à cette fonction si on n'a plus rien à recevoir (et donc éviter qu'elle attende dans le vide)"
=> d'où l'intérêt d'utiliser des threads, pour ne plus avoir cette limitation :)
t'attends que ton client ferme tranquillement sa socket, et hop. ton thread gérant la requête se termine.

Pour info, les objets sockets en python contiennent déjà de quoi faire ce genre de lecture.
tu as une méthode makefile pour créer des objets type fichier, qui travaille sur des buffers.

s.bind((HOST, PORT))
s.listen(1)
conn, addr = s.accept()

# pseudo fichier en lecture, binaire, buffer taille par défaut du système
rfile = conn.makefile('rb', -1)

while 1:
    data = rfile.readline()
    if not data: break
    print data

readline retourne bien la chaîne jusqu'au premier \n rencontré, et non pas juste à la fin de ce que te retourne recv

Hum, d'ailleurs, je crois qu'il y a une conn**** dans les filtres de convolution dans ma source, que j'ai jamais dû corriger...
La formule doit être un peu en vrac (c'est pas une convolution, mais c'est pas trop loin, en gros ;))

Salut,

une source que j'avais fait il y a quelques années : http://www.javafr.com/codes/FILTRES-POUR-IMAGES_23733.aspx
ça ne passe pas par RGBImageFilter (volontairement je crois ;) ça devait être pour pouvoir suivre l'avancement des filtres, et pour faire d'autres types de filtrage).
Il y a sans doute quelques filtres récupérables dedans.

Sinon, ça fait plaisir de voir des logos Gentoo sur ce site ^^ (une ptite update de la source avec Larry The Cow en plus pour l'exemple :D :D ? http://www.gentoo.org/images/szbence-badge6.png)