Input wanted: I made a printing app...
Was: Collaborators wanted: share-to-printer plugin
Update 2020-05-16
Slowly but steadily I have now managed to add support for raster formats needed by simpler printers. This now means that there is a very good chance your IPP-compatible printer is supported, and a near-guarantee if it is from the last 10 years. I have very limited access to printers to test with, so it would be really appreciated if some people could step up and help iron out the bugs. Keep up with any extra releases here:
https://github.com/attah/harbour-seaprint/releases/
--- Post-Devember status update ---
So SeaPrint has been out for a bit over a month, passing 500 installs with over 85% retention. I'd call that moderately successful.
Since printing at home is a sort of thrice-a-year activity for me, i'm not the best driver for new features, or for judging what is "enough", so i'd like to turn to you guys for priorities.
I have a list of minor things left on the TODO-list (which will probably happen by virtue of enough rainy days passing) but i'm nor sure anybody really needs it:
- Setting to prefer/require ipps/https
- A password dialog for connections that require it
- ipv6 support (had it been Internet facing this would have made more sense imo)
I could also look at exposing some few more settings for print-jobs. Ranges is the only one i can think of right now, and that's a bit of a mess UI-wise. Anything else that is obviously missing?
Then there is making an actual sharing plugin... how interesting is that to people? I'm thinking that it would just invoke the main app, so losing out on progress etc... good/bad/ugly? Needed?
The last, and probably biggest thing is format conversions to both PWG raster and URF raster. I have it more or less working, but performance would be not-so-fun. A single color A4 page is about 26MB at 300dpi "raw", and about 1/10th of that compressed to PWG/URF (for normal text, better for large solid colors, worse for detailed graphics). A more normal 600dpi is a whopping 104 MB, again before compression. I can easily see how putting even a document of compressed pages in RAM would not go so well, especially on older phones.
On top of that, both conversion and transfer would take significant time. I can easily see how say a 25-page b/w document at 600 dpi would take a minute to transfer under normal wifi conditions. Make that 3 minutes for color. Also, currently the raster encoder i made would not quite keep up with the speed required for that either. I probably just did something too naively, and will hopefully get it to within margin of error eventually.
The other day i also found out that even if i make my transcode pipeline walk and quack like a QIODevice, that won't save me from putting the entire encoded thing in RAM anyway. QNetworkAccessManager insists on reading the entire thing, as it does not support chunked transfer from what i can find. I mean, if one is going to wait for those kind of file sizes to pass through two steps that does 20-40Mb/s they can at least be allowed to move in lock-step, one would have hoped. But no.
What remains is putting it on /tmp and then, only when it is done encoding, ship it over IPP. Boy howdy would that be tedious to wait for if the document has any size at all. I don't see myself improving the codec by an order of magnitude, even if eMMC throughput would allow it. Do i go fishing for an http client that allows streaming? Needless to say, fixing a problem i don't really have myself, isn't the easiest thing to keep working at.
Ideas? Feedback? Collaborators?
--- Original post ---
I was recently reminded that there still is no printer support in SFOS, so i took a look at the printer support situation. Yes, there is CUPS, and there is QtPrintSupport bindings for that. However, they are quite big and complicated. Sure, if one was to implement bindings for the whole API the configuration possibilities would be pretty great, but simple things like "just throwing a PDF at the printer" seems to involve rendering it client-side (ugh!).
This lead me to looking in to what network printing support actually means. The Printer Working Group would at least want you to think that it is IPP (Internet Printing Protocol), which supposedly ships with 98% of modern (network-enabled) printers. Also, any Linux box or Mac should be able to act as an IPP server. It seems that IPP-enabled printers tend to accept PDFs as a transport format. Sure, this approach limits printing to supported formats, at least initially, but PDF alone would take care of a sizeable chunk of printing needs.
So i made a quick IPP client in my favourite protocol handling language, Erlang, and before too long i had printed a PDF. IPP is pretty simple, and relying of huge monolith libraries seems as unnecessary as i thought. Following this, I started on a client in QT-flavoured C++, i.e. for SailfishOS. It sort of works, but boy was it painful. It must have taken an order of magnitude more time for a similar level of functionality. No GUI bindings or anything yet either... Since i print things about twice a year, the chances i'll bother finishing this are approaching zero.
Does anyone feel like pitching in? Do you just want to complain that this is the wrong approach?
Find me on IRC, #sailfishos at freenode.
More on sharing plugins here: https://together.jolla.com/question/164166/how-to-create-sharing-plugin-for-sailfish/
PS, while disillusioned by C++ i started a mDNS (discovery protocol used by IPP) client in Erlang too, and unless there is a really spot-on implementation available i'd say we are better off making our own client here too.
Update 2019-08-29 It appears that not listing pdf in the format query is less fatal than i thought. Upon further consultation of the RFC i came across this:
4.1.9.1 Application/octet-stream -- Auto-Sensing the document format
One special type is 'application/octet-stream'. If the Printer object supports this value, the Printer object MUST be capable of auto-sensing the format
That could mean that printers claiming to support PDFs (e.g. in their manual) still do, they just advertise it poorly.
Please help checking if your networked printer(s) would benefit from this
See wiki-answer.
I'm just wondering why you don't invest your time and energy into making cups work on the phone.
You know the use cases are limited because many printers can work only via USB or whatever local driver, but for the network printers a simple configuration should work
deloptes ( 2020-05-17 11:22:21 +0200 )editThose printers are very well served by a CUPS instance on another computer. I don't see may people plugging in their printers via USB to their phones, and any "speciality" drivers are unlikely to be available for ARM anyway. The RPC protocol of choice for CUPS is IPP, or as someone describing it put it: "CUPS thinks in IPP". So, if you like you can see this as the better part of a frontend for CUPS on the phone. I just think we are much better of with direct IPP or CUPS on another machine. I also value harbour-friendlyness highly, so that it becomes usable for regular users. And i must disagree with the use cases being limited by not using CUPS locally, compared to using CUPS remotely.
attah ( 2020-05-17 11:36:56 +0200 )editI am sorry but I have not looked into the solution as I do not have a use case for this. A use case on my end would involve BT or USB through the local network. The WLAN is on the other side of the firewall and the phone can never see the cups printer. The printer itself do not have WLAN on purpose. But all this does not really matter when handling the possible use cases.
IMO there are 3 possibilities:
Are you saying the solution covers option 2.?
thanks
deloptes ( 2020-05-17 13:26:12 +0200 )editI can't really cater specifically to people segmenting their networks, as non-reachability is the intended effect of it. Not sure what you mean by "USB through the local network", as to me that implies a computer with CUPS in-between.
attah ( 2020-05-17 13:59:55 +0200 )editThat's what it is meant to do, talk directly to the printer. I don't know what more things hide behind the buzzword "Direct Print", but i got the impression that it was basically IPP and some p2p WiFi mode.
Any CUPS instance, including on the phone should work as a go-between. However configuring the printer in CUPS is of course out of the scope of the app.
Same as 2.
OK, thank you for explanation.
There is a clear requirement to keep the WLAN outside of the local network, which is used for business as well. Of course I could configure the firewall to let access to the cups server, but I usually do not print via the phone, because I have the desktop in the same network as the printer. Anyway I was curious what was behind the software. Thanks again for explaining.
With BT or USB, I mean that I can have the phone access the local network via BT or USB on a local machine. I can then decide if I use cups on the phone or cups server on the local network. I was wondering if I had a option in the gui to configure the phone, but this is also answered.
deloptes ( 2020-05-17 14:41:30 +0200 )edit