Looking for the latest version? Download duplex_0_2_3.tar.gz (50.0 kB)
Name Modified Size Downloads / Week Status
Totals: 3 Items   40.8 kB 6
duplexpr 2013-04-28 11 weekly downloads
README 2013-04-28 14.0 kB 55 weekly downloads
Test_File.ps 2010-10-28 26.8 kB 11 weekly downloads
Release Notes - Duplex 0.2.3 - 04/28/2013 Duplex 0.2.3 Minor enhancement release Added kmprb_one - Print ALL one page jobs from print queue. kmprb - Added gui error message if mprb fails Fixed bug that offered hidden files as choices Added -1 option to kmprb to call kmprb_one allowing the user to print ALL one page jobs first. When kmprb is done with that, it goes ahead, as before, to allow printing of the rest of the jobs in the print queue. Improved buttons on dialogs Added --on-top to all dialogs (doesn't seem to help much) mprb - Finally fixed printing of null jobs at one end of odd page count jobs. (Didn't hurt anything, but wasted resources.) Added "FF" to the end of print job numbers for jobs that are just form feeds to get first or last odd page ejected from printer Added FAKE_PRINT_JOB_NUMBER for use with fake lp (not in package) for debuging without printing Fixed lp error detection bug krmpq - Added test for empty print queue Fixed bug that offered hidden files as choices Improved buttons on dialogs Added --on-top to all dialogs pqnext - Made next job number selectable for use with copy and paste Rewrote next file logic to ignore non-numeric file names in print queue Added --on-top to all dialogs mpr, duplex, mprb - Replaced pdf page counting logic using pdfinfo Fixed bug so that print_file_type can handle symlinked print files dplx, duplex - Improved buttons on dialogs Added --on-top to all dialogs If you have a lot of 1 page jobs, the new feature (kmprb_one/kmprb -1) is much faster because it doesn't have to print all the blank even pages first (print strategy 2) and it prints all the jobs as one print job. Duplex (two-sided) printing saves paper, money, trees, and space. Several other utilities are available which provide this functionality, but most require the user to select options in a popup window and are prone to user error. No utility I am aware of will (gracefully) allow a user to print multiple duplex print jobs in a batch. The duplex package is a set of shell scripts for duplex printing. The nature of shell scripts makes them relatively easy to extend and modify. I have tried to use string constants and put system dependencies in functions to further facilitate this. Once the package (tarball) is unpacked, the scripts are ready to use. Just put them in a directory that is in your PATH (e.g. $HOME/bin) so your shell can find them. Several of the scripts use enscript to convert text files to postscript. For this to work correctly, add the following to the file .enscriptrc in your home directory. If this file does not exist, create it. # Defaults for enscript (used by duplexpr package) Spooler: <path>/dplx where "<path>" is the full path of the directory where you installed dplx. For example, if you installed dplx in /home/joe/bin then it would be: Spooler: /home/joe/bin/dplx You may also need to set the default paper type as in: DefaultMedia: Letter (Replace Letter with the page definition for the paper you use.) All of the scripts are optional. Use those that fit your work style. The script names are intended to be unique (should not replace any existing commands on your system), but be sure to verify this for yourself BEFORE installing them. Brief synopsis of the scripts (see duplex.txt for details): dplx - Prints one two-sided print job by setting up the parameters and calling duplex duplex - Prints one two-sided print job mpr - Multiple print duplex jobs - one complete job (both sides) at a time using dplx mprb - Multiple print batch duplex jobs - prints the odd pages of all jobs in one pass and all the even pages in the other pass dprint - Prints one text file two-sided using some settings such as margins, wordwrap, and, optionally, font dprintm - Prints one text file two-sided with a mono-spaced font (for structured text e.g. source code or tabular data,) rmpq - Remove files from the print queue kmprb - gui to preview, print, and then remove printed files kmprb_one - gui to preview, print, and then remove all one page jobs (to speed things up.) krmpq - gui version of rmpq pqnext - gui to display the next available print queue job name (which can be used with copy and paste) General Notes: After installation, the file, Test_File.ps should be printed using dplx. This four page (two sheet) document will show you clearly whether duplex printing is working on your system. A detailed description of how this file printed along with the value of the -ps parameter should be included in any bug reports related to printed output page issues. If the default does not work, try adding -ps 1 as the first parameter and see if that fixes it for your printer. If it does, you can modify the default value in the scripts. I have several notebook computers running kubuntu (currently kubuntu oneiric and precise) with kde4. I have a couple of laserjets and one Photosmart Inkjet printer and three print queues running under CUPS. The Duplex package works well in this setup. I almost feel like I have a new, better printer now that I don't have to flip the output of each job and watch out not to reinsert the last page of odd page count jobs. I wanted this to work as easily as it does under Windows. And now, with mprb/kmprb/kmprb_one, it works a lot better than Windows! Managing your own print queue also has it's advantages. You can print some jobs and, if you like the output, you can then print multiple copies without having to regenerate the print jobs. I routinely look at the print queue before printing (using mprb -i or mprb -I). Sometimes, I see a large job and decide to just delete it if it's something I don't really need. Using a notebook, it's particularly helpful to have a print queue. When the printer is not attached, all the jobs just go into the print queue and are ready to print when the printer is attached *and* when I'm ready to deal with printing. Paper doesn't just start shooting out of the printer as soon as it is attached. It's also very nice to "print" things and just keep working with an uninterrupted workflow without having to stop and attend to the printer every time something needs to be printed. After many jobs have been "printed", then they can be sent from the queue to the printer all at once. If there's a paper jam, or ink/toner runs out, all the jobs are still there to be reprinted. With mprb -pass2, I can even reprint just the second sides of jobs whose pass one output survived the problem. Many computer systems are far more complex than mine. I look forward to others testing the package on systems with networked printers, multiple printers and queues, and shared printers. I think it should work on all of them (as long as no one else is printing to a shared printer at the same time as one of these scripts is printing to it!), but there is no substitute for testing. The code has a couple of system dependencies and I don't know how universally applicable they are. The function ps_page_ct() relies on whatever creates the postscript files to be printed (or enscript, if the files to be printed are text files) to put the postscript %%Pages: nnn line into the file near the beginning or end of the file. So far, it's been in one or the other place in all files I've printed except those printed by Opera. For those, the script counts the number of showpage commands. This method is not guaranteed to work because one showpage command could be in a function or loop and be called multiple times. I have recently seen a document in PostScript 1.6. My page counting algorithms do not know how to handle this format yet (and neither do I! and so it will fail with an error message.) A similar situation exists for pdf_page_ct() with pdf files. It searches heuristically for the largest page count. To get the definitive answer, the script/function would have to use ghostscript to render the complete print file just to accurately count the number of pages generated. That would be way too resource/time intensive to justify on current end user computers. I have added experimental support for PDF 1.5 documents. It works on the few I have encountered so far. PDF 1.6 is not supported (and won't be until I can figure out how to count pages.) The function lp_queue_id() relies on the output of the lp command to contain the queue-job_number in the fourth word of the line. This is too hard coded for my taste, but I don't know another way to do it. Although yad (the tool that provides the gui interfaces) does depend on GTK, I think it should run fine on other window managers and desktops. I use it under KDE with no issues. If not, a console-only version of the scripts would be easy to write, but it wouldn't be quite as user friendly. The code is written for the way an HP Deskjet printer (page handling strategy 1) or an HP Laserjet P1006 printer (page handling strategy 2) handles paper. It also gets it perfectly for my HP Photosmart C4480 (page handling strategy 1). The Laserjets now print all the pages correctly using page handling strategy 2. To get this to work for all printers may requre a rewrite because one size doesn't fit all. It will probably require at least four (maybe 16) printing strategies to cover most printers and for now, there are only two. (But Hey, that's twice as many as in version 0.1.3) If another printer works differently, all the same components of the code should still work with some rearranging of the sequence. The Deskjet prints such that the output stacks printed face up with the most recent page on top. To print the reverse side, all pages are manually removed, rotated 180 degrees horizontally and reinserted into the in paper tray. The Laserjets print such that the output stacks printed face down with the most recent page on the top. To print the reverse side, all pages are manually removed, rotated 180 degrees horizontally and reinserted into the in paper tray. The way I use the system is: As I'm browsing the Internet or doing other tasks, I use "Print to File" for most things and put them all in one directory ($HOME/pq) with file names like 01, 02, 03, .... (File names ending in .ps or .pdf now work fine as well.) That keeps the print jobs in the same order I generated them in. Then, when I'm ready, I just cd to that directory, do an mprb -I * to see how much I'm going to print (and if I need to modify the print order to put some small jobs ahead of large ones, etc.). Then, I usually let it go ahead and print the whole queue. When it's done and checked, I use rmpq to delete the files in the print queue. When I have a lot to print, I just use shell glob expressions to specify which files to print and then rmpq. E.g. mprb -I 0* or mprb -I 0[123] . For anyone interested, I aso have an AutoKey macro available (not included in the duplex package) which is tied to ctrl-p for Firefox and Thunderbird. It automagically selects print to file and fills in the next available print queue file name. Then it ends so that other print dialog options can still be selected. Now that I have kmprb, I have added an icon for it to my panel (task bar). Once I have generated the print files as above, usually, I just click on the panel icon and let kmprb do the rest. That way, I can stay focused on what I am doing because I don't need to navigate through any menus or switch to a console window on another desktop. I also have an icon for pqnext in my panel, so I can get the next print queue file name for manual use with applications other than Firefox or Thunderbird. These icons are not added to the panel by installing the duplex package. It must be done manually. Sometimes, I do an mprb -i * first. If there are any one-page print jobs, I print them all directly with one lp command (very fast) and then delete them. Then, I print any remaining jobs with mprb. With this release, I can do that automatically just by using kmprb -1. This is especially useful if you use print strategy 2 which will print all one page jobs as blank pages during pass one because it prints even pages first and there aren't any. (The script doesn't look ahead, so it doesn't know that in advance.) In real life, printers run out of ink, occasionally jam, and feed multiple pages at one time. To handle this eventuality, mprb only prints one job at a time during pass two (where jams, and especially multi-feeds are more likely) so it can be killed without having to remove a number of jobs from the system print queue with lprm. mprb also has a -pass2 option so that, after a jam, any jobs which still have good pass one output (all sheets with just one side printed) may be reinserted into the printer to print just pass 2 (the other side of all the sheets). Now, with faster processors and printers and big print buffers, this doesn't work as nicely as it used to, but if this is a problem, it would be easy to add an additional delay between pass 2 print jobs. I am also including a few gui apps. They work, but are hard coded to expect the print queue to be in $HOME/pq. kmprb is a gui which does it all. It displays all the files in the print queue along with the number of pages each will generate. Next, it allows you to select which files to print and prints them. Finally, it allows you to select which of the successfully printed files to delete. (Presumably, they are not needed any longer once they have been successfully printed.) kmprb_one is similar to kmprb, but it finds and prints ALL one page jobs very quickly. krmpq allows you to select those print files you want to delete once they have been printed. pqnext pops up an information dialog with the number of the next available print queue file name along with a count of jobs and and pages in the print queue. This is useful for manually specifying the file name in applications.
Source: README, updated 2013-04-28