I messed up!
All releases of SeaPrint so far have had a faulty implementation of the RLE compression algorithm used for URF/PWG raster.
This resulted in documents being 2-4 times larger than they needed when printed via these formats, and thus taking more time.
It was still compliant, just quite wasteful. For images it was less bad.
Fixed in 0.6.1 - sorry for the update spam.
I always thought that the documents were so big just because the format is crappy. Great that you found the bug!
No need to be sorry, this is good!
Thats the type of spam people like 
Works with Canon PiXma MX470, connected to an fritzbox !!
Iām guessing thatās over USB since you mention the router brand?
Thatās pretty cool!
Any difference from how it works with using the printerās own network interface?
A request/idea/suggestion: Wouldnāt it be more user friendly to have all the files that can be printed by the app appear when you select a file instead of the file browser?
Hmm, i donāt understand what you mean. Can you clarify?
Are some file(type)s not appearing?
Instead of having to go through the folders to find the file to have a list with all the files that can be printed. A list like the one that appears when you open the Documents app.
Ah! This was actually asked and answered before.
The problem is that i will get exactly the list in the Documents app, which includes lots of files the app cannot print. This would likely be very confusing to most people.
For whatever reason the (built-in) DocumentPickerPage does not provide an option to filter on types/extensions, only FilePickerPage has it.
It would be nice but it is not re-implementing core Silica functionality-nice.
Ok. Kind of a bummer but i understand why it is that way. Anyway.
@atah
I have an issue. When taping the icon to see the list of documents on the device i see none. It says to copy some on the device. I have mainly .txt files and pdfs.
What gives.
Hmmā¦ so as you might guess i found a way to do what you asked for, but not very nice if it breaks.
You shouldā¢ only see PDFs and Postscript. I assume you see your PDFs in the documents app? Do you also see them in the attachment selector in the email app?
Do stop by on IRC if you have some time, iāll be there another couple of hours.
Edit: tested fresh installs on both 4.0 and 3.4ā¦ both works 
I think i found the bug. Whatever you did is case sensitive. Ie. myfile.pdf works, myfile.PDF doesnāt work.
Havenāt tested extensively though.
That sounds correct. I thought it was that way before too, but perhaps it had some magic. Itās an easy fix to at least include all-uppercase file suffixes. In the meantime; may i recommend the sharing plugin on openrepos?
I started messing around with supporting more file formats, but itās not so easy.
For doc(x), odt etc, calligrawords has a command line option to convert to pdf that i could probably lean on. Supposedly there is also the more generic calligraconverter, but even the version that ships with my Linux distro segfaults no matter what i throw at it. The same goes for calligraconverter on SFOS. It was fairly easy to add that to the sailfish-office build, but adding calligra-words seems not so easy.
Then there is plaintext; how hard can it be?
Very, apparently.
My one printer that supports it definitely wants \r\n newlines, so iāll need to re-linebreak files that i send over. Not too terrible, but using any sort of readily available readline functionality, it seems i will lose track of any \f characters.The horror!
And since plaintext support seems quite rare, iād like to render my own in PWG/URF raster images.
I donāt think i want it more fancy than the standard 72*60 monospace characters per page, but still. For example; should there be any reflow at all? And in that case, keeping track of the number of lines or page fitment gets quite hard.
ā¦and the same thing about \f goes for this too.
Or i could lean on some existing tool to go via PDF, but there doesnāt appear to be a standard tool for this, just oddball stuff.
Surely there must be a better way, especially with all the fancy Qt stuff availableā¦
If anyone wants to pitch in, or just help me think, please get in touch!
There are certainly multiple ways to go here. One way could be using a2ps, ps2pdf and friends. Or indeed go the QPrinter way. Or perhaps check how the ādownload as pdfā feature in the browser is implemented? Sorry, I probably didnāt help much
You itch my curiosity here. Iāll try to look at that segfault and see if it can be cured without too much pain.
Here is the merge request upstream to fix some of the crashes encountered in calligraconverter :
https://invent.kde.org/office/calligra/-/merge_requests/19
I still need to investigate why it still insists on opening a window when called with --batch option, but at least it converted the ODT files I tried to throw at it, into PDF ones. Having this GUI opening may be problematic under Sailfish for your use case.
If fixes are accepted upstream, Iāll make a MR in SailfishOS to upgrade Calligra to latest upstream.
Thank you very much!
Since iām quite curious, i hand-patched that into the SFOS packaging of Calligra and compiled it.
Unfortunately that still segfaults, maybe due to that GUI you mentioned having failed to instantiate?
All i did to get calligraconverter to build there was to add APP_CONVERTER to -DPRODUCTSET in calligra.spec. (Then the build will fail/complain that the resulting binary is not packaged, but i just grab it from there and fling it over)
Also, it needs a LD_LIBRARY_PATH=/usr/lib/calligra-kf5/ to run.