ONYX:9.0:Utilisation:Gestion des codes OMR(KERN) - Historique des versions

Jdieu : Cette version a été marquée pour être traduite

2025-01-03T08:19:58Z

Cette version a été marquée pour être traduite

Voir les modifications

Jdieu le 3 janvier 2025 à 08:19

2025-01-03T08:19:49Z

Nsmet le 13 décembre 2024 à 14:19

2024-12-13T14:19:38Z

Nsmet le 13 décembre 2024 à 14:02

2024-12-13T14:02:24Z

Nsmet le 13 décembre 2024 à 14:01

2024-12-13T14:01:24Z

Nsmet : /* Calculs des codes OMR */

2019-11-15T13:42:24Z

‎Calculs des codes OMR

Nsmet : /* Calculs des codes OMR */

2019-11-15T13:41:25Z

‎Calculs des codes OMR

Izarai : /* Ajout des codes OMR */

2019-04-18T11:54:08Z

‎Ajout des codes OMR

Izarai : /* Ajout des codes OMR */

2019-04-18T09:21:50Z

‎Ajout des codes OMR

Izarai : /* Calculs des codes OMR */

2019-04-18T09:18:59Z

‎Calculs des codes OMR

@@ Ligne 1 : / Ligne 1 : @@
+<languages/>
 Cette partie détaille les étapes nécessaires aux calculs et à l’impression de marques KERN pour le pilotage des matériels de mise sous plis. Pour ce faire, le point de départ est un document XPS de factures déjà composé et indexé.
@@ Ligne 200 : / Ligne 201 : @@
 [[Fichier:OX S OMR MD.png|centré|sans_cadre|921x921px]]

@@ Ligne 28 : / Ligne 28 : @@
 '''omrduplex=on/off'''
-Calculs effectués en mode recto/verso en tenant compte des attributs de finition du document XPS. Ce paramètre influe sur les calculs et ajoute des compteurs de feuilles dans le XML.
+Les calculs sont effectués en tenant compte du mode recto/verso dans les attributs de finition du document XPS. Ce paramètre influence les calculs et ajoute des compteurs de feuilles dans le XML généré.
-Attention : à ce jour, la détermination des sauts de feuille est basée exclusivement sur les printtickets "JobDuplexAllDocumentsContiguously" et "PageForceFrontSide" (au niveau page). C'est-à-dire que si le XPS est "multi documents", le passage d'un document à l'autre ne sera pas considéré comme provoquant un retour sur une page "recto" contrairement au comportement par défaut lors de la conversion du XPS en PCL si le paramètre "jobduplexalldocumentscontiguously" de la commande map_xps n'est pas "ON".
+⚠️ Remarque importante : actuellement, la détection des sauts de feuille repose uniquement sur les printtickets "JobDuplexAllDocumentsContiguously" et "PageForceFrontSide" (au niveau des pages). Cela signifie que si le document XPS contient plusieurs sous-documents, le passage d’un sous-document à un autre ne sera pas considéré comme un retour automatique à une page recto. Ce comportement diffère de la conversion par défaut du XPS en PCL, où un changement de sous-document force un retour sur recto, sauf si ce comportement est désactivé via le paramètre ''"jobduplexalldocumentscontiguously"'' dans la commande <code>map_xps</code>.

← Version précédente		Version du 13 décembre 2024 à 14:02
Ligne 29 :		Ligne 29 :

	Calculs effectués en mode recto/verso en tenant compte des attributs de finition du document XPS. Ce paramètre influe sur les calculs et ajoute des compteurs de feuilles dans le XML.		Calculs effectués en mode recto/verso en tenant compte des attributs de finition du document XPS. Ce paramètre influe sur les calculs et ajoute des compteurs de feuilles dans le XML.
		+
	Attention : à ce jour, la détermination des sauts de feuille est basée exclusivement sur les printtickets "JobDuplexAllDocumentsContiguously" et "PageForceFrontSide" (au niveau page). C'est-à-dire que si le XPS est "multi documents", le passage d'un document à l'autre ne sera pas considéré comme provoquant un retour sur une page "recto" contrairement au comportement par défaut lors de la conversion du XPS en PCL si le paramètre "jobduplexalldocumentscontiguously" de la commande map_xps n'est pas "ON".		Attention : à ce jour, la détermination des sauts de feuille est basée exclusivement sur les printtickets "JobDuplexAllDocumentsContiguously" et "PageForceFrontSide" (au niveau page). C'est-à-dire que si le XPS est "multi documents", le passage d'un document à l'autre ne sera pas considéré comme provoquant un retour sur une page "recto" contrairement au comportement par défaut lors de la conversion du XPS en PCL si le paramètre "jobduplexalldocumentscontiguously" de la commande map_xps n'est pas "ON".

← Version précédente		Version du 13 décembre 2024 à 14:01
Ligne 29 :		Ligne 29 :

	Calculs effectués en mode recto/verso en tenant compte des attributs de finition du document XPS. Ce paramètre influe sur les calculs et ajoute des compteurs de feuilles dans le XML.		Calculs effectués en mode recto/verso en tenant compte des attributs de finition du document XPS. Ce paramètre influe sur les calculs et ajoute des compteurs de feuilles dans le XML.
−		+	Attention : à ce jour, la détermination des sauts de feuille est basée exclusivement sur les printtickets "JobDuplexAllDocumentsContiguously" et "PageForceFrontSide" (au niveau page). C'est-à-dire que si le XPS est "multi documents", le passage d'un document à l'autre ne sera pas considéré comme provoquant un retour sur une page "recto" contrairement au comportement par défaut lors de la conversion du XPS en PCL si le paramètre "jobduplexalldocumentscontiguously" de la commande map_xps n'est pas "ON".
−
−	~~'''maxomrmark=NN'''~~
−
−	~~Nombre maximum~~ de ~~feuilles par pli. Ce paramètre influe~~ sur les ~~calculs mais n’ajoute rien de plus dans le XML~~.
−
−
−	'''~~omrduplex=on/off'''~~
−
−	~~Calculs effectués en mode~~ recto~~/verso en tenant compte des attributs~~ de ~~finition~~ du ~~document~~ XPS~~. Ce~~ paramètre ~~influe sur les calculs et ajoute des compteurs~~ de ~~feuilles dans le XML~~.

← Version précédente		Version du 15 novembre 2019 à 13:42
Ligne 5 :		Ligne 5 :

	A partir de ce document XPS indexé, le principe est d’utiliser les valeurs d’un index particulier (par exemple sur le numéro de client = CustomerID dans notre cas) pour produire un fichier XML compatible M-Designer en y intégrant tous les calculs d’allotissements, les modulos de page et de séquence, les ruptures, etc…		A partir de ce document XPS indexé, le principe est d’utiliser les valeurs d’un index particulier (par exemple sur le numéro de client = CustomerID dans notre cas) pour produire un fichier XML compatible M-Designer en y intégrant tous les calculs d’allotissements, les modulos de page et de séquence, les ruptures, etc…
−	Le commutateur principal est '''-toXMLDRAW''' (permettant de générer un fichier XML Mapping, ~~appelé~~ "XMLDraw"), pour demander une sortie XML à partir du document XPS. Cette sortie est enrichie avec les arguments suivants et utilisables en ligne de commandes (-param:NOM=valeur) ou dans un profil de conversion :	+	Le commutateur principal est '''-toXMLDRAW''' (permettant de générer un fichier XML Mapping, appelés "XMLDraw"), pour demander une sortie XML à partir du document XPS. Cette sortie est enrichie avec les arguments suivants et utilisables en ligne de commandes (-param:NOM=valeur) ou dans un profil de conversion :

← Version précédente		Version du 15 novembre 2019 à 13:41
Ligne 5 :		Ligne 5 :

	A partir de ce document XPS indexé, le principe est d’utiliser les valeurs d’un index particulier (par exemple sur le numéro de client = CustomerID dans notre cas) pour produire un fichier XML compatible M-Designer en y intégrant tous les calculs d’allotissements, les modulos de page et de séquence, les ruptures, etc…		A partir de ce document XPS indexé, le principe est d’utiliser les valeurs d’un index particulier (par exemple sur le numéro de client = CustomerID dans notre cas) pour produire un fichier XML compatible M-Designer en y intégrant tous les calculs d’allotissements, les modulos de page et de séquence, les ruptures, etc…
−	Le commutateur principal est '''-toXMLDRAW''', pour demander une sortie XML à partir du document XPS. Cette sortie est enrichie avec les arguments suivants et utilisables en ligne de commandes (-param:NOM=valeur) ou dans un profil de conversion :	+	Le commutateur principal est '''-toXMLDRAW''' (permettant de générer un fichier XML Mapping, appelé "XMLDraw"), pour demander une sortie XML à partir du document XPS. Cette sortie est enrichie avec les arguments suivants et utilisables en ligne de commandes (-param:NOM=valeur) ou dans un profil de conversion :

@@ Ligne 82 : / Ligne 82 : @@
 Significations:
 * boc : la marque de rupture est sur la première page de chaque lot (par défaut).
-* eoc : la marque de rupture est sur la dernière page de chaque lot.
+*boc : la marque de rupture est sur la première page de chaque lot (par défaut).
@@ Ligne 191 : / Ligne 192 : @@
 (***) Valeurs possibles de type de page :
 * start : première page du pli
-* middle : page intermédiaire dans le pli
+*start : première page du pli
-* end: dernière page du pli
+*middle : page intermédiaire dans le pli
-* start_end : une seule page dans le pli
+*end: dernière page du pli
 (****) La marque de parité permet d’avoir un nombre impair de barres.
@@ Ligne 204 : / Ligne 206 : @@
 Voici ci-dessous un exemple de modèle M-Designer :

← Version précédente		Version du 18 avril 2019 à 09:21
Ligne 199 :		Ligne 199 :

	==Ajout des codes OMR==		==Ajout des codes OMR==
		+
		+	La deuxième étape consiste maintenant à réutiliser le fichier XML de données préalablement constitué pour apposer sur le document XPS d’origine alors considéré comme un calque, les marques KERN devant piloter le matériel de mise sous plis.
		+
		+
		+	Voici ci-dessous un exemple de modèle M-Designer :

@@ Ligne 182 : / Ligne 182 : @@
   …
   </doc>
 ==Ajout des codes OMR==