I am trying to print out an HTML document that has MARGINWIDTH set to
1, however, upon printing, HTML table cell contents are cut off, for
exmample:
<table border="0" width="780">
<tr>
<td>Hello, this is a long piece of text that should be printed in
its entirety</td>
</tr>
</table>
However, this is what the user sees upon printout:
Hello, this is a long piece of text that should be printed in its ent
I have set the font settings to be as small as possible and
MARGINWIDTH to 1, to no avail. If the user uses IE to print, it gets
cut off, if I use Firefox 0.6, the font and margins seem small enough
to print everything in its entirety.
What can I do to allow for the users out there to universally print
HTML documents without cutoff? Asking them to switch browsers is
unreasonable and undoable.
Thanx
Phil 18  12265 
On 14 Sep 2004 08:01:25 -0700, Phil Powell <ph**************@gmail.com>
wrote: I am trying to print out an HTML document that has MARGINWIDTH set to
1, however, upon printing, HTML table cell contents are cut off, for
exmample:
<table border="0" width="780">
<tr>
<td>Hello, this is a long piece of text that should be printed in
its entirety</td>
</tr>
</table>
However, this is what the user sees upon printout:
> Hello, this is a long piece of text that should be printed in its ent
How many pixels wide is the paper? Less than 780?
You've discovered one of the drawbacks of fixed width design.
Congratulations.
I have set the font settings to be as small as possible and
MARGINWIDTH to 1, to no avail. If the user uses IE to print, it gets
cut off, if I use Firefox 0.6, the font and margins seem small enough
to print everything in its entirety.
What can I do to allow for the users out there to universally print
HTML documents without cutoff? Asking them to switch browsers is
unreasonable and undoable.
Using a print stylesheet is recommended.
Phil Powell wrote: I am trying to print out an HTML document that has MARGINWIDTH set to
1, however, upon printing, HTML table cell contents are cut off, for
exmample:
<table border="0" width="780">
What can I do to allow for the users out there to universally print
HTML documents without cutoff? Asking them to switch browsers is
unreasonable and undoable.
Don't use fixed width tables.
--
Mark. http://tranchant.plus.com/
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On 14 Sep 2004 08:01:25 -0700, Phil Powell <ph**************@gmail.com>
wrote:
I am trying to print out an HTML document that has MARGINWIDTH set to
1, however, upon printing, HTML table cell contents are cut off, for
exmample:
<table border="0" width="780">
<tr>
<td>Hello, this is a long piece of text that should be printed in
its entirety</td>
</tr>
</table>
However, this is what the user sees upon printout:
> > Hello, this is a long piece of text that should be printed in its ent
How many pixels wide is the paper? Less than 780?
This leads me to a question that should have occurred to me before: What
*are* browsers treating as a "pixel" for printing purposes? If I'm using a
1200 dpi printer, shouldn't a fixed-width 720 pixel page by printing less
than an inch wide? In fact, that doesn't happen, leading me to think that
something entirely different is going on.
You've discovered one of the drawbacks of fixed width design.
Congratulations.
"Harlan Messinger" <h.*********@comcast.net> wrote: What
*are* browsers treating as a "pixel" for printing purposes? If I'm
using a 1200 dpi printer, shouldn't a fixed-width 720 pixel page by
printing less than an inch wide? In fact, that doesn't happen,
It doesn't indeed, and it wasn't meant to happen.
HTML 3.2 said, at the end of the definition of tables:
"Note that pixel values for width and height refer to screen pixels, and
should be multiplied by an appropriate factor when rendering to very high
resolution devices such as laser printers. For instance if a user agent
has a display with 75 pixels per inch and is rendering to a laser printer
with 600 dots per inch, then the pixel values given in HTML attributes
should be multiplied by a factor of 8." http://www.w3.org/TR/REC-html32.html#table
HTML 4.01 refers (at http://www.w3.org/TR/html4/types.html#h-6.6 ) to the
CSS 1 specification "for information about the definition of a pixel".
And there we find (at http://www.w3.org/TR/REC-CSS1#length-units ) an
interesting "definition":
"Pixel units - - are relative to the resolution of the canvas, i.e. most
often a computer display. If the pixel density of the output device is
very different from that of a typical computer display, the UA should
rescale pixel values. The suggested reference pixel is the visual angle
of one pixel on a device with a pixel density of 90dpi and a distance
from the reader of an arm's length. For a nominal arm's length of 28
inches, the visual angle is about 0.0227 degrees."
Instead of really defining what a pixel is, it talks about "suggested
reference pixel" and about need to rescale when a device's pixel density
is "very different" from typical screen pixel. This is very vague indeed.
If I change the screen resolution from, say, 1024 by 768 to
1152 by 864 or vice versa, does the density become "very different"?
Browsers seem to think it doesn't. Scaling is performed for print media,
but not according to screen resolution.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >... "Harlan Messinger" <h.*********@comcast.net> wrote:
What
*are* browsers treating as a "pixel" for printing purposes? If I'm
using a 1200 dpi printer, shouldn't a fixed-width 720 pixel page by
printing less than an inch wide? In fact, that doesn't happen,
It doesn't indeed, and it wasn't meant to happen.
HTML 3.2 said, at the end of the definition of tables:
"Note that pixel values for width and height refer to screen pixels, and
should be multiplied by an appropriate factor when rendering to very high
resolution devices such as laser printers. For instance if a user agent
has a display with 75 pixels per inch and is rendering to a laser printer
with 600 dots per inch, then the pixel values given in HTML attributes
should be multiplied by a factor of 8."
http://www.w3.org/TR/REC-html32.html#table
HTML 4.01 refers (at http://www.w3.org/TR/html4/types.html#h-6.6 ) to the
CSS 1 specification "for information about the definition of a pixel".
And there we find (at http://www.w3.org/TR/REC-CSS1#length-units ) an
interesting "definition":
"Pixel units - - are relative to the resolution of the canvas, i.e. most
often a computer display. If the pixel density of the output device is
very different from that of a typical computer display, the UA should
rescale pixel values. The suggested reference pixel is the visual angle
of one pixel on a device with a pixel density of 90dpi and a distance
from the reader of an arm's length. For a nominal arm's length of 28
inches, the visual angle is about 0.0227 degrees."
Instead of really defining what a pixel is, it talks about "suggested
reference pixel" and about need to rescale when a device's pixel density
is "very different" from typical screen pixel. This is very vague indeed.
If I change the screen resolution from, say, 1024 by 768 to
1152 by 864 or vice versa, does the density become "very different"?
Browsers seem to think it doesn't. Scaling is performed for print media,
but not according to screen resolution.
You seem the one that I should ask how to ensure that an HTML page
with tables with set width (or no set width?) can always be printed
out without the margins cutting off text. My company is saying that
certain dynamically-genereated pages after Sept 7 will do this while
none before Sept 7 will do this (no changes to the HTML page that
generates this stuff has been done since Jan 2004).
Thanks
Phil
Jukka K. Korpela.exe failed a Turing test with If I change the screen resolution from, say, 1024 by
768 to 1152 by 864 or vice versa, does the density become "very
different"? Browsers seem to think it doesn't. Scaling is performed
for print media, but not according to screen resolution.
You'd be more than a little upset if you changed to a higher screen
resolution only to find that all the images increased in size to occupy the
same portion of the screen/window!
Nik
--
I wish to be dissociated from your interpretation of my opinions
This post is encrypted by the Quad-ROT-13 method.
Any attempt to read it may constitute a breach of the DMCA ph**************@gmail.com (Phil Powell) wrote: My company is saying that
certain dynamically-genereated pages after Sept 7 will do this while
none before Sept 7 will do this (no changes to the HTML page that
generates this stuff has been done since Jan 2004).
Sorry, my crystal ball is on vacation. Try posting the URL; maybe someone
wishes to analyze the problem if he can see it.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >... ph**************@gmail.com (Phil Powell) wrote:
My company is saying that
certain dynamically-genereated pages after Sept 7 will do this while
none before Sept 7 will do this (no changes to the HTML page that
generates this stuff has been done since Jan 2004).
Sorry, my crystal ball is on vacation. Try posting the URL; maybe someone
wishes to analyze the problem if he can see it.
Sorry, but I can't do that. The URL is an internal URL of US
Government proprietary information, unfortunately, it renders it
somewhat classified, so there is no URL I can give you. All I'm
allowed to do then is to describe the problem as best as possible in
the hopes of a solution.
Thanks
Phil
Jukka K. Korpela wrote: ph**************@gmail.com (Phil Powell) wrote:
The URL is an internal URL of US
Government proprietary information
Well, please feel to come back when you have a question about
HTML authoring for the World Wide Web.
Are there are specific newsgroup for asking about HTML intended for
intranets, CD-ROMs, personal computer hard disk, etc.?
If not isn't this place the best we have?
(Not to say the OP shouldn't create a test-case for us to see.)
--
Google Blogoscoped http://blog.outer-court.com
On 17 Sep 2004 15:43:36 GMT, Philipp Lenssen <in**@outer-court.com> wrote: Jukka K. Korpela wrote:
ph**************@gmail.com (Phil Powell) wrote:
> The URL is an internal URL of US
> Government proprietary information
Well, please feel to come back when you have a question about
HTML authoring for the World Wide Web.
Are there are specific newsgroup for asking about HTML intended for
intranets, CD-ROMs, personal computer hard disk, etc.?
If not isn't this place the best we have?
(Not to say the OP shouldn't create a test-case for us to see.)
alt.html serves as a catch-all for most people. Nearly any HTML or
HTML-connected topic is in bounds there.
On 17 Sep 2004 07:04:51 -0700, Phil Powell <ph**************@gmail.com>
wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:<Xn*****************************@193.229.0.31 >... ph**************@gmail.com (Phil Powell) wrote:
> My company is saying that
> certain dynamically-genereated pages after Sept 7 will do this while
> none before Sept 7 will do this (no changes to the HTML page that
> generates this stuff has been done since Jan 2004).
Sorry, my crystal ball is on vacation. Try posting the URL; maybe
someone
wishes to analyze the problem if he can see it.
Sorry, but I can't do that. The URL is an internal URL of US
Government proprietary information, unfortunately, it renders it
somewhat classified, so there is no URL I can give you. All I'm
allowed to do then is to describe the problem as best as possible in
the hopes of a solution.
Create a duplicate with replaced content. Post it on a public server.
Without that, we can't really assist.
On Fri, 17 Sep 2004, Philipp Lenssen wrote: Are there are specific newsgroup for asking about HTML intended for
intranets,
Yes; but I don't follow them myself so I can't say how good they are.
(And they don't all start with microsoft.* )
If not isn't this place the best we have?
(Not to say the OP shouldn't create a test-case for us to see.)
But it's utterly frustrating to be asked what appears to be a bona
fide WWW question, to try to give a good answer, and then to be
slapped down with "oh no, that's no use on our Intranet".
They might at least /pretend/ for the purposes of discussion that it's
a WWW question, and find some public place to present a test-case.
Anyhow, it's been my experience of several Intranet situations that
they were considerably improved by applying WWW-appropriate
techniques. In at least one case, the motive was to avoid the risk of
prosecution for discrimination against disabled employees.
begin quote from Philipp Lenssen in <2r*************@uni-berlin.de>: Are there are specific newsgroup for asking about HTML intended for
intranets, CD-ROMs, personal computer hard disk, etc.?
If not isn't this place the best we have?
(Not to say the OP shouldn't create a test-case for us to see.)
I think comp.infosystems.intranet fits, at least for the first of those.
--
Shawn K. Quinn
Shawn K. Quinn wrote: begin quote from Philipp Lenssen in <2r*************@uni-berlin.de>:
Are there are specific newsgroup for asking about HTML intended for
intranets, CD-ROMs, personal computer hard disk, etc.?
If not isn't this place the best we have?
(Not to say the OP shouldn't create a test-case for us to see.)
I think comp.infosystems.intranet fits, at least for the first of
those.
You guys are certainly right. I just thought that HTML was not
restricted to the WWW -- it was great for CD-ROMs, Intranet, etc. There
is no specific "intranet" markup that is superior. And even if people
think in an Intranet they have a special context -- like, they only
need to support one browser -- later on they often find out they are
wrong (such as when they need to support more than a single browser, or
they find out the latest browser update breaks their nifty add-ons, or
they find out they have to transport portions of the system onto the
WWW).
--
Google Blogoscoped http://blog.outer-court.com
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn****************************@193.229.0.31> ... ph**************@gmail.com (Phil Powell) wrote:
The URL is an internal URL of US
Government proprietary information
Well, please feel to come back when you have a question about
HTML authoring for the World Wide Web.
I do have a question about HTML authoring for the World Wide Web, it's
just that the URL provided is under federal protection by the US
Government and thus, I cannot give it out due to its content being
classified.
The problem I'm having is that now the company is complaining that PDF
documents and other authored HTML pages on the same domain and
instance are all being cut off at the right margin, and every trick I
know to do fails to stop this from happening.
Based on your experience, what would you recommend I do so that the
documents are not cut off at the right margin?
Phil
Phil Powell <ph**************@gmail.com> wrote: The problem I'm having is that now the company is complaining that PDF
documents and other authored HTML pages on the same domain and
instance are all being cut off at the right margin, and every trick I
know to do fails to stop this from happening.
Based on your experience, what would you recommend I do so that the
documents are not cut off at the right margin?
Two replies to your original message told you what to do:
Stop trying to print fixed-width content on media that is narrower
than the content.
Without seeing the offending documents, it's hard to be any more specific.
For PDF documents, my copy of Acrobat Reader includes a "Shrink oversized
pages to paper size" feature in the Print dialog. Opera has a "Scale print"
setting in the Print Options dialog that works similarly, except that it
must be set by hand. Other software may have similar features.
HTH
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"Red meat isn't bad for you. Fuzzy blue-green meat is bad for you."
Darin McGrew <mc****@stanfordalumni.org> wrote in message news:<ci**********@blue.rahul.net>... Phil Powell <ph**************@gmail.com> wrote: The problem I'm having is that now the company is complaining that PDF
documents and other authored HTML pages on the same domain and
instance are all being cut off at the right margin, and every trick I
know to do fails to stop this from happening.
Based on your experience, what would you recommend I do so that the
documents are not cut off at the right margin?
Two replies to your original message told you what to do:
Stop trying to print fixed-width content on media that is narrower
than the content.
Without seeing the offending documents, it's hard to be any more specific.
For PDF documents, my copy of Acrobat Reader includes a "Shrink oversized
pages to paper size" feature in the Print dialog. Opera has a "Scale print"
setting in the Print Options dialog that works similarly, except that it
must be set by hand. Other software may have similar features.
HTH
Thanx.. actually we are testing to see if it's not the printer itself,
which is now what I believe is the offending agent. Considering that
multiple PCs here have cut-off printouts now and it occurs in spite of
changes to IE, to Adobe Acrobat Reader and even to the HTML pages
themselves (all the while it never happens whenever I print from my
machine using Linux Red Hat and Mozilla Firefox 0.6).
Phil This discussion thread is closed Replies have been disabled for this discussion. Similar topics
2 posts
views
Thread by Luis Serrano |
last post: by
|
6 posts
views
Thread by Terry Olson |
last post: by
|
reply
views
Thread by Matthew Belk |
last post: by
|
2 posts
views
Thread by Ned |
last post: by
|
reply
views
Thread by Siv |
last post: by
|
1 post
views
Thread by scrawnyguns |
last post: by
|
7 posts
views
Thread by Mark |
last post: by
| | | | | | | | | | | | | | | | | | | | | | | |
