Opened 4 years ago
Last modified 3 years ago
#16318 new enhancement
IPP-Everywhere and AirPrint - Print support the XXIst century way
Reported by: | pulkomandy | Owned by: | phoudoin |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Printing | Version: | R1/beta2 |
Keywords: | Cc: | ||
Blocked By: | #1042, #6795, #16320 | Blocking: | |
Platform: | All |
Description (last modified by )
The printing user experience in Haiku is bad. Let's fix that! This ticket is a starting point for better printing support. There are many things to fix, but I wanted to gather the info in a single place at first.
Printer discovery (#6795)
Everything in Haiku is hot-plug. Connect anything to an USB port and it will start working immediately. But printers must be added manually through the printer preferences. This should not be the case.
There are 4 things to take care of:
- Network printers: should use mdns and dns-sd (aka Bonjour/Zeroconf) to discover the printer automatically (#1042)
- USB: already enumerated in the "transports" when adding a printer, but should use the vendor/device ID to automatically configure the printer with the correct driver
- Virtual printers: I think they should be added automatically. When the PDF printer add-on is installed, make it available as a printer by default.
- Legacy parallel and serial port printers: the only case where specific configuration should be needed. And we may consider ignoring it because no one has these ports on their computers anymore anyway. I think it's ok if the UI is a bit less friendly for these.
Driver selection
Until now Haiku has relied mainly on Gutenprint for printer-specific drivers, and provided some generic drivers as well (PCL5, PCL6). However, and mainly due to efforts from Apple to allow printing from an iPad, there has since been a lot of work on driverless printing. The idea is that printers now use a common language and need no specific driver: all configuration can be discovered from the printer itself. This led to the AirPrint standard and later IPP-Everywhere. A lot of modern printers can be used in this way.
There are 3 steps to this:
- Discovery of a printer: see above, using USB enumeration or Zeroconf.
- Transport: IPP is used as a transport (and there is an IPP over USB but I'm not exactly sure how that works). We already have an IPP transport so we should be good to go
- Data format: these printers expect a raster image (no ps interpreter in the printer). The standard formats are JPEG (but it's lossy) and pwg-raster which is based on Cups raster format but simplified a bit (specification: pwg-5102.4). We don't implement this yet. Printers may aditionally implement AppleRaster / image/urf format but this one is not documented. Mine also supports PCL3GUI which is a bitmap only variant of PCL, apparently, but that's not part of the standard.
Printer management and job control
Our current printer preferences provides some very minimal job control and no printer management. Things like checking ink cartridge presence and ink levels, printer status, error messages from the printer, etc, should be added.
The IPP transport allows for this, including getting an icon for the printer, localized error and status messages, and a lot more information. It also provides the list of available paper formats and other things like that.
Change History (14)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Blocked By: | 1042, 6795 added |
---|---|
Description: | modified (diff) |
comment:3 by , 4 years ago
Blocked By: | 16320 added |
---|
comment:4 by , 4 years ago
In addition, I would really like to get rid of the old libprint.so, primarily because it has a very unfriendly driver interface and weird licensing. (Though that may be too much work to rewrite that sort of printing infrastructure, though maybe at a later date)
comment:5 by , 4 years ago
It isn't that weird (there are not many other ways to do things) and it is a lot of code that I don't think is worth replacing. I will however consider cleaning up the IPP transport to use our current HTTP implementation (allowing gzip compression at the transport level, making things more efficient), and probably rewrite other parts of it if I try to get into IPP over USB.
As for the license, we were researching this and apparently we did get agreement from the author when including it into OpenBeOS: https://www.freelists.org/post/haiku/Canon-LIPS43-printer-Driver,3 so it seems fine to assume MIT as for everything else (it would have been better to track this more precisely than a mail in the ML archive, but the CVS history was unfortunately lost when switching to SVN, so everything that happened before 2002 we have no logs for).
comment:6 by , 4 years ago
Ah, I wasn’t aware about the mailing list post, so that works out at least! While I’ll budge and say that libprint is usable, I still believe some expansion could help, as I find the print api still a bit limited in terms of feature support. (The BeOS Dano print kit allowed one to query support for cleaning print heads and other finer details :D)
comment:7 by , 4 years ago
Well, libprint does not get in the way of adding more things. In fact it does not define the print API, it merely implements parts of it to make it more convenient for people writing printer drivers.
The design is as follows:
The BeOS printing API is essentially "here is a BPicture, print that on the page". But most printers don't want a BPicture nowadays. When this API was designed, some of them would handle postscript or the like, and BPicture could be converted to that. But now, as the computers have better CPUs and memory than the printers, it is simpler and faster to just send a big bitmap to the printer. Libprint is there to do this conversion from vector to bitmap.
It also provides the transports implementation (but I will probably replace large parts of the IPP transport).
Finally, it attempts to complement the printer configuration (page formats and the like) for which Be had not specified much, in this area there is indeed room for improvement by redesigning the UI, and probably consolidating a lot of it in the actual print API, rather than in libprint in each driver.
comment:8 by , 4 years ago
Are there headers for the Dan0 print kit? Perhaps we can take some inspiration from that, if it is still relevant.
comment:9 by , 3 years ago
Printing is still not working easily for users (like me). Printer manager just does not help with setting up a printer. I have a Canon MX870 that runs on my network and all computers (Apple mac,linux and windows) see the printer and find it via Bonjour. What can be done? ipp is not working nor is CUPS type URL (lpd://localhost:631/ipp/192.168.1.102) To me this is a basically important aspect of an OS for user friendliness and 'out of box' behavior!
comment:10 by , 3 years ago
Nothing can be done currently. That's why this ticket exists.
CUPS URL will not work because we don't use CUPS. IPP is not working because we don't implement it yet.
You can vote for this ticket if you think it is important (there are arrows to vote tickets up/down at the top right of the page). We take this into account when deciding what to work on.
comment:11 by , 3 years ago
EDITED AFTER READING COMMENT BY @pulkomandy Printing may not be fundamental for some people anymore but I often print or scan documents and photos. So, could it be possible to implement the following recommendation given by a developer who is building "helloSystem":(probono Jul 16, 2019)
“Quick” fix: Deeply integrate mDNS/Zeroconf into the system and use something like CUPS for printing (it is what Apple uses, after all)
@pulkomandy do you mean printing is just not to be included in Haiku? What do we need to do to get it moving? I could help, but my drawback is that I am not a programmer. How do you suggest that this could be at least make to work with standard, old fashioned line printing methods? Can any of the Haiku developers issue a howto for implementing this? It looks very strange to a user like myself that a whole Preferences App exists that basically is just a dummy code that does nothing to the hardware. If Haiku does not want to use CUPS, what does Haiku want to use? Can we offer printer driver files? I understand that users can always find a workround for printing: export pdf to othe devices,e.g. but that does not make it look very nice in a basically useful OS like Haiku
follow-up: 13 comment:12 by , 3 years ago
The existing prefernces work, but there is no support for modern IPP printers. Only older models supported by Gutenprint work currently, and the network printing support is broken and needs to be completely replaced.
There is nothing much to do about it, we need to fix many problems before we can get there. Modern network printing (Airprint/IPP needs to be implemented). For this to work, we need mDNS/Zeroconf. For this to work we need working multicast support in our network stack.
So it's just a lot of missing underlying technologies before we get this up and running. It is not a matter of just adding a printer driver file. There are much deeper issues.
This is why Haiku is still in beta phase: a lot of things like this are missing before we consider ourselves ready for general users. There are many, many tickets like this one. But despite our repeated warnings that Haiku is in beta phase, people keep having high expectations.
I understand that users can always find a workround for printing: export pdf to othe devices,e.g. but that does not make it look very nice in a basically useful OS like Haiku. PS: it would be a shame to read a Haiku review somewhere stating that printing is not working at all!!
Are you trying to shame the developers for not having gotten to this yet? I perceive this a bit negatively. We are well aware of our limitations and doing our best to solve the problems, but with our limited time, it can take a few years before we get to it. As I already said, if you are not a developer, there is not a lot to do at the moment but vote for this ticket, and watch it to see if any progress is made.
We will see how the recently announced full time contract helps us making some progress on this and other areas.
comment:13 by , 3 years ago
Replying to pulkomandy:
Are you trying to shame the developers for not having gotten to this yet? I perceive this a bit negatively. We are well aware of our limitations and doing our best to solve the problems, but with our limited time, it can take a few years before we get to it. As I already said, if you are not a developer, there is not a lot to do at the moment but vote for this ticket, and watch it to see if any progress is made.
We will see how the recently announced full time contract helps us making some progress on this and other areas.
I am not 'shaming' anybody! What I meant was that reading negative reviews about a giant piece of work like Haiku would be a shame! I have donated to Haiku because I believe in it as a user: I have worked and used computers since 1980s and the linuxes and windows are getting worse, not better. So, Haiku has an opportunity window which is open for a short time. Sorry if you felt badly about this. I look forward to see developments at Haiku!!
comment:14 by , 3 years ago
The opportunity window has been "open for a short time" for at least 20 years, and I think it will continue to be open for the next 20 years because no one else is trying to fill it (or if someone beats us to it, that's great too).
We will get there eventually :)
I completely agree! I don’t think I have been able to print from Haiku before, and I consider myself a Haiku veteran! :) While these files won’t help much with actual print driver handling, I hope this might inspire some new print panel interfaces: https://github.com/CodeforEvolution/BeOSDanoHeaders/tree/master/headers/be/print
In addition, I have a fresh BeOS Dan0 VM that I can use to experiment with their new print kit interface to maybe find some inspiration. :D