PDF komprimieren

PDF komprimieren

Ich hoffe, Ihr könnt mir helfen.
Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
basteln. Dies soll später automatisiert unter Linux laufen, also
brauche ich Kommandozeilentool.

Ich habe hierzu bisher folgende Lösungen gefunden:

pdftk test1.pdf output test2.pdf compress

Dieses macht aus der 76,3 MB großen Datei aber nur eines, welches 76,0
MB groß ist.

Dann habe ich folgende tolle Seite gefunden:
http://wiki.scribus.net/index.php/PDF-Dateien_f%C3%BCr_das_Internet_komprimieren,_inklusive_Perl-Skript

Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
immer. Manche Seite sind schön klein geworden, andere nicht, dafür
kaputt (Grafiken werden falsch positioniert, sind schwarz, blinken?!).
Die gs-Parameter sind hier übrigens:
gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3
-dPDFSETTINGS=/screen -dEmbedAllFonts=true -dSubsetFonts=true
-dColorImageDownsampleType=/Bicubic -dColorImageResolution=144
-dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=300
-dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=300
-sOutputFile=test.tmp_wR3gfH -c .setpdfwrite -f test.ps_IsmPuN
test.meta

Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
Library 7.0

Nun die Fragen: 
- Kann GS mit dem Format nicht umgehen?
- Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Falls diese Gruppe nicht die richtige ist (was ich nicht hoffe), dann
würde ich mich über einen freundliche Hinweis auf die richtige Gruppe
freuen.

Viele Grüße,
Andreas Muschkat

Re: PDF komprimieren

   Andreas Muschkat schrieb:
> Ich hoffe, Ihr könnt mir helfen.
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
> basteln. Dies soll später automatisiert unter Linux laufen, also
> brauche ich Kommandozeilentool.  [...]

Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
in neue PDF-Dateien umwandeln ...

Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Stefan

.

Re: PDF komprimieren

On Sun, 08 Jun 2008 23:00:04 +0200, Stefan Lagotzki <lago20@gmx.de>
wrote:
>Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
>Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
>in neue PDF-Dateien umwandeln ...

Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

>> Die gs-Parameter sind hier übrigens:
>> gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatib...

und 

>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?

>Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Danke für den Link. Ich habe noch ein Parameter geändert, aber die
Konvertierung ist weiterhin fehlerhaft. Daher gelten meine beiden
Fragen aus dem Eingangsposting weiterhin.

Andreas

Re: PDF komprimieren

   Andreas Muschkat fragte:
> 
> Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

Ja. Und deshalb habe ich geschrieben: "Mit GhostScript kann man auch
PDF-Dateien in neue PDF-Dateien umwandeln." Du hast es aber mit Post-
Script versucht.

Stefan

.

Re: PDF komprimieren

Moin,

On Sun, 08 Jun 2008 20:51:12 +0200 Andreas Muschkat
<newsgroup1689@muschkat.de> wrote:

> Erstellt wurden die PDFs =FCbrigens mit Adobe InDesign CS2 / Adobe PDF
> Library 7.0
>=20
> Nun die Fragen:=20
> - Kann GS mit dem Format nicht umgehen?

Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
neueste Version?

Und lass' mal die Compatibility-Level-Einstellung und das
Font-Embedding/Subsetting weg, das bringt f=FCr dein Ziel eh nicht viel.

Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
PitStop und Co.

-hwh

Re: PDF komprimieren

Hallo,

On Mon, 9 Jun 2008 12:14:49 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:
>> Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
>> Library 7.0
>> 
>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?
>
>Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
>neueste Version?

Auf dem Server ist Version 8.15.3 installiert, bei mir habe ich die
Version 8.61, was aber keinen nennenswerten Unterschied brachte.

>Und lass' mal die Compatibility-Level-Einstellung und das
>Font-Embedding/Subsetting weg, das bringt für dein Ziel eh nicht viel.

Hier mal ein paar Beispiele. Ich habe alle PDFs so wie am Anfang
beschrieben erstellt, außer die bei Seite 5.

Hier gibts rechts einen schwarzen Balken:
http://www.muschkat.de/pdf/seite3_vorher.pdf
http://www.muschkat.de/pdf/seite3_nachher.pdf

Hier sind säliche Grafiken kaputt:
http://www.muschkat.de/pdf/seite4_vorher.pdf
http://www.muschkat.de/pdf/seite4_nachher.pdf

Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
Optimierung noch wesentlich größer. Vorher 4,9 MB, nacher 28-34 MB.
Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
der Aufruf:
pdftops -level3 seite3.pdf seite3.ps_GXUzyB

http://www.muschkat.de/pdf/seite5_vorher.pdf
http://www.muschkat.de/pdf/seite5_nachher.pdf

Hier habe ich den Teil -dCompatibilityLevel=1.3 weggelassen:
http://www.muschkat.de/pdf/seite5a_nachher.pdf

Hier zusätzlich die beiden Font-Parameter:
http://www.muschkat.de/pdf/seite5b_nachher.pdf

Dieses PDF habe ich mit der Version 8.61 erstellt. Es ist kleiner als
die drei Versionen oben aber genauso kaputt.
http://www.muschkat.de/pdf/seite5c_nachher.pdf

Kaputte Grafiken und noch ein fehlender Font (da liegt aber wohl der
Fehler in der Erstellung)
http://www.muschkat.de/pdf/seite6_vorher.pdf
http://www.muschkat.de/pdf/seite6_nachher.pdf


>Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
nicht auf die Idee, dass in dem Maße fehlerhaft sein könnte.

>> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
>
>Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und
>PitStop und Co.

Hmm..

Viele Grüße,
Andreas

Re: PDF komprimieren

Hi,

> Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
> Optimierung noch wesentlich gr=F6=DFer. Vorher 4,9 MB, nacher 28-34 MB.
> Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
> der Aufruf:
> pdftops -level3 seite3.pdf seite3.ps_GXUzyB

Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS
rasterst. Das musst du gar nicht, da Ghostscript selbst auch PDF
versteht (lesend). F=FCtter' mal direkt PDF hinein, vielleicht gibt das
schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
gemacht, das Ergebnis von

gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dEmbed=
AllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dColorImag=
eDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -dColorIma=
geResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayImageDownsamp=
leType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsampleThreshol=
d=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResolution=3D200 -s=
OutputFile=3Dtest.pdf -f seite5_vorher.pdf

Anm.: das =BB-c .setpdfwrite=AB ist =FCberfl=FCssig, ich habe die Grafikauf=
l=F6sungen
  noch etwas weiter 'runtergeschraubt, da der Satzspiegel ja ziemlich
  gro=DF ist -- obwohl das hier nicht viel Gewinn bringt

ist bei mir ganz ordentlich (wenn du das sehen willst, dann schreib'
mal 'ne PM, ich wollte es nicht ins Web packen, da nicht mein Inhalt)
-- 1,9 MB, also ca. Faktor 0,4.

Einmal pdfopt dr=FCberlaufen lassen ist auch sicher gut, wenn das
Ergebnis ins Web soll (macht aber f=FCr Einzelseiten keinen Sinn).

> >Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.
>=20
> Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
> nicht auf die Idee, dass in dem Ma=DFe fehlerhaft sein k=F6nnte.

Und ich dachte dagegen, es sei allein Ghostscript beteiligt.... Also
erstmal eher nicht... Und es scheint jetzt ja gut zu funktionieren.

> >> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
> >
> >Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
> >PitStop und Co.
>=20
> Hmm..

...genau :-(
Acrobats Optimierung schrumpft das ganze =FCbrigens auch nicht unbedingt
noch kleiner.

Gru=DF,

-hwh

Re: PDF komprimieren

On Tue, 10 Jun 2008 14:20:22 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:

>versteht (lesend). Fütter' mal direkt PDF hinein, vielleicht gibt das
>schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
>gemacht, 

Danke, das klappt schon recht gut. Allerdings habe ich beim Aufruf der
PDFs noch diverse Meldungen "In der Schrift XX ist der Wert für /BBox
fehlerhaft" und bei 2 PDFs bekomme ich Fehlermeldungen ("Missing
glyph" und mit einer längeren Meldung, die mit "In der Schrift "ERROR:
/rangecheck in --cvrs--" beginnt). Die Ursprungs-PDFs scheinen wohl
doch zu "anspruchsvoll" zu sein...

Andreas

Re: PDF komprimieren

Andreas Muschkat schrieb am 11.06.2008 in <news:akbv44t863u9rl40cjmpetqg3ugh6ifmci@4ax.com>
> Die Ursprungs-PDFs scheinen wohl doch zu "anspruchsvoll" zu sein...

Eher Dein Werkzeug zu beschränkt bzw. grundsätzlich untauglich für den 
Zweck :-)

Gruss,

Thomas

Re: PDF komprimieren

Hans-Werner Hilse <hilse@web.de> schrieb:
> gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dE=
mbedAllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dCol=
orImageDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -d=
ColorImageResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayIma=
geDownsampleType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsa=
mpleThreshold=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResol=
ution=3D200 -sOutputFile=3Dtest.pdf -f seite5_vorher.pdf
>=20

Also, irgendwas ist da noch suboptimal: Ich lie=C3=9F das mal =C3=BCber
seite3_vorher.pdf laufen, und dann passierte folgendes:

|$ gs #etc -f seite3_vorher.pdf
|   **** Warning: ToUnicode CMap has invalid syntax near CIDSystemInfo.
|#last message repeated 11 times
|
|   **** This file had errors that were repaired or ignored.
|   **** The file was produced by:=20
|   **** >>>> Adobe PDF Library 7.0 <<<<
|   **** Please notify the author of the software that produced this
|   **** file that it does not conform to Adobe's published PDF
|   **** specification.

Aha: Adobe selbst erf=C3=BCllt die eigenen Spezifikationen nicht. Aber es
kommt noch schlimmer:

|$ xpdf test.pdf
|Error: Illegal entry in bfrange block in ToUnicode CMap
|#last message repeated 22 times
|Out of memory

Was bitte? Kein Speicher mehr?

|$ free -m
|             total       used       free     shared    buffers     cache=
d
|Mem:           187         83        103          0          3         1=
9
|-/+ buffers/cache:         60        126
|Swap:          703        189        513

Reichen 103 MB nicht zum anzeigen der PDF? Zumal ja noch 513 MB im
Swap frei w=C3=A4ren. Aber von den Gr=C3=B6=C3=9Fenverh=C3=A4ltnissen sie=
ht die Sache ganz
gut aus:

|$ ll test.pdf seite3_vorher.pdf
|-rw------- 1 markus markus  13M 10. Jun 08:30 seite3_vorher.pdf
|-rw------- 1 markus markus 495K 11. Jun 11:39 test.pdf

Trotzdem: Ein "Out of memory" hatte ich noch nie. Wieviel
Zusatz-Speicher ist denn n=C3=B6tig? Alle relevanten ulimits stehen auf
unlimited. (Au=C3=9Fer max locked memory, das steht 32 kb)

=C3=9Cbrigens ist auf der Seite noch ein Schreibfehler: In der
Bildunterschrift hei=C3=9Ft der Typ noch "Mark Kitter", in der
Sub=C3=BCberschrift des Artikels "Marc Kitter" (also einmal mit k, einmal
mit c).

Und ehe ich es vergesse:

|$ gs --version
|8.62

> Gru=C3=9F,
>=20
> -hwh

Tsch=C3=B6,
    Markus
--=20
Nur weil ein Genie nix rei=C3=9Ft, mu=C3=9F ja nun nicht gleich jeder Idi=
ot
pausieren... Bully hats ja auch geschafft.
    -- gUnter nanon=C3=BCm in de.alt.anime

Re: PDF komprimieren

Certain Adobe applications (like Indesign) in certain versions (I
believe CS 2) are writing the "CIDSystemInfo" in the ToUnicode map
without the necessary leading slash ("/CIDSystemInfo" must be a name
object). Any conforming parser for the ToUnicode map will then fail to
successfully parse the ToUnicode map. Also, AFAIK, the problem has
been corrected in CS 3.

Olaf Dr=FCmmer

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 10.06.2008 in <news:20080610142022.66e8e726.hilse@web.de>
> Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS 
> rasterst.

Eher konvertieren, denn "rastern". Das pdftops aus dem XPDF-Paket ist 
kein RIP sondern ein (mehr oder weniger guter) Konverter, der die 
Elemente aus dem PDF soweit es geht in PS-Pendants überträgt. Sinnvoll 
ist dieser (Um-)Weg aber natürlich nicht.

> Das musst du gar nicht, da Ghostscript selbst auch PDF versteht 
> (lesend).

Auch da gilt aber die Einschränkung, daß dabei alles, was über ein 
kleines Subset an PDF-Features hinausgeht, auf der Strecke bleibt. Mag 
für grafisch wenig anspruchsvolles PDF reichen, man sollte sich aber 
nicht wundern, wenn nachher Elemente ganz fehlen (alles non-visuelle 
bspw. komplett) oder "kaputt" erscheinen.

> Acrobats Optimierung schrumpft das ganze übrigens auch nicht unbedingt 
> noch kleiner.

Naja, das kommt immer auf sowohl Ausgangsdaten als auch Parameter (in 
dem Fall vor allem PDF-Version an, da jede höhere Version mehr an 
Kompression ermöglicht) an.

Bevor ich eine GhostScript-Verwurstung eines PDF in Betracht ziehen 
würde, käme bei mir zuerst mal direkt das Acrobat eigene "Optimieren" 
zum Zuge, da das in jedem Fall bessere Ergebnisse liefert. Wenn man 
mittels GhostScript ein Zwischenprodukt schafft und erst dann Acrobat 
drauf losläßt, kann es sein, daß man suboptimale Ausgangsdaten für 
Acrobat erzeugt hat und dann in der Tat eine weitere Optimierung nicht 
mehr viel bringt.

Gruss,

Thomas

Re: PDF komprimieren

Hallo Andreas,

> http://www.muschkat.de/pdf/seite3_vorher.pdf
> http://www.muschkat.de/pdf/seite4_vorher.pdf
> http://www.muschkat.de/pdf/seite5_vorher.pdf
Ich habe mal alle diese Dateien durch den PDFCreator (der verwendet auch 
Ghostscript) geschickt (durch drucken mit dem Adobe Reader).
Die Ergebnisse unterschieden sich im Bild nicht, nur die Dateigröße 
betrug ca. 1/10.
Das Programm ist aber ein Windows-Programm, dafür aber OpenSource.

Frank

Freeware pdf-writer gesucht!

Hallo!
Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit dem 
Adobe Writer, pdfs bearbeiten kann?
Danke schom im Voraus für Tipps!
Viele Grüße
Peter
mail@skodawessely.de 

Re: Freeware pdf-writer gesucht!

Sk schrieb:
> Hallo!
> Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit 
> dem Adobe Writer, pdfs bearbeiten kann?
> Danke schom im Voraus für Tipps!
> Viele Grüße
> Peter
> mail@skodawessely.de

Es gibt kein Programm mit dem Namen Adobe Writer. Ist eventuell Adobe 
Acrobat gemeint?

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 09.06.2008 in <news:20080609121449.ff93e604.hilse@web.de>
> Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und 
> PitStop und Co.

Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
PitStop und Co. ;-)

Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
> PitStop und Co. ;-)
> 
> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Automatisiert? Mir schien es eher so, dass er keinen Zugriff
auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat
(ab der Standardversion?), mit der man auch PDF-Dateien in einer
angepassten Qualität erzeugen kann: Sequenz "Schnelle Webanzeige"
hieß das IIRC in Acrobat 7.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb in <news:g35gus$5ii$03$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat 
>> und PitStop und Co. ;-)
>> 
>> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
>> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...
>
> Automatisiert? Mir schien es eher so, dass er keinen Zugriff
> auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
> InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
> sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
jetzt aber so, als ob das einerseits nicht der Fall wäre und 
andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
auf einem Linux-Server laufen _müsse_.

> Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat (ab der 
> Standardversion?), mit der man auch PDF-Dateien in einer angepassten 
> Qualität erzeugen kann:

Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
sozusagen extern verfügbar macht.

Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
(am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
nicht per AppleEvents)

Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 
Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
gar kein Acrobat gibt.

> Sequenz "Schnelle Webanzeige" hieß das IIRC in Acrobat 7.

Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
<http://tinyurl.com/6xnsz9>)

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
> jetzt aber so, als ob das einerseits nicht der Fall wäre und 
> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
> auf einem Linux-Server laufen _müsse_.

Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
dem Mac zu lösen.
Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
> alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
> gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
> Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
> sozusagen extern verfügbar macht.
> 
> Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
> auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
> man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
> (am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
> nicht per AppleEvents)

Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich
auch schon dazu? ;-)
Welche Form der Automatisierung wäre denn vom Preis/Leistungsverhältnis
her besser und weniger seicht?

> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
> Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 

Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
komplette Serverlösung von Adobe wäre sicher ungleich teurer.

> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
> nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
> gar kein Acrobat gibt.

Können die Leute denn so schnell gestalten und setzen, wie Deine
Automatisierung die anderen Aufgaben erfüllt? ;-)

   [Schnelle Webanzeige:]
> Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
> Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
> anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
> Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
> <http://tinyurl.com/6xnsz9>)

Wie gesagt, das war aus der Erinnerung und die kann trügen. Ich
meine mich zumindest zu erinnern, dass auch mehrfach vorhandene
Objekte aus den PDF-Dateien entfernt wurden. Aber das ist eine Weile
her. Eigentlich wollte ich nur auf die Möglichkeit heraus, das ganze
auf dem Rechner in Stapelverarbeitung zu machen, wo die CS samt Acrobat
sowieso schon arbeitet.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb am 16.06.2008 in <news:g367rg$k2k$00$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich 
>> das jetzt aber so, als ob das einerseits nicht der Fall wäre und 
>> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
>> auf einem Linux-Server laufen _müsse_.
>
> Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
> für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
> dem Mac zu lösen.
> Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
> eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

Ich weiß (ich mach' beruflich oft nix anderes, als die seitens Kunde 
formulierte Aufgabenstellung zu zerpflücken, zwei Schritte 
zurückzugehen, Wissen nachzufüttern, das Problem neu einzugrenzen und 
dann schlußendlich was völlig anderes als initial gewünscht umzusetzen)

Aber das Rätsel kann nur der OP lösen :-)

>> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
>> alles, was es in Acrobat-"Preflight" an internen Korrektur- 
>> Möglichkeiten gibt (im Kontext des OP interessant: Reduktion der 
>> Bildauflösungen, Konvertierung nach sRGB, Entfernen eingebetteter 
>> Dateien, etc.) sozusagen extern verfügbar macht.
>> 
>> Im Sinne des Erfinders, also Adobe, zieht man dann manuell 
>> PDF-Dateien auf diese Droplets bzw. nutzt seichte Formen von 
>> Automatisierung, indem man so ein Droplet bspw. mit einem open-Event 
>> und Pfad zum PDF beglückt (am Mac jetzt, geht unter Windows natürlich 
>> genauso, wenngleich da auch nicht per AppleEvents)
>
> Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich 
> auch schon dazu? ;-)

Hotfolder (zumindest, wenn sie an separaten von den eigentlichen 
Produktionsdaten abgekoppelten Orten liegen) mag ich eh nicht so 
besonders ;-)

> Welche Form der Automatisierung wäre denn vom Preis/ 
> Leistungsverhältnis her besser und weniger seicht?

Mit dem "seicht" wollte ich andeuten, daß durch diese Form der Acrobat- 
Droplets ein enormes PDF-Manipulationspotential besteht, das aber so gut 
wie niemand nutzt, weil 

* der Name "Preflight-Droplet" den Usern suggeriert, sie könnten damit 
  maximal PDFs prüfen

* Das mit den Droplets nach allenfalls Semi-Automatismus aussieht, weil 
  man ja eigentlich per Drag&Drop Dateien auf die Dinger ziehen muß 

* Sowieso das Potential von Acrobat Pro verkannt wird

>> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
>> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
>> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort 
>> via Acrobat-Droplet die PDFs durch den Wolf drehen und dann 
>> zurückschicken).
>
> Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
> fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
> komplette Serverlösung von Adobe wäre sicher ungleich teurer.

Einerseits das, andererseits bringen die reinen Server-Lösungen teils 
wieder andere Einschränkungen mit sich. Diese Form der Client- 
Automatisierung (ich fackel damit auch noch Fernsteuerung von Quark, 
InDesign, Photoshop, Illustrator, etc. und teilweise auch MacOS X Basis- 
technologien wie bspw. "Image Events" ab) hat aber auch wiederum 
Nachteile. Bspw. muß man sich drum kümmern, daß die Programme allerhand 
idiotische Nervdialoge in den Weg stellen, die man dann _sinnvoll_ 
wegklicken (lassen) muß.

>> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
>> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
>> nutzen zu können -- und das von Plattformen wie Solaris aus, für die 
>> es gar kein Acrobat gibt.
>
> Können die Leute denn so schnell gestalten und setzen, wie Deine
> Automatisierung die anderen Aufgaben erfüllt? ;-)

Kommt immer drauf an, welche Rolle im Druckvorstufenprozeß der Laden 
spielt. Zum Teil werden da zigtausende Dokumente täglich durchgeschleust 
(und zu meiner Verwunderung laufen die Macs teilweise wochenlang durch, 
bis dann ein Neustart fällig wird, weil die Interprozeß-Kommunikation 
zwischen unseren Unix-Daemons und dem AppleEvent-Überbau, der die 
eigentliche Fernsteuerung der Programme übernimmt, zusammenbricht)

Gruss,

Thomas

Re: PDF komprimieren

Andreas Muschkat schrieb am 08.06.2008 in <news:3k9o449doo95v12nmgv13h73jila67nlqp@4ax.com>
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum 
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu 
> basteln. Dies soll später automatisiert unter Linux laufen, also 
> brauche ich Kommandozeilentool.

Guckstu hier:

    <http://www.callassoftware.com/callas/doku.php/de:products:pdftoolboxcli>

pdfConvertCLI bietet diese Modifikationen auf Objektebene, nach denen Du 
suchst.

> Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
> dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
> immer.

Das funktioniert sogar ganz grundsätzlich nur mit PDF, die ein ganz 
klitzekleines Subset von PDF-Features nutzen. Hintergründiges hier:

    <http://www.acrobatusers.com/blogs/leonardr/2006/10/06/why-refrying-a-pdf-is-evil/>

Gruss,

Thomas

PDF komprimieren

Ich hoffe, Ihr könnt mir helfen.
Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
basteln. Dies soll später automatisiert unter Linux laufen, also
brauche ich Kommandozeilentool.

Ich habe hierzu bisher folgende Lösungen gefunden:

pdftk test1.pdf output test2.pdf compress

Dieses macht aus der 76,3 MB großen Datei aber nur eines, welches 76,0
MB groß ist.

Dann habe ich folgende tolle Seite gefunden:
http://wiki.scribus.net/index.php/PDF-Dateien_f%C3%BCr_das_Internet_komprimieren,_inklusive_Perl-Skript

Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
immer. Manche Seite sind schön klein geworden, andere nicht, dafür
kaputt (Grafiken werden falsch positioniert, sind schwarz, blinken?!).
Die gs-Parameter sind hier übrigens:
gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3
-dPDFSETTINGS=/screen -dEmbedAllFonts=true -dSubsetFonts=true
-dColorImageDownsampleType=/Bicubic -dColorImageResolution=144
-dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=300
-dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=300
-sOutputFile=test.tmp_wR3gfH -c .setpdfwrite -f test.ps_IsmPuN
test.meta

Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
Library 7.0

Nun die Fragen: 
- Kann GS mit dem Format nicht umgehen?
- Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Falls diese Gruppe nicht die richtige ist (was ich nicht hoffe), dann
würde ich mich über einen freundliche Hinweis auf die richtige Gruppe
freuen.

Viele Grüße,
Andreas Muschkat

Re: PDF komprimieren

   Andreas Muschkat schrieb:
> Ich hoffe, Ihr könnt mir helfen.
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
> basteln. Dies soll später automatisiert unter Linux laufen, also
> brauche ich Kommandozeilentool.  [...]

Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
in neue PDF-Dateien umwandeln ...

Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Stefan

.

Re: PDF komprimieren

On Sun, 08 Jun 2008 23:00:04 +0200, Stefan Lagotzki <lago20@gmx.de>
wrote:
>Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
>Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
>in neue PDF-Dateien umwandeln ...

Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

>> Die gs-Parameter sind hier übrigens:
>> gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatib...

und 

>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?

>Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Danke für den Link. Ich habe noch ein Parameter geändert, aber die
Konvertierung ist weiterhin fehlerhaft. Daher gelten meine beiden
Fragen aus dem Eingangsposting weiterhin.

Andreas

Re: PDF komprimieren

   Andreas Muschkat fragte:
> 
> Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

Ja. Und deshalb habe ich geschrieben: "Mit GhostScript kann man auch
PDF-Dateien in neue PDF-Dateien umwandeln." Du hast es aber mit Post-
Script versucht.

Stefan

.

Re: PDF komprimieren

Moin,

On Sun, 08 Jun 2008 20:51:12 +0200 Andreas Muschkat
<newsgroup1689@muschkat.de> wrote:

> Erstellt wurden die PDFs =FCbrigens mit Adobe InDesign CS2 / Adobe PDF
> Library 7.0
>=20
> Nun die Fragen:=20
> - Kann GS mit dem Format nicht umgehen?

Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
neueste Version?

Und lass' mal die Compatibility-Level-Einstellung und das
Font-Embedding/Subsetting weg, das bringt f=FCr dein Ziel eh nicht viel.

Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
PitStop und Co.

-hwh

Re: PDF komprimieren

Hallo,

On Mon, 9 Jun 2008 12:14:49 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:
>> Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
>> Library 7.0
>> 
>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?
>
>Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
>neueste Version?

Auf dem Server ist Version 8.15.3 installiert, bei mir habe ich die
Version 8.61, was aber keinen nennenswerten Unterschied brachte.

>Und lass' mal die Compatibility-Level-Einstellung und das
>Font-Embedding/Subsetting weg, das bringt für dein Ziel eh nicht viel.

Hier mal ein paar Beispiele. Ich habe alle PDFs so wie am Anfang
beschrieben erstellt, außer die bei Seite 5.

Hier gibts rechts einen schwarzen Balken:
http://www.muschkat.de/pdf/seite3_vorher.pdf
http://www.muschkat.de/pdf/seite3_nachher.pdf

Hier sind säliche Grafiken kaputt:
http://www.muschkat.de/pdf/seite4_vorher.pdf
http://www.muschkat.de/pdf/seite4_nachher.pdf

Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
Optimierung noch wesentlich größer. Vorher 4,9 MB, nacher 28-34 MB.
Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
der Aufruf:
pdftops -level3 seite3.pdf seite3.ps_GXUzyB

http://www.muschkat.de/pdf/seite5_vorher.pdf
http://www.muschkat.de/pdf/seite5_nachher.pdf

Hier habe ich den Teil -dCompatibilityLevel=1.3 weggelassen:
http://www.muschkat.de/pdf/seite5a_nachher.pdf

Hier zusätzlich die beiden Font-Parameter:
http://www.muschkat.de/pdf/seite5b_nachher.pdf

Dieses PDF habe ich mit der Version 8.61 erstellt. Es ist kleiner als
die drei Versionen oben aber genauso kaputt.
http://www.muschkat.de/pdf/seite5c_nachher.pdf

Kaputte Grafiken und noch ein fehlender Font (da liegt aber wohl der
Fehler in der Erstellung)
http://www.muschkat.de/pdf/seite6_vorher.pdf
http://www.muschkat.de/pdf/seite6_nachher.pdf


>Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
nicht auf die Idee, dass in dem Maße fehlerhaft sein könnte.

>> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
>
>Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und
>PitStop und Co.

Hmm..

Viele Grüße,
Andreas

Re: PDF komprimieren

Hi,

> Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
> Optimierung noch wesentlich gr=F6=DFer. Vorher 4,9 MB, nacher 28-34 MB.
> Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
> der Aufruf:
> pdftops -level3 seite3.pdf seite3.ps_GXUzyB

Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS
rasterst. Das musst du gar nicht, da Ghostscript selbst auch PDF
versteht (lesend). F=FCtter' mal direkt PDF hinein, vielleicht gibt das
schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
gemacht, das Ergebnis von

gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dEmbed=
AllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dColorImag=
eDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -dColorIma=
geResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayImageDownsamp=
leType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsampleThreshol=
d=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResolution=3D200 -s=
OutputFile=3Dtest.pdf -f seite5_vorher.pdf

Anm.: das =BB-c .setpdfwrite=AB ist =FCberfl=FCssig, ich habe die Grafikauf=
l=F6sungen
  noch etwas weiter 'runtergeschraubt, da der Satzspiegel ja ziemlich
  gro=DF ist -- obwohl das hier nicht viel Gewinn bringt

ist bei mir ganz ordentlich (wenn du das sehen willst, dann schreib'
mal 'ne PM, ich wollte es nicht ins Web packen, da nicht mein Inhalt)
-- 1,9 MB, also ca. Faktor 0,4.

Einmal pdfopt dr=FCberlaufen lassen ist auch sicher gut, wenn das
Ergebnis ins Web soll (macht aber f=FCr Einzelseiten keinen Sinn).

> >Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.
>=20
> Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
> nicht auf die Idee, dass in dem Ma=DFe fehlerhaft sein k=F6nnte.

Und ich dachte dagegen, es sei allein Ghostscript beteiligt.... Also
erstmal eher nicht... Und es scheint jetzt ja gut zu funktionieren.

> >> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
> >
> >Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
> >PitStop und Co.
>=20
> Hmm..

...genau :-(
Acrobats Optimierung schrumpft das ganze =FCbrigens auch nicht unbedingt
noch kleiner.

Gru=DF,

-hwh

Re: PDF komprimieren

On Tue, 10 Jun 2008 14:20:22 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:

>versteht (lesend). Fütter' mal direkt PDF hinein, vielleicht gibt das
>schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
>gemacht, 

Danke, das klappt schon recht gut. Allerdings habe ich beim Aufruf der
PDFs noch diverse Meldungen "In der Schrift XX ist der Wert für /BBox
fehlerhaft" und bei 2 PDFs bekomme ich Fehlermeldungen ("Missing
glyph" und mit einer längeren Meldung, die mit "In der Schrift "ERROR:
/rangecheck in --cvrs--" beginnt). Die Ursprungs-PDFs scheinen wohl
doch zu "anspruchsvoll" zu sein...

Andreas

Re: PDF komprimieren

Andreas Muschkat schrieb am 11.06.2008 in <news:akbv44t863u9rl40cjmpetqg3ugh6ifmci@4ax.com>
> Die Ursprungs-PDFs scheinen wohl doch zu "anspruchsvoll" zu sein...

Eher Dein Werkzeug zu beschränkt bzw. grundsätzlich untauglich für den 
Zweck :-)

Gruss,

Thomas

Re: PDF komprimieren

Hans-Werner Hilse <hilse@web.de> schrieb:
> gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dE=
mbedAllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dCol=
orImageDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -d=
ColorImageResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayIma=
geDownsampleType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsa=
mpleThreshold=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResol=
ution=3D200 -sOutputFile=3Dtest.pdf -f seite5_vorher.pdf
>=20

Also, irgendwas ist da noch suboptimal: Ich lie=C3=9F das mal =C3=BCber
seite3_vorher.pdf laufen, und dann passierte folgendes:

|$ gs #etc -f seite3_vorher.pdf
|   **** Warning: ToUnicode CMap has invalid syntax near CIDSystemInfo.
|#last message repeated 11 times
|
|   **** This file had errors that were repaired or ignored.
|   **** The file was produced by:=20
|   **** >>>> Adobe PDF Library 7.0 <<<<
|   **** Please notify the author of the software that produced this
|   **** file that it does not conform to Adobe's published PDF
|   **** specification.

Aha: Adobe selbst erf=C3=BCllt die eigenen Spezifikationen nicht. Aber es
kommt noch schlimmer:

|$ xpdf test.pdf
|Error: Illegal entry in bfrange block in ToUnicode CMap
|#last message repeated 22 times
|Out of memory

Was bitte? Kein Speicher mehr?

|$ free -m
|             total       used       free     shared    buffers     cache=
d
|Mem:           187         83        103          0          3         1=
9
|-/+ buffers/cache:         60        126
|Swap:          703        189        513

Reichen 103 MB nicht zum anzeigen der PDF? Zumal ja noch 513 MB im
Swap frei w=C3=A4ren. Aber von den Gr=C3=B6=C3=9Fenverh=C3=A4ltnissen sie=
ht die Sache ganz
gut aus:

|$ ll test.pdf seite3_vorher.pdf
|-rw------- 1 markus markus  13M 10. Jun 08:30 seite3_vorher.pdf
|-rw------- 1 markus markus 495K 11. Jun 11:39 test.pdf

Trotzdem: Ein "Out of memory" hatte ich noch nie. Wieviel
Zusatz-Speicher ist denn n=C3=B6tig? Alle relevanten ulimits stehen auf
unlimited. (Au=C3=9Fer max locked memory, das steht 32 kb)

=C3=9Cbrigens ist auf der Seite noch ein Schreibfehler: In der
Bildunterschrift hei=C3=9Ft der Typ noch "Mark Kitter", in der
Sub=C3=BCberschrift des Artikels "Marc Kitter" (also einmal mit k, einmal
mit c).

Und ehe ich es vergesse:

|$ gs --version
|8.62

> Gru=C3=9F,
>=20
> -hwh

Tsch=C3=B6,
    Markus
--=20
Nur weil ein Genie nix rei=C3=9Ft, mu=C3=9F ja nun nicht gleich jeder Idi=
ot
pausieren... Bully hats ja auch geschafft.
    -- gUnter nanon=C3=BCm in de.alt.anime

Re: PDF komprimieren

Certain Adobe applications (like Indesign) in certain versions (I
believe CS 2) are writing the "CIDSystemInfo" in the ToUnicode map
without the necessary leading slash ("/CIDSystemInfo" must be a name
object). Any conforming parser for the ToUnicode map will then fail to
successfully parse the ToUnicode map. Also, AFAIK, the problem has
been corrected in CS 3.

Olaf Dr=FCmmer

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 10.06.2008 in <news:20080610142022.66e8e726.hilse@web.de>
> Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS 
> rasterst.

Eher konvertieren, denn "rastern". Das pdftops aus dem XPDF-Paket ist 
kein RIP sondern ein (mehr oder weniger guter) Konverter, der die 
Elemente aus dem PDF soweit es geht in PS-Pendants überträgt. Sinnvoll 
ist dieser (Um-)Weg aber natürlich nicht.

> Das musst du gar nicht, da Ghostscript selbst auch PDF versteht 
> (lesend).

Auch da gilt aber die Einschränkung, daß dabei alles, was über ein 
kleines Subset an PDF-Features hinausgeht, auf der Strecke bleibt. Mag 
für grafisch wenig anspruchsvolles PDF reichen, man sollte sich aber 
nicht wundern, wenn nachher Elemente ganz fehlen (alles non-visuelle 
bspw. komplett) oder "kaputt" erscheinen.

> Acrobats Optimierung schrumpft das ganze übrigens auch nicht unbedingt 
> noch kleiner.

Naja, das kommt immer auf sowohl Ausgangsdaten als auch Parameter (in 
dem Fall vor allem PDF-Version an, da jede höhere Version mehr an 
Kompression ermöglicht) an.

Bevor ich eine GhostScript-Verwurstung eines PDF in Betracht ziehen 
würde, käme bei mir zuerst mal direkt das Acrobat eigene "Optimieren" 
zum Zuge, da das in jedem Fall bessere Ergebnisse liefert. Wenn man 
mittels GhostScript ein Zwischenprodukt schafft und erst dann Acrobat 
drauf losläßt, kann es sein, daß man suboptimale Ausgangsdaten für 
Acrobat erzeugt hat und dann in der Tat eine weitere Optimierung nicht 
mehr viel bringt.

Gruss,

Thomas

Re: PDF komprimieren

Hallo Andreas,

> http://www.muschkat.de/pdf/seite3_vorher.pdf
> http://www.muschkat.de/pdf/seite4_vorher.pdf
> http://www.muschkat.de/pdf/seite5_vorher.pdf
Ich habe mal alle diese Dateien durch den PDFCreator (der verwendet auch 
Ghostscript) geschickt (durch drucken mit dem Adobe Reader).
Die Ergebnisse unterschieden sich im Bild nicht, nur die Dateigröße 
betrug ca. 1/10.
Das Programm ist aber ein Windows-Programm, dafür aber OpenSource.

Frank

Freeware pdf-writer gesucht!

Hallo!
Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit dem 
Adobe Writer, pdfs bearbeiten kann?
Danke schom im Voraus für Tipps!
Viele Grüße
Peter
mail@skodawessely.de 

Re: Freeware pdf-writer gesucht!

Sk schrieb:
> Hallo!
> Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit 
> dem Adobe Writer, pdfs bearbeiten kann?
> Danke schom im Voraus für Tipps!
> Viele Grüße
> Peter
> mail@skodawessely.de

Es gibt kein Programm mit dem Namen Adobe Writer. Ist eventuell Adobe 
Acrobat gemeint?

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 09.06.2008 in <news:20080609121449.ff93e604.hilse@web.de>
> Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und 
> PitStop und Co.

Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
PitStop und Co. ;-)

Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
> PitStop und Co. ;-)
> 
> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Automatisiert? Mir schien es eher so, dass er keinen Zugriff
auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat
(ab der Standardversion?), mit der man auch PDF-Dateien in einer
angepassten Qualität erzeugen kann: Sequenz "Schnelle Webanzeige"
hieß das IIRC in Acrobat 7.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb in <news:g35gus$5ii$03$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat 
>> und PitStop und Co. ;-)
>> 
>> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
>> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...
>
> Automatisiert? Mir schien es eher so, dass er keinen Zugriff
> auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
> InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
> sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
jetzt aber so, als ob das einerseits nicht der Fall wäre und 
andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
auf einem Linux-Server laufen _müsse_.

> Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat (ab der 
> Standardversion?), mit der man auch PDF-Dateien in einer angepassten 
> Qualität erzeugen kann:

Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
sozusagen extern verfügbar macht.

Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
(am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
nicht per AppleEvents)

Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 
Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
gar kein Acrobat gibt.

> Sequenz "Schnelle Webanzeige" hieß das IIRC in Acrobat 7.

Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
<http://tinyurl.com/6xnsz9>)

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
> jetzt aber so, als ob das einerseits nicht der Fall wäre und 
> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
> auf einem Linux-Server laufen _müsse_.

Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
dem Mac zu lösen.
Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
> alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
> gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
> Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
> sozusagen extern verfügbar macht.
> 
> Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
> auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
> man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
> (am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
> nicht per AppleEvents)

Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich
auch schon dazu? ;-)
Welche Form der Automatisierung wäre denn vom Preis/Leistungsverhältnis
her besser und weniger seicht?

> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
> Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 

Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
komplette Serverlösung von Adobe wäre sicher ungleich teurer.

> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
> nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
> gar kein Acrobat gibt.

Können die Leute denn so schnell gestalten und setzen, wie Deine
Automatisierung die anderen Aufgaben erfüllt? ;-)

   [Schnelle Webanzeige:]
> Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
> Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
> anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
> Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
> <http://tinyurl.com/6xnsz9>)

Wie gesagt, das war aus der Erinnerung und die kann trügen. Ich
meine mich zumindest zu erinnern, dass auch mehrfach vorhandene
Objekte aus den PDF-Dateien entfernt wurden. Aber das ist eine Weile
her. Eigentlich wollte ich nur auf die Möglichkeit heraus, das ganze
auf dem Rechner in Stapelverarbeitung zu machen, wo die CS samt Acrobat
sowieso schon arbeitet.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb am 16.06.2008 in <news:g367rg$k2k$00$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich 
>> das jetzt aber so, als ob das einerseits nicht der Fall wäre und 
>> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
>> auf einem Linux-Server laufen _müsse_.
>
> Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
> für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
> dem Mac zu lösen.
> Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
> eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

Ich weiß (ich mach' beruflich oft nix anderes, als die seitens Kunde 
formulierte Aufgabenstellung zu zerpflücken, zwei Schritte 
zurückzugehen, Wissen nachzufüttern, das Problem neu einzugrenzen und 
dann schlußendlich was völlig anderes als initial gewünscht umzusetzen)

Aber das Rätsel kann nur der OP lösen :-)

>> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
>> alles, was es in Acrobat-"Preflight" an internen Korrektur- 
>> Möglichkeiten gibt (im Kontext des OP interessant: Reduktion der 
>> Bildauflösungen, Konvertierung nach sRGB, Entfernen eingebetteter 
>> Dateien, etc.) sozusagen extern verfügbar macht.
>> 
>> Im Sinne des Erfinders, also Adobe, zieht man dann manuell 
>> PDF-Dateien auf diese Droplets bzw. nutzt seichte Formen von 
>> Automatisierung, indem man so ein Droplet bspw. mit einem open-Event 
>> und Pfad zum PDF beglückt (am Mac jetzt, geht unter Windows natürlich 
>> genauso, wenngleich da auch nicht per AppleEvents)
>
> Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich 
> auch schon dazu? ;-)

Hotfolder (zumindest, wenn sie an separaten von den eigentlichen 
Produktionsdaten abgekoppelten Orten liegen) mag ich eh nicht so 
besonders ;-)

> Welche Form der Automatisierung wäre denn vom Preis/ 
> Leistungsverhältnis her besser und weniger seicht?

Mit dem "seicht" wollte ich andeuten, daß durch diese Form der Acrobat- 
Droplets ein enormes PDF-Manipulationspotential besteht, das aber so gut 
wie niemand nutzt, weil 

* der Name "Preflight-Droplet" den Usern suggeriert, sie könnten damit 
  maximal PDFs prüfen

* Das mit den Droplets nach allenfalls Semi-Automatismus aussieht, weil 
  man ja eigentlich per Drag&Drop Dateien auf die Dinger ziehen muß 

* Sowieso das Potential von Acrobat Pro verkannt wird

>> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
>> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
>> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort 
>> via Acrobat-Droplet die PDFs durch den Wolf drehen und dann 
>> zurückschicken).
>
> Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
> fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
> komplette Serverlösung von Adobe wäre sicher ungleich teurer.

Einerseits das, andererseits bringen die reinen Server-Lösungen teils 
wieder andere Einschränkungen mit sich. Diese Form der Client- 
Automatisierung (ich fackel damit auch noch Fernsteuerung von Quark, 
InDesign, Photoshop, Illustrator, etc. und teilweise auch MacOS X Basis- 
technologien wie bspw. "Image Events" ab) hat aber auch wiederum 
Nachteile. Bspw. muß man sich drum kümmern, daß die Programme allerhand 
idiotische Nervdialoge in den Weg stellen, die man dann _sinnvoll_ 
wegklicken (lassen) muß.

>> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
>> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
>> nutzen zu können -- und das von Plattformen wie Solaris aus, für die 
>> es gar kein Acrobat gibt.
>
> Können die Leute denn so schnell gestalten und setzen, wie Deine
> Automatisierung die anderen Aufgaben erfüllt? ;-)

Kommt immer drauf an, welche Rolle im Druckvorstufenprozeß der Laden 
spielt. Zum Teil werden da zigtausende Dokumente täglich durchgeschleust 
(und zu meiner Verwunderung laufen die Macs teilweise wochenlang durch, 
bis dann ein Neustart fällig wird, weil die Interprozeß-Kommunikation 
zwischen unseren Unix-Daemons und dem AppleEvent-Überbau, der die 
eigentliche Fernsteuerung der Programme übernimmt, zusammenbricht)

Gruss,

Thomas

Re: PDF komprimieren

Andreas Muschkat schrieb am 08.06.2008 in <news:3k9o449doo95v12nmgv13h73jila67nlqp@4ax.com>
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum 
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu 
> basteln. Dies soll später automatisiert unter Linux laufen, also 
> brauche ich Kommandozeilentool.

Guckstu hier:

    <http://www.callassoftware.com/callas/doku.php/de:products:pdftoolboxcli>

pdfConvertCLI bietet diese Modifikationen auf Objektebene, nach denen Du 
suchst.

> Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
> dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
> immer.

Das funktioniert sogar ganz grundsätzlich nur mit PDF, die ein ganz 
klitzekleines Subset von PDF-Features nutzen. Hintergründiges hier:

    <http://www.acrobatusers.com/blogs/leonardr/2006/10/06/why-refrying-a-pdf-is-evil/>

Gruss,

Thomas

PDF komprimieren

Ich hoffe, Ihr könnt mir helfen.
Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
basteln. Dies soll später automatisiert unter Linux laufen, also
brauche ich Kommandozeilentool.

Ich habe hierzu bisher folgende Lösungen gefunden:

pdftk test1.pdf output test2.pdf compress

Dieses macht aus der 76,3 MB großen Datei aber nur eines, welches 76,0
MB groß ist.

Dann habe ich folgende tolle Seite gefunden:
http://wiki.scribus.net/index.php/PDF-Dateien_f%C3%BCr_das_Internet_komprimieren,_inklusive_Perl-Skript

Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
immer. Manche Seite sind schön klein geworden, andere nicht, dafür
kaputt (Grafiken werden falsch positioniert, sind schwarz, blinken?!).
Die gs-Parameter sind hier übrigens:
gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3
-dPDFSETTINGS=/screen -dEmbedAllFonts=true -dSubsetFonts=true
-dColorImageDownsampleType=/Bicubic -dColorImageResolution=144
-dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=300
-dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=300
-sOutputFile=test.tmp_wR3gfH -c .setpdfwrite -f test.ps_IsmPuN
test.meta

Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
Library 7.0

Nun die Fragen: 
- Kann GS mit dem Format nicht umgehen?
- Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Falls diese Gruppe nicht die richtige ist (was ich nicht hoffe), dann
würde ich mich über einen freundliche Hinweis auf die richtige Gruppe
freuen.

Viele Grüße,
Andreas Muschkat

Re: PDF komprimieren

   Andreas Muschkat schrieb:
> Ich hoffe, Ihr könnt mir helfen.
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu
> basteln. Dies soll später automatisiert unter Linux laufen, also
> brauche ich Kommandozeilentool.  [...]

Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
in neue PDF-Dateien umwandeln ...

Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Stefan

.

Re: PDF komprimieren

On Sun, 08 Jun 2008 23:00:04 +0200, Stefan Lagotzki <lago20@gmx.de>
wrote:
>Linux, PDF, Kommandozeile: warum schaust Du nicht nach passenden
>Optionen für GhostScript? Mit GhostScript kann man auch PDF-Dateien
>in neue PDF-Dateien umwandeln ...

Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

>> Die gs-Parameter sind hier übrigens:
>> gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatib...

und 

>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?

>Optionen: http://ghostscript.com/doc/8.54/Ps2pdf.htm

Danke für den Link. Ich habe noch ein Parameter geändert, aber die
Konvertierung ist weiterhin fehlerhaft. Daher gelten meine beiden
Fragen aus dem Eingangsposting weiterhin.

Andreas

Re: PDF komprimieren

   Andreas Muschkat fragte:
> 
> Hast Du mein Posting überhaupt zu Ende gelesen? Ich schrieb u.a.:

Ja. Und deshalb habe ich geschrieben: "Mit GhostScript kann man auch
PDF-Dateien in neue PDF-Dateien umwandeln." Du hast es aber mit Post-
Script versucht.

Stefan

.

Re: PDF komprimieren

Moin,

On Sun, 08 Jun 2008 20:51:12 +0200 Andreas Muschkat
<newsgroup1689@muschkat.de> wrote:

> Erstellt wurden die PDFs =FCbrigens mit Adobe InDesign CS2 / Adobe PDF
> Library 7.0
>=20
> Nun die Fragen:=20
> - Kann GS mit dem Format nicht umgehen?

Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
neueste Version?

Und lass' mal die Compatibility-Level-Einstellung und das
Font-Embedding/Subsetting weg, das bringt f=FCr dein Ziel eh nicht viel.

Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.

Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
PitStop und Co.

-hwh

Re: PDF komprimieren

Hallo,

On Mon, 9 Jun 2008 12:14:49 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:
>> Erstellt wurden die PDFs übrigens mit Adobe InDesign CS2 / Adobe PDF
>> Library 7.0
>> 
>> Nun die Fragen: 
>> - Kann GS mit dem Format nicht umgehen?
>
>Doch, eigentlich funktioniert das prima. Du verwendest auch sicher die
>neueste Version?

Auf dem Server ist Version 8.15.3 installiert, bei mir habe ich die
Version 8.61, was aber keinen nennenswerten Unterschied brachte.

>Und lass' mal die Compatibility-Level-Einstellung und das
>Font-Embedding/Subsetting weg, das bringt für dein Ziel eh nicht viel.

Hier mal ein paar Beispiele. Ich habe alle PDFs so wie am Anfang
beschrieben erstellt, außer die bei Seite 5.

Hier gibts rechts einen schwarzen Balken:
http://www.muschkat.de/pdf/seite3_vorher.pdf
http://www.muschkat.de/pdf/seite3_nachher.pdf

Hier sind säliche Grafiken kaputt:
http://www.muschkat.de/pdf/seite4_vorher.pdf
http://www.muschkat.de/pdf/seite4_nachher.pdf

Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
Optimierung noch wesentlich größer. Vorher 4,9 MB, nacher 28-34 MB.
Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
der Aufruf:
pdftops -level3 seite3.pdf seite3.ps_GXUzyB

http://www.muschkat.de/pdf/seite5_vorher.pdf
http://www.muschkat.de/pdf/seite5_nachher.pdf

Hier habe ich den Teil -dCompatibilityLevel=1.3 weggelassen:
http://www.muschkat.de/pdf/seite5a_nachher.pdf

Hier zusätzlich die beiden Font-Parameter:
http://www.muschkat.de/pdf/seite5b_nachher.pdf

Dieses PDF habe ich mit der Version 8.61 erstellt. Es ist kleiner als
die drei Versionen oben aber genauso kaputt.
http://www.muschkat.de/pdf/seite5c_nachher.pdf

Kaputte Grafiken und noch ein fehlender Font (da liegt aber wohl der
Fehler in der Erstellung)
http://www.muschkat.de/pdf/seite6_vorher.pdf
http://www.muschkat.de/pdf/seite6_nachher.pdf


>Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.

Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
nicht auf die Idee, dass in dem Maße fehlerhaft sein könnte.

>> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
>
>Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und
>PitStop und Co.

Hmm..

Viele Grüße,
Andreas

Re: PDF komprimieren

Hi,

> Hier habe ich nicht mal Text. Seltsamerweise wird das PDF nach der
> Optimierung noch wesentlich gr=F6=DFer. Vorher 4,9 MB, nacher 28-34 MB.
> Liegt das vielleicht an der vorherigen Wandlung vom PDF zum PS? Hier
> der Aufruf:
> pdftops -level3 seite3.pdf seite3.ps_GXUzyB

Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS
rasterst. Das musst du gar nicht, da Ghostscript selbst auch PDF
versteht (lesend). F=FCtter' mal direkt PDF hinein, vielleicht gibt das
schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
gemacht, das Ergebnis von

gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dEmbed=
AllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dColorImag=
eDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -dColorIma=
geResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayImageDownsamp=
leType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsampleThreshol=
d=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResolution=3D200 -s=
OutputFile=3Dtest.pdf -f seite5_vorher.pdf

Anm.: das =BB-c .setpdfwrite=AB ist =FCberfl=FCssig, ich habe die Grafikauf=
l=F6sungen
  noch etwas weiter 'runtergeschraubt, da der Satzspiegel ja ziemlich
  gro=DF ist -- obwohl das hier nicht viel Gewinn bringt

ist bei mir ganz ordentlich (wenn du das sehen willst, dann schreib'
mal 'ne PM, ich wollte es nicht ins Web packen, da nicht mein Inhalt)
-- 1,9 MB, also ca. Faktor 0,4.

Einmal pdfopt dr=FCberlaufen lassen ist auch sicher gut, wenn das
Ergebnis ins Web soll (macht aber f=FCr Einzelseiten keinen Sinn).

> >Vielleicht solltest du die Bugs auch an die Entwickler kommunizieren.
>=20
> Bisher ging ich von Benutzung der falschen Parameter aus und kam gar
> nicht auf die Idee, dass in dem Ma=DFe fehlerhaft sein k=F6nnte.

Und ich dachte dagegen, es sei allein Ghostscript beteiligt.... Also
erstmal eher nicht... Und es scheint jetzt ja gut zu funktionieren.

> >> - Welche Tools gibts noch? Es darf zur Not auch ein wenig kosten.
> >
> >Hm, da f=E4llt mir sonst nur Windows-Software ein, Acrobat halt und
> >PitStop und Co.
>=20
> Hmm..

...genau :-(
Acrobats Optimierung schrumpft das ganze =FCbrigens auch nicht unbedingt
noch kleiner.

Gru=DF,

-hwh

Re: PDF komprimieren

On Tue, 10 Jun 2008 14:20:22 +0200, Hans-Werner Hilse <hilse@web.de>
wrote:

>versteht (lesend). Fütter' mal direkt PDF hinein, vielleicht gibt das
>schon den Ausschlag. Ich habe das mal testweise mit deinen Daten
>gemacht, 

Danke, das klappt schon recht gut. Allerdings habe ich beim Aufruf der
PDFs noch diverse Meldungen "In der Schrift XX ist der Wert für /BBox
fehlerhaft" und bei 2 PDFs bekomme ich Fehlermeldungen ("Missing
glyph" und mit einer längeren Meldung, die mit "In der Schrift "ERROR:
/rangecheck in --cvrs--" beginnt). Die Ursprungs-PDFs scheinen wohl
doch zu "anspruchsvoll" zu sein...

Andreas

Re: PDF komprimieren

Andreas Muschkat schrieb am 11.06.2008 in <news:akbv44t863u9rl40cjmpetqg3ugh6ifmci@4ax.com>
> Die Ursprungs-PDFs scheinen wohl doch zu "anspruchsvoll" zu sein...

Eher Dein Werkzeug zu beschränkt bzw. grundsätzlich untauglich für den 
Zweck :-)

Gruss,

Thomas

Re: PDF komprimieren

Hans-Werner Hilse <hilse@web.de> schrieb:
> gs -q -dNOPAUSE -dBATCH -sDEVICE=3Dpdfwrite -dPDFSETTINGS=3D/screen -dE=
mbedAllFonts=3Dtrue -dSubsetFonts=3Dtrue -dCompatibilityLevel=3D1.4 -dCol=
orImageDownsampleThreshold=3D1.1 -dColorImageDownsampleType=3D/Bicubic -d=
ColorImageResolution=3D120 -dGrayImageDownsampleThreshold=3D1.1 -dGrayIma=
geDownsampleType=3D/Bicubic -dGrayImageResolution=3D200 -dMonoImageDonwsa=
mpleThreshold=3D1.1 -dMonoImageDownsampleType=3D/Bicubic -dMonoImageResol=
ution=3D200 -sOutputFile=3Dtest.pdf -f seite5_vorher.pdf
>=20

Also, irgendwas ist da noch suboptimal: Ich lie=C3=9F das mal =C3=BCber
seite3_vorher.pdf laufen, und dann passierte folgendes:

|$ gs #etc -f seite3_vorher.pdf
|   **** Warning: ToUnicode CMap has invalid syntax near CIDSystemInfo.
|#last message repeated 11 times
|
|   **** This file had errors that were repaired or ignored.
|   **** The file was produced by:=20
|   **** >>>> Adobe PDF Library 7.0 <<<<
|   **** Please notify the author of the software that produced this
|   **** file that it does not conform to Adobe's published PDF
|   **** specification.

Aha: Adobe selbst erf=C3=BCllt die eigenen Spezifikationen nicht. Aber es
kommt noch schlimmer:

|$ xpdf test.pdf
|Error: Illegal entry in bfrange block in ToUnicode CMap
|#last message repeated 22 times
|Out of memory

Was bitte? Kein Speicher mehr?

|$ free -m
|             total       used       free     shared    buffers     cache=
d
|Mem:           187         83        103          0          3         1=
9
|-/+ buffers/cache:         60        126
|Swap:          703        189        513

Reichen 103 MB nicht zum anzeigen der PDF? Zumal ja noch 513 MB im
Swap frei w=C3=A4ren. Aber von den Gr=C3=B6=C3=9Fenverh=C3=A4ltnissen sie=
ht die Sache ganz
gut aus:

|$ ll test.pdf seite3_vorher.pdf
|-rw------- 1 markus markus  13M 10. Jun 08:30 seite3_vorher.pdf
|-rw------- 1 markus markus 495K 11. Jun 11:39 test.pdf

Trotzdem: Ein "Out of memory" hatte ich noch nie. Wieviel
Zusatz-Speicher ist denn n=C3=B6tig? Alle relevanten ulimits stehen auf
unlimited. (Au=C3=9Fer max locked memory, das steht 32 kb)

=C3=9Cbrigens ist auf der Seite noch ein Schreibfehler: In der
Bildunterschrift hei=C3=9Ft der Typ noch "Mark Kitter", in der
Sub=C3=BCberschrift des Artikels "Marc Kitter" (also einmal mit k, einmal
mit c).

Und ehe ich es vergesse:

|$ gs --version
|8.62

> Gru=C3=9F,
>=20
> -hwh

Tsch=C3=B6,
    Markus
--=20
Nur weil ein Genie nix rei=C3=9Ft, mu=C3=9F ja nun nicht gleich jeder Idi=
ot
pausieren... Bully hats ja auch geschafft.
    -- gUnter nanon=C3=BCm in de.alt.anime

Re: PDF komprimieren

Certain Adobe applications (like Indesign) in certain versions (I
believe CS 2) are writing the "CIDSystemInfo" in the ToUnicode map
without the necessary leading slash ("/CIDSystemInfo" must be a name
object). Any conforming parser for the ToUnicode map will then fail to
successfully parse the ToUnicode map. Also, AFAIK, the problem has
been corrected in CS 3.

Olaf Dr=FCmmer

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 10.06.2008 in <news:20080610142022.66e8e726.hilse@web.de>
> Ach! Ich hatte gar nicht geahnt, dass du die Seiten erst zu PS 
> rasterst.

Eher konvertieren, denn "rastern". Das pdftops aus dem XPDF-Paket ist 
kein RIP sondern ein (mehr oder weniger guter) Konverter, der die 
Elemente aus dem PDF soweit es geht in PS-Pendants überträgt. Sinnvoll 
ist dieser (Um-)Weg aber natürlich nicht.

> Das musst du gar nicht, da Ghostscript selbst auch PDF versteht 
> (lesend).

Auch da gilt aber die Einschränkung, daß dabei alles, was über ein 
kleines Subset an PDF-Features hinausgeht, auf der Strecke bleibt. Mag 
für grafisch wenig anspruchsvolles PDF reichen, man sollte sich aber 
nicht wundern, wenn nachher Elemente ganz fehlen (alles non-visuelle 
bspw. komplett) oder "kaputt" erscheinen.

> Acrobats Optimierung schrumpft das ganze übrigens auch nicht unbedingt 
> noch kleiner.

Naja, das kommt immer auf sowohl Ausgangsdaten als auch Parameter (in 
dem Fall vor allem PDF-Version an, da jede höhere Version mehr an 
Kompression ermöglicht) an.

Bevor ich eine GhostScript-Verwurstung eines PDF in Betracht ziehen 
würde, käme bei mir zuerst mal direkt das Acrobat eigene "Optimieren" 
zum Zuge, da das in jedem Fall bessere Ergebnisse liefert. Wenn man 
mittels GhostScript ein Zwischenprodukt schafft und erst dann Acrobat 
drauf losläßt, kann es sein, daß man suboptimale Ausgangsdaten für 
Acrobat erzeugt hat und dann in der Tat eine weitere Optimierung nicht 
mehr viel bringt.

Gruss,

Thomas

Re: PDF komprimieren

Hallo Andreas,

> http://www.muschkat.de/pdf/seite3_vorher.pdf
> http://www.muschkat.de/pdf/seite4_vorher.pdf
> http://www.muschkat.de/pdf/seite5_vorher.pdf
Ich habe mal alle diese Dateien durch den PDFCreator (der verwendet auch 
Ghostscript) geschickt (durch drucken mit dem Adobe Reader).
Die Ergebnisse unterschieden sich im Bild nicht, nur die Dateigröße 
betrug ca. 1/10.
Das Programm ist aber ein Windows-Programm, dafür aber OpenSource.

Frank

Freeware pdf-writer gesucht!

Hallo!
Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit dem 
Adobe Writer, pdfs bearbeiten kann?
Danke schom im Voraus für Tipps!
Viele Grüße
Peter
mail@skodawessely.de 

Re: Freeware pdf-writer gesucht!

Sk schrieb:
> Hallo!
> Gibt es eigentlich ein Freeware-Programm, mit dem man, ähnlich wie mit 
> dem Adobe Writer, pdfs bearbeiten kann?
> Danke schom im Voraus für Tipps!
> Viele Grüße
> Peter
> mail@skodawessely.de

Es gibt kein Programm mit dem Namen Adobe Writer. Ist eventuell Adobe 
Acrobat gemeint?

Re: PDF komprimieren

Hans-Werner Hilse schrieb am 09.06.2008 in <news:20080609121449.ff93e604.hilse@web.de>
> Hm, da fällt mir sonst nur Windows-Software ein, Acrobat halt und 
> PitStop und Co.

Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
PitStop und Co. ;-)

Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat und 
> PitStop und Co. ;-)
> 
> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...

Automatisiert? Mir schien es eher so, dass er keinen Zugriff
auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat
(ab der Standardversion?), mit der man auch PDF-Dateien in einer
angepassten Qualität erzeugen kann: Sequenz "Schnelle Webanzeige"
hieß das IIRC in Acrobat 7.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb in <news:g35gus$5ii$03$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Mir würde da spontan auch noch Mac-Software einfallen, bspw. Acrobat 
>> und PitStop und Co. ;-)
>> 
>> Beim OP klingt es aber nach automatisierter Umgebung, was die Kosten 
>> gerne mal ein wenig nach oben treibt, wenn man es richtig machen will...
>
> Automatisiert? Mir schien es eher so, dass er keinen Zugriff
> auf die Quellen der PDF-Dateien hat. Wenn die PDF-Dateien aus
> InDesign kommen (wie er schrieb), dann dürfte es doch sinnvoller
> sein, sie einmal als Print- und einmal als Web-Version abzuspeichern.

Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
jetzt aber so, als ob das einerseits nicht der Fall wäre und 
andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
auf einem Linux-Server laufen _müsse_.

> Und dann gäbe es doch noch die Stapelverarbeitung in Acrobat (ab der 
> Standardversion?), mit der man auch PDF-Dateien in einer angepassten 
> Qualität erzeugen kann:

Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
sozusagen extern verfügbar macht.

Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
(am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
nicht per AppleEvents)

Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 
Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
gar kein Acrobat gibt.

> Sequenz "Schnelle Webanzeige" hieß das IIRC in Acrobat 7.

Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
<http://tinyurl.com/6xnsz9>)

Gruss,

Thomas

Re: PDF komprimieren

   Thomas Kaiser schrieb:
> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich das 
> jetzt aber so, als ob das einerseits nicht der Fall wäre und 
> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
> auf einem Linux-Server laufen _müsse_.

Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
dem Mac zu lösen.
Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
> alles, was es in Acrobat-"Preflight" an internen Korrektur-Möglichkeiten 
> gibt (im Kontext des OP interessant: Reduktion der Bildauflösungen, 
> Konvertierung nach sRGB, Entfernen eingebetteter Dateien, etc.) 
> sozusagen extern verfügbar macht.
> 
> Im Sinne des Erfinders, also Adobe, zieht man dann manuell PDF-Dateien 
> auf diese Droplets bzw. nutzt seichte Formen von Automatisierung, indem 
> man so ein Droplet bspw. mit einem open-Event und Pfad zum PDF beglückt 
> (am Mac jetzt, geht unter Windows natürlich genauso, wenngleich da auch 
> nicht per AppleEvents)

Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich
auch schon dazu? ;-)
Welche Form der Automatisierung wäre denn vom Preis/Leistungsverhältnis
her besser und weniger seicht?

> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort via 
> Acrobat-Droplet die PDFs durch den Wolf drehen und dann zurückschicken). 

Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
komplette Serverlösung von Adobe wäre sicher ungleich teurer.

> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
> nutzen zu können -- und das von Plattformen wie Solaris aus, für die es 
> gar kein Acrobat gibt.

Können die Leute denn so schnell gestalten und setzen, wie Deine
Automatisierung die anderen Aufgaben erfüllt? ;-)

   [Schnelle Webanzeige:]
> Hmm... wenn die allersdings nicht noch mehr macht wie bspw. 
> Bildauflösungen reduzieren, dann ist genau das Feature ja was völlig 
> anderes (nur ein Seiten-index für die PDF-Datei, der seitenweise 
> Auslieferung bzw. Nachladen aus dem Browser ermöglicht, siehe bspw.
> <http://tinyurl.com/6xnsz9>)

Wie gesagt, das war aus der Erinnerung und die kann trügen. Ich
meine mich zumindest zu erinnern, dass auch mehrfach vorhandene
Objekte aus den PDF-Dateien entfernt wurden. Aber das ist eine Weile
her. Eigentlich wollte ich nur auf die Möglichkeit heraus, das ganze
auf dem Rechner in Stapelverarbeitung zu machen, wo die CS samt Acrobat
sowieso schon arbeitet.

Stefan

.

Re: PDF komprimieren

Stefan Lagotzki schrieb am 16.06.2008 in <news:g367rg$k2k$00$1@news.t-online.com>
>    Thomas Kaiser schrieb:
>> Klar, wenn man Einfluß auf den PDF-Erzeuger hat. Für mich las sich 
>> das jetzt aber so, als ob das einerseits nicht der Fall wäre und 
>> andererseits das Ganze irgendwie automatisiert und irgendwie synchron 
>> auf einem Linux-Server laufen _müsse_.
>
> Wäre aber irgendwie nicht richtig nachzuvollziehen: so sehr ich
> für Linux-Server bin, dieses Problem wäre doch viel einfacher auf
> dem Mac zu lösen.
> Die Anwender schreiben oft »Automatisierung«, wenn sie im Grunde
> eine Stapelverarbeitung per Shell-Script oder Cronjob meinen.

Ich weiß (ich mach' beruflich oft nix anderes, als die seitens Kunde 
formulierte Aufgabenstellung zu zerpflücken, zwei Schritte 
zurückzugehen, Wissen nachzufüttern, das Problem neu einzugrenzen und 
dann schlußendlich was völlig anderes als initial gewünscht umzusetzen)

Aber das Rätsel kann nur der OP lösen :-)

>> Ab Acrobat 8 kann man ja auch "Preflight-Droplets" erzeugen, die auch 
>> alles, was es in Acrobat-"Preflight" an internen Korrektur- 
>> Möglichkeiten gibt (im Kontext des OP interessant: Reduktion der 
>> Bildauflösungen, Konvertierung nach sRGB, Entfernen eingebetteter 
>> Dateien, etc.) sozusagen extern verfügbar macht.
>> 
>> Im Sinne des Erfinders, also Adobe, zieht man dann manuell 
>> PDF-Dateien auf diese Droplets bzw. nutzt seichte Formen von 
>> Automatisierung, indem man so ein Droplet bspw. mit einem open-Event 
>> und Pfad zum PDF beglückt (am Mac jetzt, geht unter Windows natürlich 
>> genauso, wenngleich da auch nicht per AppleEvents)
>
> Seichte Formen der Automatisierung: zählt da ein Hotfolder für Dich 
> auch schon dazu? ;-)

Hotfolder (zumindest, wenn sie an separaten von den eigentlichen 
Produktionsdaten abgekoppelten Orten liegen) mag ich eh nicht so 
besonders ;-)

> Welche Form der Automatisierung wäre denn vom Preis/ 
> Leistungsverhältnis her besser und weniger seicht?

Mit dem "seicht" wollte ich andeuten, daß durch diese Form der Acrobat- 
Droplets ein enormes PDF-Manipulationspotential besteht, das aber so gut 
wie niemand nutzt, weil 

* der Name "Preflight-Droplet" den Usern suggeriert, sie könnten damit 
  maximal PDFs prüfen

* Das mit den Droplets nach allenfalls Semi-Automatismus aussieht, weil 
  man ja eigentlich per Drag&Drop Dateien auf die Dinger ziehen muß 

* Sowieso das Potential von Acrobat Pro verkannt wird

>> Wir nutzen das bei einigen Kunden dazu, den prall gefüllten Acrobat- 
>> Werkzeugkoffer remote verfügbar zu machen (von Unix-Servern aus über 
>> sowas Ähnliches wie XML-RPC/Soap PDFs an 1-n Macs schicken, die dort 
>> via Acrobat-Droplet die PDFs durch den Wolf drehen und dann 
>> zurückschicken).
>
> Verstanden: die Mac-Rechner sind eigentlich keine Server, aber sie
> fungieren in diesem Fall als Server für diese spezielle Aufgabe. Eine
> komplette Serverlösung von Adobe wäre sicher ungleich teurer.

Einerseits das, andererseits bringen die reinen Server-Lösungen teils 
wieder andere Einschränkungen mit sich. Diese Form der Client- 
Automatisierung (ich fackel damit auch noch Fernsteuerung von Quark, 
InDesign, Photoshop, Illustrator, etc. und teilweise auch MacOS X Basis- 
technologien wie bspw. "Image Events" ab) hat aber auch wiederum 
Nachteile. Bspw. muß man sich drum kümmern, daß die Programme allerhand 
idiotische Nervdialoge in den Weg stellen, die man dann _sinnvoll_ 
wegklicken (lassen) muß.

>> Hat den Nachteil einer gewissen zeitlichen Asynchronität aber den 
>> Vorteil, eben das richtige Werkzeug zur jeweiligen Aufgabenstellung 
>> nutzen zu können -- und das von Plattformen wie Solaris aus, für die 
>> es gar kein Acrobat gibt.
>
> Können die Leute denn so schnell gestalten und setzen, wie Deine
> Automatisierung die anderen Aufgaben erfüllt? ;-)

Kommt immer drauf an, welche Rolle im Druckvorstufenprozeß der Laden 
spielt. Zum Teil werden da zigtausende Dokumente täglich durchgeschleust 
(und zu meiner Verwunderung laufen die Macs teilweise wochenlang durch, 
bis dann ein Neustart fällig wird, weil die Interprozeß-Kommunikation 
zwischen unseren Unix-Daemons und dem AppleEvent-Überbau, der die 
eigentliche Fernsteuerung der Programme übernimmt, zusammenbricht)

Gruss,

Thomas

Re: PDF komprimieren

Andreas Muschkat schrieb am 08.06.2008 in <news:3k9o449doo95v12nmgv13h73jila67nlqp@4ax.com>
> Ich suche mir einen Wolf, um aus einem riesengroßen PDF, welches zum 
> Druck gemacht wurde (Beispiel-PDF ist 76 MB groß) ein kleines zu 
> basteln. Dies soll später automatisiert unter Linux laufen, also 
> brauche ich Kommandozeilentool.

Guckstu hier:

    <http://www.callassoftware.com/callas/doku.php/de:products:pdftoolboxcli>

pdfConvertCLI bietet diese Modifikationen auf Objektebene, nach denen Du 
suchst.

> Hier wird das PDF zunächst mittels pdftops in ein PS gewandelt und
> dann wieder mittels gs zum PDF gemacht. Dies funktioniert aber nicht
> immer.

Das funktioniert sogar ganz grundsätzlich nur mit PDF, die ein ganz 
klitzekleines Subset von PDF-Features nutzen. Hintergründiges hier:

    <http://www.acrobatusers.com/blogs/leonardr/2006/10/06/why-refrying-a-pdf-is-evil/>

Gruss,

Thomas