phase-1: document capture hook complete#68
Conversation
|
Hi! I think, document completion hook should be common for proto/ipp and proto/ieee1284 So looks it should be an interface, similar to abstract.Scanner, and should be defined in the abstract package. Logically, this is the printing backend, which received and handles documents to be printed at the protocol-independent manner (like abstract.Scanner does the similar work for scanning) Obviously, document completion hook needs not only the document body, but negotiated parameters as well I would also prefer to avoid prefetching the entire document into the large buffer and prefer some streaming interface P.S. My access to Telegram temporary doesn't work (I think I will be able to recover it within 1-2 days), so lets temporary communicate here |
|
Okk alex
…On Fri, Jun 5, 2026 at 3:33 PM Alexander Pevzner ***@***.***> wrote:
*alexpevzner* left a comment (OpenPrinting/go-mfp#68)
<#68 (comment)>
Hi!
I think, document completion hook should be common for proto/ipp and
proto/ieee1284
So looks it should be an interface, similar to abstract.Scanner, and
should be defined in the abstract package. Logically, this is the printing
backend, which received and handles documents to be printed at the
protocol-independent manner (like abstract.Scanner does the similar work
for scanning)
Obviously, document completion hook needs not only the document body, but
negotiated parameters as well
I would also prefer to avoid prefetching the entire document into the
large buffer and prefer some streaming interface
P.S. My access to Telegram temporary doesn't work (I think I will be able
to recover it within 1-2 days), so lets temporary communicate here
—
Reply to this email directly, view it on GitHub
<#68?email_source=notifications&email_token=BAJYYICYYI3RMGM7EXFZNPD46KLF7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTGAZTQOBTGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4630388368>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BAJYYIBL4T7JFFYLKKBCVND46KLF7AVCNFSM6AAAAACZ2HZMDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMZQGM4DQMZWHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Replace DocumentReceiver function type with PrintBackend interface in abstract package, shared by both proto/ipp and proto/ieee1284. - abstract/printer.go: new PrintBackend interface + PrintJobParams struct - proto/ipp: SetPrintBackend(), streaming rq.Body, builds PrintJobParams - proto/ieee1284: MIME() on DocFormat, emitDocument calls PrintBackend - all tests updated to use testBackend implementing PrintBackend
|
Hey Alex. 1.I created a new 2.For the IPP side, I updated it to pass 3..For the IEEE1284 side, it still needs to buffer internally because the protocol requires scanning the byte stream to detect document boundaries (UEL markers, Ctrl-D). Once the document is complete, it wraps the buffer in |
|
Hey, I have implemented the change that you requested, take a look.
On Fri, Jun 5, 2026 at 11:08 PM Mohammad Arman ***@***.***>
wrote:
… Okk alex
On Fri, Jun 5, 2026 at 3:33 PM Alexander Pevzner ***@***.***>
wrote:
> *alexpevzner* left a comment (OpenPrinting/go-mfp#68)
> <#68 (comment)>
>
> Hi!
>
> I think, document completion hook should be common for proto/ipp and
> proto/ieee1284
>
> So looks it should be an interface, similar to abstract.Scanner, and
> should be defined in the abstract package. Logically, this is the printing
> backend, which received and handles documents to be printed at the
> protocol-independent manner (like abstract.Scanner does the similar work
> for scanning)
>
> Obviously, document completion hook needs not only the document body, but
> negotiated parameters as well
>
> I would also prefer to avoid prefetching the entire document into the
> large buffer and prefer some streaming interface
>
> P.S. My access to Telegram temporary doesn't work (I think I will be able
> to recover it within 1-2 days), so lets temporary communicate here
>
> —
> Reply to this email directly, view it on GitHub
> <#68?email_source=notifications&email_token=BAJYYICYYI3RMGM7EXFZNPD46KLF7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTGAZTQOBTGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4630388368>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BAJYYIBL4T7JFFYLKKBCVND46KLF7AVCNFSM6AAAAACZ2HZMDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMZQGM4DQMZWHA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
2 participants
I have completed phase 1 work of GSoC with this PR. Earlier, when the virtual printer received a document via Send-Document, it simply threw away the bytes :
io.Copy(io.Discard, rq.Body).There was no way to get those bytes out of the printer, which made it impossible to build an automated testing pipeline. So I fixed that with this pr by:-
proto/ipp/capture.goThe Printer had no way to hand documents to the outside world. So I created a new file with:
i
DocumentReceiver:- a function type that anyone can implement to receive documents.ii
SetDocumentReceiver():- a method to install the callback on the printer.iii receiver field added to the Printer struct.
2.Fixed
proto/ipp/printer.goReplaced the stub in
handleSendDocument:i.
io.Copy(io.Discard, rq.Body):- io.ReadAllto actually read the bytes.ii. Added the
DocumentReceivercallback invocation after reading.3.Added tests in
proto/ipp/capture_test.goThree tests to verify the capture hook works correctly:
i.
TestDocumentReceiverCalled:- sends a document and verifies the receiver gets the correct job ID, format and exact bytes.ii.
TestDocumentReceiverNilNoPanic:- verifies no crash when receiver is nil.iii.
TestDocumentReceiverLargeDoc:- sends a 1MB document and verifies every single byte arrives correctly.i. In
proto/ipp/createjob.go,senddocument.go,validatejob.goJob attributes were read from msg.Printer but the encoder stores them in msg.Job. This caused JobID to always decode as 0, making every Send-Document silently fail with "job not found".So fixed it by reading from msg.Job in all three files (createjob.go,senddocument.goandvalidatejob.go.)ii. In
proto/ipp/server.go trace.OnResponsewas called beforequery.WriteHeader, so DumpResponse read a status of 0 and panicked with invalid WriteHeader code 0. Fixed by movingtrace.OnResponseto afterquery.WriteHeader.