Hallo,
stelle mein Problem hierher, da ich im Corel-Forum nicht unbedingt eine Antwort
erwarten kann.
Problem:
Erstelle ich in Corel (aktuelle Version) eine PDF/X-3 mit der "Unicode" Einstellung
verweigert AcrobatPro 9 je nach verwendeter Schrift die Validierung.
Einmal "Ja" und einmal "Nein" - macht mich ratlos!
Wird die Validierung "PDF/x-3" in AcrobatPro 8 durchgeführt erhalte ich die Meldung: "keine Probleme". Jetzt bin ich noch ratloser!!
Überprüfung durch ToolBox4 (callas) findet kein Probelem. Jetzt noch vielmehr
ratloser.

Zum Test anbei Daten:

http://f.imagehost.org/view/0629/unicode
http://f.imagehost.org/download/0121/Unicode_fehler
http://f.imagehost.org/download/0972/Unicode_richtig

Wäre schön, wenn mir jemand den Sachverhalt erklären könnte.

Anmerkung:
Verwende ich zum Erzeugen der PDF die Einstellung "Ascii" funktioniert alles wunderbar.
VG

Hallo, Reitschuster!
In den beiden PDFs werden unterschiedliche Schriften verwendet. Da ist ein Vergleich fast so etwas wie Äpfel gegen Birnen. Ich bitte also darum mit ein und dem gleichen Text-Beispiel die beiden Ausgabeoptionen ASCII und Unicode durchzuspielen.

Hallo,
nun zum direkten Vergleich:
http://f.imagehost.org/download/0975/test_ascii
http://f.imagehost.org/download/0062/test_unicode

Viele Grüße

Hallo, Reitschuster!
Gibt es irgendwelche Ergänzungen, Analysevorschläge des Problems von anderer Seite?
Ich habe mir die beiden Dateien mal angeschaut. Interessant ist, daß der Fehler nicht bei allen Schriften auftaucht (zwei im Beispiel "test_unicode") sind da ausgenommen. Die Schrift "Aller" und die "EuroSansPro".
Siehe auch den Screenshot vom Acrobat 9 Pro-Preflight:
"TestUNICODE.png"
Auffällig dabei ist, daß bei den fehlerhaft gemeldeten Schriften kein "CFF"(Compact Font Format)-Eintrag im PDF vorhanden ist, bei den beiden korrekt ausgegebenen Schriften schon.
Im Vergleich dazu die ASCII-Version:
"TestASCII.png"

Tja, wo liegt nun der Fehler?
Sind Acrobat 8 und die PDF-Toolbox toleranter gegenüber den Konstrukten, die CorelDraw in PDF schreibt?
Oder geht der Preflight in Acrobat 9 an dieser Stelle zu scharf vor?
Weshalb schreibt CorelDraw bei der einen Schrift einen gültigen "CFF"-Eintrag, bei der anderen nicht?

Hallo Uwe Laubender,
Callas schaut sich die zwei PDF-Daten an.
Habe aber noch keinen Rücklauf.
Was ich noch versucht habe:
Ziehe ich die PDF (Unicode) in Quark 8 und exportiere diese wieder mit PDF-X ready Einstellung, zeigt Acrobat Pro 9 "keine Probleme".
Also denke ich, dass die Schriften in der ominösen PDF ok sind, sonst müsste ja eine Müll-PDF aus Quark kommen.
Viele Grüße

Hallo Reitschuster!
Hast Du Dir mal den "Preflight: Interne Struktur aller Dokumentenschriften darstellen" für die aus QXD erzeugte PDF-Datei angeschaut? Wie sind die Schriften dort codiert? Auch als CFF-Schriften? Laut Adobe ist diese CFF-Definition eine Art komprimierte "Verpackung" für Schriftinformation. Siehe auch dieser Link:
http://www.adobe.com/...e/archives/cff2.html

Hallo

Evtl. ist das hier ein ähnliches Problem, wie im QuarkXpress-Forum.
http://www.hilfdirselbst.ch/..._P384804.html#384804

Hallo,
anbei Struktur der in Quark "durchgeschleustern" PDF.

http://g.imagehost.org/view/0943/Corel_PDF_aus_QUARK

Wenn ich aber über PS/Distiller gehe - habe ich wieder das oben beschriebene Problem.

Viele Grüße

Nachtrag:
und das zeigt Indesign CS4:
http://g.imagehost.org/view/0744/Corel_PDF_aus_INDESIGN_CS4

Hallo, Reitschuster!
Hier auf meinem Mac kann ich das Problem so nicht nachvollziehen. Was ich getestet habe:
die Problemdatei "test_unicode.pdf" auf eine InDesign-Seite platziert, PostScript-Ausgabe, Distillt nach PDF; oder PDF-Export aus InDesign.
Jeweils die Varianten CS3 und CS4 durchgespielt, distillt mit Distiller 9, überprüft mit Acrobat 9 Pro. Erzeugt habe ich verschiedene PDF-Varianten: PDF/X-1a, PDF/X-3:2002, PDF/X-3:2002.

Hallo Laubender,
stimmt. Mein Fehler.
Rücklauf von callas:

Sehr geehrter Herr Reitschuster,

ich habe nun Rückmeldung von der Entwicklung erhalten. Das Preflight in
Acrobat 9 hat hier Recht, der interne Fontname enthält ein Leerzeichen, was
laut CFF-Spezifikation verboten ist:

"For compatibility with client software, such as PostScript interpreters and
Acrobat®, font names should be no longer than 127 characters and should not
contain any of the following ASCII characters: [, ], (, ), {, }, <, >, /, %,
null (NUL), space, tab, carriage return, line feed, form feed. It is
recommended that font names be restricted to the printable ASCII subset, codes
33 through 126."
("The Compact Font Format Specification"->"7 Name INDEX", page 12)

pdfToolbox 4 hat diesen nicht entdeckt, dieser Bug wird aber auch in der
nächsten Release-Version behoben sein.


Wenn ich das richtig versehe, sind o.g. Zeichen nicht verboten, sonder sollten nicht verwendet werden. Da ist Acrobat Pro 9 strenger als vorgesehen.

Hallo, Reitschuster!

Antwort auf [ Reitschuster ]

stimmt. Mein Fehler.

Weshalb?

Zu den Erkenntnissen, was den Fontnamen betrifft: die Frage ist WESHALB das Leerzeichen in die interne Fontbezeichnung geschrieben wird, ohne daß das Leerzeichen im Code geschützt (escaped) oder oktal definiert oder anderweitig korrekt abgebildet wird.

Hndelt es sich hierbei um ein CorelDraw-Problem? Kann der PDF-Export bei Schriften, die ein Leerzeichen im Namen tragen, dieses nicht korrekt ins PDF schreiben? Die Experimente mit InDesign scheinen doch zumindest darauf hinzudeuten, daß das Problem nachträglich (nochmaliger Export, re-distillen) lösbar ist.

Gibt's, was die Reparatur im Acrobat-Preflight angeht, einen Lösungsvorschlag?

Hallo Laubender,
"mein Fehler" mit Bezug auf die PDF-Durchschleusung mit Indesign.

Meiner Meinung nach sollte Acrobat Pro 9 in dieser Sache nur einen Hinweis anzeigen, da das "Leerzeichen" expilizit nicht verboten ist.
Ich werde man eine Versuch wagen und mit der "Unicode-Einstellung" eine kleine
Auflage drucken lassen.
Viele Grüße

Hallo, Reitschuster!
Anschließend noch eine Bemerkung zum nachfolgenden Zitat:

Antwort auf [ Reitschuster ]

"For compatibility with client software, such as PostScript interpreters and Acrobat®, font names should be no longer than 127 characters and should not
contain any of the following ASCII characters: [, ], (, ), {, }, <, >, /, %,
null (NUL), space, tab, carriage return, line feed, form feed. It is
recommended that font names be restricted to the printable ASCII subset, codes
33 through 126."
("The Compact Font Format Specification"->"7 Name INDEX", page 12)

"Should not" (sollte nicht) ist nicht "must not" (darf nicht).
Dies ist eine Vorsichtsmaßnahme (eine art "Real-World-Situation"), da offensichtlich nicht jeder Druckertreiber, Exportmechanismus die im Zitat gelisteten Zeichen vernünftig ins PDF weiterreichen kann. CorelDraw scheint mir so ein Fall zu sein. Adobe schafft das schon. Siehe meine Versuche mit InDesign.

Hallo Laubender,
ich denke inzwischen auch, dass Corel mit "Leerzeichen" und "-" bei den Schriftnamen ein Problem hat.
Nach mehreren "Teststunden" habe ich es zumindest geschafft eine Testdatei ohne Fehlermeldung zu erstellen.

http://g.imagehost.org/download/0266/Unicode_bestanden

Vielen Dank für deine Geduld und Mühe.

Aber ob sich deine und meine Mühe lohnt - Corel ist bei der Bug Beseitigung recht träge.