KGF.dll: fonctions Print

Toujours concernant la documentation, dans KGF.pdf page 121: PrinterFunction, je précise que les couleurs doivent être données au format BGR, et non pas RGB comme indiqué, ce qui fausse tout.

Oups... J'ai corrigé KGF_SUB.bas, pour la procédure:
PrinterFunctionStyle(pol$,siz%,R%,G%,B%,gras%,ital%,sous%,barr%)

En effet, la valeur RGB était calculée à l'envers ! Maintenant, la procédure dans KGF_SUB.bas est correcte.

Pour mémoire, la formule est la suivante:
RGB = ((B*256+G)*256+R)


Merci pour l'info !

A mon avis il faudrait aussi corriger la doc dans KGF.pdf, où il est écrit RGB, sinon ça trompe, on a tendance à mettre R dans les poids forts et B dans les poids faibles.
On s'est habitués à l'ordre R, G, B, qui est le cas général, mais en fait dans les images bmp l'ordre est bien B, G, R, et certaines fonctions doivent rendre les couleurs dans cet ordre, la preuve.

Eh bien, oui, justement ! Dans la notation RGB, il s'agit d'un triplet, c'est-à-dire 3 octets qui se suivent. Le premier octet est R, le second est G, le troisième est B. En binaire, cela représente:

00000000BBBBBBBBGGGGGGGGRRRRRRRR

On peut aussi écrire la formule autrement, de façon plus "intuitive":

RDB = R + G*256 + B*256*256

Ainsi, l'ordre est respecté.

EDIT

J'ai modifié la doc pour la fonction PrinterFunction, en expliquant le sens de la valeur RBG et en donnant les deux formules equivalentes pour calculer cette valeur.

Bonsoir à tous !
Ne serait-il pas possible de savoir si lors d'envoi successif, si l'utilitaire d'impression est en cours de fonctionnement. Je passe par un utilitaire "GreenCloud Printer", et en version gratuite les pages sont limitées. Il faut donc que j’arrête d'envoyer des pages, attendre que l'utilitaire se ferme, pour continuer. Cela oblige de mettre un message de blocage, le temps que les impressions se fasse pour continuer.
merci à toi.

Question intéressante ! Je propose d'ajouter un code opération à la fonction PrinterFunction pour retourner la liste des "jobs" dans la file d'attende de l'imprimante. Est-ce que ça peut résoudre ton problème ? Techniquement, c'est faisable.

Citation :

un code opération à la fonction PrinterFunction pour retourner la liste des "jobs"

Si cela correspond à savoir si le programme d'impression est en cours de fonctionnement, c'est effectivement se ce que recherche. Avoir un temps de retard pour la page suivante. Je crois que ça se passe pas trop mal avec 4 pages en cours, mais j'ai vu surgir une erreur avant que ça ne se ferme, sans avoir pu la lire.

Ok. Je vais faire la chose suivante: ajouter un code opération à PrinterFunction. Ce code retournera un texte dans un mémo Panoramic, dans lequel chaque ligne décrit un job dans la file d'attente de l'imprimante. Entre autres informations, je retournerai le nom du job, le nombre total de pages à imprimer, ainsi que le nombre total de pages déjà imprimées. Je retournerai comme valeur résultante de la fonction le nombre de jobs dans la file d'attente.

Je pense que ce sera fait assez rapidement.

C'est fait... sous forme d'une nouvelle fonction GetPrinterQueueInformation. Regarde le programme de démo que j'ai posté. Je pense que ça va résoudre ton problème.

Bonjour Klaus, j'espère que ça va pour toi, je sais que tu es très occupé et pas forcément de manière agréable...

C'est juste une petite remarque concernant la doc pour la fonction de kgf.dll 'WriteTextOverPicture'
Expérience faite (en comparant les tailles des print Panoramic et des print kgf.dll), il me semble bien que le coefficient à attribuer pour la taille dans attr% est 24, et non 16 comme indiqué dans la doc.

Je trouve curieux d'ailleurs ce coefficient 24 qui ne correspond pas comme les autres à un décalage dans attr% (qui devrait être 1,2,4,8,16,32, etc.)

Bon courage !

Bonjour Klaus, et excuse-moi de déterrer ce vieux sujet, mais comme je me sers de cette fonction  ça me chiffonne et ça m'intrigue toujours, il s'agit de la fonction WriteTextOverPicture.

Le coefficient attribué à la taille de la police, x16, qui semble logique, puisque suivant les 4 bits d'enrichissement B, I, U et S des 4 premiers bits, me paraît toujours incorrect.
Un petit exemple:

Code:

DIM p%,txt$,x%,y%,fnt$,sz%,coul%,attrib%,degre%,hnd%,pos%,res%
PICTURE 1: FULL_SPACE 1
p% = 1
txt$ = "Au clair de la lune"
fnt$ = "Arial": sz% = 36
print_target_is p%: font_name p%,fnt$: font_size p%,sz%
print_locate 10,10: print txt$

x%=10: y% = 50: coul% = 0: degre% = 0
DLL_ON "C:\PANORAMIC\KGF\KGF.dll"
  attrib% = sz%*24: ' <====== ?
  attrib% = attrib%+degre%*65536: ' rotation en degrés dans le sens trigonométrique
  hnd% = HANDLE_CANVAS(p%)
  pos% = x% + 65536*y%
  res% = DLL_CALL6("WriteTextOverPicture",hnd%,pos%,ADR(txt$),ADR(fnt$),attrib%,coul%)
DLL_OFF
END

Pour arriver à la même taille (et encore, approximativement) que l'affichage Panoramic par Print, je suis obligé de multiplier la taille par 24 et non par 16 comme indiqué dans la doc de la fonction.

C'est troublant, parce que le multiplicateur devrait correspondre à 1 bit de décalage, soit x16, x32, x64 etc.

De plus, si la taille donnée est impaire, le texte est barré (ça doit positionner le bit 3 = Strike...)
Pour l'angle de rotation, le décalage est correct (x65536).

Les coeficients indiqués sont bien les bons. Mais tu ne peux pas comparer les dimensions en absolu de l'affichage à l'écran et de l'impression sur papier. On raisonne en unités "logiques", dont les dimensions physiques réelles dépendent des caractéristiques techniques de l'imprimante et de l'écran, ainsi que de la résolution confidurée pour l'écran. Même losqu'on considère uniquement l'écran, la dimension d'un "pîxel" n'est pas la même suvant la résolution de l'écran. Pour l'imprimante c'est parail -ça dépend du fabriquant et du modèle, de la résolution configurée pour l'imprimante (nombre de pixels par pouce), etc.

Donc, pour l'impression, la seule solution consiste à faire des essais jusqu'à obtenir le résultat souhaité. Pour cela, chez moi, j'ai installé une imprimante virtuelle produisant un fichier PDF, ce qui permet de ne pas gâcher du papier pour rien. J'utilise PDFCreator, mais il y en a plein d'autres, en freeware.

Merci Klaus pour ta réponse rapide et pour tes explications.

Tout d'abord je ne compare évidemment en aucun cas l'affichage sur écran et l'impression sur papier, il s'agit ici uniquement de l'affichage sur un même écran dans les deux cas.

Je suis bien d'accord avec toi que la taille de l'affichage dépend du périphérique physique, ici en l'occurence le moniteur.
Mais il me semblait que pour un même périphérique donné, ici mon moniteur, comme dans mon exemple, j'aurais dû avoir le même résultat, une police donnée de taille donnée générant le même nombre de pixels.

En tout cas, la solution pour moi (je l'avais déjà fait), c'est donc de multiplier la taille sz% de la police par un coefficient donné, avant de faire le décalage de 4 pixels (x16), si je veux avoir la même taille de caractères pour une police donnée, en affichant soir avec print, soit avec WriteTextOverPicture.

Malheureusement, ce coefficient n'est pas constant et varie en fonction de la taille de la police, donc ma solution est très empirique et peu satisfaisante...

D'accord. J'avais mal compris. Je pensais aux fonctions d'impression sur papier...

Essaie de comparer les tailles avec l'affichage dans un EDIT et/ou dans un ALPHA. Est-ce que les tailles apparaissant dans ces objets sopnt plus proches des tailles générés par PRINT dans un PICTURE, ou plus proches des tailles générées par ma fonction ?

Je reprends mon petit exemple:

Code:

DIM p%,txt$,x%,y%,fnt$,sz%,coul%,attrib%,degre%,hnd%,pos%,res%
fnt$ = "Arial": sz% = 20
txt$ = "Au clair de la lune"
COLOR 0,200,255,255
ALPHA 1: TOP 1,0
EDIT 2: TOP 2,40: WIDTH 2,400
PICTURE 3: TOP 3,100: WIDTH 3,400
FOR x% = 1 TO 3: FONT_NAME x%,fnt$: FONT_SIZE x%,sz%: NEXT x%
CAPTION 1,txt$+" (ALPHA)"
TEXT 2,txt$+" (EDIT)"
p% = 3
print_target_is p%: print_locate 10,10: print txt$+" (PRINT)"

x%=10: y% = 50: coul% = 0: degre% = 0
DLL_ON "C:\PANORAMIC\KGF\KGF.dll"
  ' sz% = sz%*1.55
  attrib% = sz%*16: ' <====== ?
  attrib% = attrib%+degre%*65536: ' rotation en degrés dans le sens trigonométrique
  hnd% = HANDLE_CANVAS(p%)
  pos% = x% + 65536*y%
  txt$ = txt$+" (WriteText...)"
  res% = DLL_CALL6("WriteTextOverPicture",hnd%,pos%,ADR(txt$),ADR(fnt$),attrib%,coul%)
DLL_OFF
END

Résultat:


Pour obtenir la même taille qu'avec les autres fonctions, il faut multiplier sz% par 1,5 à 1,6, mais je le répète, c'est empirique.

Ok. J'ai trouvé le bug grâce à ton petit programme. Télécharge la nouvelle version et ce sera réglé.

Impec Klaus, tout va maintenant très bien.

Cette fonction est très intéressante pour écrire à fond transparent sur des images.
J'avais essayé d'autres méthodes:
- transfert pixel par pixel, très long
- écriture sous forme de sprite
Mais dans les deux cas il y a apparition de pixels parasites autour des caractères.
Avec WriteTextOverPicture, tout est propre et net.

Merci Klaus.

PS
Une remarque quand même:
La taille des caractères avec WriteTextOverPicture est limitée à 63 (donc codée sur 6 bits seulement), au delà on repart de 0.
dommage...

Code:

DIM x%,y%,hnd%,tx$,fnt$,sz%,pos%,attr%,coul%,res%
PICTURE 1: WIDTH 1,560: HEIGHT 1,400
tx$ = "Au clair"
fnt$ = "Arial": coul% = 0
sz% = 64
x% = 10: y% = 10: pos% = x% + 65536*y%
attr% = 16*sz% + 65536*coul%
DLL_ON "C:\PANORAMIC\KGF\KGF.dll"
  hnd% = HANDLE_CANVAS(1)
  res% = DLL_CALL6("WriteTextOverPicture",hnd%,pos%,ADR(tx$),ADR(fnt$),attr%,coul%)
DLL_OFF
print_target_is 1: font_name 1,fnt$: font_size 1,sz%
print_locate 10,100: print tx$+" (Print)"
END

Recharge la DLL et essaie à noveau... tu disposes maintenant de 12 bits (jusqu'à une taille de 4095) pour coder la taille.

J'y cours !

C'est fait, super Klaus, plus de limitation, ça j'en suis bien content.
(pour la taille 4095 j'attendrai d'avoir mon écran mural).

Merci beaucoup pour tout, l'outil est parfait !

Est-ce que tu as vu, dans la doc, que tu peux écrire, non seulement avec n'importe quel angle, mais encore en suivante une courbe quelconque ? Un cercne, une parabole, un sinus - n'importe quoi...

J'ai vu tout ça effectivement, et j'utilise occasionnellement le mode incliné, ça peut être très pratique, en particulier à 90°.

Par contre je n'ai jamais testé l'affichage suivant une courbe, je n'en ai pas eu l'usage (mais sans doute justement parce que je n'ai pas testé !)
Je ferai un essai, au moins pour voir...

PS une petite précision.
Sauf erreur de ma part, la limitation de la taille de caractères est de 2047, et non 4095. Ce qui correspond à la place disponible dans le champ des paramètres.
En effet, 4 bits pour les enrichissements (BIUS), 11 bits pour la taille, le bit suivant étant justement le bit 'écriture sur courbe' (x32768), puis le champ 'angle de rotation' (x65536).

D'ailleurs j'ai fait l'expérience, la limite est bien 2047.
Mais bon, tant pis, je ferai avec...  

PS2 pour ce qui est de l'écriture sur courbe, j'ai regardé, mais ça ne me paraît pas du tout évident à mettre en oeuvre, avec cette fonctions ConfigureCurveWtoP... je crois bien que je vais reporter ça à plus tard...

Je reviens sur l'écriture suivant une courbe (puisque tu en as parlé ).
Vraiment je n'arrive à rien du tout et quelque chose doit m'échapper.
J'ai essayé de reprendre le plus fidèlement possible l'exemple donné dans la doc de la fonction ConfigureCurveWToP, mais... aucun affichage.
C'était juste pour voir, mais... je n'ai rien vu ! Je dis ça, à tout hasard...

Code:

DIM txt$,x%,y%,xc%,yc%,fnt$,sz%,attr%,coul%,degre%,delta%,facteur%,r%,g%,b%
DIM hnd%,res%,pos%
PICTURE 1: FULL_SPACE 1
fnt$ = "Arial": sz% = 36
txt$ = "Mon message pour voir"
degre% = 30
xc% = 300: yc% = 285
delta% = 10: ' incrément de l'angle d'écriture (degrés)
facteur% = 100: ' écriture sur cercle
DLL_ON "C:\PANORAMIC\KGF\KGF.dll"
  res% = DLL_CALL4("ConfigureCurveWToP",xc%,yc%,delta%,facteur%)
  x% = 90: y% = 140: pos% = x% + 65536*y%
  r% = 0: g% = 0: b% = 255: coul% = (b%*256+g%)*256 + r%
  attr% = sz%*16 + 32768 + degre%*65536: ' + bit 'courbe'
  hnd% = HANDLE_CANVAS(1)
  res% = DLL_CALL6("WriteTextOverPicture",hnd%,pos%,ADR(txt$),ADR(fnt$),attr%,coul%)
DLL_OFF
END

Oui, il y a un problème. Je regarde ça.