cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Send directly to printer....?
Date Sun, 19 Jan 2003 01:50:05 GMT
Hi Dale:

Thanks for your explained answer. I will use all the tips you advised
here. Its is a very fine description of the problem and your effort in
this area. Surely it will save me many time trying it. Many thanks again.

In my concrete case we can make use of some of the approach you suggested
here. My requirements are:

1-All the users are MS IE fans. It is a controlled LAN environment. They
only use MS IE 5.0 and grater.

That means I did not take care of how old NS4 and the new Mozilla at all
address this issue. But of course the correct way is to find a solution
that can apply to all browsers. But I have until tuesday morning to give
an answer.

2-I need to control that the user is able to print only once the document:
This is a Web Database application (WeDBA) where the user must be able to
print a coupon just one time. If the printer make some error, then we mark
the coupon as invalid and create a new one.

Currently approach was to present a PDF doc and let people manually print
the doc using Adobe Acrobat Reader. But since we had detected one "smart"
user that printed the coupon 2 times. Now the user's chief is asking for a
way to control the print of the coupons. He asked to let print only once.

I was thinking in a Java Applet that will control the PDF doc and let just
one printing. But after searching on the Internet I found that this
solution is more complicated because of the security concerns about the
applets.... Well, it will be more complicated to install applets on each
client, give to the applet the permission to print and so on.

All this Java Applet solution was discarded because will add complex in
the mantainement of the user base. We will return to the client-server age
where after a client upgrade you need to upgrade all your client base.
This is not acceptable to us. Then it was discarded.

Then after thinking a little more about another solution I was started to
think in a Javascript solution. This looks eaier and elegant because only
need to open another window (can be very little) and after loading the PDF
doc in the new window, can be printed and closed.

If the user will press the print button from the main window for second
time it will not work because the XSP page that generate the PDF also set
a flag to "printed" for every coupon in the PDF doc. This PDF doc can
contain more than 1 page (I saw some print jobs of 300 pages).

The link that give me the idea for window.print is:

I will inform you about my progress in this area.

Best Regards,

Antonio Gallardo

Dale Frye dijo:
> A word of caution here:
> This will only work with some browsers: The problem I had (I can't
> remember if it was with IE 6 or Moz, but I think it was Moz) was that
> the print function would return immediately and the close function would
>  then close the window before the window actually printed (the print
> dialog never displayed). It ended up that I didn't need to start the
> print automatically so I removed it from the code but I think I had it
> working.. My first solution was to use a timer to call a function to
> close the window. I seem to recall that I may have used two timers. The
> first timer gave the print dialog a chance to grab the thread. Once the
> thread returned the attached function would be called and would start
> the second timer. This timer gave the browser time to get the actual
> print process started. Finally the second function would close the
> window. I can't remember if this was exactly what I found and what other
>  problems I may (or may not) have had. The timers were not very long,
> less than 1000ms.
> Another solution I recall (however it won't help you with your PDF) was
> to make the called window responsible for printing and closing itself on
>  the onLoad. (I found some old code that did this on the page I was
> wanting to autoprint.) I guess the race condition didn't exist here. I
> just don't remember.
> FYI: All these methods will cause a new window to appear for a few
> seconds and then disappear. This can startle the user. I used the width
> and height attributes on the open function to make this window as small
> as possible but it will still be visible.
> I just had a wild idea. Would this work???? It would get rid of the new
> window problem (I have NOT tested any of the following. No clue if it
> actually works!)
> Create a hidden IFRAME anywhere on the page:
> <div style="display:hidden; "><iframe name="hiddenframe"></div>
> <!-- found (the hard way) some browsers (IE) won't hide IFRAME directly,
>  therefore surround with <DIV> -->
> <script language="Javascript">
> function doPrint(printpage) {
> document.frames.hiddenframe.location.href = printpage
> // I think I read somewhere this (in the next statement),or something
> like it, will wait until the page is loaded.
> // Other concern would be if you printed the same page twice. Would the
> href need to be cleared manually?
> // Of course if you knew what page would print at the creation of this
> page on the server you could just put it in the IFRAME
> // tag above and skip everything here except the actual print statement
> below.
> while (document.frames.hiddenframe.location.href != printpage) {
> // should put in some code to time this out if page never loads
> }
> document.frames.hiddenframe.print()
> // could have race condition here, it could put the IFRAME state back
> before the print takes place
> window.back() // put the history list current page pointer back since it
>  was modified when the IFRAME was dynamically loaded
> }
> </script>
> Would that just print what's in the IFRAME???? If you try this please
> post results back to the list.
> This won't work with NS4 (it doesn't support IFRAME). Maybe could try
> using frames and make one frame real small. Access this frame from
> another like:
> parent.frames.smallframe.print()
> Of course this introduces some potential problems caused by frames 1:
> FRAME (but not IFRAME) shows the URL of the frame page, not the
> displayed page, in the address bar (as user moves from page to page the
> URL in the address bar doesn't change.
> 2:: if you dynamically load the page using Javascript then the browser
> history list is updated. Can cause unexpected results (appears that
> button didn't work) when the user uses the back and forward buttons.
> All right, somebody hit me. I just don't know when to shut up.
> Dale Frye
> Antonio Gallardo wrote:
>>I mean on the cliente. I was ”researching” and found a solution using
>> javascript:
>>This are not the exactly commands, but it can work. I will try it. But
>> if you know another solution, please let me know. :-)
>>Best Regards,
>>Antonio Gallardo
>>Geoff Howard dijo:
>>>Do you mean a printer on the client, or the server?
>>>>-----Original Message-----
>>>>From: Antonio Gallardo []
>>>> Sent: Saturday, January 18, 2003 2:55 AM
>>>>Subject: Send directly to printer....?
>>>>Is there a way to send a document directly to printer?
>>>>I am using XSL-FO and serializing to PDF. But now I need to send a
>>>> document directly to printer without presenting it first in the
>>>> client browser first. Is there a way to do that?
>>>>Thanks in advance.
>>>>Antonio Gallardo.
>> Please check that your question  has not already been answered in the
>> FAQ before posting.     <>
>>To unsubscribe, e-mail:     <>
>> For additional commands, e-mail:   <>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <>
> To unsubscribe, e-mail:     <>
> For additional commands, e-mail:   <>

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message