LP-Druckserver mit IPP

[droptix]

Machbarkeitsfrage: Kann man mit Python einen Druckserver (Line Printer) umsetzen?

Hat jemand Ideen für Ansätze, Tutorials zum Nachlesen etc.?

Möchte quasi die RAW-Druckdaten von einen normalen Windows-Drucker (PostScript- oder PCL-Druckertreiber) empfangen, der als Anschluss mit dem Standard TCP/IP Port eingerichtet ist. Die Daten sollen temporär gespeichert und später weiter verarbeitet werden.

[BlackJack]

Ich wüsste jetzt nicht was dagegen spricht.

[droptix]

Wie würdest du das umsetzen? Socket Server und einfach die Rohdaten empfangen?

Der Windows-Spooler erwartet ja sowas wie eine Rückmeldung vom Drucker, ob die Daten alle angekommen sind, ob der Drucker bereit ist etc. -> weiß nicht genau was ein Line Printer Daemon alles können muss. Dafür suche ich Ansätze.

[EyDu]

Wenn du es ganz genau wissen willst.

[droptix]

Das hab ich mir vorab auch schon angesehen Da Programmierer aber faul sind, möchte ich erstmal nur das Nötigste umsetzen... und nicht gleich nach RFC coden.

Weiß jemand, was davon unabdingbar ist, damit ich dem Windows-Spooler ein OK oder einen Fehler signalisieren kann?

[droptix]

So, habe nun das Grundgerüst für den TCPServer fertig. Ich kann Daten vom Windows-Spooler empfangen.

Es hängt nun an der Verständigung über das Line Printer Daemon Protocol, genauer gesagt an folgender Stelle im RFC 1179:

3.1 Message formats

[...] All commands begin with a single octet code, which is a
binary number which represents the requested function. The code is
immediately followed by the ASCII name of the printer queue name on
which the function is to be performed.

Wie bekomme ich aus den empfangenen Rohdaten den Octet-Code raus?

[EyDu]

So ein Octet ist pure Magie: http://en.wikipedia.org/wiki/Octet_(computing) ^^

Durch kurzes Scrollen vermute ich mal, dass das erste Byte jeder Nachricht für das Kommando steht. Wenn du die Rohdaten hast, dann sollte das kein Problem sein.

[droptix]

So ein Octet ist pure Magie: http://en.wikipedia.org/wiki/Octet_(computing) ^^

Durch kurzes Scrollen vermute ich mal, dass das erste Byte jeder Nachricht für das Kommando steht. Wenn du die Rohdaten hast, dann sollte das kein Problem sein.

Spricht du mit ironischer Stimme... ?

Mir ist schon klar was ein Octet ist, aber das erste Byte (8 Bit = Octet) der Rohdaten sieht aus wie ein Sonderzeichen und nicht wie die im RFC angegebenen Codes 1, 2, 3, ...

Daher meine Frage, ob ich den Rohdaten-String erst noch umwandeln muss, bevor ich ihn parse.

P.S. Gibt es denn eigentlich noch niemanden, der einen LPD-Server in Python geschrieben hat... ? Ich bin sicherlich nicht der erste.

[BlackJack]

@droptix: Was heisst "sieht aus wie ein Sonderzeichen"? Welchen *Wert* hat das Byte denn?

[Leonidas]

@droptix: Was heisst "sieht aus wie ein Sonderzeichen"? Welchen *Wert* hat das Byte denn?

Naja, es hat vermutlich, wie im RFC steht, den Wert 1, 2 oder 3 oder ähnlich wodurch es ein non-printable Character ist.

[BlackJack]

@Leonidas: Das vermute ich ja auch, deswegen frage ich ja.

[droptix]

Aaaah, ihr meint den Wert, der bei ord(myString[0]) rauskommt? Muss ich testen...

Da ich weiter unten im RFC auch ASCII-Buchstaben gelesen hatte, bin ich von druckbaren Zeichen ausgegangen:

7. Control file lines

This section discusses the format of the lines in the control file
which is sent to the line printer daemon.

Each line of the control file consists of a single, printable ASCII
character which represents a function to be performed when the file
is printed.

Aber da steht nun extra "printable".

Danke für den Denkanstoß!