Re: block-containers with BPD set

2005-01-27 Thread Jeremias Maerki
Thank you, Victor, now I think I finally understand what you mean.
However, I see is that this could lead to very funny results. Imagine a
BC with BPD set, overflow=repeat and reference-orientation=180. When the
contents overflow the first VPA, a new one is created under the first
(in BC parent's BP direction), if there's enough room for a second VPA
on the same reference area. If you looked at the paper upside down after
printing, it would look like this (the number indicate the order of the
blocks inside the BC):

5
6
7
8
1
2
3
4

Just for the fun of it. :-) I know it's a bit exotic.

I don't quite see the use-cases for this whole thing yet. But for XSL
1.0 it essentially means that there's only one VPA if the BPD is set,
right? So the current implementation in FOP would be ok for now.


Jeremias Maerki



RE: block-containers with BPD set

2005-01-27 Thread Victor Mote
Jeremias Maerki wrote:

> Thanks to Victor and Andreas for helping me here, although 
> I'm still confused.
> 
> On 27.01.2005 00:25:27 Victor Mote wrote:
> > Andreas L. Delmelle wrote:
> > 
> > > Do you feel the contents of the block-container should 
> not be broken 
> > > up at all? (Hence the analogy to a fo:external-graphic?)
> > 
> > No, sorry, I didn't mean to imply that. I think the contents can 
> > (possibly, depending on the overflow constraints) be broken up, but 
> > that the viewport cannot be. So the analogy with external-graphic 
> > breaks down there. The similarity is in the fact that they (in this 
> > case) have a fixed size and must move in their entirety.
> 
> This seems to be contradicting. I don't see how the overflow 
> property would control such behaviour. Also, if you say that 
> they "must move in their entiretly", how can the contents be 
> broken up? Or does "they"
> refer to something else than the contents?
 
I'll try to clarify what I mean. A distinction must be made between the
viewport area(s)that are created by the block-container, which I will call
the container areas, and the areas that are generated by the children of the
block-container (block-level FOs), which I will call the child areas. Each
viewport area is a fixed size in the scenario described. It cannot be split
between columns or pages. If there is not room for it in its entirety on
page n, it must be moved in its entirety to page n + 1. However the child
areas are free to flow between the container areas, just like they would
flow between the main-reference-areas on two pages. So a block inside the
block-container might have part of its contents in one container area and
part in a subsequent one.

The overflow property enters in because of the "Issue" that you mentioned
(1.1 Standard, Section 6.5.3): "The overflow property applies to this
formatting object. There is a question of interpretation on whether the
fo:block-container generates more than one area when the
block-progression-dimension is fixed. The change proposed here
requires the user to specify the "repeat" value for the overflow property
when they want multiple instances of the block-container rather than the
initial value for overflow."

The default value for overflow is auto, which probably results in contents
being clipped for printed media (there being no opportunity for a
scroll-bar). But if the user sets the value to "repeat", additional content
areas can be created to contain the overflowed content. If the overflow
settings are such that overflowed content has no place to go, then
conceptually it all stays in the one container area, and is clipped. So the
setting of the overflow value on the block-container directly affects
whether those contents might be split between two container areas or simply
clipped.

You are correct that "they" in my original post did not refer to the child
areas, but rather to the container areas. My apologies for the ambiguity.

> > Yes. This seems most useful to me in cases where the viewport would 
> > occupy most or all of the main-reference-area, as in the 
> case of the 
> > report-turned-sideways example I gave earlier. Suppose you 
> have some 
> > unknown quantity of 132-column output you want to show in landscape 
> > mode. You can create a fixed-size block-container, tell it 
> to overflow 
> > into other ones, add a "break" constraint at the end of 
> each page, and 
> > you now get n pages of output.
> 
> Well, this is a case where I'd rather use a separate 
> page-sequence with the reference orientation set on the 
> simple-page-master.

Fair enough. Here are some things to consider:
1. I think using a block-container gives you the *potential* option of
letting the viewports be out-of-line areas. So your content might read: "See
Listing 1 , where the effects
of this ..." The content continues, but perhaps the next 3 pages are filled
with the block-container contents. I am not yet convinced that I fully grasp
all of the implications of the ordering issues, so it may be that this isn't
supported by the Standard.
2. What if the requirement is that 2 portrait "pages" be turned 90 degrees,
side-by-side, on the now landscape page? Depending on the amount of room on
the first page, and the parity of the number of such pages, you might end up
with an empty half-page. If your content needs to continue (as opposed to
looking like a new chapter), the repeating block-container looks like a good
option.

Victor Mote



Re: block-containers with BPD set

2005-01-27 Thread Jeremias Maerki
Thanks to Victor and Andreas for helping me here, although I'm still
confused.

On 27.01.2005 00:25:27 Victor Mote wrote:
> Andreas L. Delmelle wrote:
> 
> > Do you feel the contents of the block-container should not be 
> > broken up at all? (Hence the analogy to a fo:external-graphic?)
> 
> No, sorry, I didn't mean to imply that. I think the contents can (possibly,
> depending on the overflow constraints) be broken up, but that the viewport
> cannot be. So the analogy with external-graphic breaks down there. The
> similarity is in the fact that they (in this case) have a fixed size and
> must move in their entirety.

This seems to be contradicting. I don't see how the overflow property
would control such behaviour. Also, if you say that they "must move in
their entiretly", how can the contents be broken up? Or does "they"
refer to something else than the contents?



> > (more or less the effect the page-height property has on the 
> > page-viewport-areas generated during formatting) In that 
> > case, is it even conceivable to have more than one 
> > viewport-area for a block-container with constrained bpd?
> 
> Yes. This seems most useful to me in cases where the viewport would occupy
> most or all of the main-reference-area, as in the case of the
> report-turned-sideways example I gave earlier. Suppose you have some unknown
> quantity of 132-column output you want to show in landscape mode. You can
> create a fixed-size block-container, tell it to overflow into other ones,
> add a "break" constraint at the end of each page, and you now get n pages of
> output.

Well, this is a case where I'd rather use a separate page-sequence with the
reference orientation set on the simple-page-master.

> > Or would it mean that _all_ of them taken together should be 
> > _that_ big?
> 
> The previously-cited 1.1 item seems to indicate that the constraint applies
> to each of the viewport areas individually as opposed to all of them in
> total. However, I could misunderstand.
> 
> > Having no constraints on the keeps, and only the bpd 
> > specified, it seems perfectly legal to break and interpret 
> > the bpd constraint as a total that may be divided over 
> > multiple viewport areas, but it may seem a bit tricky.
> 
> You may be right, but I can't think of a case where that would be useful.
> 
> AFAICT, keeps and space constraints would be left intact for the contents of
> the block-container. So, if a decision has been made that an additional
> viewport is needed to fit the contents, the keeps, breaks, and spaces would
> be used to decide which content went to an anterior vp and which to a
> posterior vp, just like in any page-break decision.

Hmm, seems like there's some room for interpretation. Yet another
question for the FO WG. Sigh.

I guess we're not so bad off with the current handling, so I'll let it
be for the moment and go on to more important tasks. At any rate, this
thread is flagged in my mail client...

Thanks,
Jeremias Maerki



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Andreas L. Delmelle wrote:

> Do you feel the contents of the block-container should not be 
> broken up at all? (Hence the analogy to a fo:external-graphic?)

No, sorry, I didn't mean to imply that. I think the contents can (possibly,
depending on the overflow constraints) be broken up, but that the viewport
cannot be. So the analogy with external-graphic breaks down there. The
similarity is in the fact that they (in this case) have a fixed size and
must move in their entirety.

> As an attempt to clarify:
> I wasn't 100% certain, but IIC, not breaking the 
> block-container between the two blocks would come down to 
> having default constraints for the keep-* properties (initial 
> value other than "auto")
> 
> Very rough interpretation of how I read it, for the block-container :
> - keep-with-previous="always" (only in case one of its 
> children returns a reference-level-out-of-line area ~ 
> side-float|absolute) or "auto" (in all other cases)
> - a default of keep-together="auto"
> 
> > The user has dogmatically told us how big the viewport(s) should be.
> 
> More precisely:
> "The user has dogmatically told us the constraints to which 
> all viewport-areas generated by the block-container are subject."
> Would this mean that _each_ generated viewport-area has to be 
> _that_ big?

Yes (if I am right). They can choose not to constrain it at all, or they can
constrain it flexibly with a . The fact that they have rigidly
specified the value indicates that they want it to be that size.

> (more or less the effect the page-height property has on the 
> page-viewport-areas generated during formatting) In that 
> case, is it even conceivable to have more than one 
> viewport-area for a block-container with constrained bpd?

Yes. This seems most useful to me in cases where the viewport would occupy
most or all of the main-reference-area, as in the case of the
report-turned-sideways example I gave earlier. Suppose you have some unknown
quantity of 132-column output you want to show in landscape mode. You can
create a fixed-size block-container, tell it to overflow into other ones,
add a "break" constraint at the end of each page, and you now get n pages of
output.

> Or would it mean that _all_ of them taken together should be 
> _that_ big?

The previously-cited 1.1 item seems to indicate that the constraint applies
to each of the viewport areas individually as opposed to all of them in
total. However, I could misunderstand.

> Having no constraints on the keeps, and only the bpd 
> specified, it seems perfectly legal to break and interpret 
> the bpd constraint as a total that may be divided over 
> multiple viewport areas, but it may seem a bit tricky.

You may be right, but I can't think of a case where that would be useful.

AFAICT, keeps and space constraints would be left intact for the contents of
the block-container. So, if a decision has been made that an additional
viewport is needed to fit the contents, the keeps, breaks, and spaces would
be used to decide which content went to an anterior vp and which to a
posterior vp, just like in any page-break decision.

Victor Mote



RE: block-containers with BPD set

2005-01-26 Thread Andreas L. Delmelle
> -Original Message-
> From: Victor Mote [mailto:[EMAIL PROTECTED]
> Sent: woensdag 26 januari 2005 21:49
>
> Just to be clear (not argumentative), I was saying something quite
> different. For the example that Andreas has given, my
> understanding is that there would only be one child
> viewport area, containing the entire contents of both blocks,
> but that it would be pushed onto the following column/page.

Do you feel the contents of the block-container should not be broken up at
all? (Hence the analogy to a fo:external-graphic?)

As an attempt to clarify:
I wasn't 100% certain, but IIC, not breaking the block-container between the
two blocks would come down to having default constraints for the keep-*
properties (initial value other than "auto")

Very rough interpretation of how I read it, for the block-container :
- keep-with-previous="always" (only in case one of its children returns a
reference-level-out-of-line area ~ side-float|absolute) or "auto" (in all
other cases)
- a default of keep-together="auto"

> The user has dogmatically told us how big the viewport(s) should be.

More precisely:
"The user has dogmatically told us the constraints to which all
viewport-areas generated by the block-container are subject."
Would this mean that _each_ generated viewport-area has to be _that_ big?
(more or less the effect the page-height property has on the
page-viewport-areas generated during formatting) In that case, is it even
conceivable to have more than one viewport-area for a block-container with
constrained bpd?
Or would it mean that _all_ of them taken together should be _that_ big?

Having no constraints on the keeps, and only the bpd specified, it seems
perfectly legal to break and interpret the bpd constraint as a total that
may be divided over multiple viewport areas, but it may seem a bit tricky.
One block-container having two vpa's for two rectangles over two pages. Its
children generating a possible total of three areas, two of which are inside
the vpa for the rectangle on the first page.

Greetz,

Andreas



Re: block-containers with BPD set

2005-01-26 Thread The Web Maestro
We can't unsubscribe you. To unsubscribe, you need to send an e-mail to:
[EMAIL PROTECTED]
Web Maestro Clay
On Jan 26, 2005, at 1:16 PM, Feifei Lu wrote:
please remove my email address in this list. Thanks.
--- Victor Mote <[EMAIL PROTECTED]> wrote:
Andreas L. Delmelle wrote:
In either case it seems to make little sense to speak of
'remaining space'
as in 'the space not allocated by descendant FOs inside the
b-c', unless you mean the space remaining on the _page_ after
the first child viewport for the b-c is added. The sum of the
b-p-d of the two child viewports will be five units, period.
Just to be clear (not argumentative), I was saying something quite
different. For the example that Andreas has given, my understanding
is that
there would only be one child viewport area, containing the entire
contents
of both blocks, but that it would be pushed onto the following
column/page.
Only if the contents didn't all fit into the first viewport would
additional
ones be created (and then only if the overflow properties are set
properly).
The user has dogmatically told us how big the viewport(s) should be.
Victor Mote


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


RE: block-containers with BPD set

2005-01-26 Thread Andreas L. Delmelle

try sending a message to '[EMAIL PROTECTED]'

> -Original Message-
> From: Feifei Lu [mailto:[EMAIL PROTECTED]
> Sent: woensdag 26 januari 2005 22:16
> To: fop-dev@xml.apache.org
> Subject: RE: block-containers with BPD set
> 
> 
> please remove my email address in this list. Thanks.



RE: block-containers with BPD set

2005-01-26 Thread Feifei Lu
please remove my email address in this list. Thanks.
--- Victor Mote <[EMAIL PROTECTED]> wrote:

> Andreas L. Delmelle wrote:
> 
> > In either case it seems to make little sense to speak of 
> > 'remaining space'
> > as in 'the space not allocated by descendant FOs inside the 
> > b-c', unless you mean the space remaining on the _page_ after 
> > the first child viewport for the b-c is added. The sum of the 
> > b-p-d of the two child viewports will be five units, period.
> 
> Just to be clear (not argumentative), I was saying something quite
> different. For the example that Andreas has given, my understanding
> is that
> there would only be one child viewport area, containing the entire
> contents
> of both blocks, but that it would be pushed onto the following
> column/page.
> Only if the contents didn't all fit into the first viewport would
> additional
> ones be created (and then only if the overflow properties are set
> properly).
> The user has dogmatically told us how big the viewport(s) should be.
> 
> Victor Mote
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Andreas L. Delmelle wrote:

> In either case it seems to make little sense to speak of 
> 'remaining space'
> as in 'the space not allocated by descendant FOs inside the 
> b-c', unless you mean the space remaining on the _page_ after 
> the first child viewport for the b-c is added. The sum of the 
> b-p-d of the two child viewports will be five units, period.

Just to be clear (not argumentative), I was saying something quite
different. For the example that Andreas has given, my understanding is that
there would only be one child viewport area, containing the entire contents
of both blocks, but that it would be pushed onto the following column/page.
Only if the contents didn't all fit into the first viewport would additional
ones be created (and then only if the overflow properties are set properly).
The user has dogmatically told us how big the viewport(s) should be.

Victor Mote



RE: block-containers with BPD set

2005-01-26 Thread Andreas L. Delmelle
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]


> ...Anyway, maybe I should ask the question in a different way:
>
> Given a block-container where the BPD is specified, are its children
> subject to column/page breaking if the whole block-container doesn't fit
> into the available area in BP direction?

So the question is, given an input like

fo:block-container b-p-d="5"
  fo:block
block A, with b-p-d of max. 3 (specified/calculated?)
  /fo:block
  fo:block
block B, with b-p-d of max. 2 (specified/calculated?)
  /fo:block
/fo:block-container

What should happen when the block-container as a whole doesn't fit on the
page, and the area for block A is too small to fill up all of the remaining
space (say, a remaining space of 4 units)? A space of at least one unit will
be carried over to the next page, but...
Should block B be split in two areas of one unit, or should the break occur
before the single area (2 units) for block B?
And what should happen with the space remaining after area A is added, and B
as a whole shifts to the next page?

> [Victor:]

> My reading of the passage cited is that, while it may be
> possible for there to be more than one immediate child viewport,
> each of the immediate child viewports fits into exactly one
> rectangle on one page, ... Now, if by "children" you are
> referring to (for example) a block object that is inside
> the block-container, then yes, that block could generate
> areas that are inside more than one of the immediate child
> viewport(s). In other words, the contents of the block-
> container could flow from one viewport area to another,
> but each viewport area itself must remain in one piece.

I very much agree with this assessment. It seems the answer lies in the fact
that:
a. either the second block is split over the two child viewports
b. or it is moved as a whole to the child viewport on the next page

In either case it seems to make little sense to speak of 'remaining space'
as in 'the space not allocated by descendant FOs inside the b-c', unless you
mean the space remaining on the _page_ after the first child viewport for
the b-c is added. The sum of the b-p-d of the two child viewports will be
five units, period.
In that case, the space of one unit could still play a role in the layout of
the nearest ancestor reference-area --may be the area generated by the
immediate parent FO, but could also be the current-page area.
In that context, the question of what to do with that extra space suddenly
becomes meaningful, but it may lead one to look for pointers in other places
...?


HTH

Greetz,

Andreas



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Jeremias Maerki wrote:

> Given a block-container where the BPD is specified, are its 
> children subject to column/page breaking if the whole 
> block-container doesn't fit into the available area in BP 
> direction? If yes, how is the remaining space in BP direction 

My reading of the passage cited is that, while it may be possible for there
to be more than one immediate child viewport, each of the immediate child
viewports fits into exactly one rectangle on one page, i.e. it cannot be
broken into more than one piece. Now, if by "children" you are referring to
(for example) a block object that is inside the block-container, then yes,
that block could generated areas that are inside more than one of the
immediate child viewport(s). In other words, the contents of the
block-container could flow from one viewport area to another, but each
viewport area itself must remain in one piece.

So, the direct answer to your question is (I think) "no". If the BP
constraints cannot be satisfied in the current column/page, the viewport
must be moved to a subsequent one. That may seem klunky, but the user can
prevent it by making the BPD a .

> direction? If yes, how is the remaining space in BP direction 
> which is not taken up the BC's children to be handled?
> 
> The quote you provided above probably point in the right 
> direction. But I guess my problem is that I haven't found the 
> part of the spec, yet, that establishes this constraint for 
> block-progression-dimension. I've searched the spec back and 
> forth and haven't found anything. After a lot of thinking I 
> believe it's chapter 4.3.2 "Overconstrained 
> space-specifiers", but I don't understand how this explains 
> whether to do breaking inside the block-container or not.

AFAICT, space-specifiers aren't part of the question. In my mind
block-container is analogous to an external-graphic. You wouldn't split an
image into two pieces. If the user has said
block-progression-dimenension="6cm", he/she has deliberately placed a
constraint on the viewport. The default behavior is that there is no such
constraint, that the viewport expands and contracts as needed to contain the
contents.

The use-case for block-container may help also. Suppose you are rotating the
contents 90 degrees so that you can show, for example, a wide page in
landscape mode. You might want the contents to use the whole page, so
specifying the BPD/IPD allows you to insist upon that.

I'm not sure I am right about this, and don't mean to sound dogmatic. This
is just my understanding of the matter.

Victor Mote.



Re: block-containers with BPD set

2005-01-26 Thread Jeremias Maerki

On 26.01.2005 18:43:58 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > Now, I've got a different problem. I run accross a bug in 
> > layout concerning block-containers with height/BPD specified 
> > (absolute-position="auto"). I tried to fix it but I can't 
> > find the passage in the spec that tells me how to deal with 
> > the space that is not allocated by descendant FOs inside the 
> > block-container.
> > 
> > Is this space considered as part of the padding-after, and if 
> > yes with what conditionality?
> 
> BPD and IPD both specify the size of the content-rectangle, so no part of
> unused BPD could be considered part of padding.

Makes sense.

> > The problem is page/column breaking. Normal blocks can be 
> > broken between lines which is probably also the case for 
> > plain block-containers (no properties specified). But as soon 
> > as the BPD is predefined
> > (autoheight=false) it is unclear to me how to handle it.
> > 
> > I also saw that in the 1.1 WD there is an issue (see 
> > block-container) that may be related to this, but it didn't help.
> 
> I'm not sure I understand the question or know the answer. What I think you
> have described is an area with an absolute size and a relative position that
> does not fit in the current column or page, but that may not use all of the
> available BPD. Regardless of how well the contents fit inside the area,
> doesn't such an area have to be forced to the next page or column (unless it
> floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies
> this a bit by saying "All generated viewport-areas are subject to the
> constraints given by the block-progression-dimension and
> inline-progression-dimension traits of the fo:block-container". I take this
> to mean that a block-container might generate more than one such
> viewport-area if the contents are too big to fit into one (subject to the
> 1.1 issue that you mention), but that, in any case, if the contents are too
> small, the generated viewport-area must meet the IPD and BPD constraints.
> The user can specify IPD and BPD as  if they want to allow the
> rectangle some flexibility in how it is sized.
> 
> HTH.

It does, at least a bit. Anyway, maybe I should ask the question in a
different way:

Given a block-container where the BPD is specified, are its children
subject to column/page breaking if the whole block-container doesn't fit
into the available area in BP direction? If yes, how is the remaining
space in BP direction which is not taken up the BC's children to be
handled?

The quote you provided above probably point in the right direction. But
I guess my problem is that I haven't found the part of the spec, yet,
that establishes this constraint for block-progression-dimension. I've
searched the spec back and forth and haven't found anything. After a lot
of thinking I believe it's chapter 4.3.2 "Overconstrained space-specifiers",
but I don't understand how this explains whether to do breaking inside
the block-container or not.

Thanks,
Jeremias Maerki



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Jeremias Maerki wrote:

> Now, I've got a different problem. I run accross a bug in 
> layout concerning block-containers with height/BPD specified 
> (absolute-position="auto"). I tried to fix it but I can't 
> find the passage in the spec that tells me how to deal with 
> the space that is not allocated by descendant FOs inside the 
> block-container.
> 
> Is this space considered as part of the padding-after, and if 
> yes with what conditionality?

BPD and IPD both specify the size of the content-rectangle, so no part of
unused BPD could be considered part of padding.

> The problem is page/column breaking. Normal blocks can be 
> broken between lines which is probably also the case for 
> plain block-containers (no properties specified). But as soon 
> as the BPD is predefined
> (autoheight=false) it is unclear to me how to handle it.
> 
> I also saw that in the 1.1 WD there is an issue (see 
> block-container) that may be related to this, but it didn't help.

I'm not sure I understand the question or know the answer. What I think you
have described is an area with an absolute size and a relative position that
does not fit in the current column or page, but that may not use all of the
available BPD. Regardless of how well the contents fit inside the area,
doesn't such an area have to be forced to the next page or column (unless it
floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies
this a bit by saying "All generated viewport-areas are subject to the
constraints given by the block-progression-dimension and
inline-progression-dimension traits of the fo:block-container". I take this
to mean that a block-container might generate more than one such
viewport-area if the contents are too big to fit into one (subject to the
1.1 issue that you mention), but that, in any case, if the contents are too
small, the generated viewport-area must meet the IPD and BPD constraints.
The user can specify IPD and BPD as  if they want to allow the
rectangle some flexibility in how it is sized.

HTH.

Victor Mote



block-containers with BPD set

2005-01-26 Thread Jeremias Maerki
Thanks for all the comments so far on my questions. I'm afraid I have to
postpone some of the issues, however.

Now, I've got a different problem. I run accross a bug in layout
concerning block-containers with height/BPD specified
(absolute-position="auto"). I tried to fix it but I can't find the
passage in the spec that tells me how to deal with the space that is not
allocated by descendant FOs inside the block-container.

Is this space considered as part of the padding-after, and if yes with
what conditionality?

The problem is page/column breaking. Normal blocks can be broken between
lines which is probably also the case for plain block-containers (no
properties specified). But as soon as the BPD is predefined
(autoheight=false) it is unclear to me how to handle it.

I also saw that in the 1.1 WD there is an issue (see block-container)
that may be related to this, but it didn't help.

Any pointers are appreciated.

Jeremias Maerki



DO NOT REPLY [Bug 664] - Basic-Link does not move with its content, when using absolute postitioned block containers

2002-11-11 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=664>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=664

Basic-Link does not move with its content, when using absolute postitioned block 
containers

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-11 23:46 
---
Works with current CVS (maintenance branch)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: block containers

2002-09-19 Thread J.Pietschmann

[EMAIL PROTECTED] wrote:
> Running Fop 0.20.3 we cannot get fo:Block-containers to work at all.
...
> -
> java.lang.ClassCastException: org.apache.fop.layout.BlockArea
> at
> org.apache.fop.fo.flow.BlockContainer.layout(BlockContainer.java:109)

You must not put block-container into another block. For FOP,
a block container musst be a child of either another
block-container (not recommended), a flow or a static-content.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




block containers

2002-09-18 Thread kieran . donovan


Running Fop 0.20.3 we cannot get fo:Block-containers to work at all.

We are translating from XSLT with XML to PDF.
e.g.

Fop -xml test1.xml   -xsl test1.xsl   -pdf test1.pdf

Any ideas ??

thanks,

Kieran




XSLT
==



  Insured name




 



RESULT
=
.
.

DEBUG]: Pages rendererd: 0

[ERROR]: org.apache.fop.layout.BlockArea
org.apache.fop.apps.FOPException: org.apache.fop.layout.BlockArea
at org.apache.fop.apps.Driver.render(Driver.java:486)
at
org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:72)
at org.apache.fop.apps.Fop.main(Fop.java:19)

-

javax.xml.transform.TransformerException: org.apache.fop.layout.BlockArea
at
org.apache.xalan.transformer.TrAXFilter.parse(TrAXFilter.java:137)
at org.apache.fop.apps.Driver.render(Driver.java:481)
at
org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:72)
at org.apache.fop.apps.Fop.main(Fop.java:19)

-
javax.xml.transform.TransformerException: org.apache.fop.layout.BlockArea
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1212)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:2894)
at java.lang.Thread.run(Unknown Source)
-
java.lang.ClassCastException: org.apache.fop.layout.BlockArea
at
org.apache.fop.fo.flow.BlockContainer.layout(BlockContainer.java:109)
at org.apache.fop.fo.flow.Block.layout(Block.java:262)
at org.apache.fop.fo.flow.Flow.layout(Flow.java:156)
at org.apache.fop.fo.flow.Flow.layout(Flow.java:113)
at
org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:296)
at
org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182)
at
org.apache.xalan.transformer.ResultTreeHandler.endElement(ResultTreeHandler.java:284)
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:749)
at
org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemForEach.java:495)
at
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:193)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2154)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2097)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2029)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1189)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:2894)
at java.lang.Thread.run(Unknown Source)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]