[opensuse] RFR: Printing From Browsers
Hi, I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary. Does anyone know of a browser that does well with printing? Thanks. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "Randall R Schulz"
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
I never heard of a browser that prints very well. The obvious reason is html just isn't designed for that. It's designed intentionally to flow to fill the shape of whatever container it's in. (render as sensibly as possible in any size/shape display device.) whereas documents intended to be printed are written and formatted for a specific type of "display" (hard copy) from the outset. But that very statement about flowing to fit any window makes me think that it should be no problem for a browser or plug-in to simply re-render the page in an imaginary window that has the same properties as a printed sheet, (A4 or Letter dimensions at 300 dpi, or maybe 100dpi for rendering the page since thats what web designers assume screens are, and then scale the result to 300 or just ask the printer driver to do so) In my own app I have to generate html specially for printing. There are a few css attributes that can provide the crudest of ability to make an html document that paginates sort of ok. I have to have pre-formatted text (captured print-to-file from an application) and then in html I specify the font type and size, and wrap the text (or every x lines of it) in pre tags, and apply css page-break-before to the pre tag. Similarly, for scanned documents, I apply the same css page-break-before attrib to an img tag and display the img with 100% width and the height unspecified, which, as long as as the image was a letter or a4 geometry, ends up printing sensibly even though you can only see part of the image actually in the browser window. Since I have to both a) have content that I somehow know is already pre-formatted well for printing, and b) inject my own page breaks where I happen to know they should go because of a). I don't see how a random html that wasn't specifically written to be printed can print very well. <head> <style type="text/css"> pre.ff {page-break-before: always} img.ff {page-break-before: always} </style> </head> <img src="pgtest01.jpg" width="100%" class=ff> <pre class=ff> [...] </pre> -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Brian K. White wrote:
----- Original Message ----- From: "Randall R Schulz"
To: Sent: Wednesday, August 20, 2008 3:53 PM Does anyone know of a browser that does well with printing?
I never heard of a browser that prints very well. The obvious reason is html just isn't designed for that.
Well, the author of a webpage could prepare special css for rendering the page specifically for printing. It is in fact done quite often, although not always with css.
But that very statement about flowing to fit any window makes me think that it should be no problem for a browser or plug-in to simply re-render the page in an imaginary window that has the same properties as a printed sheet, (A4 or Letter dimensions at 300 dpi, or maybe 100dpi for rendering the page since thats what web designers assume screens are, and then scale the result to 300 or just ask the printer driver to do so)
Look up chapter 13 in the CSS2 specification. It's all about paged media. I know it doesn't solve Randalls (nor others') printing problem, but the browser shouldn't be getting all the blame. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Aug 21 07:54 Per Jessen wrote (shortened):
Brian K. White wrote:
But that very statement about flowing to fit any window makes me think that it should be no problem for a browser or plug-in to simply re-render the page in an imaginary window that has the same properties as a printed sheet
Exactly. In particular since CUPS exist, any application can get the whole PPD file for a particular print queue (even for remote print queues) from the cupsd and the PPD file contains all necessary information about the capabilities of the output device, in particular - imageable area (the media size is wrong and useless!) - color or monochrome - resolution And if the application likes to produce generic output (i.e. output which is not specific for a particular printer) it could use its own generic PPD file (also as fallback if no CUPS is available - e.g. on a system with LPRng).
... the browser shouldn't be getting all the blame.
Not all the blame but almost all the blame. In particular usual HTML text intermixed with usual images could be printed perfectly. I see only problems when there is dynamically changing stuff in the HTML, e.g. sequences of images ("movies"). In this case I think that the HTML must somehow contain information which one of the sequence of images is the right one which should appear on a "fixed" printout or provide an alternative fixed image for printout. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 20 August 2008 23:34, Brian K. White wrote:
----- Original Message ----- From: "Randall R Schulz"
To: Sent: Wednesday, August 20, 2008 3:53 PM Subject: [opensuse] RFR: Printing From Browsers Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
I never heard of a browser that prints very well. The obvious reason is html just isn't designed for that. It's designed intentionally to flow to fill the shape of whatever container it's in. (render as sensibly as possible in any size/shape display device.) whereas documents intended to be printed are written and formatted for a specific type of "display" (hard copy) from the outset.
But that very statement about flowing to fit any window makes me think that it should be no problem for a browser or plug-in to simply re-render the page in an imaginary window that has the same properties as a printed sheet, (A4 or Letter dimensions at 300 dpi, or maybe 100dpi for rendering the page since thats what web designers assume screens are, and then scale the result to 300 or just ask the printer driver to do so)
In my own app I have to generate html specially for printing. There are a few css attributes that can provide the crudest of ability to make an html document that paginates sort of ok. I have to have pre-formatted text (captured print-to-file from an application) and then in html I specify the font type and size, and wrap the text (or every x lines of it) in pre tags, and apply css page-break-before to the pre tag. Similarly, for scanned documents, I apply the same css page-break-before attrib to an img tag and display the img with 100% width and the height unspecified, which, as long as as the image was a letter or a4 geometry, ends up printing sensibly even though you can only see part of the image actually in the browser window.
Since I have to both a) have content that I somehow know is already pre-formatted well for printing, and b) inject my own page breaks where I happen to know they should go because of a). I don't see how a random html that wasn't specifically written to be printed can print very well.
<head> <style type="text/css"> pre.ff {page-break-before: always} img.ff {page-break-before: always} </style> </head>
<img src="pgtest01.jpg" width="100%" class=ff>
<pre class=ff> [...] </pre>
Years ago, there was a program for Windows 95 called Snap32. It would print anything on screen, from a window, from a selected rectangle, from the whole screen, and it would certainly print whatever kind of pdf or whatever. (Just select the text on screen and print it.) It was pretty quick, too. It came from a guy in Canada, who has long since removed the link and the program, or maybe he died, I don't know. It was extremely simple and nice to use. If anyone has this, and could reverse engineer it for Linux or Windows, I would be happy to pay a reasonable fee for it. (For both environments!) If anyone is willing to send me a copy (with password) for Windows, I'd surely be interested. I lost mine in a disk crash. --doug Blessed are the peacemakers ... for they shall be shot at from both sides. --A.M. Greeley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 21 August 2008 17:52, Doug McGarrett wrote:
...
Years ago, there was a program for Windows 95 called Snap32. It would print anything on screen, from a window, from a selected rectangle, from the whole screen, and it would certainly print whatever kind of pdf or whatever. (Just select the text on screen and print it.) It was pretty quick, too.
But a screen image printer is far from what one needs in general and certainly in my case. For screen snapshots there are plenty of adequate programs for capturing images which can then be printed by whatever raster image manipulation program you choose.
...
--doug
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 21 August 2008 07:52:29 pm Doug McGarrett wrote:
Years ago, there was a program for Windows 95 called Snap32. It would print anything on screen, from a window, from a selected rectangle, from the whole screen,
In KDE3 press key Prt Scrn and it will invoke KSnapshot, where you can do all mentioned. If that doesn't work, than in classic KDE Main menu > Utilities > Desktop you can find KSnapshot. -- Regards, Rajko http://en.opensuse.org/Portal needs helpful hands. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
Thanks.
Randall Schulz
I have had success in the past printing to PDF first. Not sure why. Manne -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
I guess this is not a problem of the browser but of the design of the web pages: many web programmers and older sites (including some of my own ones...) still use tables and fixed width, size and position declarations instead of a floating design that adapts to different screen or paper sizes. However, the opera browser gives you a lot of possibilities to change the appearance of a page. You can view the structure of a page and en- or desable the parts that are disturbing a proper print output. kind regards Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com erotic art photos: http://www.bauer-nudes.com Madagascar special: http://www.fotograf-basel.ch/madagascar/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Daniel Bauer wrote:
Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
I guess this is not a problem of the browser but of the design of the web pages: many web programmers and older sites (including some of my own ones...) still use tables and fixed width, size and position declarations instead of a floating design that adapts to different screen or paper sizes.
However, the opera browser gives you a lot of possibilities to change the appearance of a page. You can view the structure of a page and en- or desable the parts that are disturbing a proper print output.
kind regards
Daniel
Yes but if the browser can render the page correctly on the screen canvas it should theoretically be able to render it correctly to a paper canvas (using some scaling factor). If it does not display correctly I would agree it is a page layout issue. Manne -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Aug 21 10:05 Manne Merak wrote (shortened):
Daniel Bauer wrote:
... many web programmers and older sites ... still use tables and fixed width, size and position declarations instead of a floating design that adapts to different screen or paper sizes. ... Yes but if the browser can render the page correctly on the screen canvas it should theoretically be able to render it correctly to a paper canvas (using some scaling factor).
Not always. Because there are no scroll bars on the paper canvas! On screen a too big element (a table or image or whatever) results a scroll bar and for the user it looks correct. But what should the browser do for a canvas without scroll bars? Should it scale down the too big element until it fits in the imageable area (which seems a reasonable default for an usual image) or should it split the too big element into pieces to keep its original size (which seems a reasonable default for a table to avoid too tiny fonts in the printout) or should it print only the table on a separated page in landscape orentation if the table fits in the imageable area in landscape orentation or whatever else even more sophisticated magic? Another interesting case: Assume there are (big) images which fit exactly in the imageable area of a printer and between each image there are two lines of text. One line is meant to be the header line of the image. The other line is meant to be the footer line of the image. Should the browser scale the images down so that header, image, and footer fit in the imageable area or should the browser keep the original image size and print the text on separated pages? Without hints in the HTML where a page break makes sense the browser cannot produce a good printout automatically. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Johannes Meixner wrote:
Hello,
On Aug 21 10:05 Manne Merak wrote (shortened):
Daniel Bauer wrote:
... many web programmers and older sites ... still use tables and fixed width, size and position declarations instead of a floating design that adapts to different screen or paper sizes. ... Yes but if the browser can render the page correctly on the screen canvas it should theoretically be able to render it correctly to a paper canvas (using some scaling factor).
Not always. Because there are no scroll bars on the paper canvas!
On screen a too big element (a table or image or whatever) results a scroll bar and for the user it looks correct.
I agree, if the page is too wide it will be a problem. But most website are not that way.
Kind Regards Johannes Meixner
There should be a print option allowing to print the on-screen image scaled down to x DPI to paper - scaling the width to fit the page width. (landscape or portrait) Manne -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Manne Merak wrote:
There should be a print option allowing to print the on-screen image scaled down to x DPI to paper - scaling the width to fit the page width. (landscape or portrait)
Use a screen snapshot tool, followed by gimp :) Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Aug 21 13:57 Manne Merak wrote (shortened):
There should be a print option allowing to print the on-screen image scaled down to x DPI to paper - scaling the width to fit the page width. (landscape or portrait)
If the application doesn't provide such an option: Since CUPS 1.2 there is a "fitplot" option, see http://www.cups.org/documentation.php/options.html -------------------------------------------------------------------- The -o fitplot option specifies that the document should be scaled to fit on the page: lp -o fitplot filename lpr -o fitplot filename The default is to use the size specified in the file. Note: This feature depends upon an accurate size in the print file. If no size is given in the file, the page may be scaled incorrectly! -------------------------------------------------------------------- Of course scaling via the printing system if the PostScript which was produced by the application doesn't fit into the printer's imageable are is more a workaround than a real solution of the original problem. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x).
Interesting responses from various people and I agree with much of what's been said but I think everybody's missed the point ...
The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
This isn't true for Firefox, at least not for FF 1.5 or 2. Firefox does split text in complete rows as you'd hope (and it tries to follow most of CSS2). I never see the problem you describe with either FF1.5 or FF2. I think it's much more likely that this is a problem with page margin or header settings or printable area in the Firefox or printer config. Sorry, I don't have any more specific suggestion to offer. FWIW, the main problems I see with FF are: - when authors use position:absolute wrongly (they haven't read CSS2 chap 13 - paged media as Per suggested :) and that leads to all the output just flowing off the bottom of a single page. - when there's a long pre-formatted line, leading FF to shrink it to fit and making all the text unreadably small. I think FF is at least partly at fault for that. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Howorth wrote:
Randall R Schulz wrote:
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x).
Interesting responses from various people and I agree with much of what's been said but I think everybody's missed the point ...
The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
This isn't true for Firefox, at least not for FF 1.5 or 2. Firefox does split text in complete rows as you'd hope (and it tries to follow most of CSS2). I never see the problem you describe with either FF1.5 or FF2.
I think it's much more likely that this is a problem with page margin or header settings or printable area in the Firefox or printer config. Sorry, I don't have any more specific suggestion to offer.
FWIW, the main problems I see with FF are:
- when authors use position:absolute wrongly (they haven't read CSS2 chap 13 - paged media as Per suggested :) and that leads to all the output just flowing off the bottom of a single page.
- when there's a long pre-formatted line, leading FF to shrink it to fit and making all the text unreadably small. I think FF is at least partly at fault for that.
Cheers, Dave
Hmmm.. In many cases this is not FF but sloppy Web Authoring as already been pointed out elsewhere but.... Firefox 2.x was ok for me for quite a while on 10.2, but after a particular point it started getting very confused about paper size and orientation. (landscape became portrait and vice versa, and A4 seemed to be coming out as either A5 or letter and page top right was somewhat randomly positioned). The only way I could get anything remotely useful out of it was to go into landscape at 50% and then one usually needed a microscope to read the results :-). So if I needed to print a page from a browser (which is rare) I got into the habit of accessing the page via Konqueror and printing which usually worked OK. As I printed rarely from a browser I had no way of effectively pinning down which combination of updates/configuration changes was responsible for the change in behaviour (and to be honest I was not prepared to invest the time I because I could work around it, FF was the only application that was effected, and web searching did not turn up any clues about where to start looking for a solution). Since upgrading 11.0 and starting using v3 the problem has gone away (for the moment). - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkitWqcACgkQasN0sSnLmgJK9QCgq5DFOBDpINtgZyAf2+J82G6h T7YAniuK36AvGTa5uB3EO1IP8UKD7N1f =SWzz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 20 August 2008 12:53, Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). ...
Does anyone know of a browser that does well with printing?
I'm replying to my own message as a catch-all for the responses that came in overnight. Thanks everybody for the feedback and ideas. A few specific replies: - I'm aware of (but far from an expert with) CSS and its specific accommodations for alternative output media, but it would have to be an extraordinary case in which I mirrored a page's HTML and other resources, including stylesheets, so that I could fix the CSS (while learning how to do so)! - The sliced text line problem is definitely happening in Firefox 2.0.10. - I think creating a raster page or document image and manipulating it with GIMP is a bit more work that I'm willing to carry out. - I'll try the PDF route. - I'll also try Opera. I've experimented with it in the past and my recollection was that it's a techy dream, with bazillions of configurable options. Thanks again. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). The most common problem I encounter is that text lines mean nothing to the pagination process and it is common for a row of text to be sliced horizontally and split across a page boundary.
Does anyone know of a browser that does well with printing?
Thanks.
Randall Schulz
Interesting this blog was posted a few days ago claiming this is a Firefox issue. ========== Why can't Firefox print as well as Internet Explorer? What are they thinking at Mozilla? How could they devote time and effort to eye candy like new icons and drastically reworking the address bar when Firefox so often fails at printing. How did printing get pushed to the bottom of the priority list? I read lots of Web pages in hard copy and from the get-go (version 0.8 or so) Firefox has underperformed when it comes to printing Web pages. That issue and the slow start-up time are two constant annoyances endured by devoted Firefox users. It's been quite awhile now, and I think it's time that Mozilla get around to making Firefox the equal of Internet Explorer in terms of printing Web pages. http://news.cnet.com/8301-13554_3-10020813-33.html ========== Not that this helps us on Linux, but it is interesting others are complaining about deficiencies in Firefox printing. Jim F -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 August 2008 06:26, Jim Flanagan wrote:
Randall R Schulz wrote:
Hi,
I am almost always frustrated by the results of printing HTML pages from Firefox (I'm using version 2.0.x). ...
Randall Schulz
Interesting this blog was posted a few days ago claiming this is a Firefox issue.
========== Why can't Firefox print as well as Internet Explorer?
...
http://news.cnet.com/8301-13554_3-10020813-33.html
==========
Not that this helps us on Linux, but it is interesting others are complaining about deficiencies in Firefox printing.
Well, it's nice to know it's not my imagination.
Jim F
RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 August 2008 06:26:36 am Jim Flanagan wrote:
Not that this helps us on Linux, but it is interesting others are complaining about deficiencies in Firefox printing.
It is interesting people are even complaining about printing web pages. Though I occasionally archive a web page into PDF, I can't remember how many years it has been since I printed a web page. -- kai www.filesite.org || www.4thedadz.com || www.perfectreign.com remember - a turn signal is a statement, not a request -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 August 2008 15:47, Kai Ponte wrote:
...
It is interesting people are even complaining about printing web pages. Though I occasionally archive a web page into PDF, I can't remember how many years it has been since I printed a web page.
If it's the only form in which some necessary information exists, especially if it's the kind of information that is best used in printed form, then you'll be faced with wanting to print HTML documents.
-- kai
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 August 2008 03:49:03 pm Randall R Schulz wrote:
On Friday 22 August 2008 15:47, Kai Ponte wrote:
...
It is interesting people are even complaining about printing web pages. Though I occasionally archive a web page into PDF, I can't remember how many years it has been since I printed a web page.
If it's the only form in which some necessary information exists, especially if it's the kind of information that is best used in printed form, then you'll be faced with wanting to print HTML documents.
Okay, in that sense, you're best off copying the form to a document such as OOo Write and then formatting/printing from there. I *have* done that a few times. -- kai www.filesite.org || www.4thedadz.com || www.perfectreign.com remember - a turn signal is a statement, not a request -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 August 2008 16:26, Kai Ponte wrote:
On Friday 22 August 2008 03:49:03 pm Randall R Schulz wrote:
On Friday 22 August 2008 15:47, Kai Ponte wrote:
...
It is interesting people are even complaining about printing web pages. Though I occasionally archive a web page into PDF, I can't remember how many years it has been since I printed a web page.
If it's the only form in which some necessary information exists, especially if it's the kind of information that is best used in printed form, then you'll be faced with wanting to print HTML documents.
Okay, in that sense, you're best off copying the form to a document such as OOo Write and then formatting/printing from there.
Oy! The point is to avoid jumping through hoops!
I *have* done that a few times.
I usually deal with suboptimal HTML printing by just putting up with the resulting crap...
-- kai
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Kai Ponte schreef:
On Friday 22 August 2008 06:26:36 am Jim Flanagan wrote:
Not that this helps us on Linux, but it is interesting others are complaining about deficiencies in Firefox printing.
It is interesting people are even complaining about printing web pages. Though I occasionally archive a web page into PDF, I can't remember how many years it has been since I printed a web page.
Have you never looked up a route on Google maps and printed it just because you reeeeely didn't trust your GPS? Or because you don't have one? -- Amedee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (13)
-
Amedee Van Gasse
-
Brian K. White
-
Daniel Bauer
-
Dave Howorth
-
Doug McGarrett
-
G T Smith
-
Jim Flanagan
-
Johannes Meixner
-
Kai Ponte
-
Manne Merak
-
Per Jessen
-
Rajko M.
-
Randall R Schulz