bei der highend-ausgabe eines kunden-pdf tanzen die buchstaben einer schrift. im pdf selbst ist nichts aussergewöhnliches zu sehen, die buchstaben halten die schriftlinie. das kunden-proof ist auch in ordnung. es handelt sich um eine truetype-schrift.

geben wir das pdf auf einem laserwriter (test 1x farb-, 1x sw-laser) oder auf unserem proof (agfa sherpa43) aus, sind die buchstaben in ordnung. bei der ausgabe über den apogee-workflow oder aus preps aber tanzen die letter.

was läuft da falsch?

dank&gruss. gremlin

Darf ich raten?
Es handelt sich um einen Direktexport aus Adobe InDesign, wobei die Fonts vollständig (0%) eingebettet wurden. Weiterverabeitet wird dort wo getanzt wird auf Acrobat 4 oder gleichwertigen OEM-Produkten.

Zwei Lösungen:
1. Mit Acrobat 5 arbeiten
2. Fontuntergruppen verwenden beim Direktexport aus InDesign (100%)

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

tut mir leid, haeme, ich muss dich enttäuschen...

das pdf wurde über laserwriter 8.8.3fc2 (??) aus xpress 4.11 erstellt. distiller war aber 5.0.5 for windows am werke, das pdf liegt in der version 1.2 vor.
der font ist ein truetype, und wie ich hier im forum gelernt habe, werden truetype immer als untergruppe eingebettet - so ist es auch der fall.

tatsächlich aber wird acrobat 4 verwendet (apogee arbeitet damit), aber nicht nur bei den tanzenden buchstaben, sondern auch bei der ausgabe auf die laserwriter/proof.

danke trotzdem! weitere ideen?

Legst Du das PDF in einen Hotfolder für Apogee? Was passiert wenn Du die Datei mal druckst?
Hast Du einen Preflight gemacht der PDF-Datei, sind die Schriften wirklich richtig eingebettet.
PDF 1.2 lässt die Base14 Fonts nicht einbetten. Handelt es sich im eine solche Schrift?

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

das pdf wird normalerweise per job ticket editor verarbeitet. allerdings liegt das problem nicht da, da ja beim verarbeiten direkt mit preps genau der gleiche effekt auftritt. wie meinst du das: "...wenn Du die Datei mal druckst..."?

ja, ich habe einen preflight gemacht. daher weiss ich auch, dass die schrift truetype und als untergruppe eingebettet ist. keine fehlermeldung, nix.

base14: nein, ist eine bodoni poster compressed.

your turn... ;-)

Was mir nicht logisch ist, was Preps in Deinem Fall reinfunkt. Preps braucht Ihr doch nur, um Standbögen zu zeichnen, da geht doch weder PostScript noch PDF rein oder raus?!? :-0

Mit drucken meine ich, die PDF-Datei nicht in den vom Normalizer überwachten Ordner zu stellen, sondern via Druckdialog aus Acrobat auf Eure Queue zu drucken.

Ansonsten könntest Du mir die PDF-Datei auch mal mailen.

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

>> Was mir nicht logisch ist, was Preps in Deinem Fall reinfunkt. Preps braucht Ihr doch nur, um Standbögen zu zeichnen<<
ja klar - wenn ich den weg über den apogee-workflow gehe. aber um auszuschliessen, dass da drin der wurm steckt, bin ich zur probe den "alten" weg gegangen und habe die gesamte verarbeitung in preps vorgenommen. mit demselben resultat wie über den workflow.

übrigens: ein angeliefertes pdf braucht nicht mehr in den normalizer-hotfolder gelegt zu werden, da es ja bereits ein pdf ist...

auf die laserwriter/das proof hatte ich bereits aus acrobat ausgegeben: resultat richtig. nun hatte ich endlich die glorreiche idee, aus acrobat auch übers rip zu schicken (man muss ja auch erst mal gemerkt haben, dass man auch da die möglichkeit hat, die in-rip-separation zu aktivieren........). auch da: resultat richtig.

mir scheint also, dass das problem beim preps liegt - ob im zusammenspiel mit apogee oder direkt...

gibt es hier eigentlich auch ein preps-forum...? :-)))

noch mal ich...

da hier ja öfter herr zacherl von der impressed - die u.a. preps vertreiben - anzutreffen ist, kann er mir bestimmt folgende frage beantworten:
wie generiert preps 3.7 die postscript-dateien, wenn pdfs verarbeitet werden? dazu wird ja acrobat angesprochen. wird da quasi auf die ps-export-funktion von acrobat zugegriffen? in welchem ps-level sind die dateien?

dank&gruss. gremlin

Hallo Gremlin

Bezüglich Preps kann ich dir leider auch keine Auskunft geben, da ich diese Applikation so gut wie gar nicht kenne.

Trotzdem möchte ich zu einer deiner Aussagen Stellung nehmen. Du hast geschrieben, dass du das gelieferte PDF nicht mehr in den Hotfolder stellen musst, weil dieses schon ein PDF sei. Nun, PDF ist leider nicht gleich PDF. Da gibt es tonnenweise Fehler, die beim Erstellen einer PDF-Datei hätten passieren können. Ich nehme jetzt einfach einmal an, dass dem Normalizer-Hotfolder schlussendlich auch ein Preflight-Profil (z.B. von Enfocus PitStop) zugrunde liegt? In diesem Falle wäre es absolut sinnvoll, wenn die gelieferten PDF-Daten ebenfalls in den Hotfolder gestellt würden, damit auch diese Daten einem Preflight unterzogen werden. Alternativ könnte auch jede Datei in Acrobat geöfnet und z.B. mit PitStop preflightet werden, was angesichts der Rationalität gegenüber einem solchen Workflow wie Apogee aber keinen Sinn macht.

Mit freundlichen Grüssen
Michel Mayerle
freelancer@ulrich-media

hallo michel

der preflight wurde ja auch ausgeführt - manuell, da ich keine lust habe, bei bestehenden pdfs wegen eines blossen preflights der manchmal ziemlich langen leitung des normalizers ausgesetzt zu sein. wie schon geschrieben, erbrachte dieser preflight keine fehlermeldung - es scheint alles in bester ordnung zu sein.

gruss. gremlin

Hi Gremlin

Das was jetzt zum Erfolg führte, versuche ich seit 2 Tagen zu schreiben, eben dies meine ich mit Drucken (Du nennst es "aus Acrobat auch über RIP schicken". Es ist so, dass schon Fehler entstehen, wenn RIP PDF "nativ" verrechnen sollen und die Fehler aus den gleichen Dateien oftmals nicht auftreten, wenn die PDF-Dateien eben via Druck (PostScript) ausgegeben werden. Dies kommt davon, dass nicht alle PostScript 3 RIP's wirklich 100prozentig PDF 1.3-kompatibel sind.

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

sorry, dass wir so aneinander vorbeigeredet haben!

es ist aber so, dass das rip gar keine pdf verrechnet! agfa nennt die dinger zwar schon wunderbar "pdf rip" - tatsache ist aber, dass alles, was das rip zwischen die zähne kriegt, postscript ist. preps 3.7 ist offenbar noch nicht in der lage, pdf direkt zu verarbeiten. wenn ein pdf in den ausschuss geladen wird, wird im hintergrund im zusammenspiel mit acrobat automatisch ein postscript-file erzeugt. dasselbe geschieht auch über den apogee-workflow (serie 2, in verbindung mit ebenfalls preps 3.7). mein verdacht ist nun also, dass das problem mit diesem automatisch generierten postscript-file entsteht. deshalb würde ich gerne mehr darüber erfahren - wie denn das file nun genau generiert wird!

gruss. gremlin

ps: blöder automatischer log-out!! ich war kurz abgelenkt, bevor ich meine antwort fertig geschrieben hatte - und inzwischen hat's mich einfach rausgeworfen...! ;-)

Momentan gibt es gar keine Adobe-RIP's (OEM), die direkt PDF verarbeiten, nicht nur AGFA.
Einzig Harlequin behauptet dies mit dem Ecplipse RIP nun zu können. Jedenfalls muss dies der Weg sein, schon wegen der Transparenzen.

Preps kann erst ab Version 4.1 mit PDF arbeiten. Aber dann entweder/oder, also rein PDF oder rein PostScript. Soweit ich aber weiss, ist es doch in Apogee so, dass mit Preps nur die Standbogen gemacht werden und die dann via Jobticket zugewiesen werden (vgl. Prinergy).


Wegen dem Logout. Du kannst beim Anmelden klicken, dass Du jeweils angemeldet bleibst.

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

so, jetzt hast DU aber die ganze zeit nicht verstanden, was ich sagte... ;-)))

es stimmt, dass man über den apogee-workflow preps nur zum erstellen der standbögen verwendet. dies ist aber nur die anwender-betrachtung! der blosse anwender sieht eigentlich nur, dass sein job nach dem klicken auf "ausgeben" im job ticket editor vom pilot - dem kernstück des workflows (pc unter winNT) - abgearbeitet wird, dann auf dem rip auftaucht und schliesslich mehr oder minder fixfertig auf dem printdrive - der "ausgabesteuerung" - liegt, von wo aus er ein formproof erstellt und dann die platten- oder filmbelichtung initiiert.

wenn man aber für die funktionalität des workflows verantwortlich ist, muss man halt ein wenig hinter die kulissen gucken. und dann erkennt man, dass der job ticket editor im prinzip nur eine grafische oberfläche einer automatisierung von preps darstellt. d.h. klickt man im jte auf "ausgeben", geschieht grob gesagt folgendes:
es geht eine meldung an den pilot, dass er doch bitte (per imposition-plug-in) in seinem preps die ausgesuchten pdfs mit dem gewählten standbogen und mit den entsprechenden einstellungen ausschiessen und ausgeben soll. genau das, was man bisher einfach manuell in preps getan hatte. und dementsprechend werden die pdf natürlich auch gleich behandelt: für die effektive verarbeitung werden via acrobat postscript-files erzeugt!

allfällige agfa-mitarbeiter, die dies lesen, wollen mir diese plumpe blossstellung doch bitte verzeihen... ;-)))

aber irgendwie sind wir längst vom eigentlichen problem abgewichen: was kann eine schrift dazu bringen, bei der ausgabe via preps zu tanzen? wie werden die "hintergrund-ps-files" für die verarbeitung von pdf in preps 3.7 generiert? liegt da der hund begraben?

gruss. gremlin

Ich muss jetzt passen, weil ich weder Preps noch Apogee wirklich gut kenne. Gibt es denn keine Apogee-Anwender, die hier mitlesen?

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

Ausserhalb des Forums habe ich mit Robert Zacherl, Impressed, Kontakt aufgenommen, also Infos aus erster Hand vom Distributor von Preps und absoluten Kenner.

Hier seine Antwort:
""
ScenicSoft Preps 3.7 wurde standardmässig mit Acrobat 3.01 ausgeliefert. Ich gehe davon aus, dass innerhalb der Apogge-Installation des Anwenders eine 4er Version von Acrobat zum Einsatz kommt. Da Preps 3.7 noch keinen nativen PDF-verarbeitung unterstützte und keinen eigenen sog. PrepsConverter beinhaltete, der die PDF-nach-PostScript Wandlung übernahmen konnte (geht seit Version 4), bediente man sich des vorgefundenen Acrobats und veranlasste dieses mit Hilfe eines Plug-Ins die Wandlung durchzuführen. Der erzeugte PostScript-Code entspricht 1:1 dem was Acrobat 3/4 bei einem Export als PostScript generieren würde. Wichtig ist der laut Preps Profile vorgegebene PostScript Level, der sich mit dem Profil-Eintrag

-PLUGINPSLEVEL:2

beeinflussen lässt (steht standardmässig auf 2 und sollte unbedingt auf 3 abgeändert werden, was bei Apogge-Installationen aber automatisch geschieht). Lange Rede, kurzer Sinn: Ich gehe davon aus, dass sich der selbe Effekt zeigen würde, wenn die problematische PDF-Datei händisch aus der verwendeten Acrobat-Version als PostScript exportiert werden würde. Vielleicht hat der Anwender einfach eine fehlerhafte 4.0 Version von Acrobat im Einsatz. Falls alles nichts hilft, soll er und mal die Problem PDF-Datei zukommen lassen.

Robert

--

*****************************
Robert Zacherl
IMPRESSED GmbH
Tel:++49(0)40/89 71 89-0
Fax:++49(0)40/89 71 89 71
eMail: rzacherl@impressed.de
http://www.impressed.de
*****************************


Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

herzlichen dank, haeme und robert!

es ist tatsächlich die ps-export-einstellung schuld. und zwar jene die truetype-schriften zu type 1 konvertiert! ich frage mich nun bloss, wieviel sinn macht diese einstellung? oder anders gefragt: weshalb wurde sie so eingestellt? gibt es einen nachteil, wenn ich die ausschalte? und wie/wo ändert man diese preps-konfiguration?

dank&gruss. gremlin

In PostScript-Level-1-RIP's gibt es keine TrueType-Renderer. Darum ist für Level 1-Kompatibiltät dies Option notwendig.

Herzliche Grüsse
Häme Ulrich
http://www.ulrich-media.ch

Gremlin,

die meisten Exportoptionen sind im ScenicSoft Acrobat-Plugin fest verdrahtet und können somit nicht beeinflußt werden. Dazu zählt wohl auch die Art und Weise wie mit TrueType-Fonts umgegangen wird.
Da bleibt dann nur der manuelle Export aus Acrobat mit den gewünschen Optionen oder der Einsatz einer automatisierten EPS-Erzeugung wie Callas pdfOutput, Callas MadeToPrint für Acrobat in Verbindung mit Callas Autopilot o.ä.
Bei den aktuellen Preps-Versionen ist das natürlich auch kein Thema mehr.

Mit freundlichen Grüßen

Robert Zacherl

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