Hallo Leute,

gestern Nacht kam ich nun endlich dazu mir eine erste Pre-Relase von Quark anzuschauen und möchte nun einen ersten Erfahrungsbericht abgeben.
Ausprobiert habe ich die Tabellenfunktion - das ansteuern ist noch immer etwas eigen, dennoch eigentlich sehr einfach, wenn man weis wie es geht. Die Tabelle kann in der Zwischenzeit auch auf einem durchscheinenden Hintergrund platziert werden. Tabellen benutze ich gerne bei strukturierten Eingaben (Preislisten oder so..). Auch für den Transfer zu HTML-Seiten eignet sich so eine Tabelle ungeheuer um so schöner, dass diese Funktion nun auch anspruchsvolleren Gestaltern gerecht wird.
PDF-Export direkt aus Quark. Lang ersehnt nun endlich wahr geworden. Das Interface für die Ausgabe ist dem PDF-Filter in der letzten Version sehr ähnlich und somit für viele sicherlich genauso intuitiv zu bedienen wie bisher gewohnt, nur müssen jetzt auch wirklich die scharfen Einstellungen in Quark gemacht werden. Die Qualität der PDF's habe ich zwar noch nicht geprüft - das werde ich aber schnellstens nachholen. Was aber denke ich der wichtigste Faktor ist, PDF's werden nun aus dem Programm selbst generiert.
Die XML-Ecke habe ich mir kurz angesehen, sah sehr vertraut aus, jedoch konnte ich noch keine genaueren Tests durchführen - Ihr könnt Euch sicherlich vorstellen - die liebe Zeit, es gibt einfach zu wenig davon.
Das war es vorerst von mir, sobald ich mehr Erkenntnisse habe werde ich das hier wieder posten.


Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

>> Was aber denke ich der wichtigste Faktor ist, PDF's werden nun aus dem Programm selbst generiert.

die druckvorstufen-menschen heulen laut auf...! :-( :-)

gruss. gremlin

(((aussage basierend auf der kenntnis, dass der weg über ps/distiller - und nicht über programmeigene pdflibs! - noch immer der beste ist für die druckvorstufe, sowie der bekannten hmmm... "schwäche" von xpress in sachen postscript. weshalb sollte pdf besser laufen...? [vorurteil, ich weiss!])))

Hallo Gremlin,

das ist nur zur Hälfte korrekt.
Quark wird in der Version 6 von QuarkXPress die PDF-Bibliothek von Global Graphics einsetzen. Diese basiert auf dem JAWS PostScript-Interpreter. Was also passiert ist, dass QuarkXPress 6 eine PostScript-Datei generiert und diese sofort mit Hilfe der PDF-Bibliothek interpretiert und in PDF umgesetzt wird.
Somit ist tatsächlich entscheiden, dass QuarkXPress 6 sowohl guten, PostScript 3 konformen und composite Workflow tauglichen PostScript-Code generieren kann und dass die PDF Bibliothek fehlerfrei arbeitet und hochwertige, effiziente PDF-Dateien generieren kann.

Da wir die JAWS/Global Graphics Bibliotheken sehr gut kennen (wir vertreiben die Produkte JAWS PDF Creator und JAWS PDF Server) bin ich bei letzterem Part sehr zuversichtlich. Was die PostScript-Qualität betrifft, sieht es momentan auch so aus, als ob sich nach vielen Jahren der Lethargie seitens Quark endlich etwas tut. Hervorzuheben sind in diesem Zusammenhang die beiden neuen Ausgabemodi "DeviceN" und "Im Istzustand" (wer hat sich bloß diese Übersetzung ausgedacht?). Es wäre aber noch zu früh um in vorschnelle Euphorie zu verfallen.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

da hab ich natürlich wieder den spezialisten provoziert... ;-)

wie angedeutet: meine aussage war natürlich sehr vorurteilsbehaftet und sarkastisch. aber ihre aussagen, herr zacherl, klingen doch sehr zuversicht erweckend! auf jeden fall wäre es toll, wenn aus xpress direkt vorstufen-gerechte pdf erstellt werden könnten!

vielen dank für ihre reaktion.
gruss. gremlin

Hi nochmal,

@gremlin:
Kritisieren ist schon einfach, wenn man es dennoch tut sollte man sich erst einmal die Basics reinziehen.

@Robert:
Danke für Deine Antwort, somit muss ich nun nicht alles schreiben sondern mich einfach nur Deiner Meinung anschließen.

Allgemein finde ich es in der Zwischenzeit beschämend, welches Denken in Druckvorstufenbetrieben oder Druckereien manchmal verfolgt wird. Entweder gibt es in dieser Ecke den "hörigen" Kunden der selbst den letzten Schwachsinn des Verkäufers akzeptiert, oder alles wird durch den Kakao gezogen und ersteinmal schlecht gemacht, ohne sich überhaupt kundig gemacht zu haben.
Schade dass es so wenige Vernünftige und Interessierte an der Sache gibt, denn die anderen Leute hätten so wirklich viel Geld gespart, wenn sie Leuten die von ihrem Job Ahnung haben und nicht einfach nur etwas erzählen zugehört hätten. Das ist auf jeden Fall meine Erfahrung aus jetzt 15 Jahren graphische Industrie - sorry wenn das nun etwas deutlich ist aber mir ist einfach der Kragen geplatzt.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

@conny

jetzt bin ich aber gehörig enttäuscht von dir. du dürftest anhand der schon zwischen uns stattgefundenen diskussionen und an anderen meinen beiträgen wissen, dass ich nicht einfach drauflosschwatze ohne grundlage. auch sollte zumindest mit der verdeutlichung in meinem zweiten posting in diesem thema allen klar sein, dass meine aussage nicht unbedingt ernstzunehmen war.

gruss. gremlin

ps: ein smiley bedeutet, dass man bei der entsprechenden aussage lacht/lächelt/die sache nicht ernst meint.

Hi Gremlin,

in gewisser Weise hast Du schon recht, und der letzte Teil meines Postings galt auch nicht Dir, sondern der allgemeinen Frustration, von Leuten meines Schlages und mit meiner Tätigkeit. In den letzten Jahren vermehrt es sich immer mehr, dass solche "das Problem lösen wir schon" Typen immer wieder gewinnen obwohl keinerlei Erfahrung oder Wissen vorhanden ist, wenn es um Jobs geht. Das ärgert mich schon seit langem und leider trafst Du mit Deinem Kommentar voll auf die wunde Stelle.
An weiteren Antworten die ich Dir danach gab, solltest Du aber auch erkannt haben, dass es mit meinem Posting dann aber auch erledigt war. Ich bin leider ein impulsiver Mensch und ich hoffe Du kannst das ein wenig verstehen - auf jeden Fall meine ich so etwas selten persönlich und ab und zu muß einfach mal das Ventil aufgemacht werden.
In diesem Sinne auf weitere gute Diskussionen - übrigens Deinen Smily sah ich gar nicht, da ich direkt vom Maileingang aus geantwortet habe.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Soso, PDF-Export mit einer dazulizenzierten PDFLib...
Das läßt wirklich hoffen!
Interessant wäre aber auch, ob XPress 6 nun auch
PS 2 und/oder 3 versteht (EPS) und ausgibt.
Ich will nun wirklich nicht immer über PS/PDF gehen,
wenn ich zB ein Proofgerät ansteuern will.
Können jetzt Sonderfarben aus EPSen erkannt werden?
Ich arbeite mit Version 4 und habe auch 5 - nur dies
hier noch nicht ausprobiert.
Ich hatte letztens wieder Schwierigkeiten eine Sonderfarbe
in das XPress-4-Dokument zu bekommen und mußte dann erst Level-1
EPS schreiben.
Conny, du schreibst nichts über die Geschwindigkeit unter
OS X bzw. das Problem mit dem Bildschirmaufbau. Ist das jetzt
besser oder hattest du eine Win-Version?

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Hi Oliver,

die Pre-Versions laufen auf beiden Systemen. Getestet habe ich aber auf meinem Titanium.
Bildschirmaufbau - da kein Wechsel zu Classic mehr erfolgt, ist das Thema vom Tisch, weiter bin ich allerdings aus Zeitgründen noch nicht.
Geschwindigkeit - ich habe den Eindruck, dass hier der übliche Quarkanspruch, ein flottes Programm zu bieten, wieder gelungen ist.
Sonderfarben - kann ich im Moment noch nichts dazu sagen, denke aber, dass Quark bei Ausgaben über die gekaufte Engine Möglichkeiten haben sollte. Ich denke da dürfen wir noch ein wenig gespannt sein, denn eine Pre-Release ist nicht der letzte Stand der dann ausgeliefert wird.
In diesem Sinne ...

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Naja, grade die Ausgabe ist doch sehr interessant!
Kann XPress endlich PS Lvl 3 richtig verarbeiten?
Ob die dazugekaufte PDF-Engine auch für das PS
bei normalen Druckaufträgen sorgt, wage ich zu bezweifeln.
WENN Quark aber immerhin schon für eine gute PDF-Ausgabe
sorgt, warum nicht auch PostScript?
Andererseits hätte dann nicht die Druckengine
neu programmiert werden müssen?
Spekulation...von meiner Seite...


Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Hallo nochmal,

sorry ich muss leider weg, werde das aber heute Nacht oder morgen beantworten...

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Herr Wendtland,

Ihre Aussagen "Interessant wäre aber auch, ob XPress 6 nun auch
PS 2 und/oder 3 versteht (EPS)...", "Können jetzt Sonderfarben aus EPSen erkannt werden?" und "Ich hatte letztens wieder Schwierigkeiten eine Sonderfarbe in das XPress-4-Dokument zu bekommen und mußte dann erst Level-1 EPS schreiben." irritieren mich ehrlich gesagt.

Eine EPS-Datei ist eine autarke, einseitige PostScript-Datei die von jedem Layout-Programm bei der PostScript-Ausgabe einfach nur 1:1 in den eigenen PostScript-Strom eingebunden wird. Dies ist völlig unabhängig von den PostScript-Fähigkeiten des jeweiligen Layout-Programms. Somit wäre auch ein Programm, welches selbst nur PostScript Level 1 Code generieren könnte, jederzeit in der Lage eine PostScript 3 EPS-Datei auszugeben wenn diese so platziert wird.

Die Erkennung einer Sonderfarbe innerhalb einer EPS-Datei hat wiederum nichts mit dem PostScript Level der EPS-Datei (und den Fähigkeiten bei der PostScript-Generierung) zu tun, sondern ist alleinig eine Frage der im EPS hinterlegten DSC-Kommentare und des EPS-Importfilter bzw. dessen DSC-Parsers des Layout-Programms.

Das was Sie vielleicht meinen ist die Fähigkeit eines Layoutprogramms eine EPS-Datei beliebigen PostScript Levels on-Host, also software-mässig, zu separieren. Auch dies hat aber wenig bis nichts mit den Qualitäten eines Layout-Programms im Bereich der PostScript-Generierung zu tun, sondern hängt vom Aufbau der EPS-Datei und den PostScript-Prozeduren, die für die Separation zuständig sind ab. Die Grenzen sind hier durch die Technologie selbst vorgegeben. Wer heute immer noch versucht platzierte PostScript Level 2 und PostScript 3 EPS-Dateien klassisch, also per Software zu separieren, braucht sich, egal für welches Layout-Programm er sich entscheidet, nicht zu wundern, wenn er/sie falsche Separationsergebnisse erhält. Die software-mässige Farbseparation ist eine PostScript Level 1 Technologie die nur mit eben solchen EPS-Dateien zuverlässig und sicher funktioniert. Alles was diesen Level übersteigt, kann nur noch zuverlässig unter Einsatz der alternativen Technologie, der in-RIP Separation separiert werden.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Ich meine Xpress soll zumindest erkennen, das eine Sonderfarbe
im plazierten EPS ist. Es war eben so das die Sonderfarbe im Level 2 EPS nicht, im Level 1 gesicheren aber doch erkannt wurde.
Es mag durchaus sein, das hier auch der Fehler in dem EPS lag.
FlightCheck hat die Sondefarbe jedoch sofort erkannt.
Deswegen kam ich auf die Idee, der PS-Level hätte etwas mit
der Sonderfarbenerkennung zu tun.

Um das Problem mal genauer zu erläutern:
Ich mußte für unsere Heidelberger Quickmaster DI
eine separierte Postscriptdatei erstellen.
Eine In-Rip-Separation ist zwar möglich,
aber in unserem (Direktdruck-)Workflow nicht
eingerichtet. Ich ärgere mich auch schon seit etlicher Zeit darüber,
das wir die Digi nicht über Prinergy ansteuern können.
Entschuldigen Sie die vielleicht etwas konfuse Beschreibung,
bedingt durch mein vielleicht von mir überschätztes Halbwissen ;-)
Jedenfalls kann ich keine Sondefarbe separiert aus Xpress 4 herausgeben, wenn ich sie nicht in der Farbpalette habe.

Ihr letzter Absatz hört sich so an, als ob die Grafikprogramme
(Freehand/Illustrator) bzw. RIPs für die Fehler verantwortlich sind,
die bei Separation aus XPress auftreten.
Ist technisch sicherlich richtig, ich sehe es aber eher so, das Xpress eigentlich - wie andere Layoutprogramme - mit EPSen aus
diesen Programmen umgehen können sollte (kann es nicht immer - ich weis).
Ist natürlich ziemlich blauäugig gesehen. Aber wir sind doch
jahrelang recht gut auch mit Level 2 EPS und Separationen gut
zurecht gekommen - irgentwie.
Bei Problemfällen (DCS, JPG, 2Kanalbilder) helfe ich mir immer mit Layoutbildern, die von Ethershare dann richtig separiert werden.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Was mir etwas Angst macht, ist genau die GlobalGraphics-Engine.
Hier wird PDF erstellt. Inwiefern unterscheidet sich dieses PDF von einem mit Acrobat Distiller und/oder ApogeeNormalizer erstellten? Potenzieren sich hier nicht die Fehlerquellen (siehe auch Direkt-PDF-Ausgabe aus InDesign, das ja die Adobe-Engine verwendet!)? Werden angelieferte PDF auf dieses Kriterium überprüfbar sein? Fragen über Fragen ...

böc
Magical Mister Mac

Ich glaube nicht das man da (Prüfbarkeit der PDF) Angst haben muß.
Ich denke es ist für die (Qualität der) Prüfung einer PDF egal,
ob die PDF von InDesign, Word, XPress 4 oder 6 bzw. GlobalGraphics
kommt.
Herr Zacherl berichtete ja schon von guten Ergebnissen der
Engine von GlobalGraphics. Zumindest dürften sie besser sein
als nur von XPress generierte PDFs (frei nach dem Motto: es kann nur besser werden!).
Fallt bitte nicht über mich her, wenn das etwas flapsig klingt!

Potenzieren der Fehlerquellen glaube ich nicht - halbieren vielleicht?
Im Ernst: ich halte den Schritt von Quark, sich eine gute Software eines anderen Anbieters einzukaufen für den einzig richtigen.
Inwieweit die Umsetzung klappt wird sich herausstellen.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Herr Wendtland,

Zitat: "Es mag durchaus sein, das hier auch der Fehler in dem EPS lag.
FlightCheck hat die Sondefarbe jedoch sofort erkannt."

Dies deutet darauf hin, dass die Information wohl korrekt als DSC-Kommentare im EPS-Header (ode Trailer) hinterlegt war, aber der DSC-Parser im QuarkXPress EPS-Importfilter aus welchen Gründen auch immer, die Farbe nicht "gesehen" hat. Dies sagt aber nichts über die PostScript-Erzeugungsqualitäten eines Layout-Programms aus, sondern wirft höchstens ein schlechtes Licht auf dessen EPS-Importfilter.

Zitat: "Jedenfalls kann ich keine Sondefarbe separiert aus Xpress 4 herausgeben, wenn ich sie nicht in der Farbpalette habe."

Ist so auch nicht ganz korrekt. Es funktioniert zwar nicht bei der on-Host Separation aber sehr wohl bei der in-RIP Separation sofern die Sonderfarbe tatsächlich in der Composite-Datei enthalten ist. Ein Beispiel: Wenn Sie in QuarkXPress 4 oder 5 eine PDF mit enthaltenen Sonderfarben platzieren, tauchen diese nicht in der Farbpalette auf. Wenn ich nun on-Host aus QuarkXPress separiere erhalte ich tatsächlich nur die CMYK-Auszüge. Wenn ich dagegen die selbe Datei unsepariert auf den RIP schicke und dort die in-RIP Separation und die Ausgabe aller Sonderfarben erzwinge, dann erhalte ich die Sonderfarben aus dem platzierten PDF.

Zitat: "Ihr letzter Absatz hört sich so an, als ob die Grafikprogramme
(Freehand/Illustrator) bzw. RIPs für die Fehler verantwortlich sind,
die bei Separation aus XPress auftreten."

Da verstehen Sie mich miss. Schuld ist der Anwender des Layoutprogramms der versucht eine Separations-Technologie einzusetzen die über 20 jahre alt ist, die zu Zeiten von PostScript Level geschaffen wurde und sich seitdem nicht nennenswert weiterentwickelt hat und das zusammen mit modernen Produktionsdatenformaten wie PostScript Level 2 und PostScript 3 EPS-Dateien. Das kann auf Dauer nicht gut gehen.

Zitat: "... ich sehe es aber eher so, das Xpress eigentlich - wie andere Layoutprogramme - mit EPSen aus diesen Programmen umgehen können sollte (kann es nicht immer - ich weis).
Ist natürlich ziemlich blauäugig gesehen. Aber wir sind doch
jahrelang recht gut auch mit Level 2 EPS und Separationen gut
zurecht gekommen - irgentwie."

Es ist wirklich blauäugig (ist nicht böse gemeint), weil kein Layout-Programm dieser Welt ein beliebiges PostScript Level 2 oder PostScript 3 EPS korrekt separieren kann und es vermutlich auch nie können wird. Das fing schon vor Jahren mit JPEG-komprimierten Adobe Photoshop EPS-Bildern an und setzt sich heute in Form von EPS-Dateien fort die Konstrukte wie Smooth Shades in DeviceN-Farbräumen beinhalten.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Böc,

Sie dürfen nicht vergessen, dass es sich bei PDF im Gegensatz zu PostScript nicht um eine Programmiersprache, sondern um ein klar definiertes Datenformat handelt. Dies bringt z.B. mit sich, dass jede PDF-Datei dieser Welt, egal wie sie entstanden ist, eine einheitliche interne Struktur aufweist. Wenn dem nicht so wäre, würde die Datei von jedem PDF-verarbeitenden System als nicht konform zurückgewiesen werden.
Wenn Sie 10 PostScipt-Entwickler die simple Aufgabe stellen ein Programm per hand zu schreiben, das einen roten Kreis auf einem blauen Hintergrund malt, dann werden Sie 10 verschiedene Code abgeliefert bekommen, da jeder PostScript-Entwickler andere Vorstellungen von einem optimalen Code hat.
Wenn Sie 10 PDF-Entwicklern die selbe Aufgabe stellen, werden Sie 10 beinahe identische PDF-Dateien erhalten, da die Entwickler in einem engen Korsett stecken, das ihnen die Möglichkeit nimmt sich frei auszuleben.
Dies ist einer der großen Vorteile von PDF gegenüber PostScript.

Das es trotzdem gewisse inhaltliche Qualitätsunterschiede geben kann, das steht außer Zweifel. Hier ist aber z.B. ein AGFA Apogee Normalizer in keinster Wise einem korrekt konfigurierten Acrobat Distiller 4.0.5 oder neuer überlegen. Jeder der Ihnen das versucht weisszumachen, liegt falsch.
Die qualitativen Unterschiede zwischen einem JAWS PDF Creator 3 und einem Acrobat Distiller 4/5 sind (noch) vorhanden aber für die meisten Anwender absolut irrelevant.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

"...Es funktioniert zwar nicht bei der on-Host Separation..."
Wenn ich keine InRIP-Separation habe, heißt das für mich KEINE
Sonderfarbseparation aus XPress.

"Da verstehen Sie mich miss."
Nein - ich habe Sie schon richtig verstanden und gebe Ihnen in
fast allen Punkten recht. Ich sehe die Dinge nur eher aus der Perspektive eines "dummen" Anwenders. Ich weis schon, wo die Probleme liegen und bei welchen Dateien man aufpassen muß.

"Schuld ist der Anwender des Layoutprogramms der versucht eine Separations-Technologie einzusetzen die über 20 jahre alt ist"
Ha! Das Problem ist doch, das ihm keine andere Wahl bleibt!
Ich bekomme doch dauernd die Daten von Kunden die Ihre Drucksachen
selbst produzieren (und nicht wissen was sie tun).

"und das zusammen mit modernen Produktionsdatenformaten wie PostScript Level 2 und PostScript 3 EPS-Dateien. Das kann auf Dauer nicht gut gehen."
Leider geht es doch schon viel zu lange "gut". Wir produzieren
doch schon "ewig" mit Level 2 und 3 EPSen und XPress.
Es bleibt uns doch nichts anderes übrig, wenn wir "fertige"
Daten vom Kunden bekommen.
Das Problem ist die Fehler zu erkennen und zu verhindern.

"Es ist wirklich blauäugig (ist nicht böse gemeint)"
Hab ich auch nicht so verstanden ;-)
Wenn ich mich aber in unserer Abteilung umsehe und die Kundendaten
sehe: DIE sind blauäugig, weil kaum einer die richtige Ausbildung
oder Erfahrung hat. Machen Sie spasseshalber eine Umfrage zu
XPress 4 und PS-Level 2 und 3. kaum einer weiss, dass XPress
da Probleme hat (ok - andere Programme auch).
DAS meinte ich mit blauäugig.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Herr Wendtland,

Zitat: "Wenn ich keine InRIP-Separation habe, heißt das für mich KEINE
Sonderfarbseparation aus XPress."

Nein, das heißt es nicht zwangsläufig. Aber es heißt, dass Sie bei jedem Job auf's Neue befürchten müssen, dass das Separationsergebnis negativ ausfällt. Und das wird in Zukunft immer häufiger passier, je häufiger Anwender PDF-Dateien nativ im Layout-Programm platzieren oder eben EPS-Dateien aus PostScript 3 fähigen Illustrationsprogrammen.

Zitat: "Das Problem ist doch, das ihm keine andere Wahl bleibt!
Ich bekomme doch dauernd die Daten von Kunden die Ihre Drucksachen
selbst produzieren (und nicht wissen was sie tun)."

Sofern die Farbe in den Kundendaten noch korrekt ist (dies ist natürlich Voraussetzung für ein korrektes Separationsergebnis), ist der Einsatz der geteuerten in-RIP Separation in einem PostScript 3 RIP die Lösung aller Separationsprobleme. Wenn Ihr Workflow das nicht zuläßt, dann müssen Sie sich wohl oder übel mit dieser Separations-Problematik abfinden, denn es ist für eine Fa. Quark (und jede andere auch) unmöglich gewisse existierende technologische Grenzen zu sprengen.

Mit freundlichen Grüßen

Robert Zacherl

Kurz zusammengefasst:
Ich weis wo die Probleme beim sep. Workflow liegen und wie ich sie
löse. Bei "Problemfällen", wo ich angel. PDF separieren muß,
lese ich die PDF in InDesign ein und separieren von da aus
oder ich arbeite mit OPI.
Ich habe mich ja auch mit der Problematik abgefunden und irgentwie
arrangiert.

Beenden wir damit mal die wie immer fruchtbare Diskussion.
Was bleibt ist meine Frage nach den PS2 bzw. 3-Fähigkeiten
von XPress 6.

Oliver Wendtland
Druckerei und Verlag
H. Bösmann GmbH
Detmold
_________________________________
Ich habe mich nicht verirrt. Ich bin nur ... richtungsmäßig herausgefordert.

Herr Wendtland,

ok, Schluß damit.

Aber zwei kleine Anmerkungen noch:
Auch ein Adobe InDesign kann Ihnen niemals die Korrektheit einer on-Host separierten Datei garantieren (obwohl hier die Grenzen wesentlich höher anzusetzen sind als bei allen anderen Layout-Programmen. Dies hängt mit der zum Einsatz kommenden Technologie zusammen.)
Die PostScript level 2 bzw. PostScript 3 Fähigkeit eines Layout-Programms hat nichts mit dessen on-Host Separationsfähigkeit zu tun.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo, Herr Zacherl!

Ist nicht der Distiller in der Lage die onhost-separierten InDesign-PS-Dateien mit einem Kommentar oder einer Fehlermeldung auszugeben, wenn sich manche PostScript-Konstrukte NICHT separieren ließen? Ich glaube, daß ich bereits auf so einen Fall gestoßen bin.

Das Log des Distillers enthielt folgenden Kommentar: "(Warning: Job contains content that cannot be separated with on-host methods. This content appears on the black plate, and knocks out all other plates.)"

Leider wurde das NICHT vom InDesign beim Erstellen der PS-Datei gemeldet.

Gruß,

Uwe Laubender

Herr Laubender,

es ist richtig, dass Adobe InDesign einen Anwender vorsorglich während der PostScript-Verarbeitung per entsprechender RIP-Meldung warnt, wenn erkannt wird, dass PostScript Level 2 oder PostScript 3 Konstrukte in den on-Host separierten Daten enthalten sind. Das Erscheinen dieser Meldung heißt nicht zwangsweise, dass das Separationsergebnis falsch sein wird. Es ist nur ein Warnung, dass es so sein könnte.

Eine Warnmeldung bereits während der PostScript-Genererierung zu erzeugen ist aus technologischen Gründen kaum machbar. Wenn es zu dieser Meldung während der Ausgabe kommt, dann aufgrund von platzierten EPS-Dateien die Level 2 (oder noch neuere) Kontrukte beinhalten. Dies merkt aber nur der verarbeitende PostScript-Interpreter der Level 2 Farb-Operatoren antrifft. Adobe InDesign schleust aber beim Drucken, wie bereits mehrfach erwähnt, ja nur den platzierten PostScript-Code durch ohne ihn zu interpretieren (so wie es das Ausgabegerät tut). Somit kann es selbst gar nicht wissen ob ein Problem besteht oder nicht.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo nochmal alle zusammen,

die vorangegangene Diskussion, so aufschlußreich wie interessant sie auch ist, halte ich für sehr theoretisch und möchte deswegen dazu etwas sagen.
Ich höre auch von Kunden immer wieder dass Quark kein Level 2 wie 3 beherrscht. Im Zuge diese Diskussion über die Version 6 dieses Programmes spielt das doch für Produktionen nicht gerade die erste Geige. Gerade wenn mehrere Betriebe mit unterschiedlichem KnowHow und unterschiedlichen Möglichkeiten daran arbeiten. Lasst uns doch bitte einmal reel bleiben. Wichtig ist doch wie ein solches Produkt in einen Betrieb zu integrieren ist. Kann es ohne große Schulungen von den gleichen Leuten wie bisher verwendet werden und ist es möglich dieses Tool in einen Workflow zu integrieren. Alles was ich bis jetzt gesehen und gehört habe befürwortet diese Anforderungen.
Wie ich schon in vorangegangenen Postings erwänte ist eine konkrete Aussage derzeit eigentlich nicht wirklich möglich, denn selbst ich weis nicht mit voller Sicherheit ob nicht doch noch an der ein oder anderen Stelle gedreht wird. Ich gehe aber davon aus, dass eine L3 Anforderung in allen notwendigen Belangen umgesetzt werden kann und ich weis einfach, dass die eingekaufte Engine gut ist und was fast noch wichtiger ist, sehr oft eingesetzt wird, also folglich eine breite Basis von Erfahrung besitzt.
Ich bin auf Eure Antworten gespannt und hoffe keine Antwort vergessen zu haben, wenn doch sagt es mir bitte.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

ok, Schluß damit.

Hallo Conny,

anscheinend arbeiten Sie entweder selten oder gar nicht mit Sonderfarben und/oder setzen eben keinen composite Ausgabe-Workflow ein, sonst würden Sie die Situation sicherlich anders einschätzen.
Die Anzahl der Support-Anfragen die auf diese fehlende PostScript 3 Unterstützung zurückzuführen ist spricht jedenfalls eine eindeutige Sprache.
Ein typisches Beispiel ist brandaktuell in diesem Forum nachzulesen:
http://www.hilfdirselbst.ch/...24&topic_id=6789

Trotzdem ist keine Panikmache angesagt, weil es eben Lösungsstrategien gibt. Es ist nur schade, dass sich andere die Köpfe über solche Probleme zerbrechen müssen, nur weil ein Software-Entwickler jahrelang technologische Trends verschlafen hat.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Robert,

dem möchte ich nicht gänzlich widersprechen. Ich produziere heute nicht mehr vorrangig mit XPress, kann da allerdings auf ca. 13 Jahre Erfahrung als Druckvorstufendienstleister zurückblicken und beschäftige mich eben die letzten beiden Jahre um den technik- bzw. den Prozess des Produzierens. Das soll nichts anderes heißen, als dass ich mich als Praktiker betrachte und als solche meine Workarounds entwickelt habe mit Problemen umzugehen. Ich neige nur einfach nicht dazu gleich das Kind mit dem Bad auszukippen, sondern eher nach einer Problemlösung zu suchen, die dem Problem gerecht wird. Sie scheinen im Gegensatz zu mir in diesem Thema PDF und composit Workflow wesentlich tiefer drinzustecken, was aber sicherlich nicht heißt, dass ich das entweder ignoriere oder um Probleme nicht weis. Auch in dem anderen von Ihnen erwähnten Thread habe ich eine Antwort gegeben die in diese Richtung geht. Ich habe bei Produktionen von Geschäftsausstattungen, die ja meißt auf Schmuckfarben basieren, bis jetzt keine Probleme gehabt.
Ich hoffe ich konnte meinen Standpunkt nun ein wenig klar machen. Gerne bin ich natürlich bereit mir weitere Grundlagen zu schaffen, wenn Sie mir da weitere fachverbindliche Informationen zukommen lassen wäre das sehr nett.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Conny,

ich hoffe Sie verstehen das jetzt nicht falsch. Ich schätze Ihre sehr fachlichen und fundierten Beiträge in diesem Forum sehr.
Ihre Aussage:

"... es kommt ein wenig auf die Version an um ein Bild richtig einzufärben, ich denke aber dass nicht in diesem Bereich Dein Problem liegt. Vielmehr denke ich, dass das Problem bei der Einrichtung der Schmuckfarbe liegt. Diese wird sicher nicht als Volltonfarbe angelegt sein und deswegen separiert."

zeigt aber ganz klar, dass selbst Sie sich aufgrund des nicht-Einsatzes eines composite Workflows offensichtlich auch nicht bewußt waren, dass KEINE heute verfügbare QuarkXPress Programmversion in der Lage ist ohne Einsatz einer entsprechenden XTension ein mit einer oder zwei Sonderfarbe(n) koloriertes Graustufen-TIFF korrekt unsepariert auszugeben.
Wenn Sie es mit 13 Jahren Programmerfahrung nicht wissen, wie sollte es dann der "normale" Quark-Anwender wissen?

Der von Ihnen propagierte Workaround ein Simplex/Duplex-Bild in Adobe Photoshop anzulegen funktioniert natürlich aber sagen Sie das mal einem Dienstleister der einen PDF-Workflow einsetzt und vom Kunden einen vermeintlich zweifarbigen, 48-seitigen Geschäftsbericht als PDF-Datei angeliefert bekommt und alle als Duplex gedachten Bilder plötzlich als CMYK-Bilder vorliegen.
Das heißt für den Dienstleister entweder alle Bilder in Photoshop zu konvertieren und neu zu verlinken (was neben dem Zeitaufwand auch eine potentielle Fehlerquelle darstellt) oder das PDF erneut mit geladener XTension erzeugen (wobei er erst die Daten von Kunden anfordern muss) oder die Vorzüge eines Composite Workflows über Bord zu werfen und einen für ihn absolut unattraktiven, weil nicht zu seinen Workflow-System passenden, vorseparierten Ausgabe-Workflow zu betreiben (und dabei Gefahr zu laufen, dass es wieder andere Probleme im Bereich der on-Host Separation gibt).

Man kann es drehen und wenden wie man will. Die Tatsache, dass Workarounds für die angesprochenen Defizite existieren ist schön und gut aber heißt nicht, dass die Probleme nicht mehr auftreten. Denn solange die QuarkXPress-Anwender zum größten Teil gar nicht um dessen Defizite wissen, werden sie weiterhin jedesmal ins offene Messer laufen. Und das müsste schon lange mehr passieren, wenn der Hersteller etwas früher aus seiner Lethargie erwacht wäre. Denn die dafür notwendige Technologie (PostScript 3 und die dazu passenden Ausgabegeräte) steht seit 1998 zur Verfügung.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Robert,

leider muss ich aus Zeitgründen die Antwort, welche ich nicht schuldig bleiben möchte auf einen Späteren Zeitpunkt verschieben. Spätestens an Ostern werde ich mich hier noch einmal melden, danke aber dennoch für die fachliche Anerkennung und natürlich diskutiere ich immer wieder gerne und lasse mich auch ebenso gerne überzeugen, wenn ich Defizite in meinen Argumentationen haben sollte.
In diesem Sinne haben Sie bitte ein wenig Geduld - danke.

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Nur wer als User folgende oder ähnliche Fragen jeweils ausführlich und abgewogen beantworten kann, kann in Zukunft in Ruhe leben, wenn er seine Daten zum Dienstleister (der viel mehr wissen muss) gibt:

Arbeiten wir mit PDF oder lieber mit offenen Dateien? Warum?

Ist mein Farbproof ein Composite- oder ein (an welcher Stelle?)Separiert-und-dann-wieder-zusammengesetztes-Proof?

Ist beim Farbproofing überfüllt worden?

Auf welchem Weg sind meine Sonderfarben beim Proofen simuliert worden?

Bei welchen Datenarten muss man immer noch zwingend separiert arbeiten?


Vielen Usern und Dienstleistern ist immer noch nicht klar, dass Layout-Dateien und darin enthaltene Bilddaten anders aufgebaut sein müssten oder sollten, wenn sie je nach gewähltem Ausgabe-Verfahren wirklich identische Druckergebnisse ergeben sollen.

Oder anders ausgedrückt: Unterschiedliche Verfahren führen bei gleichen Layoutdaten zu unterschiedlichen Druckergebnissen


Der momentane Technologie-Wechsel kann nur sehr gut ausgebildet überstanden werden, wenn man aber zu denen gehört, die schon seit Jahren "immer so" gearbeitet haben, wird noch so manch teure Überraschung erleben. Doch Achtung: Selbst auserwählte (man beachte die andere mögliche Sinnschöpfung) Technologie-Päpste empfehlen immer noch "grundsätzlich" die JPEG-Komprimierung in den Distiller-Einstellungen ...
Bis dann, bis zur nächsten Reklamation

@Hallo "Anonym":
Die JPEG-Einstellung im Distiller war ja auch bei der Entscheidung für den PDF-Workflow eines der WICHTIGSTEN Argumente für die Umstellung (kleinere Datenmengen). Es sollte mittlerweile klar sein, daß die JPEG-Kodierung bei schwierigen Bildvorlagen oder beim Flattening von Transparenzen zu Problemen führen kann (nicht unbedingt muß!). Da die angebotene LZW-Kodierung zwar kleinere Datenmengen erzeugt, aber selten an die Datenmenge einer JPEG-Maximale-Qualität-Menge heranreicht, müßten in zukünftigen Distillern noch andere Optionen angeboten werden. Vielleicht weist ja JPEG 2000 den richtigen Weg.

Aber für dieses Thema wäre der PDF-Preprint-Bereich dieses Forums vielleicht der geeignetere Ort.

@Herr Zacherl: "Das Erscheinen dieser Meldung heißt nicht zwangsweise, dass das Separationsergebnis falsch sein wird. Es ist nur ein Warnung, dass es so sein könnte."

Wenn ich mir die Formulierung der Meldung genau anschaue, dann muß ich an Ihrer Aussage etwas zweifeln. "cannot be separated with on-host methods" ist doch eine ziemlich eindeutige Aussage. Vielleicht können Sie da noch etwas mehr Licht in die Sache bringen.


Vielen Dank,

Uwe Laubender

Hallo zusammen,

hier auch ein paar Worte zu Quark 6 von mir:

Ich arbeite z.Z. noch mit Quark 4.11 unter OS 9. Quark 5.X ging gänzlich an mir vorbei. Deshalb könnten Funktionen für mich neu sein, die es aber schon in Version 5.X gab. Das vorne Weg.
Über Geschwindigkeit mag ich lieber nicht reden, wegen dem älteren Testrechner und OS X.
Das Tastatur-Kürzel für den Mehrfach-Duplizieren-Dialog (Apfel+Alt+D) funktioniert wieder. Es wird also nicht das Dock ein-/ausgeblendet. Das Kürzel zum Unterschneiden (Danke Jens ;-) liegt immernoch in unereichbar Entfernung. Die Voreinstellungen befinden sich jetzt in einem (1) Menü, dass wie gewohnt mit Apfel+Alt+Umsch+Y aufgerufen werden kann. Soweit "meine Problemkinder".
Schon beim Erstellen einer neuen Datei fällt auch, dass das "Dokument" jetzt "Projekt" heisst. Mit Quark 6 ist es möglich die Seite(n) als Web-Page zu generieren. Da ich keine Anwendung für diese Funktion habe, werde ich auch nicht näher drauf eingehen und unkommentiert im Raum stehen lassen...
Neu ist das "Super-Duplizieren". Hier lässt sich nicht nur der Versatz einstellen, sondern auch anderen Rahmen-Einstellungen bestimmen; auch eine Art "Angleichungswerkzeug".
Das Kontextmenü/rechte Maustaste gewinnt auch mehr an Bedeutung. So befindet sich jetzt das Kontextmenü auf der ctrl-Taste. Die +-Lupe wurde auf ctrl+Umsch verbannt. Dies lässt sich jedoch in den Voreinstellungen umschalten.

Fortsetzung folgt...

Gruß
Bernhard

Willst Du tatsächlich direkt den Weg von 4 auf 6 gehen? Wenn in 6 etwas schief gehen sollte, dann kannst Du Dateien nicht wieder in 4 öffnen.

Super-Duplizieren: Super Step and Repeat, eine Xtension, die es von Quark auch schon für Xpress 4 gab.

Hallo Anonym,

klar, bei uns wird es einen Tag "X" geben, an dem von 4.11/OS 9 direkt auf 6.0/OS X umgestellt wird. Ein Recovery wird wohl jederzeit möglich sein. Es geht ja auch um ein bisserl' mehr...

Zum Super-Duplizieren: Je weniger XTensions, desto weniger Probleme. ;-)

Gruß
Bernhard

Dann schmeiss doch auch bei Deinem XPress 6 Test bitte alle XTensions raus?!

Super Step and Repeat gibt es mindestens seit 6 jahren von Quark, seit 1999 ist es auf jeder Update-CD von QuarkXpress drauf.

Hallo Robert,

ziemlich spät ich weis - aber die liebe Zeit.
O.k. ich habe mir den ganzen Thread ausgedruckt und durchgelesen. Um noch einmal auf die in dem anderen Thread gegebene Antwort zu kommen. Ich kann erst einmal nur auf Workarounds gehen die an der Basis anfangen und das sah ich in dieser Diskussion an der Dateibasis der EPS-Datei. Einen Composit-Workflow habe ich da ersteinmal überlesen - also mein Fehler, erwischt ;-). Dennoch weis ich um dieses Problem und habe es auch mit Kunden in der Zeit als ich für Quark gearbeitet habe gelöst. Da bin ich dann auch schon bei meiner nächsten Aussage bezüglich der Integrationsfähigkeit und Workarounds finden zu müssen für diverse Anforderungen. Quark verfolgt nun einmal stark die Strategie der XT's die den Grundfunktionsumfang des Programmes benutzerdefiniert erweitert. Ich will das weder verteidigen noch schlecht machen, aber ich muss einfach zur Kenntnis nehmen das es so ist auch wenn ich nicht immer damit einverstanden bin.
Um das wiederum auf den Dienstleister zu übertragen, kann ich eigentlich nur sagen, dass dieser so gut wie flexibel sein sollte. Immerhin gibt es heute auch Möglichkeiten das über z.B. Asura und/oder Solvero oder ähnliche Produkte zu regeln. Weiterhin ist es nicht zwingend notwendig pur einen Workflow zu verfolgen. Ich in meiner Dienstleisterzeit hatte trotz nicht so ausgereifter Möglichkeiten, wie diese heute existieren, differente Workflows mit denen ich meine Kunden immer zufriedenstellte. Leider macht man sich über den Kunden und seine Anforderungen immer weniger Gedanken in der Dienstleistungsbranche (das gilt natürlich auch anders herum). Fairerweise muss ich auch sagen, dass das KnowHow immer heftiger vom Umfang her und die Möglichkeiten für kleinere Betriebe immer weniger werden da wirklich mit zu probieren und somit über die notwendige Erfahrung zu verfügen. Ich denke wir werden noch einige Zeit und viel Einfühlungsvermögen brauchen, bis diese Umbruchphase von ehemaliger Produktionsdenke zu der heutigen erledigt ist. Was mir einfach oft unterkommt sind Unternehmen die des Umsatzes halber einfach verkaufen, ohne je die Situation des Kunden beurteilt zu haben und daraus erwachsen oft Probleme. Ich versuche einfach meine Kunden fair zu beraten und Ihnen ebenso die Wahl zu lassen was sie wollen. Diese Art von Dialog hat sich in den letzten Jahren immer bewährt und wenn Kunden Dinge realisiert haben wollen, die ich bis dahin noch nicht gemacht habe, dann sage ich es Ihnen auch und treffe eigentlich immer auf Verständniß, da diese genau Wissen, dass ich sie nie über den Tisch ziehen würde.
Übrigens die von Ihnen angesprochene Problematik habe ich schon für Betriebe mit Photoshop Automatismen gelöst, wenn diese das nur über eine on-Host Separation machen mussten oder wollten - nicht unbedingt prickelnd ich weis, die Frage ist da aber sicher welches Investitionsvolumen kann geleistet werden und was soll das Ganze dann können, da müssen oft Abstriche gemacht werden.
Was den letzten Abschnitt Ihres Postings anbelangt, da gebe ich Ihnen vollkommen Recht - nur ich als einer der damit umgeht, muss das leider so nehmen wie es ist. Ich habe oft genug auch intern Tipps / Hinweise gegeben wie es einfacher, sinnvoller oder zumindest mit kleinen Mitteln angenehmer zu gestalten wäre. Tatsache ist aber, dass ich eben nicht Ebrahimi heiße und deswegen natürlich nichts entscheiden konnte. Ich versuche tagtäglich innerhalb meiner Möglichkeiten daran zu arbeiten und meinen Beitrag dazu zu bringen es besser zu machen, die Argumentationen (da gleichen sich die Aussagen von Adobe bis hin zu Quark), dass die Großkunden hauptsächlich beeinflussen wo es hingeht, machen es mir allerdings nicht immer einfach - denn ich sehe es einfach so, dass das größte KnoHow bei den kleineren Betrieben liegt. Sicherlich sind es nicht die Umsatzbringer, das kann ich auch verstehen. Ich sehe nur leider immer wieder, dass dabei Wissen verloren geht und das wiederum verursacht teilweise eben auch die Probleme über die wir hier diskutieren.
Sehr gerne würde ich mich auch mit Ihnen austauschen. Mir gehen heute natürlich die Möglichkeiten ab, Tests auf Belichtern bzw. den davor befindlichen RIP's zu fahren, ebenso ist natürlich auch mein Wissen begrenzt und ich habe immer sehr großes Interesse daran mehr zu wissen und natürlich auch mein Wissen dabei zu teilen.
In diesem Sinne freue ich mich auf weitere interessante Diskussionen in diesem Forum...
Jetzt habe ich mich aber ziemlich verpinselt - gelobe Besserung!

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net

Conny,

Sie schreiben: "Quark verfolgt nun einmal stark die Strategie der XT's die den Grundfunktionsumfang des Programmes benutzerdefiniert erweitert. Ich will das weder verteidigen noch schlecht machen, aber ich muss einfach zur Kenntnis nehmen das es so ist auch wenn ich nicht immer damit einverstanden bin."

Daran wäre auch nichts auszusetzen, wenn so dringend notwendige XTensions wie eine "Creo Color TIFF XT", "AGFA CTIFF XT" oder "AGFA in-RIP Trapping XT" nicht von Drittanbietern, sondern von Quark selbst entwickelt und kostenlos und zu einem passenden Zeitpunktan geboten worden wären.
Ich sehe die Strategie von Quark in den letzten Jahren eher so, dass man immer wieder versuchte Probleme auszusitzen. D.h. es wurde abgewartet bis sich entweder ein Prepress-Anbieter erbarmte ein QuarkXPress-Defizit in Form einer Prepress-System oder RIP-Funktionalität oder eben einer (kostenosen) XTension abzufangen oder man wartet eben so lange bis existierende Defizite schon wieder nicht mehr heikel sind. So z.B. geschehen im Falle der bis heute fehlenden Unterstützung für die in-RIP Separation eines PostScript Level 2 oder PostScript 3 RIPs. Dies ist heute kein Beinbruch mehr, weil so gut wie niemand mehr direkt aus QuarkXPress belichtet, sondern durch Einsatz großformatiger Ausgabesysteme sich Arbeitsschritte wie die digitale Bogenmontage zwischen PostScript-Ausgabe und Endausgabe einfügen und somit die Steuerung solcher RIP-Funktionalitäten auf spätere Prozesse verlagert wird. Auch eine Möglichkeit der Problemlösung.

Gott sei Dank scheint Quark ja jetzt durch schwindende Verkaufs-/Updatezahlen und damit reduzierte Gewinne wachgerüttelt worden zu sein und vollführt mit der 6er Version deutliche Anstrengungen zumindest einige der eklatanten Defizite auszumerzen (z.B. Stichwort PostScript 3 Untersützung und PDF Im- und Export).

Schade eigentlich, dass es erst zu solchen dramatischen Einbrüchen kommen mußte bis die Entscheider bei Quark merkten, dass man nicht alles ungestraft mit seinen Anwendern machen kann.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Robert,

da pflichte ich voll und ganz bei. Allerdings sehe ich das in den meisten Fällen weniger als Aussitzen oder das Feld anderen überlassen. Ich glaube bei dem was ich so gesehen habe, dass das Bewußtsein für solche Dinge etwas getrübt ist und das deswegen so ist. Auch hier will ich wirklich niemanden verteidigen, sehe aber als den einzig funktionierenden Weg solche Foren und eben diese Diskussionen in denen Wissen fachgerecht an den Mann kommt.
Nocheinmal ich plichte Ihnen wirklich voll zu und sehe auch vieles was mir nicht gefällt - versuche aber einfach durch mein Arbeiten Stück für Stück Probleme zu finden, selbige zu lösen und diese dann auch weiter zu transferieren. Im Münchner Raum komme ich da schon ganz gut hin.
Danke für die lehrreiche und interessante Diskussion und natürlich für Ihre investierte Zeit.
Einen schönen Abend wünsche ich dann noch...

Gruß
Conny
--
mailto
cornelius.hoffmann@cicero-point.net
web
http://www.cicero-point.net