Gestion des formulaires Win32 Printserver – Bien choisir son serveur d impression

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.