Revision history [back]

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. This version has transparent PDF printing temporarily disabled, for testing, and thus requires that you install poppler-utils to make it work.

https://github.com/attah/harbour-seaprint/releases/tag/0.5-BETA

--- 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.

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. This version has transparent PDF printing temporarily disabled, for testing, and thus requires that you install poppler-utils to make it work.

https://github.com/attah/harbour-seaprint/releases/tag/0.5-BETAKeep 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.