Fedora & HP Color LaserJet Pro MFP M479: moeite met printen

[Mortov Molotov]

Mijn vraag
Een stappenplan om mijn printer, zoals het hoort, aan de praat te krijgen.

Relevante software en hardware die ik gebruik
Fedora 43 KDE - pc aangesloten via ethernet
HP Color LaserJet Pro MFP M479fdw op LAN

Wat ik al gevonden of geprobeerd heb
Ik heb de voorbije dagen het gevoel dat ik tegen de harde grens van “driverless printing” ben aangelopen, en ik wil even aftoetsen of ik iets fundamenteels mis, of dat dit gewoon de stand van zaken is.

Doel was eigenlijk banaal: kleur + duplex + scan, liefst driverless (IPP Everywhere), en liefst hetzelfde gedrag op Linux, Windows en macOS.

Wat ik vaststel is… frustrerend consistent.

Met driverless / IPP Everywhere lijkt alles op het eerste gezicht oké. Kleur werkt. Scannen via NAPS2 werkt (zowel in Windows, Fedora als macos). Jobs worden netjes aangenomen. Maar duplex printen kan niet als optie worden gekozen in geen van de drie OS - dus ook niet in Linux. In Fedora zelf is printen onbetrouwbaar.

Als ik - in linux - overschakel naar een klassieke setup (socket:// + PPD via distro-packaged HPLIP), draait het beeld om. Duplex werkt altijd perfect en printen wordt weer saai en voorspelbaar. Geen hangende jobs, geen mysterieuze fouten. Scannen blijft werken. Maar kleur wordt lastig: technisch kan het (via lp met expliciete opties komt kleur er correct uit), maar in de printdialogs van elke gebruikte software (Onlyoffice, Firefox,...) wordt enkel zwart-wit als optie aangeboden.

Ik heb ook IPP over TLS (ipps://) geprobeerd, in de hoop dat dat “netter” zou zijn. Dat eindigde in jobs die eindeloos bleven hangen en printers die zichzelf uitschakelden met “credentials expired”. ipp-usb uitgeschakeld, queues manueel opnieuw aangemaakt, geen mDNS-autodetectie… geen verschil.

Uit nieuwsgierigheid (en lichte wanhoop) heb ik zelfs HP’s upstream HPLIP .run installer getest. Op Fedora 43 probeert die een halve build-omgeving te installeren, faalt op dependencies, en lost inhoudelijk niets op - heb het script uiteraard niet volledig gedraaid - ik voelde nattigheid.

Waar ik nu geëindigd ben: Linux gebruikt socket:// + PPD, dat is stabiel, duplex werkt altijd, maar ik moet wel zwart-wit accepteren bij een printer die gewoon kleur kan drukken.

Dus ja, als ik echt kleur + duplex nodig heb, moet ik de Windows PC van mijn vrouw gebruiken, waarop de driver van HP zelf werd geïnstalleerd.

Mijn vragen aan jullie:
Heeft iemand deze specifieke printer (M479fdw) wél betrouwbaar kleur + duplex zien doen via driverless printing? Is dit een gekend HP-IPP-advertisingprobleem (sides-supported, PJL vs IPP)? Zie ik een evidente workaround over het hoofd?


alvast bedankt!

[Hero of Time]

Paar jaar geleden en daarbij ook een aantal CUPS versies terug had ik op m'n werk ook zo'n probleem met de Kyocera printer bij ons. Ik had wél de optie voor kleur in m'n print dialoog, maar puntje bij paaltje kwam het er hoe dan ook zwart/wit uit. Want in de printer definitie stond dat zo opgegeven. Wat ik heb gedaan toen, was CUPS stoppen, /etc/cups/printers.conf (of waar de printer ook maar in gedefinieerd staat) aanpassen om kleur als optie toe te voegen en dan weer CUPS starten (want als je het bestand aanpast terwijl CUPS nog draait, worden aanpassingen teruggedraaid).

Nu is dat in mijn geval niet meer nodig. Heb nog wel de Kyocera driver nodig, al heb ik niet getest of het ook zonder werkt voor alle opties. Windows mist wel wat opties als ik de class 4 universele driver gebruik ervoor, maar dat staat los van Linux.
Hoe dan ook, probeer eens bovenstaand en kleur aan te zetten bij de mogelijkheden. Wie weet werkt het.

[Mortov Molotov]

Een klein verslagje na mijn geklooi deze avond:

Ik heb dus printers.conf manueel aangepast om kleur als default te forceren (met vooraf uitschakelen van CUPS); daarna CUPS opnieuw gestart. Dit alles op een klassieke setup (dus PPD + socket, niet driverless/IPP).

Helaas bracht dit geen structurele oplossing. Hoewel kleur technisch wel degelijk werkt (CUPS-testpagina print correct in kleur), blijft het gedrag vanuit desktop-applicaties inconsistent. Duplex printen werkt intussen wel overal betrouwbaar, maar kleur wordt door bepaalde applicaties opnieuw automatisch teruggezet naar zwart-wit, ondanks dat CUPS zelf correct op kleur staat.

Ik snap er niks van; gaat dit richting een structureel driver probleem voor die ene printer van mij?

[Hero of Time]

Aangezien de test pagina wél kleur doet, lijkt het eerder een probleem van de applicaties. Welke programma's gebruik je om te printen? Tonen die ook hetzelfde print dialoog? Zie je ook de juiste opties e.d. als je naar de CUPS interface gaat, dus localhost:631?

[Mortov Molotov]

Zowel flatpak apps (chrome, onlyoffice) en firefox (rpm) weigeren dienst.
Opties uitgebreid beschikbaar en correct afgevinkt in CUPS interface; I don't get it

EDIT: EINDELIJK OPGELOST:

Nav. een zoveelste zoekopdracht stootte ik op een github post van september 2024, die over een vrij gelijkaardig verhaal als het mijne ging (https://github.com/OpenPrinting/cups/issues/753).

De clue zat 'm in het IPPS protocol. Kennelijk probeert Fedora de hoogste veiligheidsstandaard te hanteren. Maar HP implementeert die standaard slordig door certificaten te gebruiken die niet door een officiële autoriteit zijn ondertekend, maar "self-signed" zijn. Gevolg: printopdrachten blokkeerden steeds met de error "invalid credentials".

Door op de firmware van mijn printer IPPS uit te schakelen kon ik mijn printer installeren via een standaard IPP protocol:

code:

sudo lpadmin -p HP_Color_LaserJet_Pro_M479_NoSSL -E -v ipp://xxx.xxx.x.xxx/ipp/print -m everywhere

En zo goed als alles werkt naar behoren, ook in flatpak apps zoals Onlyoffice:
- kleur indien gewenst
- duplex indien gewenst

Een PDF uit de bijlage van gmail afdrukken vanuit Chrome, lukt dan weer niet; in die zin dat de printer in het dialoogvenster netjes wordt gedetecteerd, en de mogelijke instellingen niet fundamenteel anders zijn dan in OnlyOffice. Maar om god weet welke reden wordt de printopdracht niet verstuurd, want de printer reageert niet, en in de print wachtrij vind ik, in dit scenario, evenmin iets terug.

Maar we zijn alweer een stapje dichter bij de verhuis van Windows 11 naar Fedora

[ Voor 82% gewijzigd door Mortov Molotov op 06-02-2026 15:44 . Reden: oplossing deels gevonden ]