Guten Tag,
Vielleicht noch etwas Hintergrund zur Problemstellung: Normales PDF als in Seiten portioniertes PostScript "weiss" nichts mehr über Spalten in Tabellen; es transportiert "nur" Anweisungen, wo auf einer Fläche was dargestellt werden soll.
Das heisst, es könnte ein PDF geben, das zuerst alle "a" auf der Seite plaziert, dann alle "b" usw. Oder kurz gesagt: PDF enthält keine verlässliche Struktur, die verbindlich interpretiert werden kann (ich lasse hier die Variante "Tagged PDF" enfachheitshalber weg).
Mit anderen Worten: Das Tabellenwerkzeug versucht irgendwie herauszufinden, wie die Tabelle aussehen könnte. Es sieht z.B. in der ersten Zeile einer Tabelle zwei Wörter mit einem normalen Abstand und anschliessend ein Wort mit einem relativ grossen Abstand. Also sagt es sich, aha, das sind zwei Spalten, auch wenn in der grossen Lücke noch andere Spalten gewesen wären, denn aus PostScript-Sicht ist hier nichts zu finden. Letztlich wird deshalb hier auch ein HTML-Exporter seine Mühe haben, eben weil alles Interpretationssache ist, und jede noch so intelligente Implementierung über Spezialfälle stolpert.
Für Dokumente, deren Layout vorhersehbar ist, können Werkzeuge erstellt werden, die diese Layoutinformationen auswerten. Beispiel: Ich habe schon vor einigen Jahren einen Konverter geschrieben, der ursprünglich manuell erfasste Katalogseiten in eine Datenbank konvertierte. Dort konnte man vorhersehen, wo Artikelnummern zu finden waren, weil halt die Spalte eine Überschrift "Art.Nr." trug. Oder ich habe für eine Firma, die täglich Marktdaten aus PDF's in eine Datenbank extrahiert, ein entsprechendes Werkzeug entwickelt.
So könnte man sicher auch für die oben diskutierten Excel-PDF-Tabellen ein Export-Werkzeug erstellen, das die Daten aufgrund von bekannten typographischen oder semantischen Kriterien wieder ausliest. Aber das lohnt sich natürlich nur, wenn es sich um grosse Datenmengen handelt.
Schöne Grüsse aus Allschwil
Marc Véron
http://www.veron.ch