Yes, obviously, if you statically override the contents of a dynamic message it no longer has any use.
Think of it as overriding toner level; if you set it to 100% it doesn’t make it so.
I’ll see if i can add the printer-state-reasons as translatable. Both the fact that there are over 800 of them, and how they are stored might make that not so easy. And no, i will not do it partially - all or nothing (translations themselves can of course still be partial).
I’ll also look in to if for strings where the printer supplies the plaintext, it can be asked to provide those matching the translation (where applicable).
Have you printed images as PNG at all?
(I.e. not necessarily a image that was a PNG, but that got transferred as PNG - best transfer format available, or manually selected)
Did it work well and behave as expected? What kind of printer was that?
I’m thinking i should change what SeaPrint does when sending images to the printer, and not apply any fit-to-page etc, same as for JPEGs.
(And where applicable converting to the target format of course).
So this would mean that for Postscript, PDF and raster formats SeaPrint would do fit-to-page, but that it no longer would do that for image formats as intermediaries.
I think things like label printers would be much happier doing the scaling themselves, and anything else would do a pretty good job anyway.
Any opinions?
And of course; if you have other feedback, don’t hesitate to share.
I print occasionally (like once a month) pngs. Printing a screen capture (which is in png format) results in somewhat distorted scale on axle x if I remember correctly. I haven’t given it many thoughts as it works good for my using scenario. Fit-to-page seems to stretch the screen capture from an Xperia 10 II wider. I have a ten years old and badly behaving Samsung SL-M2070 laser printer (after Samsung’s printer business was sold to HP, I guess, it has started to give notifications in French and Turkish on a Windows pc and the actual printing job getting done is best acchived from a pc using a cable, the wireless connection isn’t so reliable). The pngs are printed in couple of seconds when using SeaPrint. That among other things is great in SeaPrint. Thanks!
BTW is there any change to have a wireless scan option to SeaPrint? Or are the manufacturers using proprietary drivers? Wireless scan would be awesome but I can only try to imagine the work it would need.
Hmm, that doesn’t sound quite optimal. Do note that source and transfer format are rarely the same except for jpeg.
Could you please share the debug info you get by tapping the printer 5 times with no document selected?
Apart from scanning being evil in that too many people use it as a crutch to not properly keep track of digital source documents, there are no standard scanner protocols. Some combination of SANE and CUPS/PAPPL can act as a go-between and behave in a proposed-standard way, but you’d probably be better of just using those more directly. (Can you tell i never scan?)
Oh, that isn’t good.
Most of that is just noise from the UI, but where it goes wrong is “Tried to read past end”.
So it seems i must have some mistake in the IPP decoding.
Unfortunately that doesn’t really say much, so i’d need your help to get a network capture troubleshoot further if you are up for it.
Basically it goes like this:
Install (pkcon install/zypper in) tcpdump
Start tcpdump -s 0 -i wlan0 -w /tmp/tcpdump.pcap port 631
Manually try to add the printer with ipp://, not ipps:// since it is encrypted (probably ipp:// 10.100.0.100:631/ipp/print)
Stop (ctrl-c) the capture and get it to me somehow (pm perhaps)
Since it is just capturing port 631 there shouldn’t™ be anything sensitive there.
You can look at the capture with Wireshark to see that it worked and what it contains. Or you can of course keep an eye on the SeaPrint log output so you know it worked.
The failure is expected here - it will behave the same as with the automatic discovery. But it should have triggered the same IPP request/response in the background, only unencrypted. Looking forward to the capture, hopefully it is an easy fix
The 1.2-series is turning out to be an interesting one.
I just pushed 1.2.1 to GitHub and Harbour (coming next week).
1.2 added, among other things, that the app itself can perform copies by sending (sequences of) pages over and over again.
Turns out @Se’s printer is the normal one and my OKIs are the exception. Printers that are simple enough to need raster formats generally can’t perform copies.
1.2.1 Builds on that infrastructure and add custom discontinuous page ranges, at least one step on the way for manual duplex @asavasa.
But what is probably most interesting is that with some inspiration from ipptransform, i have turned off anti-aliasing and with no visual loss (thanks to the high resolution of printers) the raster sizes are halved for printing text documents.
I try to take a look in the scaling issue if it is still there (or was just me remembering wrong). Unfortunately I have been too busy with other stuff.
The coming updates surely look promising!
Well, after the (imagined?) problem appearing there have been an OS uppdate and a SeaPrint update. Anyway, now the png printing is working very well and I did not notice any problems (Xperia 10II, SFOS 4.4.0.68, SeaPrint 1.2).
Once more, thank you very much for a crucial and well working application!
It simply cannot have ever worked for you before (unless your printer changed).
That looks like the printer properties page, as opposed to the printer or print-job-page that you print from.
I.e. all you are are missing out on is making the printer flash and beep.
I’ll hide the whole menu for incapable printers.
