Wie erzeugt man heutzutage (Massen)Druckoutput?

[mjustin]

Zitat von Neutral General:

Zitat von mjustin:

Wenn es Java sein darf:

Ich gehe mal nicht davon aus, dass sie ihre Software nur deswegen komplett in Java neu schreiben wollen....

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Wenn man unbedingt zur Laufzeit des Reports noch eigene Delphi-Funktionen aufrufen will, sollte man dies zuerst noch mal überdenken.

[Neutral General]

Zitat von mjustin:

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

[mjustin]

Zitat von Neutral General:

Zitat von mjustin:

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

Wenn die zu druckenden Daten - so wie im Posting beschrieben - erst in eine Queue gestellt werden, und dann daraus nachts verschiedene Druckengines die Ausdrucke erzeugen, kann das Austauschen der Druckengine schon eine Lösung sein. In der Queue stehen Daten, die von der Druckengine verarbeitet werden müssen. Da ist nichts Delphi-spezifisch.

[ernschd]

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

[Sir Rufo]

Zitat von ernschd:

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

Wieso PCL-Dokumente? Das Umsetzen in PCL sollte der Druckertreiber erledigen.

Und mit FastReport erzeugt man auch (direkt) keine PDF-Dokumente (es sei denn man ist sehr leidensfähig oder es ist einem egal, was da raus kommt).

[ernschd]

Habe ich so verstanden:

Zitat:

Must have:
...
Ein Layout für mehrere Formate. Soll heißen, dass ich festlege, wie das Ergebnis auszusehen hat, und das System erzeugt mir darauf basierend PDF, PCL, Postscript....

Wir drucken z.B. bei uns im Unternehmen die PCL-Dokumente ohne den Druckertreiber. Die Datei wird direkt auf den PCL-fähigen Drucker kopiert, und er legt von sich aus los.

[Sir Rufo]

Das habe ich auch gelesen, nur würde ich mich mit so etwas nie rumschlagen wollen (es müsste schon ein sehr ernster Grund vorliegen um mich zu überzeugen).

Da es solche Umsetzer schon gibt (Druckertreiber) bin ich dagegen das Rad neu zu erfinden.

[p80286]

Eine Alternative zu einem Reportgenerator, wäre u.U MS Office/open Office
Im Extremfall, können diese Dokumente/Vorlagen sich die notwendigen Daten von einer DB abholen, sich selbst erzeugen und auch ausdrucken. Rein theoretisch sollte jeder fortgeschrittene Anwender in der Lage sein, entsprechende Vorlagen zu erstellen.
Ich würde allerdings empfehlen die Dokumentengenerierung und DB-Abfrage über ein eigenes Programm abzuwickeln, was zumindest der Performance zuträglich wäre.

Gruß
K-H