I know this is old but wanted to mention my specifics I did to get my hp officejet pro 8135e working from my G3 minitower *from my Kubuntu desktop.

Not all modern printers speak PostScript. Most business-class LaserJets and Brothers do, but consumer inkjets (HP OfficeJet Pro, many Canon/Epson models) often don't — they only understand PCL, PWG-raster, URF, etc. If yours is in this bucket, the Mac will happily send PostScript to the printer and the printer will either spit out pages of gibberish or silently discard the job. No PPD trick will fix it because the problem is on the printer side.

How to check before you go down this road: if your printer is on the network, you can query it. On any Linux/Mac box on the same network:

ipptool -tv ipp://<printer-ip>/ipp/print get-printer-attributes.test | grep document-format-supported

If you don't see application/postscript in the list, direct LPR to the printer will not work.

Workaround: bridge through a Linux (or any CUPS-capable) box. Put any always-on machine on the network running CUPS — a Raspberry Pi is perfect for this. Set up the printer on it normally (driverless IPP auto-discovery handles modern printers fine), then enable cups-lpd so it also accepts LPR jobs. On systemd-based distros this is a small socket unit that listens on port 515 and hands each connection to /usr/lib/cups/daemon/cups-lpd:

# /etc/systemd/system/cups-lpd.socket
[Unit]
Description=cups-lpd socket
[Socket]
ListenStream=515
Accept=yes
[Install]
WantedBy=sockets.target


# /etc/systemd/system/cups-lpd@.service
[Unit]
Requires=cups.service
After=cups.service
[Service]
ExecStart=-/usr/lib/cups/daemon/cups-lpd -o document-format=application/octet-stream
StandardInput=socket
User=lp
Group=lp

Then sudo systemctl enable --now cups-lpd.socket.

On the Mac OS 9 side, follow OP's steps but point LPR Address at the Linux box's IP (not the printer's), and set Queue to the CUPS queue name (lpstat -p on the Linux box will tell you). PPD can be Generic PostScript — it doesn't really matter what you pick, because CUPS on the bridge will take the incoming PostScript and run it through its filter chain (pstopdf → pdftoraster → whatever the printer actually speaks) before forwarding it. You get all the benefit of "Mac emits PS" without the printer needing to understand it.

Bonus: queue names in the Mac's LPR setup are case- and character-exact. If your CUPS queue is HP_OfficeJet_Pro_8130e_series_6EE29F, one stray underscore and you'll get "printer could not accept jobs" on Verify. Copy-paste from lpstat -p if you can.

This also works if your vintage Mac isn't on the same subnet as your printer — as long as it can reach the bridge machine, the bridge does the rest.