Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine 20000 (oder mehr) User möchten unbedingt einen Mengendruck haben - sie klicken in der Dokumentliste 7 oder 77 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ein Alptraum für jeden RAM. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Das war damals die gesetzte Softwareumgebung: Internet Explorer und PDF-Anzeige via Acrobat Plugin. Firefox? Chrome? Giftzeugs!!! Safari? Angebissene Äpfel gibt's bei uns nicht. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut (falls es überhaupt möglich gewesen wäre), stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine 20000 (oder mehr) User möchten unbedingt einen Mengendruck haben - sie klicken in der Dokumentliste 7 oder 77 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ein Alptraum für jeden RAM. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Das war damals die gesetzte Softwareumgebung: Internet Explorer und PDF-Anzeige via Acrobat Plugin. Firefox? Chrome? Giftzeugs!!! Safari? Angebissene Äpfel gibt's bei uns nicht. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut, stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine 20000 (oder mehr) User möchten unbedingt einen Mengendruck haben - sie klicken in der Dokumentliste 7 oder 77 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ein Alptraum für jeden RAM. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut, stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine 20000 (oder mehr) User möchten unbedingt einen Mengendruck haben - sie klicken in der Dokumentliste 7 oder 77 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut, stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine 20000 (oder mehr) User möchten unbedingt einen Mengendruck haben - sie klicken in der Dokumentliste 7 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut, stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Jörg, der Standpunkt von SelfHTML ist, dass selbst in einem Projekt, wo man die Technik vorschreibt, diese Beständigkeit solcher Vorschriften nicht garantiert ist. Für eine Webseite gibt es nicht schlimmeres, als dass sie Erfolg bei den Nutzern hat, denn das bewirkt, dass auf einmal mehr Last auf dem Server ist als gedacht, und Anforderungen kommen, von denen man in der Konzeptphase bestenfalls schreiend aus Alpträumen erwacht ist. Es ist aber dennoch Sache des Anfragenden, die Bestandshärte dieser Vorgaben korrekt einzuschätzen. Sollte sich der Fragesteller irren, können wir immerhin grinsend ein "Told You So!" erwidern. Andersrum wäre es schlimmer (für uns): Wenn wir Dir eine Schmalbandlösung empfehlen, und du auf einmal eine Breitbandlösung brauchst, maulst Du uns an, weshalb wir so einen Unsinn empfohlen hätten. Ich habe mit SelfHTML eine ähnliche Erfahrung gemacht. Ich bin in der dummen Situation, eine Art virtuelles Drucksystem betreuen zu müssen. Auf dem Großrechner druckt jemand was, der Spooler konvertiert das in ein PDF und schickt es an einen Service von mir (der LPR Protokoll spricht). Der schiebt das PDF in eine Datenbank, und meine Webseite präsentiert die Dokumente für User XYZ. Klick drauf, neues Tab geht auf, PDF ist drin. Meine User möchten unbedingt einen Massendruck haben - sie klicken in der Dokumentliste 7 PDFs an und wollen dann mit einem Button alles drucken. **GEHT NICHT IM BROWSER**. Es sei denn, ich kaufe ein PDF-Tool, das unser Serverbetrieb freigibt, mixe die PDFs zu einem zusammen und schicke dieses PDF an den Browser, wo es der Anwender dann drucken kann. Ich habe hier gefragt, wie man den Druck automatisieren kann. Ich habe darum gefleht, den Umstand zu respektieren, dass dies eine geschlossene Int**ra**netumgebung ist und die Frage, wie man das für Spam missbrauchen kann, total irrelevant ist. Half nichts. Jede Antwort sagte: sowas tut man nicht, ist im Int**er**net viel zu missbrauchsgefährdet. Ja, ist es auch, und deswegen lässt das PDF-Plugin von Adobe das nicht zu. Die Anwender haben sich mittlerweile mit dem "geht nicht" abgefunden, und unser Serverbetrieb verweigert das PDF Tool mit dem Grund, dass es zu viel Speicher frisst. Mein Service läuft in einem "Servicehotel" mit 50 anderen zusammen. Ich hätte also einen dedizierten Worker-Server dafür bestellen müssen und jemanden finden, der ihn bezahlt. Och, Geld? Betriebskosten? Nö, so wichtig ist das dann auch nicht. Und heute? Wir stellen auf Edge um (Chromium). Da ist von einem Acrobat-Plugin keine Rede mehr. Hätte ich damals was Acrobat-spezifisches für Mengendruck gebaut, stünde ich heute wieder vor dem Berg und könnte Muh machen. Das ist das Ätzende an Klugscheißern. Manchmal haben sie einfach recht. _Rolf_ -- sumpsi - posui - obstruxi