Wie in adobe.indesign.macintosh - Message-ID: <59b680a1...@webcrossing.la2eafNXanI> - z.B. schon erwähnt wird nach einem Update auf 10.5.5 eine benutzerdefinierte Seitengröße im Druckdialog von InDesign CS3 ignoriert und - anscheinend - der im Papierformat definierte Standardwert (z.B. A4) zum Drucker geschickt.
Wer davon abhängig ist, sollte sich das Update derzeit ersparen.
Thomas Liesner <tho...@vignold.de> wrote: > Wie in adobe.indesign.macintosh - Message-ID: > <59b680a1...@webcrossing.la2eafNXanI> - z.B. schon erwähnt wird nach > einem Update auf 10.5.5 eine benutzerdefinierte Seitengröße im > Druckdialog von InDesign CS3 ignoriert und - anscheinend - der im > Papierformat definierte Standardwert (z.B. A4) zum Drucker geschickt.
Deine Meldung weicht ab vom Inhalt der ursprünglichen Fehlermeldung. Dort wird beschrieben, dass der Fehler beim senden an zwei RIPs auftritt, wobei die RIPs nicht genannt werden.
Also habe ich folgendes getan: InDesign gestartet, neues Dokument mit der Größe eines CD-Covers angelegt, Blindtext eingetragen und ein PDF daraus erzeugt. => Die Größe stimmt mit der Seiteneinstellung überein.
Wenn die ursprüngliche Fehlermeldung in reproduzierbarer Form vorläge, könnte man sie vielleicht auch ernst genug nehmen um deshalb auf ein Sicherheitsupdate zu verzichten.
Mit besten Grüßen, Mike Nolte
-- E-Mail an newsgro...@mikenolte.de wird nur zugestellt, wenn die Betreffzeile "Antwort auf Usenetartikel" ohne Anführungszeichen lautet. <mailto:newsgro...@mikenolte.de?subject=Antwort auf Usenetartikel> Rechtschreibfehler sind ungewollt und dürfen gerne korrigiert werden.
>> Wie in adobe.indesign.macintosh - Message-ID: >> <59b680a1...@webcrossing.la2eafNXanI> - z.B. schon erwähnt wird nach >> einem Update auf 10.5.5 eine benutzerdefinierte Seitengröße im >> Druckdialog von InDesign CS3 ignoriert und - anscheinend - der im >> Papierformat definierte Standardwert (z.B. A4) zum Drucker geschickt.
> Deine Meldung weicht ab vom Inhalt der ursprünglichen Fehlermeldung.
Nö.
> Dort wird beschrieben, dass der Fehler beim senden an zwei RIPs > auftritt, wobei die RIPs nicht genannt werden.
Dort wird beschrieben, daß der Fehler beim *Drucken* auftritt.
> Also habe ich folgendes getan: InDesign gestartet, neues Dokument mit > der Größe eines CD-Covers angelegt, Blindtext eingetragen und ein PDF > daraus erzeugt. => Die Größe stimmt mit der Seiteneinstellung überein.
<Loriot>Ach?</Loriot>
Den Unterschied zwischen PDF-*Export* und *Drucken* hast Du aber schon mal gehört? PDF-Export findet komplett unter der Regie von InDesign mittels Adobes PDF-Library statt. Beim Drucken spielen InDesign und Spoolsystem (CUPS mit Apple-Anbauten) ineinander. Und hier tritt seit 10.5.5 besagtes Problem auf (evtl. nur bei PostScript-Interpretern, die als Band-Device und nicht als Page-Device agieren).
> Wenn die ursprüngliche Fehlermeldung in reproduzierbarer Form vorläge, > könnte man sie vielleicht auch ernst genug nehmen um deshalb auf ein > Sicherheitsupdate zu verzichten.
Für 'ne Klitsche, die neue Macs hat (AKA Zwangsverdongelung mit 10.5) und mit ID CS3 schaffen muß, ist das ein echtes Problem... denn was nützt ein "sicheres System", mit dem man nicht mehr produzieren kann?
Mike Nolte <newsgro...@mikenolte.de> wrote: > Also habe ich folgendes getan: InDesign gestartet, neues Dokument mit > der Größe eines CD-Covers angelegt, Blindtext eingetragen und ein PDF > daraus erzeugt. => Die Größe stimmt mit der Seiteneinstellung überein.
Da fehlt "Auf meinem LaserWriter 4/600 PS ist der Ausdruck ebenfalls korrekt."
-- E-Mail an newsgro...@mikenolte.de wird nur zugestellt, wenn die Betreffzeile "Antwort auf Usenetartikel" ohne Anführungszeichen lautet. <mailto:newsgro...@mikenolte.de?subject=Antwort auf Usenetartikel> Rechtschreibfehler sind ungewollt und dürfen gerne korrigiert werden.
>> Also habe ich folgendes getan: InDesign gestartet, neues Dokument mit >> der Größe eines CD-Covers angelegt, Blindtext eingetragen und ein PDF >> daraus erzeugt. => Die Größe stimmt mit der Seiteneinstellung überein.
> Da fehlt "Auf meinem LaserWriter 4/600 PS ist der Ausdruck ebenfalls > korrekt."
Was völlig irrelevant ist, da Du den mit "DIN A4" ansteuern dürftest, mithin das Problem bei den benutzerdefinierten Ausgabeformaten nicht mal wahrzunehmen bereit bist.
Lustig, Du willst das Problem an sich einfach nicht wahrhaben. Der beschriebene Workaround hilft gegen die Verzerrungen, über die einige Anwender berichtet haben. Er hilft nicht bzgl. der Unmöglichkeit, von in der PPD hinterlegten "Standard-Formaten" (bspw. DIN A4) abzuweichen. Und genau das brauchen Anwender, die nicht nur auf Desktop-Laser ausgeben (bei denen es wenig sinnvoll ist, von den Standard-Formaten abzuweichen)
Damit's klarer wird: Wenn ich einen 6-Seiter mit Wickelfalz als "Montagefläche" anlege, dann hab ich ein Dokument, das bspw. 620x297 mm groß ist. Wenn ich das auf meinen Proofer schicken will, dann muß ich inkl. Schneidzeichen bspw. ein Papierformat von 650x327 mm eingeben.
Intel-Macs (wenn's denn nur die betrifft -- ich traue diesbzgl. User- Eingrenzungen eigentlich generell nicht mehr) mit 10.5.5 schicken aber leider nur ein Dokument ans RIP, das auf das Format beschnitten ist, das im Appleschen Druckdialog ausgewählt war (meist DIN A4). Weil die Vorgaben aus Apples Druckdialog die von InDesign überschreiben (was nicht sein darf und vor 10.5.5 auch nicht so war)
Dein Drucktest mit Dokumentgröße kleiner Papierformat und dann noch Standardformat bei der Ausgabe schießt also einfach nur am Problem vorbei. Der mit dem PDF-Export sowieso.
> Es gibt erstmal keinen Grund mehr auf das Systemupdate auf Mac OS X > 10.5.5 zu verzichten.
Der einzige Workaround momentan ist in einem Programm welches den OS-eigenen Druckdialog benutzt im "Page Setup"-Menu ein entsprechendes, gesondert angelegtes Format anzulegen und auszuwählen. So kann man wenigstens in CreatePDF-Workflows mit InDesign CS3 unter OS 10.5.5 korrekte PDFs erzeugen.
> Der einzige Workaround momentan ist in einem Programm welches den > OS-eigenen Druckdialog benutzt im "Page Setup"-Menu ein entsprechendes, > gesondert angelegtes Format anzulegen und auszuwählen.
Also dann in ID "Durch Treiber definiert" definiert auswählen oder dort ein identisches benutzerdefiniertes Format auswählen?
> So kann man wenigstens in CreatePDF-Workflows mit InDesign CS3 unter > OS 10.5.5 korrekte PDFs erzeugen.
Also so, wie sich das hier und dort liest, kommt es ja zu Verschiebungen respektive Skalierungen, wenn man mit benutzerdefinierten Papierformaten hantiert. Erste Idee meinerseits wäre, daß da beim Setzen der CTM bevor der Seiteninhalt virtuell "gemalt" wird, eine Interaktion zwischen dem Format, das man im Appleschen Dialog und dem, das man im InDesign-Dialog eingibt, entsteht.
Wenn das stimmt, dann würde das bedeuten, daß bei Eingabe von zweimal "identischem" Format in beiden Dialogen dann doch evtl. Rundungs- ungenauigkeiten mit reinspielen und eine Ausgabe entsteht, die dann bspw. zu 99,8% oder 100,1% skaliert ist. Schon mal ein langes Dokument gebaut und nachgemessen? Wobei der Effekt wohl eher bei kleinen Dokumenten meßbar sein müsste, wenn die Theorie stimmt.
Ein Glück, daß ich die CS3 noch nicht aufm MBP habe -- sonst hätte ich da sicher schon ein paar Stunden in Analyse+Lösung investiert ;-)
> Thomas Liesner schrieb in <news:a0rAk.598$9W3.59785@se2-cb104-9.zrh1.ch.colt.net> >> Der einzige Workaround momentan ist in einem Programm welches den >> OS-eigenen Druckdialog benutzt im "Page Setup"-Menu ein entsprechendes, >> gesondert angelegtes Format anzulegen und auszuwählen.
> Also dann in ID "Durch Treiber definiert" definiert auswählen oder dort > ein identisches benutzerdefiniertes Format auswählen?
>> So kann man wenigstens in CreatePDF-Workflows mit InDesign CS3 unter >> OS 10.5.5 korrekte PDFs erzeugen.
> Also so, wie sich das hier und dort liest, kommt es ja zu Verschiebungen > respektive Skalierungen, wenn man mit benutzerdefinierten Papierformaten > hantiert. Erste Idee meinerseits wäre, daß da beim Setzen der CTM bevor > der Seiteninhalt virtuell "gemalt" wird, eine Interaktion zwischen dem > Format, das man im Appleschen Dialog und dem, das man im InDesign-Dialog > eingibt, entsteht.
> Wenn das stimmt, dann würde das bedeuten, daß bei Eingabe von zweimal > "identischem" Format in beiden Dialogen dann doch evtl. Rundungs- > ungenauigkeiten mit reinspielen und eine Ausgabe entsteht, die dann > bspw. zu 99,8% oder 100,1% skaliert ist. Schon mal ein langes Dokument > gebaut und nachgemessen? Wobei der Effekt wohl eher bei kleinen > Dokumenten meßbar sein müsste, wenn die Theorie stimmt.
Kurzer Test mit einem 300x200mm Dokument plus Beschnitt, einer im OS benutzerdefinierten Seitengröße (eingestellt in Textwrangler) von 315x215 und einer in ID identisch auf "Benutzerdefiniert" eingestellten Seitengröße (314,817 mm x 214,817 mm) ergab eine korektes PDF mit einer CropBox von 300x200mm Größe (gemessen in QuickPrint PDF+). So weit so korrekt. Dieser ist IMO aber nur sinnvoll, wenn man mehrere Dokumente gleichen Formates auszugeben hat. Bei einer Anzeigenstrecke mit 20 - 100 Größenadaptionen dreht man eher durch ;) Dann doch lieber ein ps erzeugen und dieses per drag 'n drop auf die eingerichteten Drucker oder Hotfolder ziehen.
> Thomas Kaiser schrieb: >> Thomas Liesner schrieb in <news:a0rAk.598$9W3.59785@se2-cb104-9.zrh1.ch.colt.net> >>> Der einzige Workaround momentan ist in einem Programm welches den >>> OS-eigenen Druckdialog benutzt im "Page Setup"-Menu ein >>> entsprechendes, gesondert angelegtes Format anzulegen und >>> auszuwählen.
>> Also dann in ID "Durch Treiber definiert" definiert auswählen oder >> dort ein identisches benutzerdefiniertes Format auswählen?
> Genau.
"Entweder/oder?" "Genau." ;-)
Aber aus dem Kontext nehme ich mal an, daß Du Letzteres meinst.
> Kurzer Test mit einem 300x200mm Dokument plus Beschnitt, einer im OS > benutzerdefinierten Seitengröße (eingestellt in Textwrangler) von > 315x215 und einer in ID identisch auf "Benutzerdefiniert" eingestellten > Seitengröße (314,817 mm x 214,817 mm) ergab eine korektes PDF mit einer > CropBox von 300x200mm Größe (gemessen in QuickPrint PDF+). So weit so > korrekt. > Dieser ist IMO aber nur sinnvoll, wenn man mehrere Dokumente gleichen > Formates auszugeben hat. Bei einer Anzeigenstrecke mit 20 - 100 > Größenadaptionen dreht man eher durch ;)
Papperlapapp, da baut man sich ein billiges AppleScript-Droplet, auf das man ID-Dateien zieht, das die Datei in ID öffnet, die Dokumentenmaße ausliest, per
schnell mal eben das ausgewählte variable Papierformat auf passende Werte bringt, den Druckdialog parametrisiert, und schon paßt alles, wenn man anschl. eben jenen aufruft ;-)
So'n Skript wäre wirklich gar nicht sooo aufwändig und auch ohne den jetzt nötigen Workaround einer Appleschen Custom Paper Size 'ne gute Idee, wenn man sich nicht unnötig im Druckdialog verklicken will. Als ich noch aktiv in der Druckvorstufe gearbeitet habe, hatte ich für Xpress genau so ein Droplet am Start -- wär' mir viel zu blöd gewesen, im Druckdialog herumzuklicken...
> Dann doch lieber ein ps erzeugen und dieses per drag 'n drop auf die > eingerichteten Drucker oder Hotfolder ziehen.
Bzw. gleich mit Ordneraktionen vollautomatisch weiter.
Schon lustig, wie solche Malheurs wie das mit dem 10.5.5-Update die Phantasie anregen können :-)
> Thomas Liesner schrieb in <news:0esAk.599$9W3.59665@se2-cb104-9.zrh1.ch.colt.net> >> Thomas Kaiser schrieb: >>> Thomas Liesner schrieb in <news:a0rAk.598$9W3.59785@se2-cb104-9.zrh1.ch.colt.net> >>>> Der einzige Workaround momentan ist in einem Programm welches den >>>> OS-eigenen Druckdialog benutzt im "Page Setup"-Menu ein >>>> entsprechendes, gesondert angelegtes Format anzulegen und >>>> auszuwählen. >>> Also dann in ID "Durch Treiber definiert" definiert auswählen oder >>> dort ein identisches benutzerdefiniertes Format auswählen? >> Genau.
> "Entweder/oder?" "Genau." ;-)
> Aber aus dem Kontext nehme ich mal an, daß Du Letzteres meinst.
Äh, ja ;)
Einstellung in ID-Dialog "Benutzerdefiniert" + Einstellung im OS-Dialog auf ein identisches benutzerdefiniertes Format.
>> Dann doch lieber ein ps erzeugen und dieses per drag 'n drop auf die >> eingerichteten Drucker oder Hotfolder ziehen.
> Bzw. gleich mit Ordneraktionen vollautomatisch weiter.
So hab ich es an dem einen betroffenen Arbeitsplatz jetzt auch gemacht.
Thomas Liesner <tho...@vignold.de> wrote: > > Also dann in ID "Durch Treiber definiert" definiert auswählen oder dort > > ein identisches benutzerdefiniertes Format auswählen?
> Genau.
F: Willst Du Kuchen oder Torte?
A: Ja!
F: Das war eine "entweder-oder"-Frage!
A: Das war eine "sowohl-als auch"-Antwort!
(by Tom Touché) -- In a world without walls and fences, who needs windows and gates?
> Wie in adobe.indesign.macintosh - Message-ID: ><59b680a1...@webcrossing.la2eafNXanI> - z.B. schon erwähnt wird nach > einem Update auf 10.5.5 eine benutzerdefinierte Seitengröße im > Druckdialog von InDesign CS3 ignoriert und - anscheinend - der im > Papierformat definierte Standardwert (z.B. A4) zum Drucker geschickt.
> Wer davon abhängig ist, sollte sich das Update derzeit ersparen.
Laut <http://www.hilfdirselbst.ch/gforum/gforum.cgi?post=367414#367414> soll es helfen, den pstops-Filter wieder auf den Stand von 10.5.4 zu bringen. Alternativ dafür sorgen, daß der das InDesignsche PostScript gar nicht erst anfaßt, bspw. durch Modifikation der PPD und einem beherzten "-" bei einem "*CupsFilter"-Eintrag:
> Wie in adobe.indesign.macintosh - Message-ID: ><news:59b680a1.-1@webcrossing.la2eafNXanI> - z.B. schon erwähnt wird nach > einem Update auf 10.5.5 eine benutzerdefinierte Seitengröße im > Druckdialog von InDesign CS3 ignoriert und - anscheinend - der im > Papierformat definierte Standardwert (z.B. A4) zum Drucker geschickt.
> Wer davon abhängig ist, sollte sich das Update derzeit ersparen.
Man kann das Ganze auch sinnig workarounden (ID CS3 auf Intel als PPC- Version via Rosetta starten, alten pstops-Filter aus 10.5.4 zum Einsatz bringen, identische Papierformate in Apples und Adobes Druckdialog nutzen) oder aber auch lösen.
IMO ist die Crux an der Geschichte die, daß Adobe es dem Appleschen Spool-System überhaupt erlaubt hat, Hand an den InDesignschen PS-Code zu legen. Alle Druck-Metadaten wie Papierformat, positiv/negativ, N'up- bzw. unterteiltes Drucken, etc. finden sich normalerweise zweimal als PS-Code-Fragmente in der entstehenden PS-Datei. Weil Adobe es nicht unterbindet, daß Apples pstops-Filter überhaupt noch in den PostScript- Datenstrom hineinferkelt.
Wen's interessiert: Bisserl Adobe-Bashing nebst Anleitung/Anregung zu einer Lösung des eigentlichen Problems findet sich nun unter:
