[résolu] Imprimantes, rendu 12 et 24 bits.
8 sujets de 1 à 8 (sur un total de 8)
-
Salut à tous, bonne année et gardez la santé et votre migou.
Par défaut, le printer.device transforme les images en 12bits de la façon suivante suivant colorclass:
– 3 * 4 bits CMY (cyan magenta jaune)
– 3 * 4 + 4 CMY K (cyan magenta jaune noir)
– 3 * 4 RGB (rouge vert bleu)
– 4 K (noir)
Pour voir les capacités de la bestiole il faut faire un dégradé de gris, rouge avec 256 registres et l’imprimer. S’il apparait avec des gradations visibles, ce n’est pas beau, si c’est une trame quasi continue, c’est excellent. (utiliser PPaint, avec rendu normal et rendu 24bits, c’est le programme que j’utilise pour faire mes tests)
La matrice de dispersion utilisée par défaut est 4×4 soit un peu plus de 2000 couleurs distinctes. Or il est possible d’utiliser une matrice 8×8, qui permet de représenter beaucoup plus de nuances. (c’est ce que fait PPaint)
Pour cela il suffit d’utiliser directement la fonction ped_Render de la structure PrinterExtendedData (include:devices/prtbase.h)
Mes problèmes: je n’arrive pas à initialiser correctement la sortie. pour l’instant ça fonctionne uniquement au deuxième coup
1) OpenDevice(printer.device…)
2) je récupére un pointeur sur PD PrinterData et PED PrinterExtendedData.
3) je fais une zolie trame
4) je la passe à ped_Render
5) je retourne à 3 tant que j’ai des lignes à sortir
6) CloseDevice.
Quelqu’un aurait-il déjà essayé de bricoler ped_Render avec plus de succès ??
Ca y est, j’ai trouvé ce qui me pourrissait la vie.
Il faut utiliser « opt nostackcheck » pour compiler sous SASC 6.0.
(sinon le programme fonctionne un fois et plante au deuxième appel… )
Voilà ce que cela donne:
LONG t_width ;
LONG t_height ;
LONG t_currentrow ;
LONG (*oldrender)(LONG, LONG, LONG, LONG) = NULL ;
LONG __saveds PRender(LONG ct, LONG x, LONG y, LONG state)
{
switch (state)
{
case 0 : t_width=x; t_height=y; break ;
case 1 : t_currentrow = y; break ;
}
if (oldrender != NULL) return oldrender(ct, x, y, state) ;
return 0 ;
}
On ouvre le « printer.device » et on récupère les structures PD (Printer Data) et PED (Printer Extended Data).
On détourne la fonction Render.
oldrender = PED->ped_Render ;
PED->ped_Render = PRender ;
Ensuite on effectue l’impression graphique, maintes fois décrites, mais au lieu d’employer DoIO, on initie une boucle avec SendIO et on contôle avec CheckIO.
Dans t_currentrow on aura la ligne en cours d’impression, et il suffira de faire un pourcentage avec t_height pour réaliser une petite barre de progression afin de faire patienter l’utilisateur.
On pourra aussi implanter un bouton « stop » qui appellera un AbortIO et WaitIO.
Il n’y a pas d’autre possibilité, vu que rien n’est prévu dans l’iorequest.
Une fois le travail fini, on remet l’état du device comme on l’a trouvé.
PED->ped_Render = oldrender ;
Puis on ferme le printer.device avec CloseDevice.
Je pense que PPaint utilise la même astuce pour faire sa barre de progression lors d’une impression.
En appelant directement PRender avec les bonnes séquences state, (on simule en fait ce que fait la partie dumprastport du printer.device dans un autre programme) on peut sortir ses propres trames, et ainsi imprimer en 24bits, sans pour autant utiliser TurboPrint ou patcher quoi que ce soit dans son système.
On a juste besoin d’une matrice 8×8 au lieu de la 4×4 d’origine et d’utiliser la résolution maxi du pilote (L’écriture d’un driver est connue car documentée dans les RomKernelManuals).
Qui l’eu cru ?
L’Amiga me surprendra tous les jours. Ce qui est dommage c’est que les informations concernant les impressions avec le printer.device sont inexistantes sur le net…
Admin Juste pour faire remonter le fil, histoire de mettre les gens au courant…
http://aminet.net/package/dev/c/anaiis_print
à vos compilateurs…
Yop Alex,
J’ai fouillé dans mes sdk et j’ai trouvé le application.doc en question.
(Malheureusement je crois bien que le NDK3.9 a disparu d’internet…)
C’est la même chose si on part du principe des 8bitpergun et hooks, mais en fait c’est un principe pour utiliser le printer.device directement sans passer par un rastport, mais sans écrire quoi que ce soit de spécifique pour l’imprimante.
Le driver se débrouille tout seul.
Un point est un point, pas un truc qui bouge en taille sans arrêt qui fait qu’une impression graphique bave ou parait floue.
De plus c’est utilisable sous 3.1, 3.0 et certainement en dessous (2.04 et 1.3)
Il y a encore un point obscur que j’ai contourné avec la fonction pr_Exit… … …
Pour tous
Le programme DirectDump de l’archive ci dessous permet d’imprimer des fichiers QRT (Povray)
Ces fichiers sont énormes (25Mo pour 2400x3600points, disque dur obligatoire) mais sont vraiment fidèles quand on les imprime.
Vous pouvez récupérer des fichiers de calibration sur le net.
(tapez + »calibration file » dans images de google, et récupérer ceux ou y’a des filles dessus: la peau est vraiment compliqué à imprimer, sans que ça ressemble à du gris ou du jaune)
Sinon il y a une colorwheel (programme que j’avais fait en 1995…) directement dans le programme et un machin de test issu d’un exemple de turboprint.
http://aminet.net/package/driver/other/anaiis_print
Si vous pouviez me dire si cela fonctionne sur vos imprimantes, ce serait sympa (mes tests: star lc 10 (RIP :'(), HP560C, HPPSC2210).
Si la page ne s’éjecte pas, envoyez le caractère 12 en fin d’impression…
J’en ai profité pour recompiler la partie impression de la miss anaiis…
8 sujets de 1 à 8 (sur un total de 8)
- Vous devez être connecté pour répondre à ce sujet.
