I installed cups onto my pi fairly smoothly, printed the test page on cups, all good. Locate the printer (HP deskjet 960c) which is located inside the RASPBERRYPI network folder, all connects fine, select the relevant driver from the list and once again prints windows test page fine. I make a test print page in open office and click print, it says that the print job has been sent to the printer and then says it has been printed, meanwhile the printer has remained silent and hasn't printed a thing, the exact same thing happened with Chrome trying to print a PDF. I am not really sure if its a problem with the cups setup (I would assume not due to the fact it can print test pages) or if there is something else stopping it from printing. Any help is really appreciated I have been trying to get this to work for hours now.
It's easiest to troubleshoot cups using the provided web status pages. IIRC, you can access it at
raspberrypi.local:631 (changing the hostname as appropriate).
You may have to add your username to the
lpadmin groups if not already present. Once connected and logged in, you should be able to view the status of jobs as they work their way through the queue. Check for things like errors in paper specification causing jobs to get "stuck" in the queue.
Try adding a new printer through the CUPS administration page, aiming the new printer at the same physical printer and connection. I had to do this on ubuntu 18 with an HP Laserjet 5m. I don't know why the first one stopped printing after a few months, but the newer queue works fine. There had been some corrupt jobs that went through that older queue, printing gibberish. Some of that might have taken out the first queue. The pre OSX mac system 9 had occasional problems with its desktop printer(s) if some garbage was sent to them, even after dumping all the old jobs. I saw this often as I was heavily involved in supporting desktop printing environments. Postscript errors anywhere in a document seemed to increase the likelihood that a queue problem may develop. The answer then, as with my ubuntu situation, was to create new printer queues, and avoid the print job that caused the trouble (if you could pin it down). There were cases where sending the same troublesome job, without doing anything to troubleshoot it or recreate it, would again corrupt the queue, the new queue. You might have something similar happening, although I am at a loss to tell you exactly what that something is precisely. I have seen rpi generated pdf's contain some gibberish during preview, and then put the same gibberish on the paper, but there might be some gibberish that the queue can not handle, a type of loose potential exploit. SO try a new queue, with a new simple document, maybe from accessories -> text editor, a very low overhead program, and see if that makes it to the paper.
Please tell us when and how your problem was resolved, so others can benefit by it.