Hallo Sophie,
offenbar hast Du andere Anforderungen als 1UP bzw. nutzt einen geringeren Umfang der HTML/CSS Welt und bist deshalb zufrieden. 1UPs Nutzungsprofil ist ein anderes, für ihn reicht HTML2PDF nicht und darum ist er[1] nicht zufrieden.
Die andere Frage ist, ob der Vorschlag von 1unitedpower geeignet ist, auf einem Server ausgeführt zu werden. Chrome schreibt (unter Windows) Daten in seinen Installationsordner (z.B. ein chrome_debug.log oder eine settings.dat), was bedeutet, dass hier eine Kollision möglich ist. Ob das unter Unix auch passiert, weiß ich nicht, das wäre zu prüfen. Will man Chrome auf diese Weise nutzen, sind mehrere Dinge unbedingt nötig:
- --print-to-pdf alleine erzeugt ein output.pdf im Chrome-Installationsordner. Ein Not-At-All-Go!
- --print-to-pdf=form1.pdf erzeugt ein form1.pdf im Chrome-Installationsordner. Immer noch ein No-Go. Ich habe das mal als Problem an Google gemeldet.
- -- print-to-pdf=C:\temp\form1.pdf erzeugt es im Temp-Ordner. Für einen Server immer noch nicht ausreichend, man sollte als Ordner einen wählen, der für das entsprechende Web spezifisch ist.
- Für eine halbwegs brauchbare Darstellung muss man den --window-size Parameter mitgeben. In der [Ankündigung von Eric Bidelman] wurde --window-size=1280,1696 für einen "standard letterhead" empfohlen.
- Allerdings ist es NICHT möglich, die Seitenausrichtung oder die Seitengröße anzugeben. Im Gegenteil - beim googlen findet man immer wieder Klagen darüber. Angeblich funktioniert was über das DevTools API - aber nun wird's wild, dafür brauchst du eine IP-Connection zur Chrome-Instanz.
- Ansonsten sollte es funktionieren, zumindest BEHAUPTET Chrome das. Sie schreiben hier: Headless Chromium allows running Chromium in a headless/server environment.
Ich empfinde diese Einschränkungen zu gravierend, als dass ich chrome --headless --print-to-pdf für mehr als eine Experimentierküche empfehlen könnte. Es scheint noch sehr unreif.
Rolf
sumpsi - posui - clusi
sofern die Annahme „1UP ist männlich“ stimmt... ↩︎