291 bytes, text/html
887 bytes, text/html
39.12 KB, patch
karnaze (gone): review+
karnaze (gone): superreview+
|Details | Diff | Splinter Review|
I know you don't claim you've implemented CSS2, which is is ok. One reason why PDF has become so popular on the web is that HTML has ignored printing. For any serious documentation project that whishes to use HTML and has to consider printing the page-break-* property is *indispensible*, and should, IMHO, be among the first ones to be considered when moving from CSS1 to CSS2. I understand that some of the page-break-* values(!) might be somewhat more difficult to implement, but a "page-break-before: always;" to start a chapter on a new page is just like a the old form feed and should be easy to do. Is it complicated to start a new pagebox? Don't be surprised to see messages like "Your browser does not support certain printing features. Please use Browser XY for proper formatting on paper".
Not sure if this feature is implemented... or is going to be. Will give to Pierre for disposition on this.. and if it is currently supported in Gecko .. Troy is doing the Pagination.
Assignee: dcone → pierre
Status: ASSIGNED → NEW
It's in Style already. I don't know for Layout yet. Reassigned to Troy.
Assignee: pierre → troy
Marking as REMIND. Probably won't be implemented for version 1.0
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → REMIND
Pierre, if page-break-* is not going to be supported by layout, then the style system should probably not recognise the property at all, much as with the "display: marker", "content: counter()", and other such issues. I'm not sure if it matters so much with this property, however, since there is no difference between recognising it but not supporting any of it and ignoring it altogether, AFAICT.
Status: RESOLVED → VERIFIED
OS: other → All
Hardware: Other → All
I don't think it matters with this property if the style sytem recognises it, and so Pierre can leave the support it. That way when layout does decide to support it we don't need to get Pierre to reenable it
reopen -> future
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
er, -> Future!
Assignee: troy → dcone
Severity: normal → enhancement
Status: REOPENED → NEW
QA Contact: shrir → sujay
Target Milestone: M15 → Future
Nominating this bug for nsbeta1 on behalf of firstname.lastname@example.org.
This is identical to bug 38164
*** Bug 38164 has been marked as a duplicate of this bug. ***
Proposing for Mozilla1.0 as with the dup'd bug. This would be very useful to have.
The testcase that I just attached (based on code in bug 38164) correctly adds the page breaks with IE5.
*** Bug 85279 has been marked as a duplicate of this bug. ***
I was wrong when I wrote on [2000-01-28 15:01] that page-break was in the style system already: it is parsed but it's not copied into the style context. Marked dependency on bug 72321.
Depends on: 72321
*** Bug 101960 has been marked as a duplicate of this bug. ***
What would it take to get this implemented sooner than 1.0? We have a customer requirement for this, so I would be willing to work on it myself.
Thanks for the offer... The changes in the style system are fairly easy: it's just an additional structure with the page breaks data (bug 72321 - I'll take care of it if you like). Most of the work is in Layout: Don and Rod may give you more details.
*** Bug 110185 has been marked as a duplicate of this bug. ***
taking, I would love to do this one, just don't have the time now.
Assignee: dcone → rods
Major corporations depend on eapp bugs, and need them to be fixed before they can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Target Milestone: Future → ---
16 years ago
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1
I would love to fix this, but at the moment the CSS parser isn't even collecting this information.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1
This requires substantial work and really is a feature. We will not be able to get to this for 1.0. Marking nsbeta1-
Mozila is AFAIK the only browser with CSS2 support which does _not_ implement this feature. Both Opera and IE>=5.5 supports this...
I'm taking the bug and will attach a patch shortly that uses rods' idea of creating dummy frames for page breaking. This will work for page-break-before:always and page-break-after:always. The other properties and values require much deeper layout changes that probably will not happen until long past m1.0.
Assignee: rods → karnaze
Created attachment 71320 [details] [diff] [review] patch to temporarily implement page-break-before/after:always This patch hasn't been tested much and there are a few things that still need to be done besides further testing - (1) the logic of creating page break frames in nsCSSFrameConstructor.cpp::ConstructFrame needs to copied to other custom construction methods (e.g. ConstructTableFrame), (2) the style system hacks should be removed and replaced with a new style struct; although if this weren't done, I don't think the 2 added data members on nsCSSDisplay would be that bad, assumming that nsCSSDisplay is not long lived like nsStyleDisplay.
Marking nsbeta1+ for supporting: page-break-before:always and page-break-after:always
Keywords: nsbeta1- → nsbeta1+
Just wanted to add my appreciation for you upping the priority on this issue, it's definitely welcome!
Created attachment 73255 [details] [diff] [review] revised patch In this patch tables handle page breaks internally. There is still a problem with the style system hacks and style context sharing.
Attachment #71320 - Attachment is obsolete: true
Created attachment 74243 [details] [diff] [review] revised patch
Attachment #73255 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Whiteboard: [Hixie-PF][eapp] → [Hixie-PF][eapp]PATCH
Created attachment 74265 [details] [diff] [review] revised patch with reviewer's suggestions Revised to include some omissions caught by attinasi. This patch (as does the previous one) also fixes the problems mentioned in comment #31, thanks to attinasi.
Attachment #74243 - Attachment is obsolete: true
Comment on attachment 74265 [details] [diff] [review] revised patch with reviewer's suggestions r= alexsavulov
Comment on attachment 74265 [details] [diff] [review] revised patch with reviewer's suggestions I think that the eCSSProperty_page_break_inside cases should either be put in, ore removed (commented at least) - there seems to be mixed attention given to that property. GetDesiredSize and Reflow should ASSERT/PRECONDITION aPresContent is non-null What does + // work around block bugs mean in GetDesiredSize? Shouldn't PageBreakFrame assert that we are in paged- mode (printing)? Anyway, those are minor points - sr=attinasi
Attachment #74265 - Flags: superreview+
Created attachment 74442 [details] [diff] [review] revised patch with additional reviewer's suggestions Encorporates all of attinasi's suggestions except the 1st one, which he agrees is ok to ommit.
Attachment #74265 - Attachment is obsolete: true
Comment on attachment 74442 [details] [diff] [review] revised patch with additional reviewer's suggestions a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74442 - Flags: approval+
+ CHECKDATA_PROP(nsCSSDisplay, mBreakBefore, CHECKDATA_VALUE, PR_FALSE), // temp fix for bug 2400 Could we please fix that comment to have the right bug number?
The patch is in. I'll fix the comment.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 16 years ago
Resolution: --- → FIXED
Is this fixed for all page-break-* properties now, or is there a bug to track the real fix (post 1.0)?
Changing summary to restrict to page-break-before/after:always. Someone can open a new bug for full page break support, but it will probably not be fixed for a long time.
Summary: CSS page-break-* Support ? → CSS page-break-before/after:always Support
I've opened bug 132035 for support of all CSS2 page-break-* properties.
Can anyone file a bug to get some tests into the printing tests used for the smoketesting ?
Andreas this is fixed now..can you verify this in latest build ? thanks...let me know if this is working for you now...
verified...REOPEN if still not fixed...h
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.