Hi Rob,
thanks for the hint with pagebreak, ist works, so i reduced the sample code
(fine :) the originally problem always exist:
I cannot printout (or preview) this htmlcode as a website in my IE7
environment.
All i see in preview is a preview dialog with endless increasing total
pagecount.
Printout never ends (I stop it after a while without result)
Can you successful preview the following code in your IE7?
* if Yes => my Environment is corrupt
* If No => IE7 has a problem with this very simple page that it shouldn't have
and, by the way, in this sample code are no special Print-related elements,
except the pagebreak.
<html>
<body>
<table>
<tr>
<td>
<span style="height:100%">
<table height="100%">
<tr>
<td>
Test
<br style="page-break-after: always ">
Test
</td>
</tr>
</table>
</span>
</td>
</tr>
</table>
</body>
</html>
thanks for advice
Regards
René
"Rob ^_^" wrote:
> Hi Rene,
>
> I beg to disagree with you. What is displayed in the browser is not
> necessarily what is expected to be printed on a device. The keyword is
> devicecontext. The browser has a different devicecontext to that of a
> printer (height,width,scale, dpi).
>
> Here is the link to the msdn documentation about placing pagebreaks in a web
> document.
> http://msdn2.microsoft.com/en-us/library/ms530842.aspx
>
> You cannot rely on the assumption that what is displayed in the browser will
> be faithfully reproduced when the web page is rendered in the printing
> device.
>
> Intuatively, I agree, that you would think that a table height of 100% would
> fill the entire height of the device in which it is rendered. A web browser
> has a height property, a printer is deterministic depending upon the
> selection of a paper size.
>
> I would normally use a table with 3 rows to make a full browser display, the
> header and footer are of a fixed height. The centre row is of an
> undetermined height (*), in which I would place another table to position
> content within the variable height row.
>
> In all the web applications that I have worked on there has been options to
> display a printer friendly version of the web page (with selection lists
> converted to strings, floating divs converted to absolute positioning etc)
>
> You will see from the msdn link given above that there is a page break
> attribute that applies to the Paragraph tag.
>
> If your goal is to provide a multi-page report to users that will look just
> the same as it is rendered in the browser then I think you will find this an
> impossibility. What a user sees may not necessarily compare to what you have
> designed in your html IDE. I would suggest that you provide the option to
> display your page in a printer friendly version that has all formating and
> positioning removed and page breaks set with classed paragraph tags.
>
> I am not being overly defensive of IE. I just think that there are limits to
> what we as developers can expect from the software environment that we
> develope in.
>
> Quite often you will start out designing something and follow a path that
> you will think will work, only to find half way down the track that it all
> does not work. More often than not you will find that someone else has
> already walked that path and has found another solution that works.
>
> My whole argument is that what we design is not necessarily what our users
> will see (or print). I have not addressed the problem of page size selection
> in the Print Preview dialog. A user can choose their paper size and
> orientation in the Print Preview dialog, thier screen height and width is
> fixed, the browser height and width is variable. I urge you to move on with
> this and to find a solution that works.
>
> Regards.
>
....