aneinanderhängen, aber es ging ja ums ausschneiden Oo

Ich finde es schlicht toll, wie zahlreich hier Varianten mit konkreten Lösungen mitgeteilt werden. PDFJAM kannte ich (analog zu sam2p) nicht; ich denke aber, dass beide Tools eine echte Bereicherung sind.

Die Tools werden von mir gerne intensiver getestet; ich danke allen für die echt wertvollen Tipps.

Warum sollte man mit CLI Tools und deren Parametern aufhören? Nur weil du das als rückständig betrachtest?

Rückständig ist eine GUI.

Klicki-Bunti-Jünger - geht doch einfach weg von Linux

Alter SD- und DDR-RAM ist weder in dieser Form noch zu diesem Preis erhältlich.
Sind diese 8GB "neuer" DDRx-RAM für 30 Euro auch qualitätsmäßig so gut, dass sie mindestens 5 Jahre Dauerbetrieb überstehen?
Verstehe mich bitte nicht falsch, wenn Du mit den 8GB RAM unter Linux etwas anfangen kannst (z.B. für mehrere VMs), dann bin ich der Letzte, der gegen einen solchen Kauf etwas sagen würde.

Das Hauptmanko ist und bleibt aber der unfreie Code. Das ist bei einem Programm, dass auf etwa (95+x)% aller Rechner eingesetzt wird, für meinen persönlichen Geschmack hoch bedenklich.
Der ganze "Bloat" dient schließlich nur zum Anzeigen von pdfs. So weit, so klar.
Das sieht man ja auch an Evince, Okular, Epdfview, Xpdf, Kpdf, alles nackter "Bloat". :-)
Z.B. Evince wäre IMHO dann in etwa mit Adobe Reader "vergleichbar", wenn er so groß wäre und soviel RAM- und CPU-Power bräuchte wie OpenOffice, nur zum Anzeigen von pdfs, versteht sich.

Gegenüber einer solchen RAM- und CPU-Verschwendung für recht wenig Leistung habe ich allerdings massive Vorbehalte, ich habe aber nichts gegen viel RAM und CPU-Power per se. Manche Programme haben es jedoch schlichtweg nicht "verdient", für das, was sie leisten, einen beträchtlichen Teil meiner Systemressourcen auffressen zu dürfen.

Mit dem Reader auch? Das wäre mir neu...

Das wäre eine gute Idee.

Ich finde z.B. kein Paket für Debian und die Sourcen von pdftk-qgui lassen sich leider auch nicht auf die Schnelle übersetzen.

Mit GUI-Applikationen meinte ich im übrigen weiter Programme wie Okular oder Xournal, beide scheinen aber irgendwie bei mir nicht richtig zu laufen.

http://sourceforge.net/projects/pdfchain/

Ich dachte, pdfedit ist eine GUI-Applikation, aber siehe da, es gibt die Option -console. Allerdings denke ich auch, dass PDFEdit einen eigenen Artikel bekommen müsste.

Und was ist mit ipython?

Genau das meinte ich. Es gibt Situationen, wo Konsolen-Programme (und sei es die PowerShell) einfach Sinn ergeben. Und es gibt Situationen, wo von diesen Programmen aus nicht über ein API, sondern über einen simplen Aufruf eines Programmes mit einigen Parametern gearbeitet werden kann und darf (inkl. STDIN, STDERR und STDOUT).

Dass Bash vielleicht nicht die genialste Sprache ist, auch darin stimme ich zu (offen gestanden finde ich Bash-Skripte echt unhandlich, vorallem in der Wartung). Was mir halt bei der Powershell fehlt, ist eine Plattformunabhängigkeit. Oder gibt es diese für Mac und Linux?

Den elegantesten Eindruck hat für mich im übrigen Ruby hinterlassen.

Wie auch immer; es gibt viele gute Gründe, ein nicht GUI-orientiertes Programm zu schreiben, und es gibt auch viele Fälle, wo es ohne GUI kaum gehen wird (hab z.B. noch kein Handy gesehen, das über die Konsole angeteuert wird).

dann lassen wir JK mal im Glauben, dass "Klick&Drop" von Microsoft erfunden wurde und sowieso nur da funktionert. Und fragen uns, warum die Pfostenquote heute so hoch ist. Ist der .Net-Stammtisch ausgefallen, oder was?

da fehlt noch ein "cat" --> pdftk *.pdf cat output all.pdf ist aber egal.

"Völliger Quatsch. Ich markiere einfach alle mit einem Klick (Alle Markieren) und ziehe sie in mein PDF-Merger-Feld."

und? alles legal? Keine Raubkopie? Natürlich!

"Ich liebe das Klick&Drop unter Windows einfach. :P"

an was sich manche Leute so aufgeilen... interessant... oder auch nicht. Ist ja jetzt auch so was von mega-neu, dieses Klick&drop... ja, Wahnsinn.

"Linux ist in die Massen eingebrochen, das ist der Grund, und Prolinux bekommt das an vorderster Front mit."

denke ich auch. Nun ist man irgendwie geneigt zu denken: "früher, ohne Einbruch in die Massen, wars besser, weil weniger Pfosten"...
Wie jede Medaille hat diese eben auch zwei Seiten.

aha, also ich markiere alle pdf's, die ich in einem Ordner habe und drucke die dann nochmal als pdf, um ein einziges pdf in der richtigen Reihenfolge zu erhalten? Was für ein Blödsinn.

"Auch Stapelverarbeitung wird in vielen PDF Programmen (nicht nur von Crap-Adobe) angeboten."

jepp, pdftk kann das richtig gut.

übrigens gibt es für pdftk auch eine grafische Oberfläche, die aber so unwichtig ist, dass ich ihren Namen vergessen habe.

Ich gehe einig damit, dass in der Entwicklung bei Applikationen direkte APIs fast immer sinnvoller sein werden. Aber, in der Administration von Systemen, bei kleinen Jobs, bei kleinsten Programmen eben, bei Konvertierungsjobs, kann es sich alleweil lohnen, über die Konsole auf Tools zurückzugreifen, ohne das API zu verwenden bzw. nach einem solchen suchen zu müssen.

Konkretes Beispiel: Ghostscript und Perl. Über Professionalität mag ich jetzt nicht streiten. Fakt ist, ich hab gerade ein Konvertierungsprojekt hinter mir, wo es darum ging ca. 500'000 PDFs in Bildateien (ca. 750'000 Bilder) zu konvertieren. Das Programm umfasst ca. 100 Zeilen:

===================================================
#!/usr/bin/perl

use strict;
use lib qw(/home/cvs/archivista/jobs);
use Archivista::Config; # is needed for the passwords and other settings
my $config = Archivista::Config->new;
my $pw = $config->get("MYSQL_PWD");
use AVJobs;

my $db = shift;
$db = "archivista" if $db eq "";
my $file = shift;
$file = "all.lst" if $file eq "";
my $job = shift;
$job = 0 if $job eq "";
my $maxjobs = shift;
$maxjobs = 1 if $maxjobs eq "";
my $stopafter = shift;
system("echo 'start $job'>>all.log;date>>all.log");
if (my $dbh=MySQLOpen("localhost",$db,"root",$pw)) {
if (HostIsSlave($dbh)==0) {
my $date1 = DocumentAddDatForm( TimeStamp() );
my $files = "";
readFile2($file,\$files);
my @files = split(/\n/,$files);
my $c = 0;
foreach my $pdffile (@files) {
if ($c % $maxjobs == $job) {
my $cmd = "pdfinfo $pdffile | grep Pages | awk '{print \$2}'";
my $pages = `$cmd`;
chomp $pages;
addDocument($dbh,$pdffile,$pages,$date1,$job) if $pages>0;
}
$c++;
last if $stopafter>0 && $c>$stopafter;
}
}
}
system("echo 'end $job'>>all.log;date>>all.log");

sub addDocument {
my ($dbh,$file,$pages,$date,$job) = @_;
my @parts = split(/\//,$file);
my $fname = pop @parts;
my $fzip = "$job-$fname";
$fzip =~ s/(\.pdf)/.zip/;
my $doc = addDocumentInsert($dbh,$file,$fname,$pages,$date);
my $cmd1 = "pdftotext -raw $file -";
my $res1 = `$cmd1`;
my @txt = split(/\x0c/,$res1);
if ($doc>0) {
for (my $page=1;$pagequote($img);
if ($page==1) {
my $source = "";
$cmd = "zip -j $fzip $file 2>/dev/null";
system($cmd);
readFile2($fzip,\$source);
system("rm $fzip");
$sql .= ",BildA=".$dbh->quote($source) if $source ne "";
}
$dbh->do($sql);
$sql = "insert into archivseiten set Seite=$nr,".
"Text=".$dbh->quote($txt[$page]).",Erfasst=1";
$dbh->do($sql);
}
}
}

sub addDocumentInsert {
my ($dbh,$file,$fname,$pages,$date) = @_;
my $sql = "insert into archiv set Seiten=$pages,Ordner=1,".
"UserNeuName='pdfjob',Datum=$date,ErfasstDatum=$date,".
"ArchivArt=1,BildInput=1,BildIntern=1,BildInputExt='TIF',".
"Erfasst=1,QuelleExt='PDF',EDVName='office;$fname',".
"Titel=".$dbh->quote($file);
$dbh->do($sql);
$sql = "select LAST_INSERT_ID()";
my @row = $dbh->selectrow_array($sql);
my $akte = $row[0];
if ($akte>0) {
$sql = "update archiv set Akte=$akte where Laufnummer=$akte";
$dbh->do($sql);
}
return $akte;
}
=================================================

Das Programm lässt sich mehrfach aufrunfen, um alle CPUs anzusprechen:

=================================================
#!/usr/bin/perl
use strict;
my $jobs = 6;
my $max = 0;
for (my $c=0;$c<$jobs;$c++) {
system("perl pages.pl archivtest all.lst $c $jobs $max &");
}
=================================================

Mein Programm (es könnte sicher weit eleganter programmiert werden) schafft dabei in 24 Stunden auf einer 6-Core-Maschine 2.3 Mio Seiten; kurzum der Job lief in weniger als 7 Stunden durch. Dabei werden nicht nur 750000 Seiten gerastert; diese werden in die Datenbank gesichert, die PDF-Dateien werden gezippt und ebenfalls in die Datenbank geschrieben, und der Text der PDF-Dateien wird ebenfalls extrahiert und in die Datenbank geschrieben. Ginge es nur um das Rastern der PDF-Dateien, so wäre der Speed nochmals fast doppelt so hoch (bei ca. 4 Mio Seiten pro Tag).

Bring mir jetzt mal ein enfaches API, dass a) Open Source ist und b) über Perl angesprochen werden kann und mit dem Du c) in 20 Stunden den Job erledigst, denn solange dauerte der Job; den der Kunde sehr wohl finanzieren wird. Beim Aufwand ist zu sagen, dass 12 Stunden investiert wurden, um die schnellste Lösung zu suchen; die Implementierung dauert ca. 4 Stunden und das Testen/Verifizieren der Daten dauert nochmals ca. 4 Stunden.

Wie gesagt, ich würde in vielen Fällen ein API vorziehen, aber für einen Job wie diesen finde ich diese Konsolentools doch sehr sehr elegant; ohne diese hätte ich den Job nicht in dieser Zeit abschliessen können.

Ich nehme dafür in Kauf, mir Rückständigkeit "vorwerfen" lassen zu müssen, möchte aber doch bitten, in der weiteren Diskussion einen besseren (effizienteren) Weg aufzuzeigen. Aussagen wie "mehere Designer im Haus" oder "versuche mal ein Konsolenprogramm zu verkaufen" sind doch sehr allgemein bzw. sehr pauschal. Die Welt ist vielfältiger, weder ein GUI ist das absolute Mass, genauso wie es die Konsolenprogramme auch nicht sind (ansonsten gs nicht den lästigen Bug mit stdout bei tiffg4 hätte).

> Seitdem immer mehr GUIs herauskommen muss man sich
> keine exotischen Skriptsprachen oder Parameter auswendig
> lernen.

Du brauchst eine GUI um eine DATENBANKANBINDUNG aus einem Webformular heraus zu erstellen? Wohlgemerkt, nicht nutzen sondern erstellen?

Was war nochmal genau dein Job? Sackoträger? Bedenkenträger? Kaffeeträger? Kaffeetrinker? Einschleimer beim Chef? Ernsthaft, deine Aussage würde ich schnell löschen lassen weil das schon extrem peinlich ist.

Die Aussage mit Omnipage ist auch recht merkwürdig. Wenn Du die Aufgabenstellung auch nur grob überflogen hast wird Dir wohl auffallen daß Omnipage weder eine direkte Datenbankanbindung bietet noch ein Pre- und Postprocessing in der Art "PDF-Inhalte filtern" oder "Ausgabe in Format, Grösse und Darstellung anpassen und anschliessen komprimieren".

Davon abgesehen daß Omnipage nichtmal ein PDF-Konverter sondern eine OCR-Software ist und damit eine totale Themenverfehlung

Problemstellungen wie die von Urs sind in der EDV absoluter Alltag und JEDER Versuch sowas mit fertigen Mitteln ohne Programmierkenntnisse zu lösen ist im Vorfeld dazu verurteilt teuer und langwierig zu scheitern und/oder suboptimale Ergebnisse zu liefern. Dazu kommt die langfristige Wartbarkeit, wenn das Problem so nocheinmal ähnlich in ein paar Jahren auftritt kann man auf weiter gepflegte Module zurückgreifen (s2pdf, perl, ghostscript) die mit minimalstem Aufwand auf das System wandern während man bei "dicken" Lösungen jede Menge Randeffekte beachten muß.

Ich hatte hier auch einmal ein ähnliches Problem: 400GB Videomaterial mit inkonsistenter Benennung mußten in einen schnittfertigen Film konvertiert werden. Die Creative Suite mag 5000 Euro kosten aber sie weis trotzdem nicht daß "Meier2-Bergvermessung-1.tif" bis "Meier2-Bergvermessung-500.tif" inhaltlich vor "Grafische Darstellung 0000.jpg" bis "Grafische Darstellung 4711.jpg" kommt. Mit einem Shell Hunderzeiler hat man aber ein ausreichendes Regelwerk erstellt welches hunderte von Einzelschnippseln zusammensetzt und dann direkt in gstreamer füttert um huffyuv-Schnittmaterial zu erzeugen. Als Bonus wurden die Audiospuren gleich dazugekittet. Hätte man das mit grafischen Mitteln machen müssen hätte man mehrere 10.000 Bilder und Videoschnippsel in der richtigen Reihenfolge händisch anordnen müssen.

Ja. Danke für den Tipp Urs (pdfinfo kannte ich nicht).

Danke für die Lorbeeren; auch wenn ich denke, dass die guten Kommentare (die Trolle lassen wir mal) wohl weit mehr den Hut verdient haben. Ich habe ja einzig ca. 2 Stunden für die Zusammenfassung benötigt. Dank der vielen wertvollen Tipps hab ich wohl deutlich mehr Zeit bei der Recherche für noch bessere Tools gespart. In diesem Sinne, danke an all die guten Postings!