Forme test PDFX-ready V3 pour PDF/X-4

[nadmad]

Bonjour à tous !

Je dois passer la Forme test PDFX-ready V3 dans notre flux "Prinect". Cela permet de tester si notre flux supporte les PDF/X-4.
Je rencontre un problème dans l'item N°7. (cf image jointe).

Est-ce que l'un de vous a eu ce problème ? C'est un problème de gestion de surimpression, d'OPM0 OPM1. J'avoue je suis un peu perdue.
J'ai tenté de cocher, décocher des options dans le flux mais rien n'y fait.

A noter qu'il passe bien quand je le passe en traitement CMJN, mais en CMJN+SPOT : j'ai une croix sur le fichier.

Nadège

Ce message a été modifié par nadmad - 9 Apr 2015, 10:46.

Fichier(s) joint(s)

 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 19
 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 6
 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 3
 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 0
 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 0
 pdfx4.png ( 33.52 Ko ) Nombre de téléchargements : 5

 

[Cri-cri]

Bonjour et bienvenue sur MacBidouille

Etant un des membres actifs du GWG, je vais pouvoir te répondre sur le sujet !

Tu fais une confusion sur la raison.
Ici, la croix t'indique qu'il y a eu une conversion en CMJN en amont (donc ton patch n'est plus en DeviceN), d'où le problème.

Le mode de surimpression OPM 1 (le plus courant aujourd'hui, dit mode Illustrator) est utilisé, et te donne ce résultat.
Si tu étais en mode OPM 0 (l'ancien mode des systèmes de prépresse), tu ne verrais pas la croix (du fait du mode de calcul de l'overprint), mais le flux ne serait toujours pas bon.

Conclusion : regarde s'il n'y a pas une conversion couleur spot -> CMJN en amont, et si oui, il faut corriger ce problème.

[trouspinette]

Bonjour et bienvenue sur MacBidouille

Etant un des membres actifs du GWG, je vais pouvoir te répondre sur le sujet !

GWG ?

Grossen Wagonnet Gallon ?

Gang des Wappitis Grecs ?

Grog au Whisky et Gin ?

Ok, je te jure, je sors ;-)

[nadmad]

Merci Cri-cri !

Merci pour ces infos. Hier j'ai réussi à sortir la forme en décochant "conserver la transparence". Ce qui me parait cavalier

Pour l'hypothèse d'un pantone traduit en CMJN : pourtant cette première page test ne contient pas de pantone à priori, et surtout je le passe dans la file qui a ordre de ne pas écraser les pantones. (file qu'on utilise quotidiennement).

Et finalement, qu'est-ce qu'on appelle "deviceN" ?

[Cri-cri]

En fait, ce patch est un peu "tricky"
(et désolé, je t'ai un peu induit en erreur en parlant de spot color, ce qui n'est pas le cas dans ce patch - je suis allé regarder de nouveau de plus près la construction et c'est réellement du DeviceN utilisé)

Il n'y a pas de ton direct (= spot color*) dans le fichier, mais une forme en 0C, 0M, 0Y, 0K, donc non présente dans aucune des séparations quadri, et donc vue comme couleurs multiples (= DeviceN)

 DeviceN.png ( 127.18 Ko ) Nombre de téléchargements : 7


Cet objet est en surimpression d'un autre objet dessous (la croix en 100M 100Y).

 Surimpression.png ( 122.92 Ko ) Nombre de téléchargements : 7


Explication du comportement de la surimpression (rappel: la surimpression se calcule séparation par séparation):
On est en OPM1, cela veut dire que 0% est transparent, c'est le mode actuel de calcul de superposition.
Donc, en OPM1, un objet à 0% dans une certaine séparation laisse voir ce qui en-dessous.

En OPM0, le 0% est opaque, et il faut spécifiquement dire quand on souhaite un objet "transparent" (c'est le mode classique des anciens systèmes de photogravure tels Scitex, Hell, etc.)
Ce mode n'est plus utilisé aujourd'hui (du fait de la reprise en main des prestations prépresse par des technologies type "Adobe"). Ce mode existe toujours pour des raisons de compatibilité en cas de reprise d'anciens fichiers.
Ce mode est très perturbant, car on peut avoir un objet en surimpression qui défonce !

Explication en détail du patch:
Ici, dans ce fichier, nous avons un élément DeviceN, donc dans aucune séparation C, M, Y ou K, donc la surimpression ne se calcule pas et l'objet, bien qu'en mode de surimpression, défonce les objets en dessous et les masque (en particulier, la croix rouge en M & Y).

Si l'objet est converti en amont en CMYK, il a donc une interaction avec ces séparations, et la surimpression ce calcule. Dans ce cas, puisque en OPM1, l'objet devient transparent par rapport aux objets en dessous et donc laisse voir la croix rouge. (en OPM0, il reste en défonce puisque 0% est opaque, voir ci-dessus).

L'objectif de ce patch est bien de voir si le DeviceN est converti ou pas en amont dans le flux. Si oui, la croix apparaît donc erreur, sinon, la crois est masquée est c'est bon.

Voilà, j'espère que c'est plus clair, encore désolé pour la confusion, je t'ai répondu rapidement entre deux portes sans regarder en détail le patch.



* Attention, Pantone = spot color, mais pas l'inverse, on peut avoir d'autres types de spot color, comme les couleurs nommées par exemple (Rouge Coca, Jaune La Laitière, etc.)

** DeviceN veut dire que ce n'est pas de la quadri (= DeviceCMYK) ou du RVB (= DeviceRGB), mais cela représente les objets en multi-couleurs (non spot)

*** Pour trouspinette, GWG = Ghent Workgroup ...et Grossen Wagonnet Wallon, ça fait GWW

[nadmad]

merci pour toutes ces infos ! c'est plus clair !

J'ai beau chercher une histoire de conversion dans les paramètres mais rien de concluant.
Si je décoche juste ce fameux "conserver la transparence", c'est triché ?

Ce message a été modifié par nadmad - 10 Apr 2015, 09:55.

Fichier(s) joint(s)

 Capture_d_____cran_2015_04_10____10.53.57.png ( 74.73 Ko ) Nombre de téléchargements : 13
 Capture_d_____cran_2015_04_10____10.54.42.png ( 86.15 Ko ) Nombre de téléchargements : 10
 Capture_d_____cran_2015_04_10____10.54.50.png ( 112.43 Ko ) Nombre de téléchargements : 5
 Capture_d_____cran_2015_04_10____10.54.58.png ( 69.87 Ko ) Nombre de téléchargements : 6
 Capture_d_____cran_2015_04_10____10.55.03.png ( 79.07 Ko ) Nombre de téléchargements : 4

 

[Cri-cri]

Oui, si tu décoches "conserver la transparence", cela veut dire que tu perds toute notion de transparence et, j'imagine, tu fais un aplatissement de transparence (car sinon, c'est just rendre opaque des objets transparents, et là, bonjour les dégâts, résultat visuel modifié).

D'après les écrans que je vois, je dirais que c'est peut-être ce réglage qu'il faudrait changer :

 Prinect.png ( 89.88 Ko ) Nombre de téléchargements : 20


Car c'est bien de cela qu'il s'agit, d'un blanc quadri, mais qui devrait défoncer au lieu d'être en surimpression...

Après, je ne sais pas si Prinect respecte les normes du GWG. En tout cas, il ne sont pas "complaint" (= ils n'ont pas passé les tests de certification, et rien en dit que leur système fonctionne parfaitement). Je t'invite à te rapprocher d'Heidelberg pour leur remonter ce problème... après tout à eux de le régler et te dire comment faire

[nadmad]

Notre audit vient de se terminer. L'option de décocher "conserver la transparence" dans la première capture écran a convenu à notre auditeur.

Merci beaucoup pour ton aide

[Cri-cri]

Et bien alors votre auditeur une brèle...

Ne surtout pas faire ça !!!

[trouspinette]

*** Pour trouspinette, GWG = Ghent Workgroup ...et Grossen Wagonnet Wallon, ça fait GWW

J'ai corrigé ma boulette => Gallon !

Tiens, et un autre PitStop2Switch... mais pas tout seul :-(

Et bien alors votre auditeur une brèle...

Hi, Hi ! J'adore tes commentaires

[nadmad]

Voilà un jugement bien rapide Pas très respectueux à mon goût...

(la case que tu me proposais, je l'avais testé et ça ne changeait rien)

Merci de ton aide.

[Cri-cri]

"Corriger" un problème en en introduisant un plus grand, je ne vois pas vraiment comment qualifier cela différemment !

J'en ai suffisamment vu des "soit-disant" auditeurs ou consultants qui préconisent n'importe quoi, en se moquant des conséquences ensuite en production.
Ils ont "leur" résultat et peuvent facturer donc leur "prestation"... Ensuite, les dégâts, ce n'est plus leur problème.

Je suis passé un jour chez un client derrière ce genre de personne, car ce client avait eu de gros soucis et sur deux dossiers, et des coûts TRES importants à prendre en charge.
Qu'ai-je vu ? Exactement la même chose que ce que tu décris... réglage à la va-vite pour faire correspondre un outil d'évaluation à un résultat attendu... sans se préoccuper de comment on le fait, le pourquoi et les implications du changement (bien sûr quand on ne sait pas ce que l'on fait, c'est difficile de comprendre les risques)

Tu ne nous as jamais dit que tu avais un auditeur dans tes murs et que c'est pour cela que tu cherchais cette réponse (je l'ai découvert à la fin de ton fil) - il me semble que si tu as eu affaire à un vrai professionnel, tu n'aurais pas eu à venir demander de l'aide ici...
De deux choses l'une, ou ton "auditeur" est un pro, et il sait ce qu'il faut faire (et il le fait, sans avoir besoin de personne), ou c'est un branque, qui utilise un outil qu'il ne comprend pas, mais fait semblant d'être un pro en l'utilisant (il pense que cela le rend intelligent).

Le malheur de cette suite du GWG, c'est que cela permet à certaines personnes de faire des choses qu'elle ne pourraient jamais faire sans ce support. Mais pour l'utiliser intelligemment et corriger les erreurs d'un flux ou d'un outil, il faut tout de même avoir de solides connaissances. Et encore une fois, je doute que ce soit le cas de ton auditeur, s'il s'est satisfait de la "tricherie" (je reprend tes mots) que tu as appliquée...

As-tu seulement repassé TOUS les patches de la suite ? Tout est toujours correct ? As-tu mesuré la colorimétrie avant et après sur un ensemble de fichiers ? Sais-tu exactement ce que tu viens de faire en cochant cette case ? Ton "pro" t'as-t-il expliqué les tenants et aboutissants de ce choix ?

Je répète ce que j'ai déjà dit plus haut, Heidelberg Prinect n'est pas certifié GWG, rien ne dit que le flux traite correctement TOUS les cas de la suite (ce qui ne veut pas dire que ce soit un mauvais système, d'autant plus que certains cas de la suite sont rares, donc ont peu de chances de se produire en prod). A Heidelberg de te dire comment régler ton flux pour que TOUS les patches de la suite soient corrects...

Maintenant, à nouveau, si tu penses qu'un bricolage (risqué, je le répète) a résolu ton problème et que cela te convient, parfait, mais ne dis pas que je ne t'aurais pas prévenu...


Pour info, la liste des applications "compliant" GWG = ayant officiellement réussi le test : http://www.gwg.org/download/overview-of-gw...t-applications/

[Guest_claude72_*]

D'après les écrans que je vois, je dirais que c'est peut-être ce réglage qu'il faudrait changer :

 Prinect.png ( 89.88 Ko ) Nombre de téléchargements : 20


Car c'est bien de cela qu'il s'agit, d'un blanc quadri, mais qui devrait défoncer au lieu d'être en surimpression...

Il est possible que cette fonction corrige le problème de conversion du DeviceN en CMJN, mais plutôt de façon indirecte en corrigeant le résultat de l'erreur de conversion en CMJN...

Mais ce n'est pas le rôle original de cette fonction, qui est en fait dans la lignée de ces fonctions que les éditeurs ont ajouté dans leurs RIP pour corriger automatiquement les conneries connues, répertoriées et récurentes des graphistes incompétents qui font n'importe quoi sans comprendre les conneries qu'ils font et qui ne savent pas contrôler leurs fichiers...

... et, comme tu le sais, le blanc (spot ou CMJN) en surimpression est une de ces conneries connues et récurentes que font les brèles de tout acabit, qu'ils ne voient pas à l'écran puisqu'ils n'activent pas l'affichage des surimpressions, et donc l'erreur devient visible seulement après une impression sur une imprimante PostScript... mais comme ce genre de brèle n'a bien-sûr pas d'imprimante PostScript, le problème n'est visible que lors d'un contrôle soigneux du PDF par l'imprimeur, ou en sortie de RIP, sur les rasters pour ceux qui ont un flux, sur les films/plaques pour ceux qui n'ont qu'un simple RIP !



**********


En revanche, ce qui m'étonne dans la capture d'écran du réglage des surimpressions du flux de nadmad, c'est que cette fonction ne soit pas déjà cochée, de même que la fonction de surimpression automatique du noir au-dessus de 100% (perso j'aurais mis plutôt 95-98%), et l'option de conversion du gris en K ???

Alors j'espère que c'est volontaire, ou que nadmad nous montre des captures d'écran de son flux non-réglé et avant l'audit ???
... parceque sinon, si elle a oublié de cocher ces options ça peut révéler un certain manque de maîtrise des options du flux et si l'auditeur a laissé ces réglages tels-quels ça montre qu'il est encore plus incompétent que Cri-cri le constatait !

Ce message a été modifié par claude72 - 12 Apr 2015, 14:09.

[Cri-cri]

Hello Claude

Oui, oui, je me doute bien qu'il s'agit de la correction du blanc en surimpression, et comme tu le dis, c'est un des, sinon le plus, fréquent(s) cas rencontré(s) des basiques

Dans les écrans que j'ai vu, c'est le seul réglage qui aurait pu corriger le problème évoqué (probablement par rebond comme tu le dis), et comme tu l'as lu, je n'ai pas affirmé que c'était ça, mais cela pourrait être ça (nuance )

Comme je ne connais pas Prinect (les vrais pros disent ce qu'ils savent et ce qu'ils ne savent pas ), je ne sais pas exactement où est ce foutu réglage pour corriger le problème décrit initialement au début du fil... s'il existe ! Encore une fois, si le flux utilisé faisait partie des applications officiellement conformes, on saurait que ça existe et on pourrait dire où cela se trouve. Ici, on est avec un flux non officiellement reconnu comme conforme (ce qui ne vaut pas dire qu'il ne le soit pas), donc impossible de dire s'il y a une réelle solution (à part viander son flux pour le plaisir des pseudo auditeurs )

[Guest_claude72_*]

Hello Cri-cri (et amitiés aussi à trouspinette )

Oui, oui, je me doute bien qu'il s'agit de la correction du blanc en surimpression...

Et je me doute bien que tu le sais ! je dirais même plus : je suis sûr que tu le sais ...

... mais en fait, bien que répondant à une citation de ton post, ma réponse était aussi/surtout destinée à nadmad

... et comme tu l'as lu, je n'ai pas affirmé que c'était ça, mais cela pourrait être ça (nuance)

Tout à fait d'accord avec toi (y compris pour la nuance ) : en fait ça pourrait être un bon "workaround" pour faire passer le patch... très certainement meilleur que de bricoler n'importe quoi sur les transparences !!!

Mais surtout, à mon avis, c'est une fonction indispensable en production.

(qu'est-ce que j'aurais été heureux si j'avais eu ça dans mes RIP... y'en a qui ne connaissent pas leur bonheur !!!)

[Cri-cri]