contao mit tcpdf ausgegebenes pdf ist "leer"?

Hallo Community,
ich arbeite hier mit Version 2.9.3 von contao. Wir haben hier eine ziemlich lange Telefonliste (geht über 5 Textelemente mit Tabelle von A-Z),...
Diese kann per Klick auf das pdf-Icon als Datei geschrieben werden.
Fehler dabei ist, die pdf-Datei ist "leer". Sie misst zwar 800 KB, aber es wird nur eine weiße Seite angezeigt.
Ich habe diese Fehlermeldung vorgestern von einem Kollegen erhalten und kann sie reproduzieren. Ich habe fast jeden pdf-Beittrag hier im Forum angesehen, finde aber keine passende Lösung. An der print-1.css kann es m.E. nicht liegen, denn damit hat es ja immer funktioniert (seit Typolight 2.7.x). Nur selbst habe ich es mit contao noch nicht ausprobiert gehabt (ja ich weiß, mein Fehler).
Frage, was ist hier passiert?
Danke für die Hilfe und Gruß
Lothar59

Also rein vom Verständnis her.
Wenn die PDF 800KB hat, muss auch was drinstehen.

Hast Du mal geschaut, ob evtl. jemand die Schriftfarbe auf "weiss" umgestellt hat.
Hört sich jetzt wirklich blöd an, kann aber durchaus sein.

Ich hatte auch mal so ein ähnliches Problem.

Hallo Kayzu,
war auch meine erste Idee, ist aber nicht. Einzig gibt es auf dieser einen weißen Seite unten links in der Ecke einen 1pt großen Hinweis "Powered by tcpdf...", der ist weiß auf weiß.

Ferner weiß ich mittlerweile, dass jeder Artikel der als pdf ausgegeben wird leer ist. Und es sind immer 802KB. Egal ob nur Text oder Text mit Grafik oder mit Foto....

Hat es vielleicht mit der Version von tcpdf zu tun? Nein kann eigentlich nicht, denn tcpdf ist ja Bestandteil von contao. Hab ich ja nicht extra installiert.

Gruß
Lothar59

Hallo Community,

wollte nicht untätig sein und habe einen neuen Artikel generiert, der auch als pdf ausgegeben werden soll.
Das erste Text-Element enthielt 10x den Satz "Dies ist ein Test..." --> speichern...

FE-Ansicht --> Klick auf pdf-Icon --> pdf-datei erzeugt, geöffnet und vorhanden. Toll.

Nächster Test:
Weiteres Text-Element in diesem Artikel erzeugt --> Text aus anderem Text-Element eines anderen Artikels kopiert und hier eingefügt
FE-Ansicht --> Klick auf pdf-Icon --> pdf-datei enthält nur erstes Text-Element.
Nicht Toll.

Nächster Test: Erweitern des ersten Test-Elements um weitere 10 Zeilen BlaBla --> speichern nicht vergessen
FE-Ansicht ok --> pdf-Datei neu erzeugt, aber der Inhalt entspricht nicht den aktuellen. Nicht Toll.

Nächster Test --> einfügen eine neuen Text-Elements vor dem ersten funktionierenden: "dritter Test.....", speichern --> FE-Ansicht zeigt es an aber pdf-Icon macht keine Änderung.

Alles ausschalten, 5 Minuten warten, Intranetseite aufrufen -->pdf-Icon klicken und pdf-Datei öffnen:
Jetzt wird plötzlich der ganze Testinhalt richtig angezeigt.

Nun also auch die anderen Artikel, klick und NIX in der pdf-Datei.

Wie ist eigentlich die Funktionsweise des tcpdf? Langsam verzweifel ich dran...

Ich kann dieses Verhalten teilweise bestätigen. Online geht das bei mir. Lokal will es nicht funktionieren.

Meine lokale version ist ein download der online version, der einzige unterschied lokalist, dass ich zu testzwecken kurz eine leere print.css angelegt hatte um das pdf stylen zu können..
noch vor dem ersten css eintrag hab ich dann am quelltext geprüft, ob diese eingebunden wird und hab dann mal ein pdf generiert. Dateigröße 800kb, jedoch blanko.

Das Problem besteht auch nachdem ich das leere print.css entfernt und den contao cache gelöscht habe .

Der tcpdf link ist auch drin, jedoch nicht sichtbar, weil weiß auf weißen hintergrund

Hallo,
schaut doch mal in diesen Thread, dort wird auch das Problem der leeren Seiten behandelt:
http://www.contao-community.de/showt...e-weiße-Seite

print.css ist übrigens nicht für die Ausgabe von Artikeln via tcpdf, sondern für den Seitendruck (Option "Seite drucken" unter "Syndikation").

MfG
Ulrike

Hallo zusammen,
danke für die Tipps. Ich habe das geprüft. Achso, ich arbeite hier auf XAMPP-Basis.
"<p>[nbsp]</p>" kommt bei mir auch vor. Es muss aber erlaubt bleiben, auf diese Art einen Absatz in Fließtext reinzubauen.

Ich habe auch die Extension von do_while, das "pdf-template", installiert, aber bei mir bleiben alle pdfs leer. Wenn ich eine pdf-Formatvorlage mit Logo in der Kopfzeile und Seitennummer in der Fusszeile und möglichen Textelementen (Ü1, Ü2,Ü3, standardtext, fett kursiv,....) definiere (siehe Anlage), dann ist genau diese Vorlage auch mein Ergebnis des pdf-export. Mit einer Erweiterung der tcpdf.css erhalten ich auch nur leere pdfs. Das hängt aber vielleicht auch daran, dass es noch eine Probieren-Version ist. Muss ich beobachten.

Und bevor in den Artikeln überall die [nbsp]s auftauchten, mein' ich das alles funktioniert hat. Ich kann nämlich alte Nachrichtenelemente aus dem Archiv als pdf ausgeben, und das pdf hat Inhalt. Erst als das mit dem [nbsp] losging klappte es anscheinend nicht mehr. Nur macht hier bei uns so selten mal einer ein pdf aus den Inhalten. Daher kommt das wohl erst jetzt auf, das Thema.

Ich weiß echt nicht mehr wo ich noch suchen soll.
Gruß
Lothar

Hallo Lothar59,

die [nbsp] sind nur die sichtbare Form der festen Leerstelle (in HTML: &nbsp; ). Die <p>-Tags bekommen ein solches Leerzeichen, da sie mit normalen Blanks leer wären und von manchen Browsern dann ignoriert werden.

Hast Du die [nbsp] mal versuchsweise entfernt, auch wenn dann die Formatierung nicht mehr korrekt ist, also nur zum Test (kannst eine Kopie des Artiekls zum Testen erstellen).

Um zu gucken, ob überhaupt Inhalte das TCPDF erreichen, könntest Du in meiner Moduldatei pdf_hookControl.php direkt an den Anfang der Funktion folgendes schreiben:

PHP-Code:

---

public function myPrintArticleAsPdf( $strArticle, $objArticle )
{
  echo nl2br(htmlentities($strArticle));
  exit; 


---

Dann sollte beim Aufruf der Quellcode zu sehen sein, der dem TCPDF übergeben wird. Wenn hier die Seite weiss bleibt, gibt's auch nichts auszugeben!

Hallo Lothar59,

ich habe das mit dem <p>[nbsp]</p> nachvollziehen können und habe das mal untersucht. Contao liefert da ein Zeichen an TCPDF, was TCPDF nicht verdauen kann und dann die Ausgabe abbricht.
Mein Modul gibt's jetzt in einem neuen Build, der die Macke umschiffen sollte. Bitte mal probieren:
http://www.contao.org/erweiterungsli...-template.html

Wenn es jetzt funktioniert, bitte melden, dann erstelle ich ein Ticket für Contao.

Hallo do_while,

danke für die Antworten. Ich habe
-einen aktuelle Nachrichtenbeitrag deformatiert (alle <p>nbsp... entfernt). pdf funktioniert danach.

-die neue build installiert (Erweiterungsverwaltung aktualisieren), hat keinen Unterschied gezeigt. Die Telefonliste oder Nachrichten werden als leere weiße Seite ausgegeben.

-die .zip-Datei aus deinem Link heruntergeladen entpackt und ins contao Verzeichnis kopiert, hat keinen Unterschied gezeigt. Die Telefonliste oder Nachrichten werden als leere weiße Seite ausgegeben.

-nochmal die Erweiterungen aktualisiert. Die Telefonliste oder Nachrichten werden als leere weiße Seite ausgegeben.

Ich habe dann mal die komplette Telefonliste als Quelltext gespeichert (copy/paste), um schwarz auf weiß zu sehen wo "falsche" Zeichen stehen. Leere Tabellenzellen enthalten wohl &nbsp;, aber kein <p>-Tag (heißt, der Suchalgorythmus des Windows Texteditors findet keine Zeichenfolge <p>). Anbei die html-Daten, die sich in echt halt bis Z wiederholen.
Vielleicht sieht man ja da drin etwas, dass ich nicht sehe.
Danke und Gruß
Lothar59

Du hast auch in dem Startpunkt der Webseite das PDF-Template eingeschaltet?
Dann kann ich Dir nur heute Abend eine veränderte Datei schicken, die einen Debug-Output erstellt, denn der Quellcode aus Deiner Datei sagt nichts über die Daten, die der PDF-Generator angeboten bekommt.

Hallo do_while,
ja, template ist eingeschaltet.

Ich habe aber mal den anderen Test gemacht, und habe den debug-code in deine Datei eingegeben. Ergebnis, siehe Anlage.

Gruß
Lothar59

Ganz oben in dem Artikel ist ein <script>-Bereich für phpmyvisites, der vielleicht stören könnte. Kannst Du den evtl. mal deaktivieren zum Test?
Die anderen "komischen" Zeichen, wie festes Leerzeichen, ÄÖÜäöüß sollten in meinem Modul umgesetzt werden.
Auch das <p class="back"></p> als leeren <p>-Tag könnte man noch mal probeweise entfernen. (Nur damit ich weis, was mein Modul dann alles filtern sollte).

Wenn das Weglassen von phpmyvisites nichts bringt muss ich Dir doch den Debug-Code schicken, das wird aber erst heute abend was.

Hallo do_while,
das script oben krieg ich weg. Aber unten den Link Zurück auf die Startseite, den find ich nicht.
Der Code ändert sich dann wie folgt (siehe Code.txt).
Gruß
Lothar59

Hallo Lothar59,

Du hattest nicht geschrieben, ob der entfernte Code von phpmyvisites den Erfolg gebracht hat. Ich habe Dir mal eine modifizierte pdf_hookControl.php angehängt (bitte das ZIP auspacken).
Bitte hebe Dir die Originaldatei auf und setze zum Test im Modul dafür die angehängte Datei ein. Die Ausgabe würde mich interessieren. Irgendwo muss noch ein Zeichen enthalten sein, was den TCPDF stört. Ich konnte aber in Deinen Dateien noch nichts ausmachen.

Anhang 3529

Hallo do-While,
sorry , hatte ich vergessen, nein pdf war trotzdem leer. Das <p class="back"></p> kommt wohl aus einem template, ist der Zurück-Link in jeder Nachricht.
Mit deinem Test-modul erziele ich beigefügte Ausgabe.
Bislang schon mal 999-Dank.
Gruß
Lothar59

Hallo Leute,
ich habe weitere Entdeckungen gemacht. So fängt meine Telefonliste an:
<div class="ce_text block">
<table style="width: 100%;" border="0" cellspacing="0" cellpadding="1" align="left">
<colgroup span="1"><col span="1" width="24%"></col><col span="1" width="21%"></col><col span="1" width="13%"></col><col span="1" width="10%"></col><col span="1" width="17%"></col><col span="1" width="15%"></col></colgroup>
<thead>
<tr>
<td><span style="color: #888888;"><strong>Name</strong></span></td>
<td><span style="color: #888888;"><strong>Vorname</strong></span></td>
<td><span style="color: #888888;"><strong>Kürzel</strong></span></td>
<td><span style="color: #888888;"><strong>Telefon</strong></span></td>
<td><span style="color: #888888;"><strong>Alternativ</strong></span></td>
<td><span style="color: #888888;"><strong>Raum-Nr.</strong></span></td>
</tr>
</thead>
<tbody>
<tr style="background-color: #c0c0c0;">
<td style="background-color: #c0c0c0;"><span style="color: #888888;"><strong>A</strong></span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;">[nbsp]</span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;">[nbsp]</span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;">[nbsp]</span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;">[nbsp]</span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;">[nbsp]</span></td>
</tr>
<tr style="background-color: #c0c0c0;">
<td style="background-color: #c0c0c0;"><span style="color: #888888;"><strong>A</strong></span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;"> </span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;"><br /></span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;"><br /></span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;"><br /></span></td>
<td style="border: 1px solid #ffffff;"><span style="color: #888888;"><br /></span></td>
</tr>

Wenn ich in der Tabelle die Einträge [nbsp] durch </br> ersetze, dann wird ein pdf mit Inhalt erzeugt.
Sobald aber dieses [nbsp] (von contao erzeugtes Zeichen) drin ist, ist die pdf offensichtlich leer. Das hat nichts mit dem <p>-Tag zu tun.

An do_while: anbei das codefragment, das daraus mit deinem Hexlister generiert wird.
Gruß
Lothar59

Zitat:

---

Zitat von do_while

http://www.contao.org/erweiterungsli...-template.html

Wenn es jetzt funktioniert, bitte melden.

---

Also wenn ich die Erweiterung installiere, ist der Fehler mit dem [nbsp] verschwunden!


Lothar59, was für ein OS und welche php version nutzt du ?

Hallo,
meine etwas weiter oben angebrachte Verlinkung ist hier offensichtlich übersehen worden.
Ich habe vor einiger Zeit mich intensiv mit der tcpdf-Ausgabe beschäftigt. Das Problem leerer Seiten hatte ich auch, und zwar immer dann, wenn tinyMCE [nbsp] in einen Artikel eingefügt hat.
[nbsp] wird nämlich nicht als "normales" Leerzeichen ausgegeben, sondern als non-breakable-space-Zeichen. Das entspricht dem Charcode 160.
Erst glaubte ich, dass tcpdf sich am Charcode 160 quasi verschluckt und dann leere Seiten ausgibt, dann aber bekam ich Zweifel, weil die leeren Seiten nur unter XAMPP auftraten, nicht aber in der echten Server-Umgebung. Also ist es vielleicht doch kein tcpdf-Problem, sondern hat irgendwas mit XAMPP oder der Kombi XAMPP/Windows zu tun.
Bei mir hat's geholfen, den myPrintArticleAsPdf-Hook zu benutzen und darin das non-breakable-space-Zeichen mittels preg_replace in ein reguläres Leerzeichen umzuwandeln.

My two cents.

MfG
Ulrike

Hallo Ulrike,

ich hatte Deinen Link gesehen und der hat mich auch ein Stück in die Richtung der jetzigen Lösung gebracht. Ich habe neulich den ganzen Abend bis Mitternacht mit ways2web gechattet und probiert, bei mir reichte schon das Austauschen des [nbsp], das sich ja bei der Übergabe zum TCPDF bereits in ein UTF-8-Zeichen gewandelt hat, gegen ein &nbsp;. Bei ways2web brachte das noch nichts, dort mussten zusätzlich alle deutschen Umlaute noch in HTML Entities gewandelt werden.
Das macht das Modul jetzt bereits alles und sogar bei ways2web hat es in allen Installationen eine bedruckte Seite ausgespuckt.
Bei Lothar59 bin ich noch ein wenig ratlos, habe aber eben erst den letzten Beitrag gelesen und werde mal in diese Richtung weiterforschen.

Hallo Hagen,
hier der betreffende Code. Die Charcodes habe ich via Alt-Taste/Ziffernblock eingegeben. Vorsichtshalber lasse ich das shy-Zeichen gleich mit entfernen (kommt in der tinyMCE-Konfigurationsdatei vor in der gleichen Reihe wie das non-breakable-space-Zeichen).

PHP-Code:

---

<?php
protected function myPrintArticleAsPdf($strArticle, $objArticle) {
        // avoid empty pages with tcpdf
        $arrSearch = array
        (
            '@*@', // what you see here isn't a normal space but a non-breakable space, charcode 160 // XAMPP seems to need this replacement
            '@*@'  // what you see here isn't a normal hyphen but the 'shy'-sign, charcode 173     // just in case
        );
        $arrReplace = array
        (
            '&nbsp;', // this is the normal space
            ''
        );
        $strArticle = preg_replace($arrSearch, $arrReplace, $strArticle);
// more code to come

}
?>

---

Könnte ja sein, dass genau diese Ersetzung auch das Problem von Lothar59 löst, denn in seinem Telefonlistenbeispiel kommt mehrfach [nbsp] vor.

MfG
Ulrike

Hallo Lothar59,

ich habe Deinen Originalcode bei mir getestet (ich gehe mal davon aus, dass tbody und table auch korrekt geschlossen werden) und es kommt Inhalt ins PDF. Irgendwo unterscheiden sich die PHP-Versionen oder irgendetwas anderes, so dass es bei Dir nicht geht. Das hatte ich auch zusammen mit ways2web feststellen müssen.

Was mir in Deiner Tabelle komisch vorkommt, sind die colgroup und col Tags, die man ja nicht so häufig sieht. Bei mir im TCPDF haben die keine Wirkung (alle Spalten bleiben gleich breit), aber vielleicht machen sie bei Dir Probleme?

Das ist eine für Contao unübliche Methode, da von den Core-Modulen her die Tabellen Spalten-Klassen haben, die dann per CSS geformt wird.
Im SelfHTML habe ich folgendes gefunden:

Zitat:

---

<col>-Tags dürfen in HTML kein Abschluss-Tag haben. Das abschließende </colgroup>-Tag ist dagegen optional. In Kapitel XHTML ist das schließende <col>-Tag aber erforderlich. Wenn Sie XHTML-Standard-konform arbeiten, müssen Sie daher das col-Element als inhaltsleer kennzeichnen. Dazu notieren Sie das alleinstehende Tag in der Form <col ... />.

---

In TCPDF heisst die Routine WriteHTML, meinen die nun HTML oder XHTML?
Ein Doc-Type wird nicht an TCPDF übermittelt.

Die [nbsp] in den Tabellen setze ich schon in &nbsp; um, das ist auch in Deinem Hexdump so zu sehen. Ein CSS benutzt Du erstmal nicht zusätzlich?

Hallo Ulrike,

danke für die Hinweise. Die Codes 160 und 173 dürften bei UTF-8 eigentlich nicht auftauchen, da nur Zeichen bis 127 mit einem Byte dargestellt werden.
Es kann natürlich sein, dass trotzdem diese Bytes hier reinkommen und dann ist TCPDF irritiert und verweigert die Ausgabe.

Ich habe einfach mal die beiden Codes zu meinen Austauschzeichen hinzugefügt, mal sehen, was Lothar59 dazu sagt.

@Lothar59:
Bitte setze noch mal die pdf_hookControl.php aus diesem ZIP in dem Modul ein. Ich möchte nicht alle Versuche über das ER schleifen. Bitte erstmal kein CSS hinzufügen.
Anhang 3534

Hallo Hagen,

nach meinen Erfahrungen ist tcpdf ziemlich unempfindlich hinsichtlich der verwendeten Zeichen. Chr(160) und chr(173) sind eigentlich kein tcpdf-Problem, denn sonst dürfte es damit auch auf dem echten Server nicht funktionieren.

Die Zeile, die ich vorhin meinte, steht in tinyMCE.php im Ordner /system/config. Sie lautet:
entities : "160,nbsp,60,lt,62,gt,173,shy"
Diese Zeile hat offensichtlich etwas mit Ersetzungen zu tun. Das betrifft wohl zunächst mal die Anzeige im tinyMCE-Textfenster.
Ich interpretiere diese Zeile so, dass tinyMCE das Zeichen chr(160) als [nbsp] darstellt, chr(60) als [lt] usw. Beim Größer- und Kleiner-Zeichen kann man diesen Austausch direkt sehen. Dass [nbsp] wirklich als chr(160) in $strArticle enthalten ist, habe ich beim Abspeichern von $strArticle vor irgendwelchen Veränderungen durch str_replace oder preg_replace bestätigt gefunden. Dieses Abspeichern habe ich zu Testzwecken gleich am Anfang des myPrintArticleAsPdf-Hooks durchgeführt.

Folgende Erfahrung habe ich mit einer eigenen Erweiterung zum Terminkalender gemacht. Ich habe ein Modul "Rahmenterminplan" als Erweiterung zu "calendar" erstellt, das nur ausgewählte Termine des Terminkalenders anzeigt. Die Anzeige wird als Tabelle realisiert. Beim Versuch, meinen Rahmenterminplan mit tcpdf auszugeben, hatte ich (fast) weiße Seiten, die Anzeige brach schon nach zwei, drei Zeilen ab. Die Analyse des Problems ergab, dass im Template mit dem HTML-Code für die Tabelle ein paar schließende Tags fehlten. Bei der Anzeige auf dem Bildschirm wurde dieser Fehler offensichtlich toleriert, bei der Ausgabe mit tcpdf aber nicht. Ein absolut sauberer HTML-Code scheint also eine Bedingung für tcpdf zu sein.

So long
Ulrike

Das habe ich auch schon festgestellt, sauberer HTML-Code kann auch ausgegeben werden. In den Daten von Lothar finde ich aber keine Problemzeichen mehr. Der TinyMCE ist eigentlich bei meinen Betrachtungen außen vor. Mir geht es darum, was beim Hook reinkommt.
Der Hexdump entsteht auch direkt am Anfang der Hook-Routine, die problematischen Zeichen setze ich erst danach um, dann kommen noch die pregs aus dem Original, dann geht es in TCPDF hinein.

Wo liegt der Unterschied zwischen den verschiedenen Verhaltensmustern?

Hallo Hagen,
bin kein Contao-Profi, deshalb kann ich hier nur beisteuern, was mir auffällt.

In dem Hex-Code, der dem Beitrag #17 angehängt ist, habe ich mal nach dez(160) = hex(a0) gesucht und bin mehrfach fündig geworden.
Bei mir würde das unter XAMPP/Windows dazu führen, dass tcpdf weiße Seiten ausgibt.

Die Frage ist, warum der Code mehrfach a0 enthält. Das konnte ich auf die Schnelle und zu so später Stunde noch nicht erkennen.

Nun warte ich mal ab, bis sich Lothar59 wieder meldet und auf deine letzte Version von pdf_hookControl.php reagiert.

Gruß
Ulrike

Ja das ist das &nbsp; in UTF-8 mit dem Code C2 A0 in Hex (siehe auch http://www.utf8-zeichentabelle.de/). Die Listings in den Beiträgen sind die Eingangsdaten in den Hook, vor der Umsetzung, also nicht das, was in TCPDF rein geht.
In der aktuellen Version, in #23, werden sowohl die Code C2 A0 und nur A0 gegen &nbsp; ausgetauscht.

Hallo zusammen,
Uuups soviel Messages...

erstmal sortieren.
@ ways2web: ich arbeite hier auf einem Win server2003 SP2, mit Apache 2.2.6 und php 5.2.4 - das läuft zuverlässig seit langer Zeit. Sollte ich hier eine Aktualisierung vornehmen, oder gilt "Never touch a running system" für den server, weil ja alles i.O. ist, wenn dieses "Sonderleerzeichen" nicht im text vorkommt?

@ Ulrike: ich habe den Hinweis auf den anderen Thread schon berücksichtigt, durchgearbeitet und getestet, aber ohne Erfolg.
Besonders interessant dabei war allerdings die Aussage, dass css nicht wirkt für tcpdf

@ do_while: ja die Tabelle ist ordentlich html-isiert (</tbody>...), m.E. haben die <col...> tags nix damit zutun, weil pdf ja funktioniert, wenn keine "Sonderleerzeichen" vorkommen.

@ do_while: Mit dem letzten Code für pdf-template (#23) ist die pdf-Datei (zu #17) leer wenn dieses "Sonderleerzeichen" drin vorkommt, und die Datei hat richtigen Inhalt, wenn das Zeichen nicht drin vorkommt.

@ do_while: Eine css-Datei bringt nix, laut Ulrike. Die tcpdf.css Datei ist ebenfalls nicht eingebunden (nur für die normale Printausgabe ist eine css eingebunden).

Sonstiges:
Ich habe hier noch einen ganz anderen Verdacht: Irgndwie habe ich das Gefühl, dass hier irgendwelche Speicher nicht aktualisiert werden, mir ist aufgefallen, dass die pdf Datei den vorherigen Inhalt zeigt, wenn z.B. das Wort "Telefonliste" drin stand und ich das Wort ersetzte durch "Tel.-Liste". Erst nach 'Extras'->'Neueste Chronik löschen' und dann pdf machen war der neue Inhalt in der pdf-Datei?
Komisch? Habe ich also hier eine ganze Community irrgeleitet?

Nur um einem Missverständnis vorzubeugen:

Ich habe nicht gesagt, dass css nichts bringt. Was ich weiter oben geschrieben habe, bezog sich ausschließlich auf die Contao-Datei print.css. Die ist nicht für tcpdf bestimmt, sondern für den Seitendruck.

Wenn man in tcpdf an der richtigen Stelle eine css-Datei einbindet, dann liest tcpdf die styles. Aber nicht alle, da hilft dann nur trial and error weiter.

MfG
Ulrike

Hallo Lothar59,

das ist schade, dass es immer noch nicht funktioniert. Ich betreibe lokal auch meinen Entwicklungsserver mit 2003 Std R2 und älteres PHP und ich habe die Probleme nicht, obwohl ich immer noch den Verdacht habe, dass es mit der PHP-Version zusammenhängt.

Wenn Änderungen immer erst nach einiger Zeit im PDF ankommen, könnte das an einem Cache liegen, z.B. auch der Seitencache in Contao. Der Browser sollte eigentlich bei der Betrachtung rausfallen, da das PDF allein vom Server generiert wird.

Zu dem CSS besteht wohl noch ein Mißverständnis. Die neuere Version von TCPDF, die erst in Contao 2.9.3 enthalten ist, kann auch CSS verarbeiten (wie Ulrike anmerkt, aber nicht alles). Die tcpdf.css habe ich extra dazu "erfunden". Diese CSS wird von meinem Modul in Inline-CSS umgewandelt und mit dem HTML-Code an TCPDF übergeben. Das funktioniert auch, nur wie gesagt nicht mit allen CSS-Instruktionen.

Im Moment fällt mir zu Deinem Problem nichts mehr ein, was man noch probieren könnte. Alle anderen Tester aus der Community haben jetzt gefüllte PDFs erhalten. Hast Du es noch mal ohne <col>-Tags probiert, denn wenn TCPDF nicht alles CSS versteht, versteht es vielleicht auch nicht alles HTML. Die Breitenanpassung erscheint jedenfalls in meinem PDF nicht, alle Spalten haben gleiche Breite.

Edit: im ersten Absatz PDF -> PHP korrigiert

Hallo,
habe weitere Experimente gemacht.
Auf meinem System habe ich einen Artikel angelegt mit dem HTML-Code der Telefonliste von Lothar59.
Gleiches Ergebnis wie bei Lothar: tcpdf produziert weiße Seite.

Wenn man allerdings in den Core von Contao eingreift, und zwar in der Datei Controller.php in system/libraries innerhalb der Funktion

protected function printArticleAsPdf(Database_Result $objArticle)

und dort folgende Zeile auskommentiert:

//$strArticle = html_entity_decode($strArticle, ENT_QUOTES, $GLOBALS['TL_CONFIG']['characterSet']);

(das ist Zeile 1030)

dann zeigt mir tcpdf die Tabelle auch an.

Eigentlich mag ich Eingriffe in den Core nicht, da sie nicht updatesicher sind, aber die genannte Zeile scheint erheblichen Einfluss darauf zu haben, ob tcpdf ein Größer- bzw. Kleiner-Zeichen als Teil eines HTML-Tags interpretiert oder als Textzeichen.

Schade, dass die Zeile 1030 im Core vor dem Aufruf des Hooks erfolgt, sonst könnte man diese Änderung im Hook selbst vornehmen.

Vielleicht kann Hagen sich diesen Sachverhalt ja auch noch einmal ansehen.

Mehr fällt mir jetzt dazu auch nicht mehr ein.

MfG
Ulrike

Hallo do_while,
ich möchte noch nicht aufgeben. Ich kann pdf erzeugen.
Wenn ich die [nbsp] Zeichen alle lösche, geht der tinymce hin und ersetzt den <td> Inhalt.
Aus
<td style="border: 1px solid #ffffff;"><span style="color: #cc99ff;"></span></td>
wird
<td style="border: 1px solid #ffffff;">[nbsp]</td>
weil es leere Felder nicht geben soll.

Es ist also die Kombination von Tag und nbsp-Zeichen:
<td><span style="color: #cc99ff;"><strong>Telefon</strong></span></td>
<td><span style="color: #cc99ff;"><strong>[nbsp]Alternativ</strong></span></td>
<td><span style="color: #cc99ff;"><strong>[nbsp]</strong></span></td>

Das in der dritten Zeile führt dazu, dass die pdf leer ist.

Wenn die dritte Zeile so <td>[nbsp]</td> aussieht gibt es trotzdem ein pdf mit Inhalt.

Ich denke ich baue die Tabelle nochmal neu. Danach berichte ich nochmal.

Wäre schön, wenn die html Tabelle funktionieren würde (siehe auch Frage: Contentelement Tabelle macht falschen csv import ) dann wäre sicherlich alles leichter.
Allen sei hier mal ordentlich DANKE gesagt.
Gruß
Lothar

Hallo Ulrike,
bezgl. deines Test mit der controller.php, wenn ich das auch mache, dann habe ich Inhalt in der pdf-Datei.

Übrigens diese Datei ist am 13.01.2011 verändert worden, nach deinem Hinweis auf den anderen Thread zum Thema leere Seiten, die Anleitung von Nina macht auch in dieser Datei rum. Da geht es um css-Funktionen zu quasi-simulieren. Hatte für mein Problem aber nix gebracht.

Danke nochmal

Hallo Do_while, hallo Ulrike,

endlich habe ich es geschafft, die gesamte Telefonliste zu bereinigen. Es ist nun eine reine Tabelle, quasi ohne schnickschnack. Und siehe da, pdf funktioniert.

Dann habe ich in der controller.php die Befehlszeile von Ulrike wieder freigegeben. Und trotzdem werden pdf gemacht.

Ich habe also nun eine pdf-Telefonliste.

Tausend Dank an die "Unermüdlichen", ohne die Dummies wie ich keien Chance hätten.
Danke do_while, danke Ulrike....
Gruß
Lothar59