3

I am trying to figure out what technology would allow me to have a web server that I control show up as a printer in Chrome. This would be added manually by the user. But I don't know what governs the printers that show up in Chrome. I notice when you click on "manage" it opens your OS's settings... so I guess maybe it can't be a webserver but has to be a specific protocol?

In that case I'm wondering if you need a VPN to do that and then the fake printer would get added by VPN/network.

The intent is to get the files being printed and then on the server side be able to store it or download it to some other client.

This is a specific use case it's not about just file upload/download that I can do. But I am specifically looking for the printing aspect. Like a printer API.

Or am I looking at writing our own desktop software that would be the fake printer and then that connects to our web server to upload the files intending to be printed?

4
  • 3
    Simply print to PDF and upload it to the server. No programming required.
    – gronostaj
    Jun 18, 2021 at 18:55
  • That's not the point. It's avoiding uploading/using the printing process as the upload Jun 18, 2021 at 18:59
  • I’m afraid you indeed have to go through the operating system procedures to add a new printer, virtual or real. I’m not sure whether unprivileged users have the required permissions to do so.
    – Daniel B
    Jun 18, 2021 at 19:10
  • This is okay, it's not strangers the users would be walked through how to do this. I just needed to know if it was possible/how. So I'm glad to hear that it is, now I gotta do it myself. Jun 18, 2021 at 19:12

1 Answer 1

5

Any host can disguise as a network printer, as long as it speaks the same protocol – that's how print servers work. Most operating systems will allow you to add a network printer by its URL.

There are a few standard print job submission protocols that are spoken by network printers – IPP (port 631), HP JetDirect (port 9100), and occassionally lpr (port 515).

Out of those, IPP is the most interesting choice for you, both because it is in fact HTTP-based (i.e. you could implement it on a webserver), and because of the 'IPP Everywhere' standard for driverless printing, which allows print jobs to be submitted in the form of standard PDF files instead of requiring a vendor-specific driver.

Implementing IPP from scratch may be complex; however, the Linux/macOS 'CUPS' software, although mostly used for local printing, is actually an IPP server at its core – it's possible that you could configure it to have a fake queue that just stores jobs on the filesystem, somehow.

And if you cannot get clients to submit jobs as "driverless" PDF files, then look for a driver that submits jobs in the PCL5 format (which Ghostscript can convert to PDF for previewing, and your printers most likely accept PCL5 straight on port 9100). At this point, you don't necessarily need to use IPP – you could also write a server that accepts the same print jobs via JetDirect or lpr instead.


Additional explanation:

Keep in mind that printing does not send the original files to the printer. Whether you're printing a PDF or a DOC or a JPEG, the client always rasterizes it into some sort of generic format, so the network printer (or your print server, in this case) only receives jobs in that final raster format – it won't know anything about the original.

That means it's not enough to implement just the network protocol – you will also need to un­der­stand the raster format that the client sends you. (This depends on the printer driver used by the client; e.g. printing through a Kyocera driver will generate KPDL-format print jobs.) This is where 'IPP Everywhere' comes in – if you want to receive PDFs, you will have to pretend to be a "driverless" printer that uses PDF as its raster format.

It also means that printing will lose all "digital" features of the original document. Even if you're printing a PDF to a PDF-based printer, you'll still most likely lose features like fillable forms or digital signatures in the process.

12
  • 1
    Want to emphasize that driverless printing (with print jobs being actual PDF files) is a much later specification, it's not guaranteed by IPP in itself. But if the "driverless" part doesn't quite work out, look for a driver that submits jobs in the PCL5 format (which Ghostscript can convert to PDF for previewing, and your printers most likely accept PCL5 straight on port 9100). Jun 18, 2021 at 19:06
  • 1
    Ah, if you're only buffering them for a specific real printer, then that's less of an issue -- in that case it's probably going to work even if the client just uses an actual printer driver in the traditional way. (For example, all our workstations have a Kyocera driver installed and submit KPDL-format jobs -- they think they're talking to a real network printer, even if it's actually just printserver software running on Windows.) Jun 18, 2021 at 19:12
  • 1
    My point was that printing never sends the files as-is. Whether your originals were PDF or DOC or DWG, the client always rasterizes it into some sort of generic format, so the network printer (or your print server, in this case) only receives jobs in that final raster format. (E.g. if you print a .docx file, the printer won't even know it was a .docx file.) So in order to receive PDFs, your server needs to pretend that it's an "IPP Everywhere" printer that expects PDF-format jobs, and even then it might still receive a pre-processed PDF rather than the original. Jun 18, 2021 at 19:19
  • 1
    It most likely will be. I wouldn't be surprised if such features got completely stripped by the client (after all, they wouldn't make any sense to a printer that puts stuff on paper). If you want to keep digital-only features, then going through the printing system might not be a good plan in the first place. Jun 18, 2021 at 19:22
  • 1
    Well I guess I will find out, thanks a lot for your time Jun 18, 2021 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .