21 replies [Last post]
uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

According to my trials, and Microsoft's documentation,

"Although @page rules are represented in the CSS object model in Microsoft Internet Explorer 5.5 and later, the rules are not used by the default print template..."

In other words, we have no control over margins and the default header/footer when printing web pages in IE via an @page rule with 'size' and 'margin' declarations. Just curious, has anyone ever found a workaround for this?

Thanx in advance for responding.

ClevaTreva
ClevaTreva's picture
Offline
Guru
A hilly place, UK
Last seen: 3 years 34 weeks ago
A hilly place, UK
Joined: 2004-02-05
Posts: 2902
Points: 0

@Page Ignored by IE?

Hi

I am going to quote css-discuss here:

Quote:
When printing Web documents, margins are set in the browser's Page Setup (or Print Setup) dialog box. These margin settings, although set within the browser, are controlled at the operating system/printer driver level and are not controllable at the HTML/CSS/DOM level.

In other words, if your user is dumb enough to have left IE with the default settings for printing a web page (instead of setting 1cm all round and no header and footer), there isn't much you can do to lift their IQ.

To allow you the necessary access to the system controls would be the equivalent of asking someone to drop their pants and bend over. :twisted:

Trevor

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Follow-Up

Thanks for the input.

When I read about the @page rule, my thinking was something like this

Okay, I'll use the following, permissible according to the CSS2 spec

@page {
size 8.5in 11in;
margin-top 0.75in;
margin-left 1in;
}

According to the spec, for paged media, when using "size" in the @page rule, the user agent should only get to decide what to do if the size is larger than the target sheet. In my example, the page box should simply go out to the limits of the target sheet, and my page area will appear within the margins I set. I would only have 2 worries

1. Perhaps, if the user has set up or left the default header and footer texts in the browser configuration, I would see that header and footer text overlayed with my page definition (in this case, appearing in my margin)

2. This approach would require that the user agent honors my @page rule as long as the size doesn't go beyond the size of the target sheet (which it doesn't, in this case), and uses my page definition, margins and all, rather than showing the header and footer specified in the browser setup.

Of course, this second point relies on user agents uniformly deciding how to handle the contention between browser-configured headers and footers and any @page rule declarations that intrude on the space the browser would normally use for such header and footer.

The point in all this is that rather than coming up with an algorithm for navigating this contention, Microsoft has apparently decided to just dispel with honoring @page rules altogether. This is par for the course for Microsoft, and I was originally just asking if anybody has found a way to "force" IE to honor @page rules.

I'm surprised, also, that this hadn't been addressed long ago. The whole point of CSS, from what I've read, is to provide a way to format output, whether to screen, print media, or whatever, whether with HTML/XML or not. The CSS2 spec has been around since 1998, yet browser manufacturers still aren't providing a way for CSS to do its job?!? I mean, come on, with all the ****ing talk about web-this and web-that, we still don't have a way to print a document so that it matches what's on the screen if it's delivered via the web (without extra plug-ins or hacks)? Jeez, is it 2005 or 1985?

thepineapplehead
thepineapplehead's picture
Offline
Moderator
Last seen: 9 weeks 3 days ago
Timezone: GMT+1
Joined: 2004-06-30
Posts: 9683
Points: 819

Re: Follow-Up

uselesslyregistered wrote:

I'm surprised, also, that this hadn't been addressed long ago. The whole point of CSS, from what I've read, is to provide a way to format output, whether to screen, print media, or whatever, whether with HTML/XML or not. The CSS2 spec has been around since 1998, yet browser manufacturers still aren't providing a way for CSS to do its job?!? I mean, come on, with all the ****ing talk about web-this and web-that, we still don't have a way to print a document so that it matches what's on the screen if it's delivered via the web (without extra plug-ins or hacks)? Jeez, is it 2005 or 1985?

People don't print pages because they like the pretty pictures and nice layout, they print pages because they want a hard copy of the data.

Background images don't print, but nobody ever complains about that!

Verschwindende wrote:
  • CSS doesn't make pies

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Answer

Thanks for the input.

After more searching, I found all the answers I need. The bottom line is that CSS 2.1 abandoned the @page rule because no browser manufacturer ever bothered to honor it. In July of 2004, the W3C proposed CSS 3 with it back in, plus additional constructs for separate header and footer boxes. Yeah! Of course, who knows if Microsoft (or others) will ever implement it.

Full details for anybody interested

http//css-discuss.incutio.com/?page=PrintStylesheets

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Oh, also...

I forgot my emotional outburst addendum

Anybody old enough to remember computing in the 80s? Problems were refreshing challenges, and almost no proposed solution survived more than a nanosecond if it wasn't at least decent, because things were so simple that bad design was hard to obfuscate under mounds of crappy documentation or abstracted layers of this and that.

This is why I hate this industry more and more...Dollars instead of Sense.

I'm going back to Physics.

<outburst concluded--thank you for your patience and understanding--H3729-A1#!0-beep signing off>

ClevaTreva
ClevaTreva's picture
Offline
Guru
A hilly place, UK
Last seen: 3 years 34 weeks ago
A hilly place, UK
Joined: 2004-02-05
Posts: 2902
Points: 0

@Page Ignored by IE?

I disagree.

To enable you to override the system's printer settings would mean you need to have access to the system, and thus a port would have to be opened for such a communication. As if browsers weren't already hard to secure, this really would let the hackers in.

Trevor

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Oh boy, I thought I was done here...

ClevaTreva wrote:
I disagree.

To enable you to override the system's printer settings would mean you need to have access to the system, and thus a port would have to be opened for such a communication. As if browsers weren't already hard to secure, this really would let the hackers in.

Trevor

No, this is not true.

For simple control of all content, I am supposed to be able to specify an @page rule; and if I include a "size" declaration with dimensions that match the target sheet size, then my page box happens to be the same size as the sheet of paper being printed on. In this way, I should be able to control all content on the paper, because the user agent is not allowed, according to the spec, to overide my content unless the "size" declaration specifies a size larger than the target sheet. Of course, limitations due to a printer driver not allowing a printer to print all the way out to the edge of the printer are an issue, and may cause cropping, but that seems to be different than the artifact I'm encountering in IE. In any case, IE and Mozilla both ignore the @page rule entirely, which means I can't do anything that the @page rule is supposed to allow me to do. And that has absolutely nothing to do with a printer driver.

And in the (new? July 2004) CSS 3 spec, there are additional selectors for header and footer boxes, but those aren't implemented in browsers either, and would also have nothing to do with a print driver.

With both @page selector in general, and headers/footers specifically, it is the user agent's job to decide whether to implement a CSS tag (such as @page) or not, and how to do it. If the programmer(Drunk of the browser so chose, he/she/they could include an algorithm for doing so. And as long as they don't go outside the area that the print driver can send to the printer, the browser can send whatever data it wants to without having anything to do with print drivers. So neither issue would imply a security concern.

In other words, consider the way headers and footers are currently set. They are set in a browser configuration dialog, not a system settings dialog. Whatever you set them to is what the browser arranges and sends to the printer driver. If I use an @page rule or CSS 3 header box in my page, that would be an instruction to override the browser settings for header/footer, not system settings. So there's no security issue.

ClevaTreva
ClevaTreva's picture
Offline
Guru
A hilly place, UK
Last seen: 3 years 34 weeks ago
A hilly place, UK
Joined: 2004-02-05
Posts: 2902
Points: 0

Re: Oh boy, I thought I was done here...

uselesslyregistered wrote:
They are set in a browser configuration dialog, not a system settings dialog.

Hi

Just to confirm (and disagree). Your browser print settings dialog DOES use the system print dll to populate itself. But the argument is pointless. You aren't going to be able to access these settings. No user in their right mind will let you. Even IF CSS3 allows it, security settings on the user's PC will block the attempt.

Trevor

thepineapplehead
thepineapplehead's picture
Offline
Moderator
Last seen: 9 weeks 3 days ago
Timezone: GMT+1
Joined: 2004-06-30
Posts: 9683
Points: 819

Re: Follow-Up

Just to reiterate:

thepineapplehead wrote:

People don't print pages because they like the pretty pictures and nice layout, they print pages because they want a hard copy of the data.

Verschwindende wrote:
  • CSS doesn't make pies

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Re: Follow-Up

thepineapplehead wrote:
Just to reiterate:

thepineapplehead wrote:

People don't print pages because they like the pretty pictures and nice layout, they print pages because they want a hard copy of the data.

This is patently false. What about reports-via-browser? That's exactly why I ended up visiting this issue in the first place.

Why do you think there's so much activity centered around web services and intranet applications? I build database apps. Lots of people build database apps. You're telling me I'm not supposed to format and print the reports I can see onscreen? That's rediculous! Or do you propose that I always use Crystal Reports, or Reporting Services, or some such thing, rather than expect to be able to format one report with CSS and make it look decent? Or is everybody here a graphic designer who never builds apps?

The @page rule has been around since '98, the header/footer boxes in CSS3 since last July. I expect to be able to print a report in an intranet app with my code, and CSS should be able to do it.

And it's just not a security problem. If I include a header box instruction in my web page code, IE should damn well be smart enough to check for maliciousness, otherwise just print it. You people are talking as if browsers have no ability to make a decision. If they can parse umteen levels of nested inline boxes and JavaScript and Flash and make all your pretty fluffy pages look nice, they sure as hell should be able to simply print some stuff near the top of the page instead of the default header crap. Jeez.

thepineapplehead
thepineapplehead's picture
Offline
Moderator
Last seen: 9 weeks 3 days ago
Timezone: GMT+1
Joined: 2004-06-30
Posts: 9683
Points: 819

Re: Follow-Up

uselesslyregistered wrote:

This is patently false. What about reports-via-browser? That's exactly why I ended up visiting this issue in the first place.

Why do you think there's so much activity centered around web services and intranet applications? I build database apps. Lots of people build database apps. You're telling me I'm not supposed to format and print the reports I can see onscreen? That's rediculous! Or do you propose that I always use Crystal Reports, or Reporting Services, or some such thing, rather than expect to be able to format one report with CSS and make it look decent? Or is everybody here a graphic designer who never builds apps?

The @page rule has been around since '98, the header/footer boxes in CSS3 since last July. I expect to be able to print a report in an intranet app with my code, and CSS should be able to do it.

And it's just not a security problem. If I include a header box instruction in my web page code, IE should *beep* well be smart enough to check for maliciousness, otherwise just print it. You people are talking as if browsers have no ability to make a decision. If they can parse umteen levels of nested inline boxes and JavaScript and Flash and make all your pretty fluffy pages look nice, they sure as *beep* should be able to simply print some stuff near the top of the page instead of the default header crap. Jeez.

I don't know what the hell you just said, but you're right, most of us make web-sites. We don't design web-based apps.

As for the @page rule being around for 7 years - there are css tags 10, 15 years old that IE7 is only just supporting.

Verschwindende wrote:
  • CSS doesn't make pies

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

Re: Follow-Up

thepineapplehead wrote:
uselesslyregistered wrote:

This is patently false. What about reports-via-browser? That's exactly why I ended up visiting this issue in the first place.

Why do you think there's so much activity centered around web services and intranet applications? I build database apps. Lots of people build database apps. You're telling me I'm not supposed to format and print the reports I can see onscreen? ....

I don't know what the *beep* you just said, but you're right, most of us make web-sites. We don't design web-based apps.

As for the @page rule being around for 7 years - there are css tags 10, 15 years old that IE7 is only just supporting.

Ok. Cool. Then most of you aren't aware of the trouble with so many people in the development arena talking about web-this and web-that, web services, PalmOS-this and Windows CE-that, and it's 2005, and I still can't just print a bloody report! It's comical!

See, Microsoft has this docs page where they tell you that you can't simply use the @page rule, but if you want, you can access the print template that IE uses to decide where to put things like the header and footer if you're writing a C++ app! It's outrageous!

And there are components for ASP/PHP/etc. developers that will turn your web-based report into PDF, RTF, etc. But we can't just use the simple method of a CSS tag. Typical IT bull*beep* Smile

Well, I think my ranting work is done here. Be forwarned CSS people: don't tell you're clients you can print stuff. It won't happen without extra work.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 25 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

@Page Ignored by IE?

uselesslyregistered, I'm with you 100% on all that you have said. I thought that we were heading towards a point where web apps/web pages were intertwined, if the CSS rules are there then the browser should be able to make use of them, dll or not. this is just one of those fudged areas.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 1 year 17 weeks ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

@Page Ignored by IE?

Web apps are one thing, and I expect most functionality to lie with the server, the browser acting as a thin client. Printing, however, is not a server function. Nor, is sgml in a browser nor any of its offspring the proper technology for delivering a document for print.

There are technologies for delivering a printer bound document. One of the most popular, if dangerous, is the MSWord .doc formatted, um, doc. The .pdf format is built from the ground up to be a platform agnostic means of delivering printable documents. The soon to be more available Star/OO.o Open Document format is also a print oriented technology. HTML is a web oriented technology, and the web is not print.

If you want to bend a note, don't use a piano, pick up a guitar, or a fiddle, or a … .

cheers,

gary

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 25 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

@Page Ignored by IE?

No the web is not print but that is a somewhat hackneyed phrase.
I'm thinking really from the point of view that a browser has a print function, this is clearly designed to provide a printed rendition of the page being viewed. It seems to stand to reason - given that the properties are provided - that we are able to format the page for optimal print conditions for our layout. I realise there are specific means of delivering print documents, but for the basic page being viewed why can we not have that fine degree of control over the formatting.

It's not a question about whether html/sgml is a correct format for delivering print more that it is a format that will be required to be printed from time to time.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 1 year 17 weeks ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

@Page Ignored by IE?

Hugo, you're right, there is a print function, and people do use it to create hard copy. My argument is that the html document is intrinsically of indeterminant width and length—especially length. It has no set font size nor output medium.

The print document is designed for the specific height and width of a piece of paper, or t-shirt, or whatever. While a web (read html) document is designed for an unknown UA. It has to work for IE and for some Braille pad. It has to work when the user has changed the font-size and colors, and who knows what his browser window is.

Sure, you can print a web page. But you're using the wrong tool. Use a print tool for a print document. You can use a pipe wrench to twist a nut, but you're likely to damage the nut. Wrong tool.

That's my story, and I'm sticking to it. Smile

cheers,

gary

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 25 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

@Page Ignored by IE?

Are you secretly a plumber on the side Gary? Smile

Your analogies are noted and I understand what your saying it's just that regardless of the unknown quantity that is a UA; in printing a page you can almost certainly predict that a A4 sheet of paper will be used - as that seems to the norm nowadays with letter/legal size seldom seeming to be used - that it would be nice to be able to format ones layout to something that is precise and immutable for a change, however it is possible to get a fairly decent level of control through the properties available.

It must be said that I'm thinking not so much about an actual document that must be printed with precision and in using html for the transmission of that file information which I guess was the intent in the original posters question,( so I have probably moved away from the original point) but of just having the properties at our disposal to the best job we can, many layouts can be subtly altered to produce a good looking printed representation with a little thought and care, it would be nice if those efforts were aided rather than hampered. other than that use one should use one of the formats designed for conveying data intended for printing.

Hugo.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 1 year 17 weeks ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

@Page Ignored by IE?

Ahh, please. The A4 sheet is very seldom seen in the U.S., but the letter and legal sizes are very common.Smile

But, that's beside the point. The OP's argument, if I read it rightly, is that an html document should be able to control printer output, say printing a report without a filename at the top, or other user controlled header/footer stuff, margins, etc..

I'm sure that could be done. But, then, why not deliver a word processor, spread sheet, or data base report document directly? These are all designed for output to paper. Better yet, convert to PDF for cross platform compatibility. The browser is designed, along with its markup language, for an amorphous medium.

It is simply my argument that we use the appropriate technology. HTML and css are not up to the task, if for no other reason than there is no concept of pagination. You'll need a different language if you want any reasonable control of the printed page.

cheers,

gary

gary

gary (Hah! I can one-up you on sigs)

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 25 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

@Page Ignored by IE?

Didn't realise the A4 size was not common in the states, it is an iso standard. Had it in mind that it originated from the states, but come to think of it you do have a strange size that is not used in the UK.

I do understand and accept your point, just feel sorry for you in the states still using these bizarre paper sizes.

Hugo.

Hugo.

Hugo.

Hugo.

I think I'm having an identity crisis at the moment and subconsciously feel the need to reinforce who I am :?

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 1 year 17 weeks ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

@Page Ignored by IE?

I quite understand.

cheers,

gary

gary

gary

gary

gary

Let's stop, my finger's tired. (That's from an old song that's not safe for work Smile )

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

uselesslyregistered
Offline
newbie
Last seen: 16 years 36 weeks ago
Joined: 2005-10-20
Posts: 8
Points: 0

To belabor the point...

kk5st wrote:
Ahh, please. The A4 sheet is very seldom seen in the U.S., but the letter and legal sizes are very common.Smile

But, that's beside the point. The OP's argument, if I read it rightly, is that an html document should be able to control printer output, say printing a report without a filename at the top, or other user controlled header/footer stuff, margins, etc..

I'm sure that could be done. But, then, why not deliver a word processor, spread sheet, or data base report document directly? These are all designed for output to paper. Better yet, convert to PDF for cross platform compatibility. The browser is designed, along with its markup language, for an amorphous medium.

It is simply my argument that we use the appropriate technology. HTML and css are not up to the task, if for no other reason than there is no concept of pagination. You'll need a different language if you want any reasonable control of the printed page.

cheers,

gary

This is not true, according to what I've read. HTML, with CSS (and specifically, CSS) is precisely up to the task. That's why there are many defined media types in the CSS spec:

all
aural
braille
embossed
handheld
PRINT
projection
etc.

And there is absolutely the concept of pagination in CSS: the @page rule; page-break-before, page-break-after, and page-break-inside rules; left, right, and first page rules, etc. See Chapter 13 in the CSS 2 spec:

http://www.w3.org/TR/1998/REC-CSS2-19980512

As well as new selectors for header boxes and footer boxes in CSS 3.

See, the thing is, there are a lot of developers, like me, writing web apps that talk to a database, or other changing data content. That means that ASP or PHP pages are generating dynamic content, often using data from a database. So static formats are out. Merges, via CSV or other files, with something like MS Word are too clumsly and insecure.

There are components that'll spit out a PDF, but they still have to be supplied with content, which in our case is dynamic. That means we either write an ASP or PHP page that creates a text file by hand and supplies it to the component, or we write an ASP or PHP page that gets the data, does whatever pre-processing is needed, and then sends it as HTML to the component. But that PDF generator still relies on HTML, or more to the point, CSS, to tell it how to paginate or otherwise format the document. There are yet other components that will generate a PDF using plain text or other source formats, but that requires even more pre-processing by the ASP or PHP page.

A simplified example: I write an ASP page that gets data from a database, puts it into a few tables (in the HTML), and sends it to a browser. If I include some CSS with a separate @media print {} rule, most browsers will obey whatever styles I specify in it when you print that web page, which can be totally different styles than what it uses for screen display. The problem is that browsers won't obey an @page rule when I specify it in my @media style section (or anywhere else). And it is the @page rule that allows us to specify size of media (paper), left, right or all-page formatting, etc.

And in response to an earlier post also regarding the appropriateness of CSS for such formatting, I quote the CSS spec:

"CSS can be used with any structured document format, for example with applications of the eXtensible Markup Language" [2.2]

"Style sheets complement structured documents (e.g., HTML and XML applications)..." [2.4]
- Me: notice it says e.g., not "i.e."

...and...

"Style sheets themselves are also vendor and platform independent, but CSS2 allows you to target a style sheet for a group of devices (e.g., printers)." [also in 2.4]

Obviously, user agent vendors are free to comply with a given CSS spec as they wish, meaning that this has become more of an academic discussion. Nevertheless, that doesn't mean it is an unimportant one.