averylongloginname has asked for the wisdom of the Perl Monks concerning the following question:

Is there a way to control how a document generated by Perl CGI is printed from a web browser (page breaks, line feeds, etc...)? I'm aware that each user can change 'page setup' options in his/her browser (margins, header, footer), but I was looking for more control. I was actually trying to print address labels - that's not the hard part, but determining where each page is going to break can get nasty if I have a large number of labels to print. thanks in advance (first time writer by the way...woo hoooo..DOHH!)
  • Comment on Is is possible to control how a printer functions from a browser?

Replies are listed 'Best First'.
Re: Is is possible to control how a printer functions from a browser?
by KM (Priest) on Dec 09, 2000 at 03:51 UTC
    You could always add a link such as 'Printable Version of this Page', and in the background produce a PDF version of the HTML page in a nice printer-friendly format for a user to print. I have done this before for large reports within HTML noone would want to have printed with the report.

    Cheers,
    KM

Re: Is is possible to control how a printer functions from a browser?
by AgentM (Curate) on Dec 09, 2000 at 00:49 UTC
    Actually, I'm glad arbitrary HTML/Jscript has no access to external devices. That would be a blatant security hole, even if the user is prompted. An easy way to force someone to restart the browser or even the computer is loop an alert(). Imagine if any Jscript could ask you to print. I can only see disastrous and not very useful effects. You would be prompted constantly to print out ads and coupons left and right. Really lame. if you want something to be easily printable on various platforms without hassle, try the pdf format. Acrobat Reader is readily available as a plug-in for browsers. Try libpdf and Inline to throw 'em into Perl.
    Update: I think that gharris' complaint is a common one. While HTML is human-readble, it is not easily well-formatted, especially with the differences in browsers these days. The simple fact remains that HTML serves its function poorly to a graphical deisgner who wants to gets some clickable images up and running fast. The situation becomes even more complicated when the designer wants to print something nicely- perhaps inserting two-pixel widths of space and a legal page size. HTML's answer is "Sorry." While adding more and more tags is alwasy an option, I think we notice that HTML is more than bloated already with various exceptions and browser inconsistencies. The solution? Don't use HTML.
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
      WARNING: This is a rant. This is only a rant.

      Actually, HTML's answer is more "I wasn't designed to do that". In fact, HTML's design choice was "I have no damned way of knowing what the user's screen is like, what they like, etc. I let the USER decide what they want things to look like". HTML is not a graphic layout language, it was never intended to be used that way. Getting this layout control is, basically, wedging a square peg into a round hole.

      I do agree, though, that if you want a language in which to do graphic design and layout, HTML is a very poor choice. The proper tool for the job at hand. I don't know what the right tool is, but it most certainly is not HTML.

      This rant brought to you by
      mikfire

      While I agree that the developer should not have direct access to the printer (as in being able to initiate a print), I like where IE is headed (hopefully) in letting the developer specify page-breaks and page formatting.
      I think it would be just grand if when you specified a <thead> and a <tfoot> that they would be printed as such, and it would let you say 'print landscape, with no margins'.
      Working in an environment where reports are generated for everything and anything that they can find numbers for, being able to control print formatting would make the web that much more valuable.

      --Glenn

      Agent M asks
      Imagine if any Jscript could ask you to print.
      ---

      <A HREF='Javascript: window.print()'> Click me!</A>
      Depending on how things are set up, maybe it'll ask you to print, maybe not. I'll let you ponder the mouseover abuse :)

      update I didn't show this to truly annoy anyone, but simply to show that it was possible. I've change it from an actual link to just text. Apologies to anyone bothered by this.

Re: Is is possible to control how a printer functions from a browser?
by gharris (Beadle) on Dec 09, 2000 at 00:38 UTC
    AFAIK, IE 5.x is the closest you are going to get, in that it fires an onbeforeprint and an onafterprint event.
    I remember some rumors about being able to control other printer properties through script in IE 5.x as well (layout, paper size, etc) but after a couple quick searches through MSDN I was only able to find info on the events.
    Printers and the web just don't seem to like each other too much yet...

    --Glenn

Re: Is is possible to control how a printer functions from a browser?
by Fastolfe (Vicar) on Dec 09, 2000 at 01:57 UTC
    CSS2 permits much finer control over the various media types used to render content, including a "print" media type. See http://www.w3.org/TR/REC-CSS2/page.html for information on using CSS specifically for "paged" or printed renditions of content. I have no idea how well (or if) these things are supported in any browsers, though.

      It is a shame but CSS2 is still not supported enough... especially by netscape. However, CSS2 and CSS3 when they come out will make browsers more graphic and layout friendly. Still, there is the problem of printing... one that has never really been covered by the browser manufacturers. Netscape, for example, will adjust the layout of a page so that layers don't overlap before printing it and, in both cases, the quality of the printing is too low for graphics. This makes it very hard for people who want to design interactive, graphics based programs for the net.

      If I sound disgruntled its because i spent about 2 years doing exactly that... and never quite got the results I wanted :P