> We also use HylaFAX, but this has little to do with Samba. You require > a client for Windows in order to give users a decent experience, I > recommend HylaFSP (which is a commercial product, but reasonably > priced). There are several Win32 clients, most of which don't really > stand up to regular use. > [Mitch says:] We did something similar "back in the day"... and we did it by creating a simple standard - the first phone number - or perhaps the first phone number in a certain font - was the destination phone number...
As long as you are working from a template doc, this is easy to keep users consistent about - all we did was grep for the first phone number pattern, and extract it for the "to". > > >[Mitch says:] >One of you had: > > >[Mitch says:] > lpq command = lpq -P'%p' > > >[Mitch says:] > lprm command = lprm -P'%p' %j > > >[Mitch says:] > lppause command = lpc hold '%p' %j > > >[Mitch says:] > lpresume command = lpc release '%p' %j > > >[Mitch says:] > queuepause command = lpc stop '%p' > > >[Mitch says:] > queueresume command = lpc start '%p' > > >[Mitch says:] >And one had only lpq and lprm with nothing after the = - > I > > >[Mitch says:] >tried both ways?!?! > > >Further to my other email... The common important element is the line: > > >print command = /usr/local/bin/pdfout1.sh %s %u %m %I > > >When I look at the calls to "lpq -P'%p" etc, they all return errors as > %p's > > >value (the printer share name) is not defined in printcap > > Sure. You can replace those lpc calls with scripts or just try echo > statements. All samba does is grab standard out and the return code. > [Mitch says:] ok - I understand the theory, but if your print command doesn't submit to lpd, and your printer is unknown, may would the lpq ever show any contents? Without using lpd to manage the queue, it doesn't seem to make sense to use the other components to report stop and start and empty queue that was never running to begin with - does it? > > >Perhaps somehow I should be using lpd to call the script? > > No. [Mitch says:] What actually processes the queue then? The samba man for the print command seems to indicate it would normally be used for submitting the job to the queue for handling, but we aren't doing that - does that mean that there is no limit on simultaneous prints? > > To create a proper queueing process and serialize the conversions? > > > Otherwise couldn't I > > >experience the "print-of-death" from my users as 100 of them start to > print > > >a PDF all at once? > > You can nice the script. [Mitch says:] Not sure what the effect of that would be with fast server and workstation with low load... Last night I already got the first expected error (I lost print jobs cause I printed too fast) - but my other concern was for samba's server ability to simultaneously process the load of a large number of simultaneous prints... (btw: I generated the fast print jobs really simply - I pdf-printed an internet explorer page with frames - the default is one print job per frame... there were 4 frames, but I only got 4 print jobs when the server was under enough load to slow the printing down so the total process took more than 4 seconds...) I don't think I want to nice the script, I think I want to somehow allow them to queue so they can be pdf'd asynchronously. Hope I'm explaining better. Thanks! m/ -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba