Software Gurus - assorted questions

[DonMan]

I'm in the process of writing a new front end to replace the VB6 one I wrote for this company: http://pmkeepsakes.com/index.html
Their system will consist of one or more Windows 7 machines, along with a few older XP machines that we'll use as workstations.

I had been planning on using a simple Apache-PHP platform. They're using an old version of Access which will eventually need to be replaced, but it will be easy enough to write the new system to make that transition without any issues. When it's time to convert the database, I'll go with MySQL unless I can find a good reason to use something else.

They have some printing issues that I'm not sure I'll be able to handle with what I had initially planned. The most straightforward way via Apache-PHP is to have PHP generate PDF files and have the client print them. We may run into quirks with different PDF reader software on different platforms, among other issues. They also have some documents that they'll always want to print multiple copies, which could get clumsy with that setup.

If I instead do all the printing server-side, all those issues go away. I can use Apache Tomcat as my platform, and have Java Servlets that do the actual printing. The documents themselves are pretty basic - just plain text of about a dozen data fields per report.

In theory I could have Tomcat just as my "print server" and use Apache-PHP for everything else. IMO it makes more sense to put the whole thing under Tomcat. It's a little tedious to setup all the mapping for the servlets and whatnot, but it's really not much more effort to do that work for 20 pages instead of 10.

So, my questions (for now) are:
- Has anybody here used Apache Tomcat? I tinkered with a previous version a few years ago. I believe it can handle my requirements, but I've never even written a modest-sized test site on it.
- Are there issues with my server-side printing solution that I've failed to notice/address? From my perspective, it seems too easy, so I must be missing something.

[Daemon]

I know we used Tomcat at one of the places I worked and it was well-liked from memory. I was not an admin on it though so I can't answer your specific questions about it.

[DonMan]

Well, it's good to know that somebody has used Tomcat. Maybe there will be others here that can provide additional feedback.

[Augustus]

They have some printing issues that I'm not sure I'll be able to handle with what I had initially planned. The most straightforward way via Apache-PHP is to have PHP generate PDF files and have the client print them. We may run into quirks with different PDF reader software on different platforms, among other issues. They also have some documents that they'll always want to print multiple copies, which could get clumsy with that setup.

I don't get the part about different PDF reader software. Are they really using PDF readers other than that provided by Adobe? Even so, the whole appeal of PDF is that the format displays documents consistently regardless of application software or OS platform. Also, is it really clumsy for the user to select number of copies in the print dialog box?

You say "the documents themselves are pretty basic - just plain text of about a dozen data fields per report." If you adhere to the latest HTML5/CSS3 standards in your client-side code, you should be able to provide for consistent and nicely-formatted html documents, and avoid having to generate PDFs altogether. Of course, that is assuming the client is using a fairly modern browser that supports CSS3. Using those standards would provide the additional benefit of helping to future-proof the web app and make future maintenance easier.

Perhaps I'm just not understanding the client's needs, but I wanted to ask these questions because it seems to me that writing Java servlets and configuring Tomcat just to print out some reports, because the client hasn't upgraded browsers on a couple of legacy PCs, might introduce an unnecessary level of complexity and result in higher maintenance cost to the client over the lifetime of the application.

http://www.php.net/manual/en/functio...set-option.php

[DonMan]

Thanks for the feedback.

With PDF, I'm concerned about issues like how the document might get scaled to fit the page, and what margins the software thinks the printer/paper has. I know when I've tried to print PDF documents via an Adobe browser plugin, it didn't always come out the same as when I saved the PDF to my hard drive and opened it directly via the Adobe reader.

One issue I failed to mention is that on some of the documents, I don't have (pardon the pun) much margin for error. If the printer decided that the margin was a 1/2 inch or even 1/4 inch different, it might not fit everything on the label.

I'm not even sure how I would do something like this via HTML5/CSS3. How would I be able to precisely place the fields on the document? How would things like page scaling and margins work? Some of the documents print on regular size paper, others print on a smaller label printer.

The owner told me they're shipping upwards of 200 pieces a week now. So there will be days that they'll be printing easily 50 and possibly upwards of 100 documents per workstation. Any unnecessary steps will get annoying pretty quickly. (in fact, already have with the old system I wrote for them)

Reading the fine print, your link is a good example of why I'm not considering PHP for server-side printing. The printer functions for Windows in PHP are somewhere between unsupported and never worked to begin with.

[Augustus]

I'm not sure why you observed differences when sending the same PDF document to the same printer. The entire purpose of the format and what makes it so ubiquitous is standardization across applications and platforms.

CSS3 and rapid standards adoption by browsers makes precise placement much more achievable than it was two years ago. IE even fixed its infamous box-model bug (at least when running in standards-compliance mode). CSS doesn't have to measure in 'px' or 'em'; it can specifiy measurements in real-world units like 'in' or 'cm'. CSS rules can specify page margins, label sizes, gutter widths and page breaks. Here's an article of a guy using html and css to print on Avery 5160 labels: http://boulderinformationservices.wo...-css-and-html/.

The only thing of interest in the PHP man page on the printer_set_option printer function I linked to earlier is the printer_copies option, with which you might specify number of copies to print. I envisioned visual display and printing specifications as being contained in html and css, with PHP used only to fetch your dataset.

If you eliminate html/css as an option in favor of handling everything server-side, I don't see why PDF wouldn't be a natural alternative. There are numerous PHP=>PDF generators that might be simpler than going through all this: http://php.net/manual/en/book.pdf.php. PHP=>PDF is server-side, and PDF should be consistent.

I understand there are challenges, but I don't see which challenges are eliminated by going to Tomcat/Java, unless you just like coding in Java, in which case that choice makes all the sense in the world. Wouldn't you still have the same issues regarding precise placement, margins, number of copies, etc., or do you have in mind a servlet that has all that stuff built in?

[DonMan]

Thanks for the additional feedback.

Generating the PDF wouldn't be the issue via PHP, getting the document to the printer (server-side) would. Based on what I've read, there isn't any reliable way in PHP under Windows to do things like generate a list of available printers, or actually print a document. These things are easy in Java. Issues like margins are a lot easier to handle with Java directly connecting to the printer (and classes/methods for all of this) as opposed to a 3rd party application that may or may not have the precise margins you're expecting.

Whether I generate a PDF via PHP, or a plain text document in Java, the logic for building the document itself will be very straightforward. I'll just build a simple database table that lists all the fields for each report - x, y, font, and anything else I happen to need. Then the logic will loop through the list and plop all the values into the print image. I suppose in theory I could accomplish the same thing via CSS - I would either need to hardcode everything or dynamically generate the CSS - neither alternative is appealing to me. That link was interesting however - I think that 5160 might be one of the labels they're using. Of course, if my client had to set the margins every time they printed that would be a royal pain in the ass.

I've looked into reporting tools I could use, in particular something called JasperReports. My opinion as of now is I haven't found a tool that won't be more trouble than it's worth.

[Augustus]

If I were going the html/css route, I would not dynamically generate the css. I would have a hard-coded css file for each document type (ie. letter_portrait.css, letter_landscape.css, legal.css, avery5160.css, etc.), and then only dynamically include the appropriate style sheet. You could put the rules into the db as you described, but I generally like to avoid puting presentation in a database, preferring to use it only for storage of real data. It's as easy to update a CSS file as a database record.

I would think that document print layout can be specified using either CSS3 or PHP-generated PDF with as much granularity as can be achieved using Java servlets, but then I don't know a thing about Java, so I might be wrong. I'm not even sure what you mean by "Java directly connecting to the printer," and talk about generating a list of available printers sounds like you want to perform some network discovery on the fly to find available devices, which I didn't anticipate.

I'll be interested in hearing what solution you employ, and how it works out.

[Mongo Freebase]

If I were going the html/css route, I would not dynamically generate the css. I would have a hard-coded css file for each document type (ie. letter_portrait.css, letter_landscape.css, legal.css, avery5160.css, etc.), and then only dynamically include the appropriate style sheet. You could put the rules into the db as you described, but I generally like to avoid puting presentation in a database, preferring to use it only for storage of real data. It's as easy to update a CSS file as a database record.

What...are you some sort of expert??

[DonMan]

If I were going the html/css route, I would not dynamically generate the css. I would have a hard-coded css file for each document type (ie. letter_portrait.css, letter_landscape.css, legal.css, avery5160.css, etc.), and then only dynamically include the appropriate style sheet. You could put the rules into the db as you described, but I generally like to avoid puting presentation in a database, preferring to use it only for storage of real data. It's as easy to update a CSS file as a database record.

Not from my perspective. If it's in a database, I can write a simple page/script to display all the information and perform updates. I was planning on keeping an Apache/PHP server around just in case I wanted to do a little task such as this without having to setup a bunch of Tomcat mappings.

If it's in a CSS file, I've got to do all of that by hand.

I would think that document print layout can be specified using either CSS3 or PHP-generated PDF with as much granularity as can be achieved using Java servlets, but then I don't know a thing about Java, so I might be wrong. I'm not even sure what you mean by "Java directly connecting to the printer," and talk about generating a list of available printers sounds like you want to perform some network discovery on the fly to find available devices, which I didn't anticipate.

I'll be interested in hearing what solution you employ, and how it works out.

Here's a summary of Java printing capabilities:
http://java.sun.com/j2se/1.4.2/pdf/JPS_PDF.pdf

Java is a general purpose language that was being used for standalone desktop applications 15 years ago. So there's plenty of built-in classes for things like looking up what printers are available and that sort of thing. The code "won't know" that it's running on a server as opposed to a standalone desktop. I won't tell if you won't.

[Augustus]

If it's in a database, I can write a simple page/script to display all the information and perform updates.
...
If it's in a CSS file, I've got to do all of that by hand.

I don't understand. You have to input and update the rules somewhere -- a database record, or a flat css file. Why would it be easier to modify style rules via a database update, rather than editing a css file -- to avoid the need for ftp?

Here's a summary of Java printing capabilities:
http://java.sun.com/j2se/1.4.2/pdf/JPS_PDF.pdf

Java is a general purpose language that was being used for standalone desktop applications 15 years ago. So there's plenty of built-in classes for things like looking up what printers are available and that sort of thing. The code "won't know" that it's running on a server as opposed to a standalone desktop. I won't tell if you won't.

That sounds like a cool solution.

[Augustus]

What...are you some sort of expert??

I don't like to like to talk about myself much. You should probably ask your wife.

[DonMan]

I don't understand. You have to input and update the rules somewhere -- a database record, or a flat css file. Why would it be easier to modify style rules via a database update, rather than editing a css file -- to avoid the need for ftp?

No, to avoid the need for manually editing a CSS file, where there's lots of room for human error. I'm probably going to need a means of listing all the entries for each report anyway just for troubleshooting purposes. I'll build a simple page for that, and have it double as a data-entry form, where I can tweak the values as needed. Throw in one more button on that page to generate a test report, and I have everything all in one place for basic development and testing. It will be so easy to use even the computer-illiterate customer will be able to tinker with things like precise field locations and fonts if he wants to.

That sounds like a cool solution.

Assuming I can actually get it to work.