Ideas for displaying as-it-would-print on a webpage

[djr33]

I know about many of the difficulties in even approaching this oncept, but I'm still interested in whether there are any reasonable ways to approach it.


I would like to create "books" that can be downloaded as PDFs, and I can generate PDFs from HTML automatically using PHP. But I also want to display the books on a webpage, and allow users to edit these books as if they are in a "page view", that is a single page at a time. I'm having some difficulty figuring out the best way to approach it, so I'm looking for any ideas you have.

Basically, I want to figure out how to page layout via bbcode markup through my website. So a user might want to insert an image, or add a table, or maybe just write a long paragraph. The question is: will that content go off the page?

What I want to do is integrate a page-based view (eg, a book) and also show it online, page by page, and edit it online, also page by page.



I'm not concerned with details like fonts and whether individual users have them, but I am concerned with how much content can reasonably fit on a single page and how I can possibly develop a method of displaying that on a webpage.



Is there some trick with using a certain kind of dimensions? Would using inches work? But isn't that just screensize? Does it necessarily apply while printing (or in a PDF)?


One resource-intensive (and serverside-only) option would be to use PHP to create a PDF, then check how many pages that PDF contains-- if it contains 1 page it's fine; if it contains 2+ pages, it's not a single page of content. But that's an odd way to go about this...


Alright, enough rambling from me. And thanks for any ideas!

[djr33]

Hmm... bump: maybe my phrasing above is too complicated. I'll say it another way:

I just want to find out how to create physical (=printer) page breaks in HTML and to accurately predict where those will fall. Ideas?

[bernie1227]

yes, you really did need a TL;DR there. from here:

Page breaks
Since the "print margins" are not under your control as Web author, you can't guarantee how much of a Web document will be printed on each page and hence where the page breaks will be. It will vary according to the user's browser, browser settings and printer. And the user's base font size and stationery size are also outside your control. You will want to use CSS to influence (not control) the position of page breaks. CSS2.1 Chapter 13 Paged Media is essential reading. Note that, in this Chapter, CSS2.1 drops some features in CSS2 that browsers have never implemented.
Support for the page-break properties (such as page-break-inside) is poor, even in the latest browsers, the major exception being Opera (Opera 5 onwards) whose support is very good:-
http://www.westciv.com/style_master/.../printing.html
http://www.ncdesign.org/html/s060oth.htm#pagebreak
Worse, browsers are liable to break pages in clearly unacceptable places (see also next paragraph). For example, I have found cases where browsers will break an image across pages. Testing on my various sites suggests that Opera's page-break handling, whilst not perfect, is distinctly more robust than that of Firefox or IE.

Eric's article (see below) mentions a bug in Gecko (Mozilla) -based browsers regarding the printing of floated elements. This bug apparently has yet to be fixed [at July 2009] result in floated elements being chopped at the end of the printed page and sometimes in only one page of a document being printed [Note 2]. I've found a similar float-chopping problem with older versions of Opera (e.g. O7.21). A different bug has been reported in IE where, if the top of a floated element happens to coincide with a page break, the floated element doesn't print at all [acknowledgement: Rennan Rieke].
For printing long tables across pages see Printing Tables .

[djr33]

Well, here's where the details from the first post come in-- I'm using PHP to generate PDFs. But I also want that content on the page.
So I wasn't worried about margins (or, as this will be used internationally, paper sizes). Instead, I just want to know that given certain dimensions on a page, where will the page breaks fall? What types of units will be reliable from the screen to the printer? Do cm/in work like this? Is that stable?

Thanks for the quote-- it does help some.

[bernie1227]

alright, so assuming that it is being printed in a4, the most common, am a4 page is 210mm × 297mm and 8.27in × 11.69in, and this details how you can create a page break in css, so this should be enough information for you to create a page break, as it would appear on an a4 page. for example:

<div class="page-break"></div>

.page-break  {
page-break-before: always; 
position: absolute;
top: 1123px;
}

NB: the top value is rounded, as the actual value is 1122.519685039

[djr33]

Ok, so let's assume that works.

Two points I'm not clear on:
1. Is it true that the printer will always have the same resolution/zoom? Does height:1cm; actually refer to 1cm on the physical page? Or just on my screen? If that's guaranteed to be how the printer interprets the information, then I'm happy enough.

2. How do I work out the actual size of the page break for displaying on the webpage? I'm more concerned with how I show this on a webpage accurately than actually printing it (again, I can use a PDF for that).


To put it in perspective, I want to allow users to design pages. So let's say they are adding a table and they would need to know if they can have 20 rows or 30 rows, because the 30 rows might go onto the next page. I'll need to figure out exactly what the borders are.

So if I can say that the page is Xcm by Ycm and that's all that's required, I'm happy. I can just hide the rest of the content in a div of the right dimensons. Is that reliable? Will it show me the real page breaks?

[bernie1227]

Ok, so let's assume that works.

Two points I'm not clear on:
1. Is it true that the printer will always have the same resolution/zoom? Does height:1cm; actually refer to 1cm on the physical page? Or just on my screen? If that's guaranteed to be how the printer interprets the information, then I'm happy enough.

a jsfiddle and a ruler later.... Yes, 1cm on a webpage, as far as I can tell is 1cm on a printed page.

2. How do I work out the actual size of the page break for displaying on the webpage? I'm more concerned with how I show this on a webpage accurately than actually printing it (again, I can use a PDF for that).

you can use specific css for printing and webpages, so you can remove the break when you print, because otherwise, as far as I can tell it will just print the break then.
I know traq hates them, but:
http://www.w3schools.com/css/css_mediatypes.asp

[djr33]

Thanks Bernie. Maybe I am just overthinking all of this.
I was worried about different printers having different settings, but if I can just use 1in or 1cm as a base unit, I can work it out from there. I'll look into this.


If anyone else has any thoughts about potential problems, please let me know. I'm not sure what to predict/expect might happen.

[bernie1227]

One thing I had a thought about, you should be careful of people printing in a different orientation, as it could completely screw up the positioning on the document. An option there, would be to offer a button to switch between portrait and landscape css. One more thing, you will need to figure out a way to get the size of the page, divide it by 1123px, and then dynamically create the breaks and their contents. You may need some jquery to get some of those values.

[djr33]

I'm just planning to display one page at a time, so I'll just put width/height values on a div and cut off any extra content. I don't need to stop people from including extra content-- I need to show them when they've put too much.

As for page orientation, the actual printing will be done through a PDF and if they choose to print landscape I can't really stop them, but it will make no sense at all. There is the issue of "letter" vs "a4" paper (a4 is slightly taller) and this site will be international; but usually printers can work out scaling PDFs as required.