fix airprint discovery

README.md

@@ -334,8 +334,31 @@ queries the printer live, offers all of them. On the Mac,
 macOS only takes its driverless AirPrint path when it accepts the printer's
 secure `_ipps` service; if that fails it silently falls back to its bundled
 generic PostScript driver. Duplex then stays hidden, because the generic PPD
-gates it behind `APOptionalDuplexer False`. The usual cause is the certificate
-(see *TLS certificate for `_ipps`*), so check that first:
+gates it behind `APOptionalDuplexer False`. There are two causes; check the
+Bonjour sub-types first.
+
+**1. The printer is advertised with the CUPS `_cups` sub-type.** macOS classifies
+a Bonjour printer as *shared* when it can be browsed under `_ipp._tcp,_cups`,
+and its AirPrint driver is only offered for a printer that carries `_universal`
+and no `_cups` (`-[DNSSDPrinter isShared]` / `-[DNSSDPrinter airprintMatch]` in
+`AddPrinter.app`'s `PMBrowser.framework`). CUPS registers
+`_cups,_print,_universal` unless `BrowseDNSSDSubTypes` says otherwise, so the
+queue is offered with the generic driver only. `cupsd.conf` therefore sets
+`BrowseDNSSDSubTypes _print,_universal`. Confirm it is in effect:
+
+```sh
+podman exec printserver avahi-browse -rt _ipp._tcp,_universal   # lists the queue
+podman exec printserver avahi-browse -rt _ipp._tcp,_cups        # must not list it
+```
+
+The second command lists other CUPS servers on the network; only *this* queue
+must be absent from it. If it does list the queue, the image's `cupsd.conf` did
+not reach `/etc/cups` — a bind-mounted `/etc/cups` hides the image's copy; see
+*Notes and limitations*.
+
+**2. The certificate is rejected.** Clients only accept it when the name they
+connected to is in its SANs *and* they trust it (see *TLS certificate for
+`_ipps`*). Check what is advertised and served:
 
 ```sh
 podman exec printserver avahi-browse -rt _ipps._tcp      # what is advertised
@@ -343,7 +366,7 @@ podman cp printserver:/etc/cups/ssl/server.crt . &&
   openssl x509 -in server.crt -noout -subject -ext subjectAltName
 ```
 
-A verified way around it is to add the queue from the command line, driverless
+A way around either cause is to add the queue from the command line, driverless
 over the same secure service (`ipptool -tv ipp://<host>:631/printers/<queue>`
 prints the UUID; drop the `urn:uuid:` prefix):
 
@@ -356,8 +379,10 @@ lpoptions -p <queue> -l     # Duplex, ColorModel and tray 2 show up now
 
 In the GUI, remove the printer and add it again, then pick **AirPrint** (not
 *Generic PostScript Printer*) under *Use*. If only the generic entry is offered,
-the secure connection is still being rejected — fix the certificate, or add the
-queue from the command line as above.
+either the `_cups` sub-type is still being advertised or the secure connection is
+still being rejected — fix that, or add the queue from the command line as
+above. macOS caches the failed attempt, so remove and re-add the printer after
+changing anything on the server.
 
 ## CUPS 3 and the future of PPDs