Filtres XPS standard
Important
La plateforme d’impression moderne est le moyen privilégié de Windows pour communiquer avec les imprimantes. Nous vous recommandons d’utiliser le pilote de classe IPP en boîte de Microsoft, ainsi que les applications de support d’impression (PSA), pour personnaliser l’expérience d’impression dans Windows 10 et 11 pour le développement de périphériques d’impression.
Pour plus d’informations, veuillez consulter la section Plateforme d’impression moderne et le Guide de conception des applications de support d’impression.
Windows fournit deux filtres XPS (standard) pour prendre en charge la conversion intégrée de XPS vers PCL6 et PostScript niveau 3.
Les filtres fournis par Windows sont disponibles à la fois pour les pilotes de classe d'impression et les pilotes d'impression v4 spécifiques au modèle. Ces filtres XPS peuvent être combinés avec les filtres de fonctionnalité IHV ainsi qu'avec les filtres de post-traitement IHV, selon les besoins, afin d'assurer la compatibilité avec les implémentations de microprogrammes existantes.
Les filtres XPS fournis par Windows ne sont pas redistribuables et ne sont pas disponibles pour les pilotes d'impression v3.
Le fichier Manifest
Pour utiliser les filtres XPS fournis par Windows, le fichier manifeste du pilote v4 doit utiliser la directive RequiredFiles dans la section DriverConfig pour spécifier les filtres. Voici les noms des filtres :
MSxpsPCL6.dll. Assure la conversion de XPS en PCL6. MSxpsPS.dll. Permet la conversion de XPS en PostScript niveau 3. Aucune mise à jour INF n'est nécessaire pour utiliser l'un de ces filtres, et la redistribution n'est pas prise en charge. Nous recommandons aux utilisateurs de ne plus utiliser ces filtres XPS.
Configuration du pipeline de filtres d'impression
Pour configurer le pipeline de filtres d'impression afin d'utiliser ces filtres, vous devez créer des fichiers de configuration comme indiqué dans les exemples suivants.
Exemple de fichier de configuration spécifiant la conversion en PCL6.
<?xml version="1.0" encoding="utf-8"?>
<Filters>
<Filter dll="MSxpsPCL6.dll" clsid="{3821E518-33AF-4d17-92B3-28EB410D46B6}" name="Microsoft XPS to PCL6">
<Input guid="{4d47a67c-66cc-4430-850e-daf466fe5bc4}" comment="IID_IPrintReadStream" />
<Output guid="{65bb7f1b-371e-4571-8ac7-912f510c1a38}" comment="IID_IPrintWriteStream" />
</Filter>
</Filters>
Exemple de fichier de configuration spécifiant la conversion en PostScript.
<?xml version="1.0" encoding="utf-8"?>
<Filters>
<Filter dll="MSxpsPS.dll" clsid="{8636D90A-5E03-4d62-9269-E06493C57473}" name="Microsoft XPS to PS">
<Input guid="{4d47a67c-66cc-4430-850e-daf466fe5bc4}" comment="IID_IPrintReadStream" />
<Output guid="{65bb7f1b-371e-4571-8ac7-912f510c1a38}" comment="IID_IPrintWriteStream" />
</Filter>
</Filters>
Fonctionnalités prises en charge
Les filtres XPS standard prennent en charge de nombreuses fonctionnalités communes. Toutes les définitions de fonctionnalités utilisent le fichier GPD ou PPD du pilote. Le filtre MSxpsPCL6.dll nécessite l'utilisation d'un fichier GPD pour la configuration, et le filtre MSxpsPS.dll nécessite l'utilisation d'un fichier PPD pour la configuration. Sauf indication contraire, si une commande PDL personnalisée est spécifiée pour une fonctionnalité, elle sera utilisée.
Si des chaînes d'injection existent dans une section particulière (spécifiée avec la commande *Order), dans le cas des fichiers GPD, le filtre fera un certain nombre d'hypothèses sur le contenu de ces chaînes et évitera d'envoyer des commandes par défaut. En effet, l'envoi de commandes par défaut dans ce cas pourrait entraîner des collisions de commandes. Par conséquent, le créateur d'un fichier GPD doit suivre ces directives :
JOB_SETUP.#
Un en-tête de flux binaire PCL6 (par exemple : ")<SP>HP-PCL XL;1;<CR><LF>") doit exister.
Un opérateur BeginSession doit exister, avec tous les attributs requis.
Un opérateur OpenDataSource doit exister, avec tous les attributs requis.
PAGE_SETUP.#
- Un opérateur BeginPage doit exister, avec tous les attributs requis.
PAGE_FINISH.#
- Un opérateur EndPage doit exister.
JOB_FINISH.#
Un opérateur CloseDataSource doit exister.
Un opérateur EndSession doit exister.
Un opérateur EndPJLCommands doit exister.
Les filtres standard XPS produisent les données PDL appropriées pour définir l'origine d'une page, sur la base des commandes *PrintableArea, *PrintableOrigin ou *ImageableArea. Afin d'éviter tout décalage supplémentaire par rapport à l'origine prévue, les fichiers GPD ne doivent pas spécifier de commandes =SetPageOrigin dans la définition de la chaîne *Cmd pour leur format de papier.
Pour plus d'informations sur les fonctionnalités PrintTicket prises en charge par les filtres XPS standard, reportez-vous à la section Fonctionnalités PrintTicket prises en charge.
Récupération du PrintTicket dans les filtres de post-traitement
Dans le modèle de pilote v4 publié avec Windows 8, lorsque vous ajoutiez un filtre de post-traitement après l'un des filtres MSxps, vous deviez parfois également ajouter un filtre de prétraitement. L'ajout du filtre de prétraitement était nécessaire pour capturer le ticket d'impression au niveau du travail. Mais cette approche ajoutait essentiellement un filtre basé sur le modèle d'objet, avant l'un des filtres MSxps basés sur le flux, ce qui entraînait la désérialisation, puis la sérialisation des données d'impression pour extraire simplement un PrintTicket.
Dans Windows 8.1, le PrintTicket par défaut de l'utilisateur est fusionné avec le PrintTicket au niveau du travail dans les filtres MSxps, et le PrintTicket fusionné est ensuite ajouté au sac de propriétés du Print Filter Pipeline. La fiche d'impression fusionnée est ajoutée à la propriété de Print Filter Pipeline de la même manière que la fiche d'impression de l'utilisateur. La propriété est nommée comme suit :
#define XPS_FP_JOB_LEVEL_PRINTTICKET "JobPrintTicket"
Lors de l'initialisation du filtre, les filtres MTI ajoutent une implémentation de IPrintReadStreamFactory dans le sac de propriétés. La seule méthode de cette interface, GetStream, se bloque jusqu'à ce que le flux PrintTicket soit disponible. Cela permet de synchroniser l'accès à la propriété.
Important : si GetStream est appelé depuis InitializeFilter, cela provoquera un blocage.
Autres fonctionnalités
Dans le cas des fonctionnalités du PrintTicket qui ne sont pas prises en charge par les filtres XPS standard, les filtres vérifient tous les membres du PrintTicket pour voir s'ils sont référencés dans le GPD/PPD, puis spécifient les commandes à émettre. Si c'est le cas, les commandes spécifiées seront générées.
Les fonctionnalités GPD sont mappées dans l'ordre suivant :
Une valeur PrintSchemaKeywordMap est spécifiée et correspond au nom de la fonctionnalité PrintTicket.
L'attribut PrintSchemaPrivateNamespaceURI est spécifié et le nom de la fonctionnalité GPD correspond au nom de la fonctionnalité PrintTicket. La correspondance des noms de fonctionnalité n'est pas simple et suit un certain nombre de règles :
Si la section *Order de la première option est PAGE_SETUP ou PAGE_FINISH et que la fonctionnalité GPD ne commence pas par « Page », « Page » est ajouté au nom de la fonctionnalité GPD avant toute tentative de correspondance.
Si la section *Order de la première option est DOC_SETUP ou DOC_FINISH, et que la fonctionnalité GPD ne commence pas par « Document », alors « Document » est ajouté au nom de la fonctionnalité GPD avant toute tentative de correspondance.
Si la section *Order de la première option est JOB_SETUP ou JOB_FINISH et que la fonctionnalité GPD ne commence pas par « Job », « Job » est ajouté au nom de la fonctionnalité GPD avant toute tentative de correspondance.
Tout caractère qui n'est pas [A-Z], [a-z], [0-9] ou « _ »est remplacé par un caractère « _ » avant de tenter une correspondance. Toutefois, si l'attribut *NoPunctuationCharSubstitute? est défini sur TRUE, le filtre ne remplace pas « . » ou « - » par un caractère « _ ».
Les fonctionnalités GPD sont mappées dans l'ordre suivant :
Une valeur PrintSchemaKeywordMap est spécifiée et correspond au nom de la fonctionnalité PrintTicket.
L'attribut PrintSchemaPrivateNamespaceURI est spécifié et le nom de la fonctionnalité PPD correspond à celui de la fonctionnalité PrintTicket. La correspondance des noms de fonctionnalité n'est pas simple et suit un certain nombre de règles :
Si la section OrderDependency est ExitServer, Prolog ou JCLSetup et que le nom de la fonctionnalité PPD ne commence pas par « Job », « Job » est ajouté au nom de la fonctionnalité PPD avant toute tentative de correspondance.
Si la section OrderDependency est DocumentSetup et que le nom de la fonctionnalité PPD ne commence pas par « Document », « Document » est ajouté au nom de la fonctionnalité PPD avant toute tentative de correspondance.
Si la section OrderDependency est AnySetup, le filtre effectue deux vérifications :
Si le nom de la fonctionnalité PPD ne commence pas par « Document », « Document » est ajouté au nom de la fonctionnalité PPD avant toute tentative de correspondance.
Si aucune correspondance n'est trouvée ou si le nom de la fonctionnalité PPD ne commence pas par « Job », « Job » est ajouté au nom de la fonctionnalité PPD avant toute tentative de correspondance.
Si la section OrderDependency est PageSetup et que le nom de la fonctionnalité PPD ne commence pas par « Page », « Page » est ajouté au nom de la fonctionnalité PPD avant toute tentative de correspondance.
Tout caractère qui n'est pas [A-Z], [a-z], [0-9] ou « _ »est remplacé par un caractère « _ » avant de tenter une correspondance. Toutefois, si l'option *MSNoPunctuationCharSubstitute? est défini sur TRUE, le filtre ne remplace pas « . » ou « - » par un caractère « _ ».
Les options GPD et PPD sont mappées dans l'ordre suivant :
Une valeur PrintSchemaKeywordMap est spécifiée et correspond au nom de l'option PrintTicket.
L'attribut PrintSchemaPrivateNamespaceURI est spécifié et le nom de l'option GPD/PPD correspond au nom de l'option PrintTicket. La correspondance des noms d'options n'est pas simple et suit un certain nombre de règles :
Si le nom de l'option GPD/PPD commence par [0-9] ou « _ », un caractère « _ » est ajouté au nom de l'option GPD/PPD avant toute tentative de correspondance. Toutefois, les règles supplémentaires suivantes s'appliquent :
S'il s'agit d'une option GPD et que l'attribut *NoPunctuationCharSubstitute? est défini sur TRUE, le filtre ne fait pas précéder « _ » d'un caractère « _ ».
S'il s'agit d'une option PPD et que la chaîne *MSNoPunctuationCharSubstitute? a la valeur TRUE, le filtre ne fait pas précéder « _ » d'un caractère « _ ».
Tout caractère qui n'est pas [A-Z], [a-z], [0-9] ou « _ »est remplacé par un caractère « _ » avant de tenter une correspondance. Toutefois, les règles supplémentaires suivantes s'appliquent :
S'il s'agit d'une option GPD et que l'attribut *NoPunctuationCharSubstitute? est défini sur TRUE, le filtre ne remplace pas « . » ou « - » par un caractère « _ ».
S'il s'agit d'une option PPD et que la chaîne *MSNoPunctuationCharSubstitute? a la valeur TRUE, le filtre ne remplace pas les caractères « . » ou « - » par le caractère « _ ».
Mappage des formulaires et des bacs
Les filtres XPS vers PCL6 et XPS vers PS prennent en charge la table de mappage forme/plateau. Si plusieurs bacs prennent en charge le format de support sélectionné (par exemple, lettre), les filtres les départagent comme suit :
Si le bac par défaut (tel que spécifié dans le fichier GPD ou PPD) est configuré pour utiliser le format de support spécifié, le bac par défaut est utilisé.
Sinon, le filtre choisit le premier bac (de haut en bas, tel qu'il a été spécifié dans le fichier GPD/PPD) qui est configuré avec le format de support spécifié.
Suppression des pages supplémentaires au verso
Par défaut, les filtres XPS vers PCL6 et XPS vers PS gèrent l'impression recto-verso de documents contenant des tailles et des types de supports mixtes, ainsi que des bacs d'entrée ou de sortie, en insérant une page vide. Lorsque les filtres insèrent cette page vide, ils forcent l'appareil à imprimer la page suivante au recto d'un nouveau support. Pour les appareils qui ne nécessitent pas l'impression d'une page verso, ce comportement peut être supprimé en ajoutant les mots-clés suivants au fichier GPD ou PPD du pilote.
Type de fichier | Mot-clé de suppression de la page de garde |
---|---|
GPD | *SuppressExtraBacksidePages?: TRUE |
PPD | *MSSuppressExtraBacksidePages: True |
Optimisation des commandes SetPageDevice
Le comportement par défaut d'un appareil PostScript qui utilise un pilote avec MSxpsPS.dll est le suivant : une commande SetPageDevice est émise pour chaque page, et cette commande indique l'ensemble des options spécifiées pour la page. Notez que certains appareils peuvent ne pas fonctionner correctement avec cette technique.
Toutefois, si votre appareil utilise MSxpsPS.dll et que le fichier PPD qui l'accompagne spécifie *MSOptimizeSetPageDevice : True, le comportement de l'appareil PostScript est le suivant : - Pour chaque page où une partie de la commande SetPageDevice a été modifiée depuis la page précédente, un nouveau commande SetPageDevice est émise pour indiquer l'ensemble des options spécifiées pour la page. Mais si aucune partie de la commande SetPageDevice n'a été modifiée depuis la page précédente, aucune commande SetPageDevice n'est émise pour la page.