Post by La Bete des Vosges (Francis Chartier)Oui, point 0 pour les règles X et Y de la page/du document.
Pas de déplacement des éléments par rapport au format de doc, juste un
déplacement aléatoire (en tout cas je n'ai rien trouvé qui permette de
comprendre le pourquoi, ni qui semble avoir un rapport avec la valeur du
déplacement) de l'origine des règles..
Rien de grave, juste un défaut pour quelque chose qui fonctionnait
correctement auparavant.
Avec ou sans flux, votre RIP semble dépendre de ce paramètre.
Post by La Bete des Vosges (Francis Chartier)Tout le monde ne travaille pas avec des flux pré-presse d'un editeur X ou
Oui, ayant une culture des flux de production depuis une dizaine
d'années, il faut que j'arrête de prendre mon cas pour une généralité...
Post by La Bete des Vosges (Francis Chartier)beaucoup de petits imprimeurs réalisent leurs
propres impositions "à la main" parce que leur parc machines (nombre de
groupes et format) ne justifie pas l'achat d'une solution Pandora+Prinergy
par exemple.
Dans ce cas, on utilise des gabarits sous Illustrator faits avec ses
petits doigts, et on monte des PDF des documents à imposer en respectant
des cotes précises par rapport au gabarit d'imposition.
Chapeau bas ! Désolé, je dois décidément être déconnecté de certaines
réalités. Les gens qui montent "encore" à la main des impositions sur
Illustrator (ou XPress, InDesign, etc) ont du mérite et m'inspirent du
respect. Il est dommage qu'ils aient parfois (souvent !?) à subir, au
sein de leur entreprise, un manque de considération et de reconnaissance
(à plus d'un titre...) malgré la charge de travail qu'ils fournissent.
En environnement prépresse, la nécessité d'automatiser certaines tâches
pousse à la course à l'armement en termes d'investissements en logiciels.
Cela peut être un mal pour un bien quand tout marche comme sur des
roulettes. Dans ce cas, l'utilisateur profite alors d'un certain confort
de travail, non pour satisfaire son plaisir personnel (même si ça compte
aussi !) mais pour assurer la bonne marche de l'entreprise. De plus,
cela permet de se concentrer sur son métier tout en s'affranchissant
d'étapes longues, répétitives et sources d'erreur(s).
Par exemple, un premier opérateur chargé de "sécuriser" une brochure va
préparer chaque page afin d'en figer la structure (incorporation et/ou
vectorisation des polices, etc) de manière à pouvoir, à partir d'un
fichier unique, faire un PDF de relecture, une sortie papier à telle
résolution avec tel profil colorimétrique, avec ou sans gamme de
contrôle. Ensuite, un deuxième opérateur montera ces pages uniques dans
une imposition sans avoir à se préoccuper d'éventuelles questions de
polices ou d'images manquantes.
En revanche, l'inverse (un bien pour un mal) peut se produire et, même
avec la présence permanente d'un administrateur spécialisé, le moindre
petit incident peut se révéler difficile, voire impossible à résoudre
sans le recours à un support technique. De ce point de vue, une
automatisation à outrance peut conduire à des contraintes et autres
effets pervers qu'il faut savoir prendre en compte :
- la nécessité d'une vigilance permanente obligeant l'administrateur à
bien connaître l'architecture (souvent client/serveur) de ses flux :
sauvegarde, entretien et maintenance, mise à jour, stratégie de
production, amélioration de l'ergonomie pour l'opérateur, information et
formation de ce dernier ;
- le risque de multiplier les talons d'Achille car, dans une
architecture relativement complexe, un fichier "se promenant" d'un
serveur à l'autre selon un besoin donné, peut faire l'objet d'un blocage
quelconque ou d'un échec : si un des serveurs s'arrête (quelle que soit
la raison : plantage, erreur logicielle, fichier soumis non conforme,
etc) tout ou partie de la production s'arrête également ;
- la déshumanisation du métier de l'opérateur qui, s'il est mal formé
aux flux, peut vite être désorienté et avoir le sentiment de passer pour
un presse-bouton : perte de repères et d'autonomie, et même de
compétences au point de ne plus savoir effectuer certaines tâches
manuellement si le flux fait défaut (en pareil cas, il se peut que
l'opérateur n'ait, de toute façon, aucun recours alternatif rapide à
mettre en œuvre), ou encore la propension à se reposer sur (ses
lauriers) la technologie "qui sait tout faire" tout en négligeant des
étapes de contrôle décisives sur les fichiers.
A mon humble avis, il faut trouver le juste équilibre entre
automatisation et travail manuel en donnant à l'opérateur une marge de
manœuvre, c'est-à-dire un mode interactif (à travers un mode opératoire)
lui permettant de prendre les bonnes décisions et d'appliquer les bonnes
pratiques avant de soumettre un fichier à un flux d'automatisation.
Par exemple, en préparation de fichiers de packaging avec ArtPro,
l'opérateur va réceptionner le fichier fourni par le client, évaluer son
exploitabilité et sa conformité à un cahier des charges (à l'aide d'un
outil comme PitStop Pro) et à un dossier de fabrication (lié au Bon de
commande du client), convertir ce fichier en format ArtPro.
Pendant cette étape de conversion, ArtPro va certifier le fichier source
à l'aide d'un profil PitStop, "nettoyer" le fichier ArtPro, signaler un
filet trop fin, tout en ayant forcé les noirs purs à 100 % en
surimpression, supprimé les couleurs inutilisées et uniformisé les
suffixes des tons directs Pantone, vectorisé les textes à la volée, etc.
Une fois la pose unitaire ArtPro mise en conformité (vérification du
tracé de découpe et recadrage de la Zone Découpe sur ce dernier,
traitement des couleurs, application de grossis-maigris, et j'en
passe...) et finalisée par l'opérateur, elle est soumise à un flux de
sortie papier pour épreuve et/ou de génération d'un fichier de relecture
via un RIP PDF (par opposition à un RIP PostScript).
Ensuite, ArtPro dispose d'un module (PowerStepper, en option) de
répétition de pose (dont les fonctions d'imposition automatisent des
tâches sans avoir recours à un flux dédié) qui consiste à interpréter un
fichier CFF2 (dont le tracé est conforme à l'outil de découpe, et qui
contient des informations de positionnement et de retournement de pose)
permettant à l'opérateur de définir les zones de page par rapport à
l'encombrement du tracé, puis de placer exactement les poses unitaires
sans se soucier de leurs coordonnées !
Enfin, après relecture de la pose unitaire par le client et obtention de
son Bon à graver, un export PDF unique de l'imposition est créé. Après
contrôle du PDF à l'écran, le fichier est soumis à deux flux distincts.
Le premier flux rippe (toujours sur le même RIP PDF) le fichier (en
conservant et en aplatissant toutes les couleurs, y compris les couleurs
techniques : réserves de vernis, tracé de découpe, etc) pour une sortie
composite sur papier en basse résolution. Cette sortie est contrôlée et
comparée au calque de tracé conforme à l'outil de découpe.
Une fois la sortie papier validée, le deuxième flux (qui, entre-temps et
sur ordre de l'opérateur, a déjà supprimé les couleurs techniques du
PDF) permet à l'opérateur d'adresser le fichier à une sortie appropriée
(en fonction du type d'impression, telle courbe de compensation
d'engraissement du point de trame sera appliquée, et des angles de trame
seront ou non forcés, etc) en séparation in-RIP (génération de
Tiff/1bit) pour flashage des plaques sur le CTP.
Voilà : un protocole parmi tant d'autres.
Post by La Bete des Vosges (Francis Chartier)L'utilisation d'un point origine immuable par rapport à des éléments
positionnés sur un calque (début d'une bande de roulement, système de
tétonnage, etc) permet de systématiquement monter les impos en étant
certain du repérage par rapport aux éléments pré-existants (forme de
découpe, cliché de dorure/gaufrage/foulage, forme déjà existante pour les
fonds ou certaines couleurs, etc.)
Sur la machine pour laquelle je bosse la plupart du temps (semi-
rotative), la laize papier utilisée est variable en fonction de la forme
de découpe et le format de cliché est donc également variable : on se
base sur une origine systématiquement située au centre du cliché dans la
laize (centrée sur la machine pour faciliter les réglages de pression des
groupes) et à 1,5mm en amont du premier filet de coupe en avance plutôt
qu'au bord du cliché, dont le positionnement est variable sur la machine.
Votre expérience montre bien que, d'un procédé d'impression à un autre
(je fais des fichiers pour de l'offset feuille à feuille), les
contraintes de préparation sont très différentes. Chaque imprimeur
choisissant une technologie plutôt qu'une autre et cette dernière
déterminant le protocole de production à mettre en place, il est
d'autant plus laborieux d'expliquer au client que tel PDF 1.3 soi-disant
universel ou tel EPS n'est pas forcément exploitable chez un imprimeur
ou un autre.
Post by La Bete des Vosges (Francis Chartier)Le gabarit ouvert sous Illustrator CS4 conserve son origine de règles à
cet endroit, ouvert sous CS5 elle sera ailleurs. Déplacée, "enregistrée
sous" ou crée avec un nouveau document elle changera encore de place,
sans aucun moyen de la figer à l'endroit voulu.
Et son emplacement n'est au centre d'aucune des dimensions, ni au centre
des éléments graphiques, que ce soit pour le document entier ou pour le
calque actif. Je cherche encore la logique du truc.
Ne connaissant pas Illustrator CS5 (je sais, c'est étonnant...), y
aurait-il une option qui permettrait de charger ou non les préférences
(origine, etc) du fichier à son ouverture (cette option existe, par ex.,
sous ArtPro) ?
Post by La Bete des Vosges (Francis Chartier)Mac, je n'ai pas de PC avec CS5 sous la main, pour des raisons
historiques plus que techniques quasiment tout le monde travaille sur mac.
Loin de moi l'idée de troller (inconsciemment ou non) en lançant le
sempiternel débat Mac/PC. C'est juste intéressant de connaître les
différences de comportement de cette application, s'il y a lieu, entre
ces deux environnements, surtout quand on est amené à faire un choix de
matériel sur un site de production.
Post by La Bete des Vosges (Francis Chartier)Tout à fait d'accord, mais ils semblent oublier que se moquer des
attentes du client à conduit Quark là où ils en sont aujourd'hui, alors
qu'ils dominaient outrageusement ce marché dans les années 90. La roue
tourne...
Oui, quand la première version de InDesign est sortie, beaucoup
d'utilisateurs (virtuoses) de XPress avaient juré mordicus qu'ils ne
passeraient pas au nouveau logiciel de Adobe. Depuis, ce sont les mêmes
qui ont viré leur cuti.
Evidemment, InDesign n'a pas évité les erreurs de jeunesse (souvenir
catastrophique du pilote PostScript de la version 1.5...) mais,
désormais, il y avait enfin des passerelles directes avec Illustrator et
Photoshop, et un moteur typographique autrement plus performant (juste
avec ses réglages par défaut) que celui de XPress.
Ce dernier, dans sa version 6.5 par ex., forçait un aplatissement des
transparences lors d'un export en PDF 1.4 !? Effaré, un technicien
spécialiste d'un flux d'automatisation m'avait rétorqué, en apprenant ce
comportement : "Ils ont vraiment envie d'arrêter la PAO, chez Quark !?".
Aujourd'hui, vu de ma fenêtre (c'est-à-dire celle du service prépresse
dans lequel je travaille), la réception de fichiers XPress est devenue
rare et les fichiers PDF issus de ce logiciel minoritaires par rapport
aux exports PDF de InDesign...
Post by La Bete des Vosges (Francis Chartier)toujours les mêmes habitudes de travail, parce qu'un tirage à refaire
coûte cher en temps machine, planning foutu en l'air et consommables.
Oui, plus le dossier de fabrication avance dans la chaîne de
fabrication, et plus le coût de revient augmente de manière
considérable, surtout quand on franchit le seuil critique du numérique à
l'analogique.
Post by La Bete des Vosges (Francis Chartier)mais
quand il s'agit d'un acheteur, d'un commercial ou du client final c'est
souvent techniquement et "politiquement" difficile d'obtenir quelque
chose de concret.
Voici les quelques critères de qualité d'un acheteur : les quantités, le
tarif et le délai. Quant au reste...
Petite conversation téléphonique entre un collègue fabricant et un
acheteur :
- l'acheteur : "Dites, vous pensez pouvoir tenir le délai de livraison
pour la semaine prochaine ?"
- le fabricant : "Euh... c'est un peu délicat : vous nous aviez déjà
fourni les fichiers soi-disant "prêts à flasher" un peu en retard, et
maintenant que nous vous avons soumis nos fichiers de relecture, vous
nous demandez de procéder nous-mêmes à des corrections de texte qui
semblent simples à réaliser (tout en n'étant pas de notre ressort) alors
que ces textes sont initialement vectorisés (ou alors les polices de
caractères sont bien incorporées dans le PDF, mais en jeux partiels)...".
Dialogue de sourds...
Cordialement,
Christophe