JETZT AKTUELL ZU QUARKXPRESS 7.2!
Ein CMS-Workflow auf Basis von Job Jackets hat nicht nur Vorteile, sondern auch ein paar Nachteile. Diese sind sicherlich auch der Implementierung von Quark geschuldet. Im Moment gilt es aber, um diese Dinge herum zu arbeiten oder aber – falls es gar nicht anders geht – alternative Lösungswege zu suchen.
Der nachfolgende Bug wurde in QuarkXPress 7.2 behoben. Allen Anwendern des defaultjackets.xml sowie verfahrensangepasster Spazial-Jackets wird daher dringend die Durchführung dieses Updates empfohlen!
Bug in Zusammenhang mit defaultjacket.xml
Wird über “Neu von Ticket” auf Basis eines der Job Jackets ein neues Dokument erzeugt, so sind die Konfigurationen für Quelle und Ausgabe nicht richtig gesetzt. Die Evaluierung findet den Fehler. Dies geschieht nur dann, wenn als defaultjacket.xml ebenfalls eines der mitgelieferten Jackets gesetzt wird (etwa das für ISOCoated_v2_eci). Wird dagegen das “leere” Standard-defaultjacket genutzt, so erfolgt auch das CMS-Setup einwandfrei.
Es gibt also zwei Workarounds:
- Wird nur sehr selten auf vom Standard abweichende Ausgabebedingungen zurückgegriffen, so kann das defaultjacket.xml genutzt werden. Dieses sollte dann temporär ersetzt werden, wenn sich am Ausgabeziel etwas ändert.
- Wird in der Produktion mit vielen verschiedenen Ausgabebedingungen gearbeitet, so sollte unbedingt auf ein “spezielles” defaultjacket.xml verzichtet werden. Steuern Sie alle Job Jackets über “Neu von Ticket” an und deaktivieren Sie die mehrfache Nutzung (alternativ kann auch auf Finder-Ebene geschützt werden).
Dieser Bug besteht in Version 7.1. Es ist zu hoffen, das Quark hier in zukünftigen Versionen nachbessert. -> In Version 7.2 passiert!
Entfallener “Neu” Dialog beim erstellen eines Dokuments
Das fällt sicherlich am schnellsten auf: Beim gewohnten Erstellen eines neuen Dokumentes fehlt beim Einsatz des defauljacket.xml der altbekannte Dialog von Seitenformat, Rändern, Spaltenzahlen usw.
Dies ist leider einer etwas unglücklichen Umsetzung von Quark geschuldet: Sobald im Job Jacket konkrete Dokument-Vorgaben gemacht werden (hier konkret Quelle und Ausgabe und Proofing-RI) entfällt dieser Dialog, auch wenn seine Einstellungen hier gar nicht vom Job Jacket betroffen sind!
Das neue Dokument wird automatisch auf Basis der zuletzt »konventionell« erstellten Datei konfiguriert. Wurde zuletzt in A4 mit zwei Spalten auf Doppelseiten gelayoutet, haben auch die zukünftigen Job Jacket-Dokumente dieses Format. Das sollte bedacht werden, um hier eine saubere Ausgangsbasis zu erhalten.
Workaround zu dieser Sache ist das nachträgliche Ändern der Layouteigenschaften bzw. Musterseiten-Einrichtung.
XPert Tools Pro und das defaultjacket.xml
Kommt die neu verfügbare XTension XPert PageSets aus der Sammlung XPert Tools Pro in einer Umgebung mit dem defaultjacket.xml zum Einsatz, gibt es leider eine Inkompatibiltät. Der „Neu“-Dialog der XTension bietet zwar die Möglichkeit Stile für die Dokumenteinrichtung auszuwählen und zu erstellen, jedoch stimmen dann die CMS-Einstellungen des defaultjacket.xml nicht! Das enstehende Projekt hat zwei Layouts: „Layout 1“ mit der korrekten CMS-Konfiguration und „Layout 2“ ohne JJ-CMS-Einstellung. Dafür sind im „Layout 2“ dann die PageSet Einstellungen zum Tragen gekommen.
Es kann also aktuell nur davon abgeraten werden, die XPert PageSets XTension gemeinsam mit einem defaultjacket.xml einzusetzen!
Ändern des Job Jackets für Job Jacket-Laien sehr komplex
Da das Arbeiten mit Job Jackets hier nicht dem gewohnten „Vorgaben-Denken“ der XPress-User entspricht, gestaltet sich die Korrektur des Job Jackets u.U. etwas schwieriger. Möchte man etwa ein anders Ausgabesetting definieren, so muss dieses nicht nur zuerst korrigiert und gesichert werden, sondern auch anschließend im Job Jacket Manager beim entsprechenden Job Jacket zur Anwendung gebracht werden. Das erfordert ein gewisses Hintergrundwissen über die Zusammenhänge und ist auf jeden Fall nochmals ein zusätzlicher Lernschritt.
Auch wenn die notwendigen Schritte relativ simpel zu erklären sind, so dürfte das wohl trotzdem einige bereits abschrecken.
Georg Obermayr, Januar 2007
Browse Timeline
Comments ( 3 )
Jean-Claude Siegrist added these pithy words on Feb 26 07 at 2:32 pmA question: During the creation of a job ticket, in which ressources (where) have I to set that I want facing pages with an automatic text bloc for the layout of a classic book?
Thanks for your help![Georg Obermayr]: Here’s the workflow to achive your goal:
- Go to the Job Jackets Manager and choose “Advanced Settings”
- Create a new Job Jacket
- Select the Job Jacket and go to the “Layout Specifications”
- Create a new Layout Specification
- Define page size, count and the other needed parameters
- Unfortunately in QuarkXPress 7.1 you are not able to predefine master pages and automatic text blocks so you can not completely pre-setup a book with job Jackets. Maybe in the next version…
- Last Step, most important: Select the Standard Job TICKET, go to “Layout” and set your newly created layout specification in the corresponding tab.
Hope this helps.
Jens Baranek added these pithy words on Oct 22 07 at 1:22 pmIch habe mich zwar bisher erst kurz mit den Job Jackets beschäftigt, meiner Meinung nach ist das Konzept noch ziemlich unausgegoren.
Wenn es – wie ich das bisher verstanden habe – auf ein reines Preflight hinausläuft, bin ich mit der Software Flightcheck definitiv besser bedient.
Das ein Grafiker mittels der Job Jackets ein Layout prüfen kann, nützt mir als Reinzeichner in einer Werbeagentur gar nichts: In der Praxis darf ich mich jedem Kreativen 20 Minuten auf den Schoß setzen um das zu erklären, mir ein “Jaja” anhören und ändern wird sich gar nichts. Es werden dieselben mangelhaften Dokumente bei mir ankommen wie vorher auch.
Zu erwarten wäre gewesen, dass ein Job Jacket die Anlage nicht definierter Eigenschaften (z.B. falsche Farben) BLOCKIEREN kann – z.B. mittels einer Dialogbox “Diese Farbe entspricht nicht blablabla …”.
Stattdessen nur ein weiteres, kompliziertes und in meinen Augen unnötiges System – das kann ich meinen Mitarbeitern in der Kreation (und letzlich meinen Vorgesetzten) nicht vermitteln.[Georg Obermayr]: Ich denke nicht, dass ich Job Jackets jetzt hier verteigen muss, aber ein bißchen mehr als “nur Preflight” sind sie schon. Es geht um Sicherheit auf mehreren Ebenen: Es kann schon zum Vorteil werden, wenn beim Erstellen des Dokuments bereits Seitenzahl und -Format sowie andere Vorgaben richtig eingestellt sind. Es kann in vielen Umgebungen von Nutzen sein, wenn etwa Hausfaben oder Stilvorlagen von mehreren Dokumenten gemeinsam genutzt werden und diese sich dann bei Änderungen durchsynchronisiert werden. Natürlich kommt auch noch das erwähnte Preflight bei der Ausgabe dazu, aus meiner Sicht ergänzt das aber eher die bereits zuvor aufgespannten Sicherheitsnetze. Der von Ihnen genannte Fall, also der Hinweis auf Verbote während der Erstellung ist sicher richtig – hier ist Quark in der Pflicht. Umgekehrt muss man auch fragen: Wo hört sinnvolle Information auf und wo fängt Gängelung von Anwendern an?
Jens Baranek added these pithy words on Oct 23 07 at 1:20 pmDie Nützlichkeit von Vorgaben ist im Grunde nicht zu kritisieren, sie bleibt aber ein Muster ohne Wert, wenn keine Möglichkeiten bestehen, Vorgaben obligatorisch zu machen.
Für einen allein agierenden Grafiker mag es Gängelung sein, aber bei Arbeiten im Team z.B. einer Werbeagentur ist das alles nur eine Fehlerquelle mehr, solange die Mitarbeiter nicht gezwungen werden können, die Option “Projekt aus Ticket” auch zu verwenden.
Wünschenswert wäre, dass Quark hier Vorgaben ermöglicht, die als Option bestimmte Eingaben und Menüeinträge sperrt.
Im jetzigen Zustand wage ich es nicht, unseren Mitarbeitern die Job Jackets zur Pflicht zu machen. Es käme nur dabei heraus, dass Projekte genauso mangelhaft bei mir ankommen wie vorher auch, mit einem einzigen Unterschied: Es wären dann Projekte MIT und OHNE Job Jackets – ehrlich gesagt, dann habe ich lieber nur Dokumente OHNE Job Jackets, als auch noch nach den zusätzlichen Fehlerquellen weiterer Optionen zu suchen.
