Sind von Acrobat erzeugte PDF-Dateien speziell?
Christoph Bier
weil es heute auf einer Mailingliste aufkam und ich selbst nie auf
die Idee gekommen bin, es könne so sein, bin ich gerade etwas
verunsichert. Erzeugt Acrobat PDF-Dateien, die mehr enthalten, als
in den Spezifikationen beschrieben ist?
Grüße
Christoph
--
+++ Typografie-Regeln (1.7): http://zvisionwelt.de/?page_id=56
Thomas Kaiser
> weil es heute auf einer Mailingliste aufkam
Link auf Thread in Listenarchiv?
> und ich selbst nie auf die Idee gekommen bin, es könne so sein, bin
> ich gerade etwas verunsichert. Erzeugt Acrobat PDF-Dateien, die mehr
> enthalten, als in den Spezifikationen beschrieben ist?
Um was geht's denn konkret? PDF 1.0 - 1.6 oder ab 1.7 (AKA ISO 32000,
siehe <http://www.adobe.com/devnet/pdf/pdf_reference.html>)
Gruss,
Thomas
Christoph Bier
> Christoph Bier schrieb in <news:82tb9e...@mid.individual.net>
>> weil es heute auf einer Mailingliste aufkam
>
> Link auf Thread in Listenarchiv?
Thread:
https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215654.html
Beitrag, auf den ich mich beziehe:
https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215706.html
>> und ich selbst nie auf die Idee gekommen bin, es könne so sein, bin
>> ich gerade etwas verunsichert. Erzeugt Acrobat PDF-Dateien, die mehr
>> enthalten, als in den Spezifikationen beschrieben ist?
>
> Um was geht's denn konkret? PDF 1.0 - 1.6 oder ab 1.7 (AKA ISO 32000,
> siehe <http://www.adobe.com/devnet/pdf/pdf_reference.html>)
Zwar wird 1.7 zitiert, aber es war eher eine grundsätzliche
Überlegung, ohne dass der Autor es wirklich weiß (was er auch
eingesteht); abgeleitet aus Microsofts Verhalten bei HTML ... Der
Autor ist der Meinung, dass es unter Linux keinen PDF-Editor geben
könne, weil Acrobat proprietär ist. Ich bin eigentlich der Meinung,
dass das eine mit dem anderen nichts zu tun hat, weil die
PDF-Spezifikationen offen gelegt sind. Aber der Autor denkt, dass
mit Acrobat erzeugte PDF-Dateien Dinge enthalten können, die nicht
in den Specs stehen und es deshalb auch nur Acrobat möglich machen,
solche Dateien nachträglich zu bearbeiten.
Josef Kleber
Am 17.04.2010 11:54, schrieb Christoph Bier:
> Aber der Autor denkt, dass
> mit Acrobat erzeugte PDF-Dateien Dinge enthalten können, die nicht
> in den Specs stehen und es deshalb auch nur Acrobat möglich machen,
> solche Dateien nachträglich zu bearbeiten.
Eine PDF Datei auch nichts anderes als eine normale Textdatei, die
speziell interpretiert wird. Man kann also jederzeit reinschauen und
könnte "analysieren" was Acrobat da so reinschreibt.
Bei der Entwicklung von pdfcomment.sty habe ich das genau so mit Foxit
gemacht. Fast leere Seite mit jeweils einer PDF annotation drauf und
hinterher den Code analysiert, um zu wissen was ich in LaTeX machen muß
damit es funktioniert (+ PDF Refernece natürlich).
Die Bearbeitungsfunktion ist tatsächlich über eine Signatur geschützt,
damit nicht jede Software diese Funktion nutzen kann. Das ist aber mehr
ein Geschäftsinteresse von Adobe. Das Analysieren funktioniert da aber
auch, siehe AREnable. Andere PDF-Writer kümmern sich überhaupt nicht
drum und schreiben einfach eine neue PDF-Datei mit den hinzugefügten
annotations.
Zu guter Letzt sollte man auf solche Verschwörungstheorien verzichten
und in die angeblichen Linux-PDF-Viewer erst mal das implementieren das
in der PDF-Reference für jeden offenliegt. Da gäbe es mehr als genug zu
tun. PDF annotations zum Beispiel scheint es für alles was auf poppler
basiert (und vieles mehr wahrscheinlich) nicht zu geben.
Viele Grüße,
Josef
--
Keine Sicherheit ohne Schäuble:
GNUPG/PGP-Key unter http://www.josef-kleber.de/pgp/Josef_Kleber_News.asc
DSA 1024 / 0xF4B1EA2A / F832 6058 319E FFD4 0EFF 088C 521B 40D4 F4B1 EA2A
Christoph Bier
Eine ähnliche Antwort habe ich auch schon in Vorbereitung, habe mich
aber wie gesagt verunsichern lassen; Gerade das mit der »normalen
Textdatei«. Denn ich meine mich an PDF-Dateien zu erinnern, die ich
mir mit einem Texteditor angesehen habe, und die Binärdaten
enthielten -- vielleicht eine Grafikdatei?
Danke für Deine Antwort!
Thomas Kaiser
> Thomas Kaiser schrieb am 17.04.2010 11:16:
>
>> Christoph Bier schrieb in <news:82tb9e...@mid.individual.net>
>>> weil es heute auf einer Mailingliste aufkam
>>
>> Link auf Thread in Listenarchiv?
>
> Thread:
> https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215654.html
>
> Beitrag, auf den ich mich beziehe:
> https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215706.html
Danke, bestätigt meine Vermutung.
>>> und ich selbst nie auf die Idee gekommen bin, es könne so sein, bin
>>> ich gerade etwas verunsichert. Erzeugt Acrobat PDF-Dateien, die mehr
>>> enthalten, als in den Spezifikationen beschrieben ist?
>>
>> Um was geht's denn konkret? PDF 1.0 - 1.6 oder ab 1.7 (AKA ISO 32000,
>> siehe <http://www.adobe.com/devnet/pdf/pdf_reference.html>)
>
> Zwar wird 1.7 zitiert, aber es war eher eine grundsätzliche
> Überlegung, ohne dass der Autor es wirklich weiß (was er auch
> eingesteht); abgeleitet aus Microsofts Verhalten bei HTML ... Der
> Autor ist der Meinung, dass es unter Linux keinen PDF-Editor geben
> könne, weil Acrobat proprietär ist. Ich bin eigentlich der Meinung,
> dass das eine mit dem anderen nichts zu tun hat, weil die
> PDF-Spezifikationen offen gelegt sind.
So sehe ich das auch und so ist das ja auch. Freilich können ab PDF 1.7
auch Erweiterungen der Specs -- von wem auch immer -- angebracht werden,
bspw. Adobe, die ja genau das auch getan haben. Und diese Erweiterungen
wiederum vollständig spezifiziert haben. Das muß aber gar nicht mal
geschehen, d.h. $irgendwer kann auch private Erweiterungen definieren
solange er die nur korrekt benennt und registriert [1]. Ein konformer
PDF-Konsument hat sich dann um solche neuen Elemente einfach nicht zu
scheren. Die Spec ist diesbzgl. doch recht klar?
When a new version of PDF is defined, many features are introduced
simply by adding new entries to existing dictionaries. Earlier
versions of conforming readers do not notice the existence of such
entries and behave as if they were not there. Such new features are
therefore both forward- and backward-compatible. Likewise, adding
entries not described in the PDF specification to dictionary objects
does not affect the conforming reader’s behaviour. See Annex E for
information on how to choose key names that are compatible with
future versions of PDF. See 7.12.2, “Developer Extensions
Dictionary” for a discussion of how to designate the use of public
extensions in PDF file.
In some cases, a new feature is impossible to ignore, because doing
so would preclude some vital operation such as viewing or printing a
page. For instance, if a page’s content stream is encoded with some
new type of filter, there is no way for an earlier version of
conforming reader to view or print the page, even though the content
stream (if decoded) would be perfectly understood by the reader.
There is little choice but to give an error in cases like these.
Such new features are forward-compatible but not
backward-compatible.
In a few cases, new features are defined in a way that earlier
versions of conforming readers will ignore, but the output will be
degraded in some way without any error indication. If a PDF file
undergoes editing by an earlier version of a conforming product that
does not understand some of the features that the file uses, the
occurrences of those features may or may not survive. public
extensions in PDF file.
> Aber der Autor denkt, dass mit Acrobat erzeugte PDF-Dateien Dinge
> enthalten können, die nicht in den Specs stehen und es deshalb auch
> nur Acrobat möglich machen, solche Dateien nachträglich zu bearbeiten.
Dann soll er halt lesen lernen. Unter dem Link, den er selbst zitiert
hat, steht doch alles klar und deutlich.
PDF-Dateien gemäß ISO 32000 enthalten als Versionssnummer PDF 1.7 nebst
Angabe der benutzen "Extensions". Adobes eigene sind AFAIK vollständig
dokumentiert, bei der ISO für die nächste ISO 32000 Revision eingereicht
und bereits akzeptiert.
Das Problem mit einem vollwertigen OpenSource-PDF-Editor (daß der
Proponent nur von Linux quatscht, ist IMO schon deutliches Zeichen von
Beschränktheit) ist doch das der Komplexität auf der einen und der
Ignoranz auf der anderen Seite. PDF dürfte das Grafikformat mit dem
umfänglichsten grafischen Modell sein, das es aktuell gibt. Was man
alleine auf der Ebene Bildformate, Kompressionsalgorithmen, Farbräume,
ColorManagement, Font-Technologien beherrschen muß, um ein PDF auch nur
sauber darstellen zu können, ist schon nicht ohne.
Das Ganze dann sinnvoll editieren zu können, setzt auch noch voraus, das
"große Ganze" zu kapieren, d.h. nicht nur das interne Format von PDF zu
beherrschen (also wo muß welcher Pointer wie zurechtgebogen werden, wenn
sich an dem und dem Objekt was ändert) sondern auch zu wissen, was wo
nachgezogen werden muß, wenn man gewisse Objekte ändert bzw. was gar
nicht geändert werden darf (bspw. gewisse Farbräume von Objekten, wenn
das PDF am Ende wieder der selben (Sub-)Spezifikation entsprechen soll,
wie vorher. RGB in PDF/X-1a ist tabu, ICCBased in PDF < 1.3 dito, usw.
usf.)
Das ist einfach verdammt komplex. Und sowas Leuten beibiegen zu wollen,
die glauben, ein PDF lasse sich verlustfrei in irgendwelche anderen
Formate umwandeln, die ein deutlich eingeschränkteres grafisches Modell
haben, und von dort wieder zurück nach PDF (wie es ja dauernd geschieht
unter Linux, wenn PDF durch GhostScript Richtung PS und zurück genudelt
wird), ist wohl aussichtslos. Die stellen sich doch zehnmal eher auf den
Standpunkt, das könne alles nicht gehen, solange der Source Code von
Acrobat veröffentlicht werden, dabei verkennend wie das mit
Spezifikation und Implementierung im Fall PDF aussieht.
Und bitte nicht falsch verstehen: Adobe ist ja wirklich kein Engelchen
(im Bereich PDF zwar noch am ehesten verglichen mit anderen Bereichen,
in denen es wirklich gravierende Abweichungen zwischen Specs und dann
doch definitiver Referenz-Implementierung in Form des passenden Adobe-
Produkts gibt) aber im Bereich PDF-Specs und Implementierung geht diese
Sorte Kritik völlig am eigentlichen Thema (Komplexität der Materie und
Ignoranz der Entwickler) vorbei.
Leute, die sich wirklich mit der Thematik beschäftigt haben (bspw.
Enfocus- oder Callas-Entwickler, die Produkte für PDF-Editierung
entwickeln) können sicherlich in Detailbereichen auch von Problemen
bzgl. Einhaltung der Specs vs. Referenz-Implementierung berichten (bzw.
von der pragmatischen Lösung, dann einfach von entsprechenden
Eigenentwicklungen auf lizensierte Adobe-Bibliotheken umzuschwenken ;-).
Aber im Großen und Ganzen kann man sich bei PDF auf die Specs verlassen.
Man muß sie halt nur auch vollständig implementieren, und das ist IMO
das eigentliche Problem.
Gruss,
Thomas
[1] <http://www.adobe.com/devnet/acrobat/pdfs/pdfregistry_v3.pdf>
Josef Kleber
Ja natürlich, aber auch z.B. eingebettete Fonts, ...! Speziell die Fonts
kann man daher ja z.B. mit fontforge wieder rausholen. Daher verbieten
ja auch alle das komplette Einbetten der Fonts. Sonst wäre es mit dem
Geschäftsmodell sehr schnell vorbei! ;-)
Die "Strukturelemente" sind aber alles "normaler" Text
Christoph Bier
> Christoph Bier schrieb in <news:82ter5...@mid.individual.net>
>> Thomas Kaiser schrieb am 17.04.2010 11:16:
>>
>>> Christoph Bier schrieb in <news:82tb9e...@mid.individual.net>
>>>> weil es heute auf einer Mailingliste aufkam
>>>
>>> Link auf Thread in Listenarchiv?
>>
>> Thread:
>> https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215654.html
>>
>> Beitrag, auf den ich mich beziehe:
>> https://lists.ubuntu.com/archives/ubuntu-users/2010-April/215706.html
>
> Danke, bestätigt meine Vermutung.
>
>>>> und ich selbst nie auf die Idee gekommen bin, es könne so sein, bin
>>>> ich gerade etwas verunsichert. Erzeugt Acrobat PDF-Dateien, die mehr
>>>> enthalten, als in den Spezifikationen beschrieben ist?
>>>
>>> Um was geht's denn konkret? PDF 1.0 - 1.6 oder ab 1.7 (AKA ISO 32000,
>>> siehe <http://www.adobe.com/devnet/pdf/pdf_reference.html>)
>>
>> Zwar wird 1.7 zitiert, aber es war eher eine grundsätzliche
>> Überlegung, ohne dass der Autor es wirklich weiß (was er auch
>> eingesteht); abgeleitet aus Microsofts Verhalten bei HTML ... Der
>> Autor ist der Meinung, dass es unter Linux keinen PDF-Editor geben
>> könne, weil Acrobat proprietär ist. Ich bin eigentlich der Meinung,
>> dass das eine mit dem anderen nichts zu tun hat, weil die
>> PDF-Spezifikationen offen gelegt sind.
>
> So sehe ich das auch und so ist das ja auch. [Weitere
> ausführliche Stellungnahme]
Vielen Dank! Ich nehme an, Du klinkst Dich nicht in den Thread auf
der ML ein (Du bist ja durchaus manchmal dort unterwegs). Darf ich
aus Deiner Antwort hier zitieren?
Schöne Grüße
Thomas Kaiser
Auf Linux-Mailinglisten?! Gott (oder was auch immer) bewahre! ;-)
> Darf ich aus Deiner Antwort hier zitieren?
Klar.
Gruss,
Thomas
Thomas Kaiser
> Eine PDF Datei auch nichts anderes als eine normale Textdatei, die
> speziell interpretiert wird.
Sehr gewagte Formulierung bzw. IMO komplett daneben :-)
Ein PDF besteht aus 'zig Objekten, die an quasi beliebiger Stelle im PDF
auftauchen können und die -- in jedem Fall schon mal seitenweise --
voneinander unabhängig sind. Damit ein PDF-Konsument findet, was er
sucht, sind alle Objekte via Querverweistabelle (xref table) indiziert,
auf die am Ende der Datei verwiesen wird und die sich ihrerseits
wiederum irgendwo in der Datei befindet.
Mal eben schnell was einzufügen oder zu löschen, geht schief, wenn man
nicht die xref table mit auffrischt. In der PostScript- und PDF-Bibel
ist das in Kapitel 12 alles schick dargestellt für die, die gar keine
Vorstellung davon haben sollten:
<http://www.pdflib.com/developer/technical-documentation/books/postscript-pdf-bibel/>
Und Deine Aussage im Parallelposting, daß die "Strukturelemente" reiner
Text seien, würde ich jetzt mal so verstehen, daß die Struktur einfach
unkomprimiert im PDF vorliegt? Was spätestens ab PDF 1.5 aber nicht mal
mehr sein muß (ab da können nicht nur einzelne Streams bzw. Elemente im
PDF komprimiert abgelegt werden sondern auch die Struktur bzw. xref
table selbst, was die Beschränkung auf ca. 9,1 GByte Dateigröße für
PDF-Dateien, die in manchen Bereichen schon zum Problem wird, aufhebt.
Dieser Fall bzw. diese PDF-Version ist in der "Bibel" aber leider noch
nicht beschrieben)
Was aber alles nichts dran ändert, daß der Kram spezifziert ist und für
jeden des Lesens und Codens Mächtigen in Form eines PDF-Parsers und
-Writers umsetzbar ist, wenn er denn Zeit/Muße aufbringt, die Specs
vollumfassend zu implementieren, was ein riesiger Haufen Arbeit ist.
Da braucht es keine Ähnlichkeit zu "Text", denn es gibt ausreichend
offen spezifizierte Binärformate bei denen kein Schwein danach schreit,
irgendein Hersteller müsse den Quellcode bspw. seines TIFF-Readers
offenlegen, nur damit die TIFF-Spezifikation auf einmal verstanden
werden könne.
> Zu guter Letzt sollte man auf solche Verschwörungstheorien verzichten
> und in die angeblichen Linux-PDF-Viewer erst mal das implementieren
> das in der PDF-Reference für jeden offenliegt. Da gäbe es mehr als
> genug zu tun. PDF annotations zum Beispiel scheint es für alles was
> auf poppler basiert (und vieles mehr wahrscheinlich) nicht zu geben.
Stimmt, das ganze "nicht Visuelle" hatte ich vorher ausgeklammert.
Betrifft ja nicht nur Annotations sondern auch Formularelemente,
Hyperlinks, Tags (barrierefreies PDF), Lesezeichen, eingebettete
Suchindizes, JavaScript-Funktionen, Ebenen bzw. OCG (Optional Content
Groups), etc.
In dem Kontext ist auch noch interessant, daß kontunierlich an neuen
PDF-(Sub-)Standards gewerkelt wird, die für bestimmte Zielgruppen
optimiert werden wie bspw. PDF/VT (variable Daten, Druckindustrie) oder
PDF/UA (Barrierefreiheit). All diese Sachen werden in verschiedenen
internationalen Arbeitsgruppen vorangetrieben, die teils bei der ISO
angesiedelt sind, teils unabhängig davon (bspw. Ghent PDF Workgroup
<http://www.gwg.org/>, European Color Initiative <http://www.eci.org>,
etc.)
Damit der Kram weiterhin unter dem Dach der ISO bleibt, wird eben dort
auch alles brav eingetütet:
<http://pdf.editme.com/pdfrefNewFeatures>
Gruss,
Thomas
Christoph Bier
> Christoph Bier schrieb in <news:82tmv4...@mid.individual.net>
>> Thomas Kaiser schrieb am 17.04.2010 13:38:
>>
>>> So sehe ich das auch und so ist das ja auch. [Weitere ausführliche
>>> Stellungnahme]
>>
>> Vielen Dank! Ich nehme an, Du klinkst Dich nicht in den Thread auf
>> der ML ein (Du bist ja durchaus manchmal dort unterwegs).
>
> Auf Linux-Mailinglisten?!
Ok, dann hast Du einen Namensvetter in der Ubuntu-Gemeinde. Habe
auch gerade gesehen, dass er eine andere E-Mail-Adresse als Du
verwendet.
> Gott (oder was auch immer) bewahre! ;-)
Insbesondere in den Ubuntu-Listen herrscht ein sehr angenehmer
Umgangston. Falls Du das meintest ... ;-)
[...]
Josef Kleber
> Josef Kleber schrieb in <news:hqc4ql$2d9$1...@kleberj.eternal-september.org>
>> Eine PDF Datei auch nichts anderes als eine normale Textdatei, die
>> speziell interpretiert wird.
>
> Sehr gewagte Formulierung bzw. IMO komplett daneben :-)
Zugegeben, etwas frei formuliert. ;-) Ich wollte damit nur ausdrücken,
daß man eine PDF-Datei durchaus auch mal im Texteditor "anschauen" kann.
> Ein PDF besteht aus 'zig Objekten, die an quasi beliebiger Stelle im PDF
> auftauchen können und die -- in jedem Fall schon mal seitenweise --
> voneinander unabhängig sind. Damit ein PDF-Konsument findet, was er
> sucht, sind alle Objekte via Querverweistabelle (xref table) indiziert,
> auf die am Ende der Datei verwiesen wird und die sich ihrerseits
> wiederum irgendwo in der Datei befindet.
>
> Mal eben schnell was einzufügen oder zu löschen, geht schief, wenn man
> nicht die xref table mit auffrischt. In der PostScript- und PDF-Bibel
> ist das in Kapitel 12 alles schick dargestellt für die, die gar keine
> Vorstellung davon haben sollten:
>
> <http://www.pdflib.com/developer/technical-documentation/books/postscript-pdf-bibel/>
Das ist mir durch meine oberflächliche Einarbeitung in PDF klar, aber
den meisten Anwendern nicht. Klassisches Beispiel in LaTeX:
Zusammenfügen von PDF-Dateien mit pdfpages.sty -> Frage: Warum hat die
neue Datei keine Links mehr
> Und Deine Aussage im Parallelposting, daß die "Strukturelemente" reiner
> Text seien, würde ich jetzt mal so verstehen, daß die Struktur einfach
> unkomprimiert im PDF vorliegt? Was spätestens ab PDF 1.5 aber nicht mal
> mehr sein muß (ab da können nicht nur einzelne Streams bzw. Elemente im
> PDF komprimiert abgelegt werden sondern auch die Struktur bzw. xref
> table selbst, was die Beschränkung auf ca. 9,1 GByte Dateigröße für
> PDF-Dateien, die in manchen Bereichen schon zum Problem wird, aufhebt.
> Dieser Fall bzw. diese PDF-Version ist in der "Bibel" aber leider noch
> nicht beschrieben)
Das wusste ich nicht. Aber ich stecke auch nicht so tief drin in PS und
PDF wie Du! ;-)
> Was aber alles nichts dran ändert, daß der Kram spezifziert ist und für
> jeden des Lesens und Codens Mächtigen in Form eines PDF-Parsers und
> -Writers umsetzbar ist, wenn er denn Zeit/Muße aufbringt, die Specs
> vollumfassend zu implementieren, was ein riesiger Haufen Arbeit ist.
Eben. Mich stört vor allem das Geschwaffel über pöse proprietäre
Software und "gute" Opensource-Software. Dabei ist es in diesem
speziellen Fall so, daß dem User vorgegaugelt wird er hätte einen
vollwertigen PDF-Viewer. Dabei werden ihm aber bestimmte Teile einer
PDF-Seite schlichtweg unterschlagen, weil komplette Teilbereiche der PDF
Reference nicht implementiert werden, obwohl der Standard offen ist. Und
der User hat keine Chance zu erkennen, daß nur ein Teil der PDF-Datei
korrekt angezeigt wird.
Christoph Bier
[...]
> Das ist mir durch meine oberflächliche Einarbeitung in PDF klar, aber
> den meisten Anwendern nicht. Klassisches Beispiel in LaTeX:
> Zusammenfügen von PDF-Dateien mit pdfpages.sty -> Frage: Warum hat die
> neue Datei keine Links mehr
OT: Dafür gibt es von Andreas Mathias schon lange einen Patch für
PDFTeX, den die Hauptentwickler aber nicht für wichtig halten ...
[...]
Thomas Kaiser
> Mich stört vor allem das Geschwaffel über pöse proprietäre Software
> und "gute" Opensource-Software. Dabei ist es in diesem speziellen Fall
> so, daß dem User vorgegaugelt wird er hätte einen vollwertigen
> PDF-Viewer. Dabei werden ihm aber bestimmte Teile einer PDF-Seite
> schlichtweg unterschlagen, weil komplette Teilbereiche der PDF
> Reference nicht implementiert werden, obwohl der Standard offen ist.
> Und der User hat keine Chance zu erkennen, daß nur ein Teil der
> PDF-Datei korrekt angezeigt wird.
Das Dilemma haste aber nicht nur bei OpenSource vs. kommerziell sondern
auch in anderen Ausprägungen (wobei eine Komponente dabei immer die
quasi semi-religiöse Grundhaltung der Leute ist). Apple setzt ja bei
MacOS X auf PDF als internes Grafikdateiformat (Bildschirminhalte werden
intern erstmal in PDF repräsentiert und dann erst gerendert -- geschieht
alles mittels des CoreGraphics-Framework).
So halb als Abfallprodukt des Ganzen ist der PDF-Support in Apples
Grafikbetrachter "Vorschau" (Preview.app) zu betrachten. Kann PDF sehr
schnell anzeigen, dito indizieren für Volltextsuche, implementiert aber
immer nur ein Subset von PDF (je höher die MacOS X Version, desto besser
-- aber es fehlen grad für manche Zielgruppen bzw. Branchen dann gerne
mal einige wichtige Features, mit denen der seitens Apple-Anwendern
gerne verschriene Adobe Reader naturgemäß keine Probleme hat).
Ich durfte mal erleben, daß ein Apple-Apologet in der Druckvorstufe
schon vor 'zig Jahren PDF nur mehr grundsätzlich mit "Vorschau"
betrachtet und Richtung Drucker geschickt hat. Und das zu 'nem Zeitpunkt
als das Programm noch nicht mal Annotations überhaupt dargestellen
konnte (was alleine deshalb durchgerutscht ist, weil die riesigen
Notizzettel mit Warnungen oder Verarbeitungshinweisen, die
Datenlieferanten quer übers PDF gepappt haben, nicht mal angezeigt
wurden, war schon immens)
Ganz zu schweigen von anderen Prepress-relevanten Sachen, die in
Preview.app einfach falsch bzw. gar nicht dargestellt/ausgegeben wurden.
Als ihm das klar (gemacht) wurde, erstmal auf kleinlaut und reuig
geschalten. Aber inzwischen wieder große Töne in allen möglichen Foren
spuckend, was der Adobe Reader doch für überflüssige Bloatware sei und
einzig Apple-Software glücklich machen würde, etc. ... "Ignorance is
bliss"
Gruss,
Thomas