Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 3 days, 9 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 4 days, 9 hrs ago - more...
 |
qwerty12 |
2009-01-10
, 16:49
|
|
Posts: 4,274 |
Thanked: 5,358 times |
Joined on Sep 2007
@ Looking at y'all and sighing
|
#21
|
Originally Posted by z2n
Your points are all correct and valid and I do not disagree at all. But I think the point is to use it when the user does not have a keypair set up (and I do agree that should be done instead of using this but some people will never bother :/ ..)
 |
|
2009-01-10
, 18:27
|
|
Posts: 16 |
Thanked: 2 times |
Joined on Jan 2008
@ California, USA
|
#22
|
Bongo -
Wow. This is really great. I didn't expect to go to sleep and wake up to 100 lines of free python code! I haven't tried it yet, but will later today (have to take my little one to gymnastics in a few minutes)
Regarding the passwords, I think setting up ssh keys is fine. I worry a bit about going password-less (password-less key) to my server just because there's already no password to get into the "user" account on the Nokia. But I can have a special printing account on my print server without many access privileges, I think.
If we don't mind making it lpr-specific, then it would be great to add a few options that apply to all printers, such as page-ranges.
If the target audience is people who can set up a print server, then it may be safe to assume they can edit a few choice lines in the script file to make printer-specific options. I'm imagining a set of check-able options, where the user can edit a few lines in the script to put in the specific commands and label for each option (things like greyscale, draft mode, etc.). It may be okay to hard code the print server host, user account, etc. in the script as well in this case. This avoids the code complexity of saving/reading user defaults, etc. At least save that complexity until a time where we think there's a broader user base out there.
I'm thinking it would be good to have a single, catch-all text entry box to specify any additional one-time options to send to lpr (options used so infrequently that the user doesn't want to add a check-box to the script).
I don't currently know python (I mostly use C/C++/csh), but I can probably figure it out if need be.
Thanks for this great script.
Wow. This is really great. I didn't expect to go to sleep and wake up to 100 lines of free python code! I haven't tried it yet, but will later today (have to take my little one to gymnastics in a few minutes)
Regarding the passwords, I think setting up ssh keys is fine. I worry a bit about going password-less (password-less key) to my server just because there's already no password to get into the "user" account on the Nokia. But I can have a special printing account on my print server without many access privileges, I think.
If we don't mind making it lpr-specific, then it would be great to add a few options that apply to all printers, such as page-ranges.
If the target audience is people who can set up a print server, then it may be safe to assume they can edit a few choice lines in the script file to make printer-specific options. I'm imagining a set of check-able options, where the user can edit a few lines in the script to put in the specific commands and label for each option (things like greyscale, draft mode, etc.). It may be okay to hard code the print server host, user account, etc. in the script as well in this case. This avoids the code complexity of saving/reading user defaults, etc. At least save that complexity until a time where we think there's a broader user base out there.
I'm thinking it would be good to have a single, catch-all text entry box to specify any additional one-time options to send to lpr (options used so infrequently that the user doesn't want to add a check-box to the script).
I don't currently know python (I mostly use C/C++/csh), but I can probably figure it out if need be.
Thanks for this great script.
 |
|
2009-01-11
, 16:35
|
|
Posts: 291 |
Thanked: 124 times |
Joined on Feb 2006
@ Trier, Germany
|
#23
|
Did my python script work for somebody? Is there demand to continue my work on it?
__________________
ongo bongo!
ongo bongo!
|
|
2009-01-11
, 16:45
|
|
Posts: 1,950 |
Thanked: 1,174 times |
Joined on Jan 2008
@ Seattle, USA
|
#24
|
Originally Posted by GraphicsGuy
Thanks, that's a handy bookmarklet.
I really like this lightweight approach, since I'm running standard maemo os2008 (not debian, not booting off mmc). I set up cups on my little nslu2 NAS (backup server mainly, "unslung").
Is there some kind of standardized file selection gui we could easily build off of? It would also be cool to add capability for a few more print options. These would be simple to add to your xterm-based script, though. Mostly file selection is a pain. Maybe calling from an existing file browser would be easiest.
BTW, here's a bookmarklet to convert the current web page to pdf for printing with lpr (still takes an extra couple of clicks to save the pdf):
javascript:void(location.href='http://www.htm2pdf.co.uk/?url='+escape(location.href))
Also, are you saying that "lpr" (which is some sort of Unix printing function?) provides a way to print a pdf from the Tablet? (For me, who hasn't figured out how to print from the Tablet, the bookmarklet is useful because it gives me a way to email myself a pdf of a webpage, which I would then print from a computer.)
|
|
2009-01-11
, 18:43
|
|
Posts: 16 |
Thanked: 2 times |
Joined on Jan 2008
@ California, USA
|
#25
|
Originally Posted by bongo
I tried it this morning. It works great. I edited the lpr command in the script to select my print queue by name (because I don't have the default set properly there yet) and did my ssh password at the command prompt (no keys set up yet).
Did my python script work for somebody? Is there demand to continue my work on it?
I'd love for you to continue development if you want to (and if you don't, I will). Regardless, thanks for what you've done so far.
Hope you don't mind a few thoughts based on my particular use case:
1) I've got a single cups print server running linux with a single printer on it. So I don't mind hard-coding those into some variables in the script. For people who don't want to edit a file, you could possibly continue along your current path (enter host, user, etc. in the gui and eventually support saving them as defaults). But I'm not sure if this part is the best use of your coding time. Leaving it out will also save more window space for per-job configuration options. Best of all worlds would have a seperate window for printer configuration versus job options.
2) I'd like to be able to specify page-ranges to lpr.
3) I'd like to be able to check off a few printer-specific option like fast draft mode and greyscale mode to save paper. If there were a few programmable "memory slots" for such options in the script, I wouldn't mind going into the script to assign the variables containing a label and a "-o" command to lpr for each slot. Similar to #1, you could allow people to enter this stuff in the gui, but I wouldn't rank that as first priority.
4) It might be nice to have an additional place to manually enter -o options for this job (not to be saved for future jobs).
For me, the main use of printing would be pdfs and web pages. I gave a bookmarklet in a previous mail for converting web page to pdf. Unfortunately, it doesn't always work well. For example, it doesn't succeed on gmail messages. Another common case would be printing a map from google maps.
|
|
2009-01-11
, 18:53
|
|
Posts: 16 |
Thanked: 2 times |
Joined on Jan 2008
@ California, USA
|
#26
|
Originally Posted by GeraldKo
This thread so far is about a simple way to print if you have a seperate print server machine that uses the lpr command (e.g. a linux box running cups). We're just sending the pdf or other file to the remote machine and issuing the lpr printing command there. If you don't have another machine to do the heavy lifting, then you need some more substantial software to run on the tablet. There are some other threads (thanks PB) about doing this by running real debian on your tablet or by just installing cups (which is still big and thus may require booting off of a memory card).
Also, are you saying that "lpr" (which is some sort of Unix printing function?) provides a way to print a pdf from the Tablet? (For me, who hasn't figured out how to print from the Tablet, the bookmarklet is useful because it gives me a way to email myself a pdf of a webpage, which I would then print from a computer.)
Does anyone know if there's such an easy way as what we are doing here to talk to a printer shared by a Windows box? That could be a common case for a lot of people. I assume we might have to communicate via samba instead of ssh. Would it make it any easier if the Windows box was running an ssh server?
| The Following User Says Thank You to GraphicsGuy For This Useful Post: | ||
|
|
2009-01-11
, 19:19
|
|
Posts: 291 |
Thanked: 124 times |
Joined on Feb 2006
@ Trier, Germany
|
#27
|
Originally Posted by GraphicsGuy
Sounds like we should work together and open a project on garage.maemo.org
I'd love for you to continue development if you want to (and if you don't, I will). Regardless, thanks for what you've done so far.
__________________
ongo bongo!
ongo bongo!
|
|
2009-01-11
, 19:26
|
|
Posts: 16 |
Thanked: 2 times |
Joined on Jan 2008
@ California, USA
|
#28
|
Originally Posted by GraphicsGuy
To follow up on my own thought, here, if the Windows box runs an ssh server, we could transfer a file and then launch an individual application that knows how to print the file in the background. For example, Acrobat reader apparently has a command-line argument to send a file to a printer without opening a print dialog (but we can presumably only use the default job options). http://support.adobe.com/devsup/devs...docs/52080.htm
Does anyone know if there's such an easy way as what we are doing here to talk to a printer shared by a Windows box? That could be a common case for a lot of people. I assume we might have to communicate via samba instead of ssh. Would it make it any easier if the Windows box was running an ssh server?
However, the Adobe example seems to be talking about a network printer rather than a local printer. I'm not sure if that matters, or if we can also refer to a local printer that way.
|
|
2009-01-11
, 20:12
|
|
Posts: 662 |
Thanked: 238 times |
Joined on Jul 2007
|
#29
|
To run commands over ssh, you could simply use pexpect to put passwords through https://garage.maemo.org/frs/?group_...elease_id=2021
AirX is the most horrid code on the planet, but pexpect is rather well done and practical...
AirX is the most horrid code on the planet, but pexpect is rather well done and practical...
|
|
2009-01-11
, 20:17
|
|
Posts: 16 |
Thanked: 2 times |
Joined on Jan 2008
@ California, USA
|
#30
|
Originally Posted by GraphicsGuy
Following up again on my follow up (sad, I know), here's a Windows batch file that just uses the file association of a file to look up the relevant print command in the registry. So for all file types with a registered print command, it can print it. Then we just have to copy the file to a temp directory on the windows box, launch the batch file with the temporary file as an argument, and delete the temporary file (hopefully it's no longer needed once the print command returns). http://www.robvanderwoude.com/files/printany_nt.txt
To follow up on my own thought, here, if the Windows box runs an ssh server, we could transfer a file and then launch an individual application that knows how to print the file in the background.
Again, the only control over job options here is the printer defaults.
In an ideal world, we might at least figure out if a file with unknown type is ASCII and print it as .txt.
Ironically, a postscript file may require an associated program like ghostscript just to send it to the printer (maybe trying to print as .txt is a really bad idea, in this case)
Last edited by GraphicsGuy; 2009-01-11 at 20:26. Reason: typo
