Re: web based applications and PRINTING
On Wed, 2004-10-20 at 19:12, Horst Herb wrote:
Unfortunately, the Australian prescription forms are provided by the
govermin. They have a serialnumber printed across the back and we are not
allowed to print these script forms ourselves, just to fill them in.
Arrrgh!
As an aside and TOTALLY off topic.are physicians responsible for a
block of serial numbers over a period of time?
It's not the PDF generation on the server that takes time, it's the process of
PDF-via-browser printing that is the time and interaction consuming PITA.
Point well taken.
What I need is a single print button which, once pressed, starts sending
output to the printer within a second without any further need for
interaction - because that's what my desktop software does, and that's what
my colleagues expect. They won't accept any less.
What format are these prescription forms in; sheets or tractor feed? If
in sheets I assume they are one per page?
I wasn't able to achieve that with PDF, and if anybody can point me into the
right direction with CSS, I would be grateful.
An example printing just test string absolutely positioned 40 mm from the
left page margin, and 60 mm from the top of the print margin would do.
When I use the absolute positioning in CSS like :
div.box {position: absolute;
left: 50mm;
top: 60mm;
width: 100mm;
height: 20mm;
padding: 5mm;
font-size: 4mm;
}
DIV class=box
This text goes in the box
/DIV
and print it with different printers (all with the same pagemargins set), I
get different positions on the paper.
Right. This reminds me of the days when we had to write (or link)
printer drivers for every application/printer combination. It isn't
just variability of the software but every printer is different as well.
If you *must* use a browser for a client and you can't live with PDF or
Postscript generation on the fly. Then you should look at workflow
modification so you can live with PDF/Postscript generation/printing
timeframe. This is a very realistic option if you show that overall you
are still gaining through the use of IT.
You have likely seen this (and similar articles):
http://www.alistapart.com/articles/goingtoprint/
I believe you'll still have variability in printers when it comes to
absolute positioning. Though these techniques may give you good
referential positioning, getting that top left corner correct is quite
difficult.
I think CSS is the wrong tool for this job.
Cheers,
Tim
Re: web based applications and PRINTING
... the Australian prescription forms are provided by the govermin. They have a serialnumber printed across the back and we are not allowed to print these script forms ourselves, just to fill them in. England and Wales' NHS prescriptions are provided, nowadays as single sheet and with a serial that includes a terminal check digit. I've found that one has to write positioning for each printer and it works well if one sends the text to it, as though it is a file. I don't imagine that is easy to do with a browser. There is a picture in http://www.defoam.net/writing/usability.fp10.html I suppose producing a config file that describes the elements of a prescription and gives the coordinates to put them on would allow some generalisation of these things. -- Adrian Midgley Open Source software is better GP, Exeter http://www.defoam.net/
Re: web based applications and PRINTING
On Tue, 2004-10-19 at 05:29, Wayne Wilson wrote: I hate to say it, but we gave up on HTML based printing and moved to PDF. For our programmed apps we use the output from the apache FOP project: http://xml.apache.org/fop/ The use of Latex maybe the way to solve this issue. The development of conversion tools allowing single or multiple HTML to Latex conversions will get the files in a format meant for printing. http://html2latex.sourceforge.net Conversion of latex PS to pdf is much better than HTML to PDF. Just to add to the list.a very good FOSS PDF library for Python apps is ReportLab http://www.reportlab.org/ HTH, Tim ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Re: web based applications and PRINTING
On Tue, 19 Oct 2004 16:26, Denny Adelman wrote: This technical hurdle doesn't really exist anymore since (most) standards are fairly well integrated now and new ones have evolved rapidly to keep pace with needs. (There is no technical reason why a printer-friendly version of a dynamic page can't be generated with the 'media=print tag in a CSS header coupled with an appropriate style sheet). I haven't managed yet to accurately fill in the mandated Australian prescription forms via CSS - it requires absolute positioning relative to page margins, and how would I do that consistently? Currently, I am generating PDFs on the fly, which is a PITA. Thankful for any advice. Horst
Re: web based applications and PRINTING
On Wed, 2004-10-20 at 18:19, Horst Herb wrote: I haven't managed yet to accurately fill in the mandated Australian prescription forms via CSS - it requires absolute positioning relative to page margins, and how would I do that consistently? Currently, I am generating PDFs on the fly, which is a PITA. Thankful for any advice. I can send you then code that I used (originally written by a contributor) in TORCH to fill in the HCFA 1500's as an example of how ReportLab handles it. That is of course still generating them on the fly but with reasonably fast machines and keeping your PDF reader open all the time it is quite fast. This actually duplicates the entire form instead of printing to one. I used to do it using pre-printed forms but color printers are readily available so the scan-able red-lines are easy enough to print. Maybe you could do the same with your script forms? HTH, Tim
Re: web based applications and PRINTING
On Thu, 21 Oct 2004 11:37, Tim Cook wrote:
This actually duplicates the entire form instead of printing to one. I
used to do it using pre-printed forms but color printers are readily
available so the scan-able red-lines are easy enough to print. Maybe you
could do the same with your script forms?
Unfortunately, the Australian prescription forms are provided by the
govermin. They have a serialnumber printed across the back and we are not
allowed to print these script forms ourselves, just to fill them in.
It's not the PDF generation on the server that takes time, it's the process of
PDF-via-browser printing that is the time and interaction consuming PITA.
What I need is a single print button which, once pressed, starts sending
output to the printer within a second without any further need for
interaction - because that's what my desktop software does, and that's what
my colleagues expect. They won't accept any less.
I wasn't able to achieve that with PDF, and if anybody can point me into the
right direction with CSS, I would be grateful.
An example printing just test string absolutely positioned 40 mm from the
left page margin, and 60 mm from the top of the print margin would do.
When I use the absolute positioning in CSS like :
div.box {position: absolute;
left: 50mm;
top: 60mm;
width: 100mm;
height: 20mm;
padding: 5mm;
font-size: 4mm;
}
DIV class=box
This text goes in the box
/DIV
and print it with different printers (all with the same pagemargins set), I
get different positions on the paper.
Horst
Re: web based applications and PRINTING
On Oct 19, 2004, at 1:52, Calle Hedberg wrote: Secondly, the posting from Will Ross re printing reminded me of a major problem we've had with certain web apps: The lack of proper control over final lay-out when you print stuff over several pages. Web printing is notoriously difficult, of course, due to the fact that HTML is so oriented towards display. Fixed web pages often have printer friendly versions, but this is more tricky with dynamically created web reports etc. Calle, Web printing 'was' notorious difficult for quite awhile, from the developer's point of view as well as the user's. The primary reason was at first the lack of tools at the disposition of the webscreen designer, then later, the lack of faithful implementation of CSS (cascading style sheets) standards by the browser makers (ie, IE). This technical hurdle doesn't really exist anymore since (most) standards are fairly well integrated now and new ones have evolved rapidly to keep pace with needs. (There is no technical reason why a printer-friendly version of a dynamic page can't be generated with the 'media=print tag in a CSS header coupled with an appropriate style sheet). It's figuring out the best way to design for the user's ease and various needs that still needs to be better understood by techies. Denny Adelman
Re: web based applications and PRINTING
Web printing 'was' notorious difficult for quite awhile, from the developer's point of view as well as the user's. The primary reason was at first the lack of tools at the disposition of the webscreen designer, then later, the lack of faithful implementation of CSS (cascading style sheets) standards by the browser makers (ie, IE). This technical hurdle doesn't really exist anymore since (most) standards are fairly well integrated now and new ones have evolved rapidly to keep pace with needs. Couple of months ago I tried to use CSS instead of nested tables to control simple text placement. No way could I do that -- then current (Aug '04) IE and Mozilla (also tested Opera) implemented basic CSS text positioning differently. Hair pulling out time and/or beating head against wall time. I'm guessing everyone is still using nested tables to position text as a least common denominator instead of doing it the correct CSS way. Anyway, I'm flagging that CSS is not at all implemented consistently across browsers. I'm not saying that by using some subset of CSS that you couldn't get it to work to print pretty pages, but if you go into CSS cold with a book in hand about how you are supposed to format pages with CSS be prepared for a rude awakening. Heitzso
Re: web based applications and PRINTING
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Calle Hedberg wrote: | | Web printing is notoriously difficult, of course, due to the fact that | HTML is so oriented towards display. | . | I presume many others have faced similar problems - anybody know of FOSS | solutions that are simple and robust without requiring a lot of fiddling | by users? | How about a lot of fiddling by the programming staff plus some work by the help desk? | | We have considered using intermediate formats like PDF (save HTML to PDF | and then print the PDF), but it's a hassle. | I hate to say it, but we gave up on HTML based printing and moved to PDF. For our programmed apps we use the output from the apache FOP project: http://xml.apache.org/fop/ For our commercial apps, mainly reporting, pdf is mandatory requirement. Having said that, PDF is a pain in the butt. It seems every version of Acrobat and Acrobat reader combined with every version of IE and other browsers, yields different results on whether in-frame rendering works reliably or not. Thus some users have acrobat as a helper app, and others have it as a built-in! So this is not really a good way to reduce end user support calls to the help desk, unless you have a standard desktop image that you know works! But, that is par for course with other issues as well. We have come to the conclusion that the only alternative to lower help desk calls while still using desktop applications is to have a standard image install of pre-tested and integrated software. I find this interesting because that's exactly what a good linux distribution gives you. Many people focus on the OS, but that's just the low level plumbing. Of course it must work, but the value in having a suite of inter-operable applications is often overlooked in the value ~ equation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdQjEY+HG7UEwVGERAkibAJ9B/9QO6BF18hlo8jPufkdxXQ9SmgCgr9wl B+adKylE2kYTJ2qq50IukDc= =e1Hc -END PGP SIGNATURE-
Re: web based applications and PRINTING
On Tue, 2004-10-19 at 05:29, Wayne Wilson wrote: I hate to say it, but we gave up on HTML based printing and moved to PDF. For our programmed apps we use the output from the apache FOP project: http://xml.apache.org/fop/ Just to add to the list.a very good FOSS PDF library for Python apps is ReportLab http://www.reportlab.org/ HTH, Tim
RE: web based applications and PRINTING
From: Heitzso [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 October 2004 8:08 PM To: [EMAIL PROTECTED] Subject: Re: web based applications and PRINTING Web printing 'was' notorious difficult for quite awhile, from the developer's point of view as well as the user's. The primary reason was at first the lack of tools at the disposition of the webscreen designer, then later, the lack of faithful implementation of CSS (cascading style sheets) standards by the browser makers (ie, IE). This technical hurdle doesn't really exist anymore since (most) standards are fairly well integrated now and new ones have evolved rapidly to keep pace with needs. Couple of months ago I tried to use CSS instead of nested tables to control simple text placement. No way could I do that -- then current (Aug '04) IE and Mozilla (also tested Opera) implemented basic CSS text positioning differently. Hair pulling out time and/or beating head against wall time. I'm guessing everyone is still using nested tables to position text as a least common denominator instead of doing it the correct CSS way. Anyway, I'm flagging that CSS is not at all implemented consistently across browsers. I'm not saying that by using some subset of CSS that you couldn't get it to work to print pretty pages, but if you go into CSS cold with a book in hand about how you are supposed to format pages with CSS be prepared for a rude awakening. Yes, that is our experience too - CSS works OK across browsers for setting fonts and colours, and for supressing things like buttons and other widgets when printing a page, but using it for complex page layout leads to days of wasted time trying to sort out differences and bugs in the way browsers render syntactically and semantically correct CSS code. Out of IE, Mozilla/Firefox and Konqueror/Safari, often the best we could do was to achieve a satisfactory result (using CSS for layout) in 2 out of 3, with the odd one out different each time. That's not to say CSS is useful. Tim C
Re: web based applications and PRINTING
Calle Hedberg wrote: One of our applications - a Web Pivot Reporter that functionally mimicks Excel Pivot tables in a browser environments Very interesting. Can you tell us more about your implemention of it and how/where it is used now that your people have had more time to learn it? What does it look like? Do you add a special row or column for the pivoting or href links from the individual data values, or something else? Is the logic all server-side or is there extensive javascript? - was initially rejected by many users due to messed up lay-out as soon as the dynamically created pivot tables extended over several pages. Their primary requirement was that reports should be easy to print, since they in general prefer to deal with information on paper and not on screen. Some users certainly prefer paper, but that is fading as on-screen display of data becomes more conveniently accessible and richly interactive and as users become more accustomed to it. I presume many others have faced similar problems - anybody know of FOSS solutions that are simple and robust without requiring a lot of fiddling by users? Our dynamically generated tables all have a page size limit (user controllable) that determines the maximum number of rows of data to be displayed per page and a continuation link as needed to view the next page. In addition to providing an easy means for users to avoid page overflow when printing, this helps to prevent long delays and wasted processing in delivering potentially huge tables that users might not really want. A simple trick that might help indirectly is to optionally change the content-type of a generated table from text/html to something associated with your user's spreadsheet application. For instance, we have found that for Excel users, changing the content-type of HTML tables to application/msexcel causes them to be opened as spreadsheets directly in Excel. --- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
Re: web based applications and PRINTING
Jim Calle Hedberg wrote: One of our applications - a Web Pivot Reporter that functionally mimicks Excel Pivot tables in a browser environments Very interesting. Can you tell us more about your implemention of it and how/where it is used now that your people have had more time to learn it? What does it look like? Do you add a special row or column for the pivoting or href links from the individual data values, or something else? Is the logic all server-side or is there extensive javascript? It was originally designed for one of the largest insurance companies in SA, and they use it extensively. HISP put in some additional development resources (about USD 50,000 or so) thus turned it into a FOSS app. It's mainly running on ASP/SQL Server at the moment, but I would like to see it ported to java at some stage - we are gradually moving from an MS environment to a java environment with DBMS independence. We've also tested it on MySQL 4.1 (it used embedded SQL extensively), and it seems to be running fine (couple of smaller issues to iron out). Almost ANY structured data base can be set up as a data source for it - the data source definition is just an XML file. (I don't think this list accepts attachments, but I'll send you a sample xml file and some sample output directly). The internal engine quite complex, with a mix of server-side and client-side logic. Simplistically, the conceptual approach for users is as follows: - User selects a data Package from a set of packages defined in the XML data source - Each package can contain one or more databases - each database contains various components - user can combine components (point and click) - the resulting list format output can be pivoted using an Excel Pivot like interface - Final pivot report is flexible (expand fields etc) Pivot reports can then be displayed (OK), printed (problem), exported to Excel (OK), or published to an integrated web portal where it can be made available to all other users with the right access privileges. The main problem we've had has been related to the printing - SA health managers demand paper reports, period. We're still some years away from broadband wireless access everywhere etc regards calle - was initially rejected by many users due to messed up lay-out as soon as the dynamically created pivot tables extended over several pages. Their primary requirement was that reports should be easy to print, since they in general prefer to deal with information on paper and not on screen. Some users certainly prefer paper, but that is fading as on-screen display of data becomes more conveniently accessible and richly interactive and as users become more accustomed to it. I presume many others have faced similar problems - anybody know of FOSS solutions that are simple and robust without requiring a lot of fiddling by users? Our dynamically generated tables all have a page size limit (user controllable) that determines the maximum number of rows of data to be displayed per page and a continuation link as needed to view the next page. In addition to providing an easy means for users to avoid page overflow when printing, this helps to prevent long delays and wasted processing in delivering potentially huge tables that users might not really want. A simple trick that might help indirectly is to optionally change the content-type of a generated table from text/html to something associated with your user's spreadsheet application. For instance, we have found that for Excel users, changing the content-type of HTML tables to application/msexcel causes them to be opened as spreadsheets directly in Excel. --- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
Re: web based applications and PRINTING
Hi, First, thanks to Wayne for the Firefox feedback - I thought the alleged spyware within firefox was unlikely myself, but you never know. Secondly, the posting from Will Ross re printing reminded me of a major problem we've had with certain web apps: The lack of proper control over final lay-out when you print stuff over several pages. Web printing is notoriously difficult, of course, due to the fact that HTML is so oriented towards display. Fixed web pages often have printer friendly versions, but this is more tricky with dynamically created web reports etc. One of our applications - a Web Pivot Reporter that functionally mimicks Excel Pivot tables in a browser environments - was initially rejected by many users due to messed up lay-out as soon as the dynamically created pivot tables extended over several pages. Their primary requirement was that reports should be easy to print, since they in general prefer to deal with information on paper and not on screen. I presume many others have faced similar problems - anybody know of FOSS solutions that are simple and robust without requiring a lot of fiddling by users? We have considered using intermediate formats like PDF (save HTML to PDF and then print the PDF), but it's a hassle. Regards calle * Calle Hedberg 46D Alma Road, 7700 Rosebank, SOUTH AFRICA Tel/fax (home): +27-21-685-6472; Cell: +27-82-853-5352 *
