xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From COFFMAN Steven <SCoff...@CBSINC.com>
Subject RE: TableCell or TableRow Larger than a page( bug fix )
Date Tue, 05 Dec 2000 17:42:12 GMT
The extra pages are printed after the last page of the normal page flow when
I print out my oversized excel spreadsheet. That behaviour would avoid
confusion here as well.

-----Original Message-----
From: Corinna Hischke [mailto:corinna@infix.de]
Sent: Tuesday, December 05, 2000 12:04 PM
To: fop-dev@xml.apache.org
Subject: Re: TableCell or TableRow Larger than a page( bug fix )


Hi Steve

> What do you do when a table row that is too wide for a page has the Keep
> Together attribute?
>
> My preference would be just to handle it so that it's like a spreadsheet.
> When you print out a spreadsheet where a row doesn't fit, a blank page
> containing the overflow portion of the rows is printed.
>

That's what I think, too. The prerequisits for this are:

1. The overflow property must have a value of "visible", "scroll" or "auto".

2. The block-progression is top to bottom.

3. There is no possibility to extend the pages from left to right, e.g. the
    media-usage property is
    - "pagination" or
    - "bounded-in-one-dimension" and page-width is fixed or
    - "auto" and that is interpreted as one of the two above.

If then an overflow in line progression dimension comes up, the overflowing
portion should be placed on an extra page, which must not be part of the
normal page flow. (Otherwise it would get page headers and footers as well
as a page number.)

But: If such overflows occur many times inside one document, the many extra
pages may cause some confusion. ;-)

- Corinna

> -Steve
> -----Original Message-----
> From: Corinna Hischke [mailto:corinna@infix.de]
> Sent: Monday, December 04, 2000 9:19 AM
> To: fop-dev@xml.apache.org
> Subject: Re: TableCell or TableRow Larger than a page( bug fix )
>
>
> Hi all,
>
> Karen suggested a solution which is fully spec-aware (as far as I can
> tell) and conforms to user expectations as well. I strongly support
> that, especially her two-step-approach:
>
> 1. Try to satisfy requirements specified by properties.
>
> 2. Deliberately give up certain constraints if a sensible solution
>    cannot be found otherwise (e.g. splitting content is preferable to
>    losing content).
>
> As regards Keiron's argument that complete rows should always appear
> on the same page because otherwise we would in effect have two rows: I
> don't agree for two reasons.
>
> 1. If we applied that argument consistently, we could not split
>    anything. Splitting a table would in effect create two tables.
>    Splitting a block would in effect create two blocks. I guess this
>    is not a 'clear indication of voter intent' ;-).
>
> 2. The table row property 'keep-together' would be meaningless.
>
> - Corinna
>
>
>

Mime
View raw message