Contribute to documentation

This week, I successfully used this project to set up driverless printing to my HP LaserJet P1005 from a Raspberry Pi 2. :raised_hands:

I'd love to be able to contribute to documentation to make this easier for others.

But there doesn't seem to be a documentation system in place yet...

some projects store documentation in the project wiki (see Documenting your project with wikis)
- advantages: easy for to add/edit documentation without submitting pull requests
- disadvantages: when a new major version is released, it's hard to tell v1 docs from v2, etc.
some projects store documentation in a docs/ folder (see About GitHub Pages and Configuring a publishing source for your GitHub Pages site)
- advantages: v1 documentation is in the v1 branch; v2 documentation is the v2 branch
- disadvantages: have to submit PRs to update docs
- note: this way also works well with ReadTheDocs versioned documentation if you prefer that over GitHub Pages

(I personally like option 2)

Maintainers, do you have a preference for where I should start submitting documentation?

Thanks a lot for reporting the first issue on the HPLIP Printer Application, and under the 3113 downloaders up to now (including you) no one reported a bug in the actual software.

And thank you for giving feedback on your experience with the HP LaserJet P1005, a printer which needs its firmware loaded everytime when it is turned on, and that on a Raspberry Pi 2 which is an ARM system and not amd64, and so knowing that the download of the proprietary plugin and after that the automatic firmware loading by the Printer Application all work as designed by me, also on non-amd64.

I even was not able to test everything straight away on my amd64 boxes, not having an appropriate printer. I did some tricks testing this on the non-firmware-needing HP OfficeJet Pro 8730, creating a fake firmware file which is simply a PDF file (this my printer prints raw, without any filters nor IPP, simply via classic USB) renamed to what a firmware file looks like, edited HPLIP's models.dat telling that my printer needs firmware, and after that getting the file printed everytime when I had turned on the printer, meaning that the "firmware" got uploaded into it.

Did you any special things for that? Or all straight-forward (click "proprietary plugin" in the web interface, follow screen instructions to download plugin, create queue for your printer via "Add printer", ...)? If you most note-worthy steps are on the level of getting a systemd-based system, get snapd on it, and afterwards the Printer Application Snap itself, you should also consider the snapcraft.io forum.

Even if we do not have decided on the documentation concept yet, could you post here in this issue report what exactly you have done and in general what you wanted to write into the documentation?

Now to the actual question of your issue report, I am also in favor of documentation concept (2). This integrates best with our projects (I think "cups" does such a thing already) this way we have a documentation version for each version of the software and we can keep track of its development.

To make a start, good parts of README.md will probably get into the documentation, and also any of your special experiences.

Hey @tillkamppeter, thanks for the quick response; and thank you very much for your hard work on hplip-printer-app!

My LaserJet P1005 has always been a bit of a pain to get working on a new computer. For a number of reasons, I had been looking for some way that I could install the HPLIP drivers on a Raspberry Pi, so I could send something to the Pi, and let it figure out how to print it, i.e.: to save me the hassle of trying to get it working on a new computer or after a reformat. For a while, I was looking into setting up CUPS and sharing printers through it, but reading that CUPS was dropping driver support in favour of IPP, I decided to teach myself a bit more about IPP; which lead me to @michaelrsweet's LPrint, which led me to PAPPL, which led me here!

So far, while I've hit some hiccups, I'm not sure if they're actually bugs or not... those hiccups might just be my own ignorance :upside_down_face: (as a software developer myself, I'm acutely aware that sometimes problems exist between my own chair and keyboard)

To confirm some of your questions, yes, I'm using a Raspberry Pi 2 model B, which has an ARM Cortex-A7 (a.k.a. armv7+ a.k.a. armv7l a.k.a. armhf, a 32-bit architecture). I installed Raspberry Pi OS Lite (Lite = no GUI), based on Debian 11 Bullseye... here is my uname and lsb_release:

$ uname -a
Linux my-hostname 5.10.63-v7+ #1488 SMP Thu Nov 18 16:14:44 GMT 2021 armv7l GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye

... once logged into the new Raspbian install, I had to install snapd, and the hplip-printer-app...

$ sudo apt install snapd
$ sudo snap install --edge hplip-printer-app

I then went to the web UI at http://my-hostname.local:8000/ to configure...

I clicked "Add Printer"... I can't remember exactly what I did but it became clear that I had to install the proprietary plugin, so...
I went back to the home screen to click "Install Proprietary Plugin", and followed the steps
I then clicked "Add printer" again, and set it up
It worked right away after that: i was able to successfully print from:
- the hplip-printer-app web UI, iOS 15.2, Android 11, Windows 11, and macOS 11.6 Big Sur without any issues;
- Ubuntu 21.10 Impish and Fedora SilverBlue 35 by adding the printer by its address (http://<ip-addr>:8000/ipp/print/myprintername) and choosing the "Generic PostScript" driver
  - the CUPS instance running on each of these computers detects the printer without me having to enter anything; but whatever it detects as the default settings doesn't seem to work - under the auto-detected settings, printing adds it to the queue, and the printer whirs for half a second and stops, but the job gets marked as complete immediately even though nothing was printed

However, I remember now that the "first print after starting the printer" (i.e.: where the firmware gets loaded) happened a few weeks ago when I plugged it into my old macOS box... I didn't understand what was happening before. I had just become accustomed to not turning off the printer - and if it gets restarted after a power failure to print a test page from macOS via direct USB connection. Thanks for clarifying what was happening there.

As I was typing this response, though I decided to perform a small experiment to see if I could figure out if the initial-firmware-load was working... I printed a test page (which worked), then power-cycled the printer, and then tried to print another test page (which has gotten stuck in "Processing" for about an hour now, which i think means the firmware may not have been properly loaded after the power cycle). Restarting the Raspberry Pi doesn't seem to have fixed the problem. So I may have just found the first bug (sorry!). I can file that as a separate ticket soon (I want to try printing a test page from macOS over a direct USB connection, and then plugging it back into the Raspberry Pi to see if that unblocks the print queue... I'd also like some sleep, as it's getting pretty late in my timezone).

Regarding the documentation; thanks for the response; I'll look into submitting a pull request soon!

Thanks again for your hard work, quick and friendly response, and for your help! :smile:

I have now updated the Snap to 3.21.12, but without any further fixes and investigations, only tested whether a print queue satys conserved and uses the current HPLIP's PPD file and whether the proprietary plugin installed under the HPLIP 3.21.8 Snap gets automatically updated when updating to the HPLIP 3.21.12 Snap. All this is the case. The plugin update can be slow.

The Snap Store is currently building the new Snap version, and if you did not change any settings on your system, in the end of the process the Snap Store will update your installed 3.12.8 Snap by 3.12.21 and the Snap itself will update your plugin.

This can improve your situation but does not necessarily do so, as no active changes concerning your problem are done.

Please report back how it all works for you.

Hi @tillkamppeter, sorry for the delay in responding.

While on revision 247 (i.e.: version 3.12.8), I power-cycled the printer, and confirmed I could not print. I then updated the snap to revision 251 (i.e.: version 3.21.12). It did keep the print queue and settings. Checking the "Install Proprietary Plugin" page, it reported "Plugin installed and up-to-date" and tried again - I still could not print.

I unplugged the printer from the Raspberry Pi (USB) and plugged it into my macOS machine (Big Sur, running the macOS "HP LaserJet P1005, 1.6.1 (greyscale)" driver, over USB), and printed a test page. I then plugged the printer back into the Raspberry Pi and tried again... I could print again from the Raspberry Pi.

(sounds like the macOS 1.6.1 driver loads the firmware properly; but the Linux HPLIP 3.2.12 driver does not)

But... if I power-cycle the printer and then run...

$ lsusb -d 03f0:3d17 # i.e.: list HP LaserJet P1005s attached to the system
Bus 001 Device 004: ID 03f0:3d17 HP, Inc LaserJet P1005
$ sudo snap run --shell hplip-printer-app # i.e.: enter the hplip-printer-app snap filesystem
$ hp-firmware -y3 -s 001:004 # i.e.: bus:device from the lsusb output earlier

... the printer whirs, and I can print after that (the -y3 - i.e.: wait 3 seconds - is from https://bbs.archlinux.org/viewtopic.php?id=157931 - I can test other values to see if they work)

I'll file this as a separate issue though - edit: filed as #2

OpenPrinting / hplip-printer-app

Contribute to documentation #1