alors là il va me falloir regarder ça de plus près , car si le driverless repose sur la disponibilité d’une autre imprimante connectée qui fasse partie de « mon » réseau LAN , c’est pas gagné vu la densité de population locale et son type . Hormis mon voisin gendarme qui en a bien une ( je la détecte ) , pas sûr qu’une autre existe à moins de 3oom ( la mairie ) . C’est une aventure ce truc !
cad ?
Quoiqu’il en soit, ce n’est pas une histoire de longueur de réseau, en soit, mais de s’assurer d’être sûr le même réseau, ou de faire le nécessaire d’autoriser le flux vers votre réseau - mais là, on est dans l’administration réseau, hors de ce contexte.
N’hésitez pas à relire mon post précédent, j’y ai rajouté des informations intéressantes et utiles 
je regarderai toutes ces infos plus tard car je sature un peu avec ce problème intéressant certes , mais qui m’amène un flux de nouveautés qui provoque une sorte de " paper jam " ( je viens juste d’en expérimenter un alors j’ai découvert cette expression ) .
merci d’avoir pris le temps de détailler .
Ahhh, je viens de relire le PDF trouvé et il est clairement marqué en petite mention :
Apple AirPrint applies only to the SP 277SNwX/SP 277SFNwX
Donc la seule possibilité restante est :
- tester si son adresse IP, par Wifi ou Ethernet, répond
Si oui, trois autres possibilités :
⇒ tester la configuration de Cups et l’impression, après avoir configuré le fichier PPD :
- en utilisant le protocole unix « historique » lpd, tel que :
lpd://adr_ip/PASSTHRU - avec le protocole IPP, tel que :
ipp://adr_ip:631/ipp/print - voir avec le protocole http, tel que :
http://adr_ip:631/ipp/print
Et si ça fonctionne, tant mieux !
Mais ce ne sera pas une « imprimante sans pilote »
Imprimante ‹ sans pilote ›, … j’adore le concept bobo marketing.
Se prendre la tête avec Apple qui est une technologie propriétaire qui est clairement plus une complication qu’autre chose, nécessitant de la tripaille en plus genre avahi-discover, il faut quand-même aimer les complications.
Je n’ai peut-être pas assez insisté précédemment sur la partie nettoyage CUPS, mais CUPS déteste qu’on lui modifie par derrière les droits sur les fichiers.
C’est comme ça qu’on se retrouve avec une impossibilité de modification imprimantes par l’interface usager.
Nettoyage CUPS, ce n’est pas juste désinstaller/réinstaller, mais bien purger, et supprimer toutes les bidouilles faites précédemment, réinstaller.
cf :
Voilà.
PS : Stp, arrêtes d’intervenir, si ce n’est pas pour être pratique, et juste pour « ergoter » ; ici, on est là pour aider, parfois en se trompant, certes… et pas plus
Ce n’est pas qu’un concept : le but de ces technologies est justement d’éviter à l’utilisateur toute la phase d’installation de pilotes avant utilisation, qui dans certains cas, est problématique.
Pour vulgariser, c’est l’équivalent du « Plug’n Play » de l’USB
AirPrint n’est pas une technologie propriétaire ; le nom AirPrint est une marque, on est d’accord, de l’entreprise sus-nommée.
Le protocole Bonjour était historiquement sous la licence libre APSL, une dérivée de la MSF à la sauce Apple, et depuis quelques années, est à-priori sous licence Apache 2.0 (Licence Open Source) !
C’est une implémentation du protocole ZeroConf…
Et Avahi en est une autre.
Quoiqu’il en soit le protocole Zeroconf a vraiment pour propos de faciliter les usages réseaux, en se reposant sur les protocoles réseaux nécessaires à ces usages, protocoles réseaux qui sont « normés », dont les RFC sont disponibles, lisibles.
donc un truc du genre
sudo apt purge cups*
sudo apt install cups*
?
oui !
Non pas suffisant, car ne nettoiera pas:
→ libcups2 libcupsfilters1 libcupsimage2 printer-driver-cups-*
Comme tu as modifié des droits de fichier cups, nettoie tous paquets relatifs à cups:
sudo apt purge *cups*
Si je dis que CUPS n’aime pas qu’on modifie les droits de fichiers, je ne le dis pas par hasard, mais juste par expérience.
Ensuite, résinstalle cups, qui installera ses dépendances.
sudo apt install cups
Et installe les mêmes drivers ‹ RICOH SP 277 › que tu as installés dans Bullseye.
Et relis mon message complet sur le nettoyage CUPS, qui ne consistait pas à juste purger des paquets, qui n’a été repris que partiellement par la suite, mais aussi précisait ceci:
Vérifie au passage que tu es bien dans le groupe lpadmin, ça peut aider, et t’évitera de changer des droits sur des fichiers système que tu ne dois pas toucher.
groups $USER
mais n’est normalement pas nécessaire d’être fait.
Et utile, dans le contexte, où tu cherches à utiliser l’outil idoine, en mode CLI
et que l’administrateur système accepte que l’utilisateur ‹ xyz › puisse faire l’administration de l’imprimante, par Cups, par le biais de l’outil en question, sur le poste en question.
Mais attention avant de donner les droits en question, car cela donne des droits admin, non seulement sur l’imprimante elle-même mais aussi sur les jobs faits par les autres utilisateurs, sur ladite imprimante - utilisateurs qui n’apprécieront peut-être pas que l’utilisateur ‹ xyz › sachent ce qu’ils impriment, et/ou modifient les jobs en question !
group $user sous Debian suffit !
voire, même mieux : getent group lpadmin, dans ce cas particulier…
[quote=« PengouinPdt, post:22, topic:87953 »]
j’ai repris ça et je crois bien que depuis le début je faisais une énorme erreur sur le sens à donner à driverless : je pensais que les informaticiens , démiurges à leurs heures , avaient trouvé le moyen de s’adresser directement à la partie de l’imprimante qui met l’encre sur le papier sans passer par un logiciel spécialisé : le pilote . Et donc , en bon Mr Jourdain je faisais déjà du driverless sans le savoir quand mon 2ème portable donnait l’ordre à mon imprimante de sortir du papier avec une impression dessus en communiquant par l’intermédiaire de la livebox .
Du coup je comprends bien mieux cette histoire de réseau local et le « cad ? » ci-dessus . mon gendarme n’a rien à voir là-dedans . Mais il faut quand même dire que présenté à froid à un utilisateur lambda pas très orienté informatique et pas très vif neuronalement y’a de quoi s’y perdre .
Cette fois je comprends mieux les commentaires de @Verner . Enfin si tout ce que je viens d’écrire est correct .
Et, oui, le pilote existe toujours, même en « driverless ».
« driverless » est une terminologie impropre, qui comme tu l’as compris, rend confus le propos.
Derrière se cachent un ensemble de protocole réseaux, et de communication d’impression dont le but est de faciliter l’usage pour l’utilisateur final, sur les périphériques compatibles.
Si le périphérique n’est pas compatible, rien à faire, ce sera impossible de communiquer par ces biais.
Mais rien n’empêche d’essayer de communiquer avec certains périphériques, s’ils sont sur le réseau informatique, et s’ils répondent aussi à certains protocoles de communications d’impression, tel lpd (à préférer en premier), ou ipp.
cf mon post plus haut à ce propos.
Concernant le fichier PPD : parfois, il peut être utile si tu n’as plus l’exact fichier PPD, qui cible ton imprimante, d’utiliser celui d’une version d’imprimante de même catégorie, et au pire, d’utiliser le PPD générique.
Exemple : pendant un temps, mes imprimantes MFP de marque Epson, pour les utiliser, j’utilisais le PPD de version déjà reconnue officiellement, de même gamme, mais dont la dénomination « sur le papier » ne correspondait pas officiellement. J’ai toujours ainsi pu imprimé, sans utiliser, le PPD générique.
Exemple :
- utiliser le PPD d’une BX supérieure en gamme à ma feu BX525WD.
- utiliser le PPD de l’ET-4700, ou de la ET-3500… pour l’ET 3700 !
ce qui m’a mis la puce à l’oreille est sur le site que tu avais signalé plus haut OpenPrinting mais à propos d’autre chose . Comme quoi , au lieu de brûler les étapes pour avoir un résultat plus rapidement j’aurais mieux fait de bien me renseigner d’abord et là j’aurais gagné du temps . Mais bon ça m’a permis de découvrir avahi et quelques autres utilitaires utiles .
Mais rien n’empêche d’essayer de communiquer avec certains périphériques, s’ils sont sur le réseau informatique, et s’ils répondent aussi à certains protocoles de communications d’impression
un tuto m’a proposé socket://IP . Je fonctionne avec ça .
OUi, bien-sûr, tu peux.
Si c’est fonctionnel, tant mieux.
Historiquement, c’est le protocole AppSocket qui est ainsi utilisé.
cf : AppSocket TCP/IP Protocol
(souvent utilisé par HP, d’ailleurs… néanmoins, beaucoup d’imprimantes réseaux le supportent, tel Epson cité ci-dessus. )
Essaye avec le protocole historique ldp ou IPP directement (Cups fonctionne nativement avec IPP), ça devrait fonctionner…
Avec AppSocket, tu rajoutes une couche de communication, qui n’est peut-être pas forcément utile.
ok pour IPP , je l’avais déjà testé pour essayer de mettre en place le driverless . Donc pas de problème .
voilà , ça tourne . Merci .
1 J'aime
Dans les faits, Cups fonctionne nativement avec IPP.
IPPEverywhere est la « surcouche driverless » à IPP ; si j’ai bien compris, c’est même une réécriture d’IPP pour fonctionner nativement en mode « driverless », car le but à terme est d’abandonner certaines choses - mais je peux me tromper…
Pour finir, avec le sujet, si tu veux créer des fichiers PDF, tu peux ajouter le paquet cups-pdf qui va créer une imprimante virtuelle pour générer des fichiers adéquats.
C’est bien une « imprimante », mais là, il faut remonter à l’histoire de l’IT, pour comprendre le sens de « print » et « printer » où une « printer » n’est pas forcément un périphérique physique… 
Allez, je sors du sujet. Bonne fin de journée et content pour toi que tu es compris le propos et que tu sois en mode fonctionnel 