Gestion des formulaires Win32 Printserver – Bien choisir son serveur d impression
Author: Titanfall —
Short summary: La plupart des imprimantes prennent en charge plusieurs formats de papier, chacun pouvant être sélectionné à partir du menu de configuration de l'imprimante. Ces tailles incluent Lettre, A4, Légal, et similaires (bien qu'il y ait des centaines de tailles standard utilisées à travers le monde). Le système d’impression sous Windows NT / 2K / XP […]
Quick overview
- Site
- Tutos GameServer
- Canonical URL
- https://tutos-gameserver.fr/2019/07/15/gestion-des-formulaires-win32-printserver-bien-choisir-son-serveur-d-impression/
- LLM HTML version
- https://tutos-gameserver.fr/2019/07/15/gestion-des-formulaires-win32-printserver-bien-choisir-son-serveur-d-impression/llm
- LLM JSON version
- https://tutos-gameserver.fr/2019/07/15/gestion-des-formulaires-win32-printserver-bien-choisir-son-serveur-d-impression/llm.json
- Manifest
- https://tutos-gameserver.fr/llm-endpoints-manifest.json
- Estimated reading time
- 10 minutes (544 seconds)
- Word count
- 1812
Key points
- La plupart des imprimantes prennent en charge plusieurs formats de papier, chacun pouvant être sélectionné à partir du menu de configuration de l'imprimante.
- Ces tailles incluent Lettre, A4, Légal, et similaires (bien qu'il y ait des centaines de tailles standard utilisées à travers le monde).
- Le système d’impression sous Windows NT / 2K / XP OS a un mécanisme centralisé de gestion des formats de papier nommés via un "API de formulaires".
- La plupart des utilisateurs ne seront pas directement exposés au système de formulaires, mais un projet récemment en construisant un PPD (Postscript Printer Description) pour l’imprimante d’un client, nous avons jugé nécessaire de devenir beaucoup plus familier avec ce que nous voulions.
Primary visual
Structured content
La plupart des imprimantes prennent en charge plusieurs formats de papier, chacun pouvant être sélectionné à partir du menu de configuration de l'imprimante. Ces tailles incluent Lettre, A4, Légal, et similaires (bien qu'il y ait des centaines de tailles standard utilisées à travers le monde). Le système d’impression sous Windows NT / 2K / XP OS a un mécanisme centralisé de gestion des formats de papier nommés via un "API de formulaires".
La plupart des utilisateurs ne seront pas directement exposés au système de formulaires, mais un projet récemment en construisant un PPD (Postscript Printer Description) pour l’imprimante d’un client, nous avons jugé nécessaire de devenir beaucoup plus familier avec ce que nous voulions.
Notre recherche a été effectuée sur Windows 2000 avec SP4. Nous espérons que nos découvertes seront utiles aux autres.
La gestion de la base de données de formulaires se fait avec cinq fonctions API fourni par WINSPOOL.LIB:
Un "formulaire" est un nom pour un certain type de support et toutes les imprimantes. partager la base de données commune. Chaque formulaire est décrit par un FORM_INFO_1 structure composée de quatre membres:
FORM_INFO_1.pName Le nom de ce formulaire, qui doit être unique dans tous les formulaires système. Le cas ne semble pas avoir d'importance. FORM_INFO_1.Size Largeur et hauteur de la forme en millièmes de millimètre, et plusieurs formulaires peuvent avoir des tailles identiques. Ceci est représenté par un TAILLE L structure, avec cx et cy membres. FORM_INFO_1.ImageableArea le RECTL qui détient la zone imageable des médias en localisant les coins inférieur gauche et supérieur droit semblent être redondants. Bien que la disposition en quatre points de ce champ suggère qu'ils représentent le la marge matérielle physique, dans la pratique, le coin inférieur gauche est toujours 0,0 et le coin supérieur droit est cx, cy.
Heureusement, les marges matérielles sont ne pas reflété ici: bien que tous (Par exemple) Le format "A4" a les mêmes dimensions extérieures physiques, chacune type d'imprimante a ses propres restrictions. Il n'y a pas moyen qu'un seul média nom pourrait représenter plusieurs arrangements physiques.
FORM_INFO_1.Flags Chaque formulaire peut être de trois types: FORM_BUILTIN, FORM_PRINTER et FORM_USER. Les formulaires intégrés font partie intégrante du système d’impression (TODO: quelle partie?), et ils ne peuvent pas être supprimés ou modifiés avec l’API Forms. Les formulaires "Imprimante" sont stockés dans le registre, de même que les formulaires "Utilisateurs". le La documentation de Microsoft suggère que les formulaires "Imprimante" soient associés avec des imprimantes individuelles, mais nous n'avons trouvé aucune indication indiquant qu'ils sont autre chose que large du système et disponible pour tout imprimantes. Nous n'avons pas trouvé comment les formulaires "utilisateur" sont implémentés.
La base de données des formulaires utilisateur et d'impression (mais pas des formulaires intégrés) est trouvée dans le registre:
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Print Forms
Il est possible de supprimer ou de renommer directement les noms de formulaire dans le registre, mais bien sûr, c'est une idée terrible: utilisez plutôt l'API Forms.
Nous avons observé plusieurs éléments de comportement de l’API Forms qui sont: pas strictement documenté. Nous allons les aborder ici.
Tous les appels d’API nécessitent un HANDLE vers une imprimante ou un serveur d’impression, mais ils ne sont pas complètement interchangeables.
API NT4 Win2000
EnumForms () imprimante imprimante ou serveur
AddForm () imprimante imprimante ou serveur
DeleteForm () imprimante imprimante ou serveur
SetForm () imprimante imprimante ou serveur
GetForm () imprimante imprimante
On ne peut pas DeleteForm () sur une forme interne: ça échoue avec ERROR_INVALID_PARAMETER.
On ne peut pas AddForm () un formulaire dont le nom ne respecte pas la casse existe déjà: il échoue avec ERROR_FILE_EXISTS.
Il est possible de AddForm () une forme "intégrée", mais c'est néanmoins toujours stocké dans le registre. Mais une fois ajouté, il ne peut pas être supprimé avec l’API Forms: l’édition directe du registre est Champs obligatoires. Cela suggère des formes "véritables intégrées" et "intégrées", qui l'API Forms ne discute pas. Nous pensons que l'ajout de formes "intégrées" via l'API est une mauvaise idée. le GetForm () L'appel d'API ne fonctionnera pas avec un handle vers un serveur d'impression, seulement une poignée à une imprimante elle-même: on ne voit pas pourquoi c'est le cas.
Lors de la manipulation de la base de données de formulaires via le registre, il faut arrêter et démarrez le spouleur (par exemple NETTOYEUR DE BUTÉE suivi par SPOOLER NET START à partir de la ligne de commande MS-DOS, ou utilisez la commande Interface graphique des services du Panneau de configuration) pour qu’elle prenne effet. Suppression une entrée de registre pour un formulaire ne permet pas au spouleur d'oublier la version en mémoire immédiatement.
Lorsque vous utilisez le SetForm () API, on fournit à la fois le nom dans l'appel de l'API et à l'intérieur de la structure FORM_INFO_1, donc suggère que l'on peut Renommer un formulaire avec:
finfo.pName = "NewForm"; ... SetForm (hPrinter, "OldForm", 1, & finfo);
mais ça ne marche pas bien. Nouvelle forme est ajouté au registre avec les dimensions mises à jour, et OldForm reste avec les anciens, mais cela n'est pas visible via l'API de formulaires. Au lieu de cela, l'ancien formulaire est mis à jour avec les nouvelles dimensions. Le redémarrage du service de spouleur rend visible les paramètres du registre, y compris en laissant l'ancien formulaire.
Cela ressemble à un bug.
Windows fournit un moyen de visualiser et de gérer tous les formulaires (intégrés et sinon), et on y parvient en ouvrant le Imprimantes applet de le panneau de contrôle. Tirer vers le bas Fichier: Propriétés du serveur du haut menu:
qui ouvre la boîte de dialogue de gestion des formulaires:
Certaines formes – comme Lettre montré ici – sont intégrés et ne sont pas disponibles pour modifier ou supprimer, mais tous les formulaires qui ont été ajoutés par l'utilisateur ou une impression le programme d'installation du pilote peut être géré directement.
Bien que l’interface graphique permette l’utilisation des unités de mesure anglaise et métrique, intérieurement tout les formes sont mesurées au millième de millimètre.
Pratiquement toutes les imprimantes compatibles PostScript utilisent l’imprimante Adobe / Microsoft. pilote, et il est assez complet. Plutôt que de modifier le pilote lui-même adapter son comportement aux capacités de l’imprimante, l’un à la place fournit un fichier PPD (Postscript Printer Description) qui caractérise le périphérique de sortie.
La création d’un PPD va bien au-delà de la portée de ce conseil technique, mais une section se rapporte à l'API Forms. le PaperDimension les balises décrivent toutes les formats de support pris en charge par cette imprimante, et le pilote les rend disponibles à l'application.
*% === Dimension du papier ====================== * DefaultPaperDimension: 14x17 * Lettre PaperDimension: "612 792" * PaperDimension A4: "595 842" * PaperDimension 8x10: "576 720" * PaperDimension 11x14: "792 1008" * PaperDimension 14x17: "1008 1224"
Cette partie est documentée dans le Adobe Spécification PPD (PDF), mais l’interaction entre les PaperDimension balise et l’API de formulaire ne l’est pas. Nous avons constaté un comportement très déconcertant.
Quand une imprimante est installée, le .PPD le fichier est copié profondément dans le Hiérarchie Windows, et sur notre système Windows 2000, il est stocké dans cette annuaire:
C: WINNT system32 spool drivers w32x86 3
le .PPD le fichier est "compilé" dans un binaire .BPD déposer chaque fois que le le pilote voit que le fichier source a changé – cela semble arriver à tout moment un nouveau travail d’impression commence et il rend probablement le pilote plus rapide en raison de la l'analyse réduite du fichier.
Certains changements dans le .PPD sont reflétés immédiatement, ce qui le rend facile pour tester un PPD. En le modifiant simplement sur place, le prochain travail d'impression est recompilé le fichier et lit les paramètres. Mais d'autres attributs, y compris les médias tailles – ne sont reconsidérés que lorsque le pilote est installé ou mis à jour.
Dans tous les cas, il ne semble pas exister de mécanisme de retour d’erreur pour erreurs syntaxiques ou sémantiques. Nous souhaitons que MS / Adobe fournisse un "Validateur PPD" utilisant la même logique d'analyse que le pilote (peut-être exposé par une API dans le pilote lui-même) – cela nous permettrait pour attraper des erreurs stupides à l'avant.
Le plus gros problème avec le pilote jusqu’à présent est l’intégration avec les formulaires. API: en traitant les descriptions de support, il tente de résoudre le PPD tailles avec celles trouvées dans la base de données. Il semble que si le nom du média est déjà dans la base de données mais les dimensions ne correspondent pas exactement, cette et tous les noms de média PPD suivants sont ignoré.
Non seulement ces noms ne sont pas ajoutés à la base de données, mais ils ne sont même pas ajouté à la liste des supports valides pris en charge par cette imprimante – c'est comme s'ils n'ont même pas été trouvés dans le PPD.
Dans la liste ci-dessus de PaperDimensions, si la taille à (disons) 8×10 ne correspond à ce qui se trouve dans la base de données de formulaires, ceci et tous les supports suivants sont ignoré. Cela signifie que l'interface graphique de configuration de l'imprimante affiche uniquement les formats Letter et A4. en tant que support valide.
La seule solution à ce problème consiste à examiner la base de données de formulaires à l'avance. et supprimez tous les formulaires préexistants qui ne correspondent pas à la bonne taille. Nous ne voyez un moyen simple de le faire avec le mécanisme d'installation d'imprimante standard: Nous avons dû développer un code C ++ personnalisé qui supprime les entrées non correspondantes et repeuple les formes avec les tailles appropriées.
Click to rate this post! [Total: 0 Average: 0]
Topics and keywords
Themes: Serveur d'impression
License & attribution
License: CC BY-ND 4.0.
Attribution required: yes.
Manifest: https://tutos-gameserver.fr/llm-endpoints-manifest.json
LLM Endpoints plugin version 1.1.2.