You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2005/09/01 15:53:46 UTC
e-g with padding and borders
I think the area tree viewport generated by the current version for an e-g
with padding and borders is wrong.
Here is the fo snippet (from external-graphic_border_padding.xml):
<fo:external-graphic
src="../../resources/images/bgimg300dpi.jpg"
border="solid 5pt" padding="5pt" background-color="white"
/>
and this is the generated viewport:
<viewport background="color=#ffffff" bap="10000 10000 10000 10000"
border-after="(solid,#000000,5000)"
border-before="(solid,#000000,5000)"
border-end="(solid,#000000,5000)"
border-start="(solid,#000000,5000)"
bpd="66080" bpda="86080"
ipd="66080" ipda="86080"
padding-after="5000"
padding-before="5000"
padding-end="5000"
padding-start="5000">
<image bap="0 0 0 0" bpd="0" ipd="0"
pos="10000 10000 46080 46080"
url="../../resources/images/bgimg300dpi.jpg" />
</viewport>
The viewport bpd/ipd includes the padding and border width while it should
only be the content width of 46080.
Am I correct? I am happy to fix it - just would like confirmation that this
is actually incorrect. BTW, the generated PDF looks pretty wrong to me as
well.
Manuel
PS: Not sure how that got through the layout engine tests!
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
On Fri, 2 Sep 2005 10:01 pm, Jeremias Maerki wrote:
> On 02.09.2005 15:38:41 Manuel Mall wrote:
> > The problems reported here with e-g and padding / borders apply
> > equally to i-f-o. It's not too hard to fix. While doing this I
> > noticed that the code for the i-f-o LM and e-g LM is logically
> > largely identical although some bits have been coded slightly
> > differently.
> >
> > Any concerns if I put a common LM for i-f-o, e-g that into the LM
> > inheritance hierarchy (working name ForeignContent LM, i.e. content
> > not native of XSL-FO)?
> >
> > So we have something like:
> > i-f-o LM implements ForeignContent LM
> > e-g LM implements ForeignContent LM
> > and
> > ForeignContent LM implements LeafNode LM.
>
> You mean "extends", not "implements", right?
>
Yes, of course...
> > This would allow all the code related to the viewport generation,
> > content scaling, and rectangle sizing for i-f-o and e-g to be in
> > one place only.
> >
> > The i-f-o and e-g LMs would become very small basically only
> > providing the image or foreignObject area to be placed into the
> > viewport.
>
> +1 to that but since this new class will be abstract I'd like to have
> it marked as such by naming it AbstractGraphicsLM (which also shows
> how I would name it). :-)
>
Yes, should be Abstract and Graphics is fine with me. Just wasn't sure
if all possible i-f-o's will be of a graphic nature. But that doesn't
really matter.
> Thanks for handling that.
>
> BTW, I'll commit a tiny little change in IFOLM in a few minutes, due
> to a change in to FO tree. Shouldn't be a problem, though. Well, I
> hope. :-)
>
Noted :-)
> Jeremias Maerki
Manuel
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 02.09.2005 15:38:41 Manuel Mall wrote:
> The problems reported here with e-g and padding / borders apply equally
> to i-f-o. It's not too hard to fix. While doing this I noticed that the
> code for the i-f-o LM and e-g LM is logically largely identical
> although some bits have been coded slightly differently.
>
> Any concerns if I put a common LM for i-f-o, e-g that into the LM
> inheritance hierarchy (working name ForeignContent LM, i.e. content not
> native of XSL-FO)?
>
> So we have something like:
> i-f-o LM implements ForeignContent LM
> e-g LM implements ForeignContent LM
> and
> ForeignContent LM implements LeafNode LM.
You mean "extends", not "implements", right?
> This would allow all the code related to the viewport generation,
> content scaling, and rectangle sizing for i-f-o and e-g to be in one
> place only.
>
> The i-f-o and e-g LMs would become very small basically only providing
> the image or foreignObject area to be placed into the viewport.
+1 to that but since this new class will be abstract I'd like to have it
marked as such by naming it AbstractGraphicsLM (which also shows how I
would name it). :-)
Thanks for handling that.
BTW, I'll commit a tiny little change in IFOLM in a few minutes, due to
a change in to FO tree. Shouldn't be a problem, though. Well, I hope. :-)
Jeremias Maerki
Re: e-g with padding and borders
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 2, 2005, at 18:42, Vincent Hennebert wrote:
Hi Vincent,
> You're right. Indeed both situations below are handled by the
> standard, thanks to border conditionality and is-first/is-last traits.
>
> Thanks for the pointer!
You're welcome, of course.
I have to correct myself on the following, though:
>> By default, the first would be applicable. If the user explicitly
>> specifies
>> border-start-width.conditional="discard", the result would have to be
>> the second.
Re-reading the Rec, I believe it should be the other way round: if the
border-width is specified as a length, the conditionality is set to
"discard" by default.
So, the first of the two would need explicit:
border-start-width.conditionality="retain"
border-end-width.conditionality="retain"
Cheers,
Andreas
Re: e-g with padding and borders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Hi Andreas,
You're right. Indeed both situations below are handled by the standard, thanks
to border conditionality and is-first/is-last traits.
Thanks for the pointer!
Vincent
Andreas L Delmelle a écrit :
> On Sep 2, 2005, at 17:44, Vincent Hennebert wrote:
>
>
> Hi,
>
> <snip />
>
>>>> ________________
>>>> This is a | chunk of text |
>>>> -----------------
>>>> ______________
>>>> | with border | blah blah
>>>> ---------------
>>>>
>>>> blah blah
>>>>
>>>> What is more intuitive and could be expected by a user is the
>>>> following:
>>>> ______________
>>>> This is a | chunk of text
>>>> ---------------
>>>> _____________
>>>> with border | blah blah
>>>> -------------
>>>>
>>>> blah blah
>>>>
> <snip />
>
> Hmm... I remember reading something about this --wait a minute... Yep!
> Got it.
>
> See Rec 4.3.1 Space resolution rules
> all the way down
> "The border or padding at the start-edge or end-edge of an inline-area I
> may be specified as conditional. If so, then it is set to zero if its
> associated edge is a leading edge in a line-area, and the is-first trait
> of I is false, or if its associated edge is a trailing edge in a
> line-area, and the is-last trait of I is false."
>
> (see also: 7.7.9 border-before-width .. XSL modifications to the CSS
> Definition)
>
> By default, the first would be applicable. If the user explicitly specifies
> border-start-width.conditional="discard", the result would have to be
> the second.
>
> No extension needed.
>
>
> Cheers,
>
> Andreas
>
Re: e-g with padding and borders
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 2, 2005, at 17:44, Vincent Hennebert wrote:
Hi,
<snip />
>>> ________________
>>> This is a | chunk of text |
>>> -----------------
>>> ______________
>>> | with border | blah blah
>>> ---------------
>>>
>>> blah blah
>>>
>>> What is more intuitive and could be expected by a user is the
>>> following:
>>> ______________
>>> This is a | chunk of text
>>> ---------------
>>> _____________
>>> with border | blah blah
>>> -------------
>>>
>>> blah blah
>>>
<snip />
Hmm... I remember reading something about this --wait a minute... Yep!
Got it.
See Rec 4.3.1 Space resolution rules
all the way down
"The border or padding at the start-edge or end-edge of an inline-area
I may be specified as conditional. If so, then it is set to zero if its
associated edge is a leading edge in a line-area, and the is-first
trait of I is false, or if its associated edge is a trailing edge in a
line-area, and the is-last trait of I is false."
(see also: 7.7.9 border-before-width .. XSL modifications to the CSS
Definition)
By default, the first would be applicable. If the user explicitly
specifies
border-start-width.conditional="discard", the result would have to be
the second.
No extension needed.
Cheers,
Andreas
Re: e-g with padding and borders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
>>What disturbs me is that when one specifies a border around a chunk of text and
>>there is line-breaking, this border should appear and the end of the first line
>>and the beginning of second line, as below:
>> ________________
>> This is a | chunk of text |
>> -----------------
>> ______________
>> | with border | blah blah
>> ---------------
>>
>> blah blah
>>
>>What is more intuitive and could be expected by a user is the following:
>> ______________
>> This is a | chunk of text
>> ---------------
>> _____________
>> with border | blah blah
>> -------------
>>
>> blah blah
>>
>>but IIUC this is not allowed by the spec. I ask for confirmation here.
>
>
> I would agree that this is not allowed by the spec. The traits are the
> same for all areas. There don't seem to be any exceptions. Actually, I'm
> glad there aren't that would complicate things even more. :-) But maybe
> someone who thinks this would be an important feature could probably
> write an extension for that. :-)
I've just checked: with CSS this is the second layout which is rendered. So
there would be an incompatibility here between XSL-FO and CSS, which is
astonishing as the spec claims several times to promote compatibility.
Anyway, it's not an important feature for me :-]
Vincent
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 02.09.2005 16:22:02 Vincent Hennebert wrote:
> Jeremias Maerki a écrit :
> > The real problem IMO is probably block-level content in fo:inlines again.
> > How are these borders to be painted? A border around each
> > inlineblockparent (one for each block inside the inline)? I'm not sure
> > judging from the specification.
>
> Here the spec starts being really complicated. I would say you're right, thought
> not sure. See the last sentence of § 4.2.2: "Unless otherwise specified, the
> traits of a formatting object are present on each of its generated areas, and
> with the same value. (However, see sections [4.7.2 Line-building] and [4.9.4
> Border, Padding, and Background].)". The referred sections don't seem to hold
> for the fo:inline case.
You mean the two references to 4.7.2 and 4.9.4, right? I agree.
> What disturbs me is that when one specifies a border around a chunk of text and
> there is line-breaking, this border should appear and the end of the first line
> and the beginning of second line, as below:
> ________________
> This is a | chunk of text |
> -----------------
> ______________
> | with border | blah blah
> ---------------
>
> blah blah
>
> What is more intuitive and could be expected by a user is the following:
> ______________
> This is a | chunk of text
> ---------------
> _____________
> with border | blah blah
> -------------
>
> blah blah
>
> but IIUC this is not allowed by the spec. I ask for confirmation here.
I would agree that this is not allowed by the spec. The traits are the
same for all areas. There don't seem to be any exceptions. Actually, I'm
glad there aren't that would complicate things even more. :-) But maybe
someone who thinks this would be an important feature could probably
write an extension for that. :-)
> So the example you provided with the 2 <fo:block>blah blah</fo:block> is
> rendered correctly in terms of borders (but there should be no space between
> them, probably part of the rendering problem you raised).
Exactly.
Jeremias Maerki
Re: e-g with padding and borders
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> I think you're reaching a point where you should understand exactly how
> the Knuth model works. I haven't looked at how conditionality is
> implemented very closely. Without diving deeper into this myself I'm
> unable to help right now other than to point you to
> BlockStackingLayoutManager again which contains at least part of the
> code that deals with space conditionality. If the comments are right in
> BlockStackingLayoutManager conditionality has not even been implemented
> for blocks in the b-p-d.
We discussed this just the other day, and I thought the outcome was that
space conditionality for blocks in bpd is implemented, but precedence
isn't yet.
<snip/>
Chris
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
On Mon, 5 Sep 2005 09:51 pm, Jeremias Maerki wrote:
> I think you're reaching a point where you should understand exactly
> how the Knuth model works.
It had to happen eventually :-).
> I haven't looked at how conditionality is
> implemented very closely. Without diving deeper into this myself I'm
> unable to help right now other than to point you to
> BlockStackingLayoutManager again which contains at least part of the
> code that deals with space conditionality. If the comments are right
> in BlockStackingLayoutManager conditionality has not even been
> implemented for blocks in the b-p-d.
>
> If you really want to go down that road I suggest you get Donald
> Knuth's "Digital Typography" or another book that contains the essay
> "Breaking Paragraphs into Lines". There may also be a little
> information about handling conditionality in the mailing list
> archives. Sorry that I can't help more, but we're getting into
> complicated terrain here.
>
That's fine - I am just trying to extract as much information as
possible the "easy way" first. Also, even if conditionality is not
implemented may be some of the original designers of the implementation
would like to share their thoughts on this topic?
I'll see if I can get my hand on the book in the university library here
(btw - I am in Perth - Western Australia).
In the meantime I'll stick with the "discard" model which happens to be
the default anyway.
Manuel
> On 05.09.2005 14:52:23 Manuel Mall wrote:
> > On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> > > Jeremias,
> > >
> > > thanks for your patience in answering my questions.
> > >
> > > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > > > On 04.09.2005 16:34:35 Manuel Mall wrote:
> >
> > <snip/>
> >
> > > > > Another question for the "Knuth" experts. It appears the
> > > > > inline LMs don't make provisions in the IPD for
> > > > > borders/padding on inlines. I assume border/padding is
> > > > > logically like a (with the width of the border +
> > > > > padding) in front of the first and after the last character
> > > > > of the inline assuming
> > > > > .conditionality=discard, that is we don't want to have let's
> > > > > say a left border alone on the end of a line with the text
> > > > > starting on the next. For .conditionality=retain this width
> > > > > needs to be reserved as well at the beginning and end of each
> > > > > intermediate line. Any suggestions how this can/should be
> > > > > integrated into the linebreaking algorithm?
> > > >
> > > > Exactly like spaces, borders and padding in b-p-d for
> > > > block-level objects: additional auxiliary boxes and penalties.
> > > > See BlockStackingLayoutManager.addKnuthElementsFor*(). Line
> > > > breaking is the same as page breaking, only in a different
> > > > direction.
> > >
> > > Thanks for the pointer. I'll have a look at that.
> >
> > That seem to have done the trick. I have copied the Border/Padding
> > before/after logic from BlockStackingLayoutManager and made it into
> > a Border/Padding start/end for the Inline LM. There were some side
> > effects in that the Line LM expectd only KnuthInlineBoxes and now
> > we have some KnuthBoxes as well but I think I solved that ok.
> >
> > Next problem: border conditionality - how do I model that with the
> > Knuth approach? At the time I add the Border/Padding start/end
> > boxes we don't have line breaks so they really only cover the
> > .conditionality=discard case. How do I tell the algorithm to leave
> > enough space at the end of each line (and the beginning of the next
> > line) for the borders (in the case of .conditionality=retain)?
> >
> > > > <snip/>
> > > >
> > > >
> > > > Jeremias Maerki
> > >
> > > Manuel
> >
> > Manuel
>
> Jeremias Maerki
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
I think you're reaching a point where you should understand exactly how
the Knuth model works. I haven't looked at how conditionality is
implemented very closely. Without diving deeper into this myself I'm
unable to help right now other than to point you to
BlockStackingLayoutManager again which contains at least part of the
code that deals with space conditionality. If the comments are right in
BlockStackingLayoutManager conditionality has not even been implemented
for blocks in the b-p-d.
If you really want to go down that road I suggest you get Donald Knuth's
"Digital Typography" or another book that contains the essay "Breaking
Paragraphs into Lines". There may also be a little information about
handling conditionality in the mailing list archives. Sorry that I can't
help more, but we're getting into complicated terrain here.
On 05.09.2005 14:52:23 Manuel Mall wrote:
> On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> > Jeremias,
> >
> > thanks for your patience in answering my questions.
> >
> > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > > On 04.09.2005 16:34:35 Manuel Mall wrote:
> <snip/>
> > > > Another question for the "Knuth" experts. It appears the inline
> > > > LMs don't make provisions in the IPD for borders/padding on
> > > > inlines. I assume border/padding is logically like a (with
> > > > the width of the border + padding) in front of the first and
> > > > after the last character of the inline assuming
> > > > .conditionality=discard, that is we don't want to have let's say
> > > > a left border alone on the end of a line with the text starting
> > > > on the next. For .conditionality=retain this width needs to be
> > > > reserved as well at the beginning and end of each intermediate
> > > > line. Any suggestions how this can/should be integrated into the
> > > > linebreaking algorithm?
> > >
> > > Exactly like spaces, borders and padding in b-p-d for block-level
> > > objects: additional auxiliary boxes and penalties. See
> > > BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is
> > > the same as page breaking, only in a different direction.
> >
> > Thanks for the pointer. I'll have a look at that.
> >
>
> That seem to have done the trick. I have copied the Border/Padding
> before/after logic from BlockStackingLayoutManager and made it into a
> Border/Padding start/end for the Inline LM. There were some side
> effects in that the Line LM expectd only KnuthInlineBoxes and now we
> have some KnuthBoxes as well but I think I solved that ok.
>
> Next problem: border conditionality - how do I model that with the Knuth
> approach? At the time I add the Border/Padding start/end boxes we don't
> have line breaks so they really only cover the .conditionality=discard
> case. How do I tell the algorithm to leave enough space at the end of
> each line (and the beginning of the next line) for the borders (in the
> case of .conditionality=retain)?
>
> > > <snip/>
> > >
> > >
> > > Jeremias Maerki
> >
> > Manuel
>
> Manuel
Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> Jeremias,
>
> thanks for your patience in answering my questions.
>
> On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > On 04.09.2005 16:34:35 Manuel Mall wrote:
<snip/>
> > > Another question for the "Knuth" experts. It appears the inline
> > > LMs don't make provisions in the IPD for borders/padding on
> > > inlines. I assume border/padding is logically like a (with
> > > the width of the border + padding) in front of the first and
> > > after the last character of the inline assuming
> > > .conditionality=discard, that is we don't want to have let's say
> > > a left border alone on the end of a line with the text starting
> > > on the next. For .conditionality=retain this width needs to be
> > > reserved as well at the beginning and end of each intermediate
> > > line. Any suggestions how this can/should be integrated into the
> > > linebreaking algorithm?
> >
> > Exactly like spaces, borders and padding in b-p-d for block-level
> > objects: additional auxiliary boxes and penalties. See
> > BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is
> > the same as page breaking, only in a different direction.
>
> Thanks for the pointer. I'll have a look at that.
>
That seem to have done the trick. I have copied the Border/Padding
before/after logic from BlockStackingLayoutManager and made it into a
Border/Padding start/end for the Inline LM. There were some side
effects in that the Line LM expectd only KnuthInlineBoxes and now we
have some KnuthBoxes as well but I think I solved that ok.
Next problem: border conditionality - how do I model that with the Knuth
approach? At the time I add the Border/Padding start/end boxes we don't
have line breaks so they really only cover the .conditionality=discard
case. How do I tell the algorithm to leave enough space at the end of
each line (and the beginning of the next line) for the borders (in the
case of .conditionality=retain)?
> > <snip/>
> >
> >
> > Jeremias Maerki
>
> Manuel
Manuel
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
Jeremias,
thanks for your patience in answering my questions.
On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> On 04.09.2005 16:34:35 Manuel Mall wrote:
> > Had a look at this problem (fo:inline with border and padding) and
> > have a question regarding the "contract" between the area tree and
> > the renderers. The inlineParent area has a property called "offset"
> > (So have other areas). This offset is used for baseline alignment,
> > i.e. it is the offset relative to the dominant baseline. The
> > question is: Is this offset relative to the content rectangle or
> > the border rectangle?
>
> I don't know. I assume it's relative to the content rect. The area
> package operates mainly on the content rectangle. See Area where the
> getAllocBPD() and getAllocIPD() calculate their values from other
> values. That means that LM operate mainly on content rectangles. The
> other way around would mean a complication anyway.
>
That's fine but there is then a minor inconsistency in that for
viewports, like those generated for e-g and i-f-o the "offset" is
relative to the border rectangle. But may be that is consistent from
the point of view that those viewports are large allocation rectangles.
So in summary the contract is that the offset is relative to the
allocation rectangle. Sounds good to me.
> > In the example "some text <fo:inline border="..."> more text
> > </fo:inline>" if the offset is for the content rectangle it would
> > be 0 if the offset is for the border rectangle it would be "-
> > (Border + Padding) width". Currently the LM sets it to 0. Therefore
> > the renderers would need to compensate for that when drawing the
> > borders (which is currently not done).
>
> ....for inline, right? That may have to do with the different
> allocation rectangles. Anyway, I think the approach is correct. It
> might simply be that there are differences in the handling of inline
> parent and block areas.
>
Good, that means the changes I have made to the renderers don't need to
be undone or moved to the LMs.
> > Alternatively the LM could take the border into
> > account when calculating the offset and the renderers don't need to
> > make any adjustments in the BPD direction. Anyone knows what the
> > original design intention was?
>
> Your alternative would start to mix approaches to much IMO. ATM, a
> lot of calculations are done in the renderers and that should stay
> that way. The only alternative I see is doing the absolute placements
> on a page entirely in the LMs and let the renderers only perform some
> painting instructions. We've discussed that earlier this year and did
> not pursue.
>
That's fine I don't want to change approaches. I just want to understand
and make sure any changes I do are consistent with what has been done
so far. That's why I am asking so much :-).
> Just look at AbstractPathOrientedRenderer.handleBlockTraits() which
> does all the necessary calculations to determine the right positions
> and offset. The same should be done for all other area elements.
>
> > Another question for the "Knuth" experts. It appears the inline LMs
> > don't make provisions in the IPD for borders/padding on inlines. I
> > assume border/padding is logically like a (with the width of
> > the border + padding) in front of the first and after the last
> > character of the inline assuming .conditionality=discard, that is
> > we don't want to have let's say a left border alone on the end of a
> > line with the text starting on the next. For .conditionality=retain
> > this width needs to be reserved as well at the beginning and end of
> > each intermediate line. Any suggestions how this can/should be
> > integrated into the linebreaking algorithm?
>
> Exactly like spaces, borders and padding in b-p-d for block-level
> objects: additional auxiliary boxes and penalties. See
> BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is
> the same as page breaking, only in a different direction.
>
Thanks for the pointer. I'll have a look at that.
> <snip/>
>
>
> Jeremias Maerki
Manuel
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 04.09.2005 16:34:35 Manuel Mall wrote:
> Had a look at this problem (fo:inline with border and padding) and have
> a question regarding the "contract" between the area tree and the
> renderers. The inlineParent area has a property called "offset" (So
> have other areas). This offset is used for baseline alignment, i.e. it
> is the offset relative to the dominant baseline. The question is: Is
> this offset relative to the content rectangle or the border rectangle?
I don't know. I assume it's relative to the content rect. The area
package operates mainly on the content rectangle. See Area where the
getAllocBPD() and getAllocIPD() calculate their values from other values.
That means that LM operate mainly on content rectangles. The other way
around would mean a complication anyway.
> In the example "some text <fo:inline border="..."> more text
> </fo:inline>" if the offset is for the content rectangle it would be 0
> if the offset is for the border rectangle it would be "- (Border +
> Padding) width". Currently the LM sets it to 0. Therefore the renderers
> would need to compensate for that when drawing the borders (which is
> currently not done).
....for inline, right? That may have to do with the different allocation
rectangles. Anyway, I think the approach is correct. It might simply be
that there are differences in the handling of inline parent and block
areas.
> Alternatively the LM could take the border into
> account when calculating the offset and the renderers don't need to
> make any adjustments in the BPD direction. Anyone knows what the
> original design intention was?
Your alternative would start to mix approaches to much IMO. ATM, a lot
of calculations are done in the renderers and that should stay that way.
The only alternative I see is doing the absolute placements on a page
entirely in the LMs and let the renderers only perform some painting
instructions. We've discussed that earlier this year and did not pursue.
Just look at AbstractPathOrientedRenderer.handleBlockTraits() which does
all the necessary calculations to determine the right positions and
offset. The same should be done for all other area elements.
> Another question for the "Knuth" experts. It appears the inline LMs
> don't make provisions in the IPD for borders/padding on inlines. I
> assume border/padding is logically like a (with the width of the
> border + padding) in front of the first and after the last character of
> the inline assuming .conditionality=discard, that is we don't want to
> have let's say a left border alone on the end of a line with the text
> starting on the next. For .conditionality=retain this width needs to be
> reserved as well at the beginning and end of each intermediate line.
> Any suggestions how this can/should be integrated into the linebreaking
> algorithm?
Exactly like spaces, borders and padding in b-p-d for block-level
objects: additional auxiliary boxes and penalties. See
BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the
same as page breaking, only in a different direction.
<snip/>
Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
Had a look at this problem (fo:inline with border and padding) and have
a question regarding the "contract" between the area tree and the
renderers. The inlineParent area has a property called "offset" (So
have other areas). This offset is used for baseline alignment, i.e. it
is the offset relative to the dominant baseline. The question is: Is
this offset relative to the content rectangle or the border rectangle?
In the example "some text <fo:inline border="..."> more text
</fo:inline>" if the offset is for the content rectangle it would be 0
if the offset is for the border rectangle it would be "- (Border +
Padding) width". Currently the LM sets it to 0. Therefore the renderers
would need to compensate for that when drawing the borders (which is
currently not done). Alternatively the LM could take the border into
account when calculating the offset and the renderers don't need to
make any adjustments in the BPD direction. Anyone knows what the
original design intention was?
Another question for the "Knuth" experts. It appears the inline LMs
don't make provisions in the IPD for borders/padding on inlines. I
assume border/padding is logically like a (with the width of the
border + padding) in front of the first and after the last character of
the inline assuming .conditionality=discard, that is we don't want to
have let's say a left border alone on the end of a line with the text
starting on the next. For .conditionality=retain this width needs to be
reserved as well at the beginning and end of each intermediate line.
Any suggestions how this can/should be integrated into the linebreaking
algorithm?
Manuel
On Fri, 2 Sep 2005 03:29 pm, Manuel Mall wrote:
> Allright, I will have a go at this and scream for help if I get
> stuck. Step 1 would be to get the area tree right and step 2 would be
> to make any required adjustments to the renderers. This means I will
> learn more about layout and rendering at the same time (need to have
> a positive angle to this).
>
> Manuel
>
> On Fri, 2 Sep 2005 02:44 pm, Jeremias Maerki wrote:
> > Interesting results if you add the following to your test case:
> >
> > <fo:block background-color="silver" margin="0pt">
> > Normal text <fo:inline border="solid 5pt red"
> > padding="5pt" background-color="white">inline with <fo:block>Blah
> > blah</fo:block><fo:block>Blah blah</fo:block>border="solid 5pt red"
> > padding="5pt"</fo:inline> normal finish </fo:block>
> >
> > Looks like a little work. The element list generates boxes with
> > height=12000pt for each of the nested blocks (which seems to be
> > correct), but the renderer increases the currentBPPosition by (2 *
> > (5pt + 5pt)) after painting the inlineblockparents. So there is
> > definitely something wrong with the renderers, too. We probably
> > need to teach them the difference between the
> > normal-allocation-rectangle and the
> > large-allocation-rectangle.
> >
> > On 02.09.2005 08:37:06 Jeremias Maerki wrote:
> > > The place to start is certainly the InlineLayoutManager. It looks
> > > like the width of the inline is reported correctly through the
> > > KnuthElements, but there is either a problem in addAreas or in
> > > the renderers that the content of the inline is not indented in
> > > i-p-d. Check getExtraIPD() which doesn't seem to be referenced.
> > > This could indicate something. The other problem is the b-p-d.
> > > Since fo:inline uses the
> > > normal-allocation-rectangle (I've check this time), the
> > > KnuthElements seem fine concerning the size they report. As with
> > > i-p-d I can imagine that there is a problem with the renderers
> > > about painting inlines. The "bpda" of the inlineparent area looks
> > > correct to me but it's not painted that way. I think this should
> > > all be easily fixable.
> > >
> > > The real problem IMO is probably block-level content in
> > > fo:inlines again. How are these borders to be painted? A border
> > > around each inlineblockparent (one for each block inside the
> > > inline)? I'm not sure judging from the specification.
> > >
> > > HTH
> > >
> > > On 02.09.2005 07:21:49 Manuel Mall wrote:
> > > > Vincent, Jeremias,
> > > >
> > > > thanks for the clarification.
> > > >
> > > > After looking just a little bit more into it it appears the
> > > > current fop version is dealing pretty badly with inline borders
> > > > and padding. There seem to be no testcases for it either.
> > > >
> > > > I'll attach 2 files.
> > > > A simple test case.
> > > > The pdf output from that as produced by the current trunk
> > > > version.
> > > >
> > > > The output is wrong on a number of points.
> > > > 1. The border / padding is overlapping with the text
> > > > 2. The top/bottom border / padding should be outside the
> > > > allocation rectangle for the fo:inline and therefore extend
> > > > above and below the enclosing block.
> > > > 3. There is a strange gap between the fo:inline and the
> > > > following text. I suspect it has to do with some piece of code
> > > > using the correct allocation rectangle and others not.
> > > >
> > > > Not sure if I am up to fixing this as that may go into the
> > > > depth of the Knuth boxes etc.. But if someone if prepared to
> > > > give me some pointers on where to start I'll be prepared to
> > > > give it a go.
> > > >
> > > > Manuel
> > > >
> > > > On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> > > > > Oh right. Again someone caught me shooting too fast from the
> > > > > hip. Damn. I will probably never manage to get that right.
> > > > > :-( It's good to have people around to pay attention.
> > > > >
> > > > > I wondered about the large-allocation-rectangle while reading
> > > > > through 6.3.2 but obviously forgot to check the docs for e-g
> > > > > and i-f-o. Sorry, Manuel, Vincent is right.
> > > > >
> > > > > On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > > > > > I'm not sure here. The fo:external-graphic uses the
> > > > > > large-allocation-rectangle (§ 6.6.5), that comprises
> > > > > > padding and border. This makes me say that in Manuel's
> > > > > > example the fo:block's bpd should be calculated with the
> > > > > > second formula. The fo:block's content forms a line whose
> > > > > > line-stacking-strategy is max-height (default). Thus its
> > > > > > allocation rectangle should comprise the image's border &
> > > > > > padding (§ 4.5). And so does the block.
> > > > > >
> > > > > > I may be wrong, as this part of the spec is still somewhat
> > > > > > unclear to me. WDYT?
> > > > > >
> > > > > > Vincent
> > > > > >
> > > > > > Jeremias Maerki a écrit :
> > > > > > > Indeed, the normal allocation rectangle of an inline area
> > > > > > > is different than the one of a block area. See 4.3.2.
> > > > > > > Geometric Definitions in the 1.0 spec.
> > > > > > >
> > > > > > > Border and padding for an inline area seem to be outside
> > > > > > > the allocation rectangle in before and after directions.
> > > > > > > Interesting.
> > > > > > >
> > > > > > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > > > > > >>I have a follow-up question on this. If we have something
> > > > > > >> as simple(?) as this:
> > > > > > >>
> > > > > > >><fo:block background-color="orange">
> > > > > > >> <fo:external-graphic
> > > > > > >> src="../../resources/images/bgimg300dpi.jpg"
> > > > > > >> border="solid 5pt"
> > > > > > >> padding="5pt"
> > > > > > >> background-color="white"/>
> > > > > > >></fo:block>
> > > > > > >>
> > > > > > >>would you expect the whole image including padding and
> > > > > > >> borders to be within the bounds of the enclosing block
> > > > > > >> or only the actual image to be in the block and the
> > > > > > >> padding and borders to "stick out" at the top and
> > > > > > >> bottom. It seems xep takes the latter approach and I am
> > > > > > >> very uncertain in this area. Or to put it differently is
> > > > > > >> the BPD of the enclosing block
> > > > > > >> bpd = image height + line-spacing
> > > > > > >>or
> > > > > > >> bpd = image-height + top_and_bottom_borders +
> > > > > > >> top_and_bottom_padding + line-spacing
> > > > > > >>?
> > > > > > >>
> > > > > > >>Manuel
> > > > > > >><snip/>
> > > > > > >
> > > > > > > Jeremias Maerki
> > > > >
> > > > > Jeremias Maerki
> > >
> > > Jeremias Maerki
> >
> > Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
Allright, I will have a go at this and scream for help if I get stuck.
Step 1 would be to get the area tree right and step 2 would be to make
any required adjustments to the renderers. This means I will learn more
about layout and rendering at the same time (need to have a positive
angle to this).
Manuel
On Fri, 2 Sep 2005 02:44 pm, Jeremias Maerki wrote:
> Interesting results if you add the following to your test case:
>
> <fo:block background-color="silver" margin="0pt">
> Normal text <fo:inline border="solid 5pt red"
> padding="5pt" background-color="white">inline with <fo:block>Blah
> blah</fo:block><fo:block>Blah blah</fo:block>border="solid 5pt red"
> padding="5pt"</fo:inline> normal finish </fo:block>
>
> Looks like a little work. The element list generates boxes with
> height=12000pt for each of the nested blocks (which seems to be
> correct), but the renderer increases the currentBPPosition by (2 *
> (5pt + 5pt)) after painting the inlineblockparents. So there is
> definitely something wrong with the renderers, too. We probably need
> to teach them the difference between the normal-allocation-rectangle
> and the
> large-allocation-rectangle.
>
> On 02.09.2005 08:37:06 Jeremias Maerki wrote:
> > The place to start is certainly the InlineLayoutManager. It looks
> > like the width of the inline is reported correctly through the
> > KnuthElements, but there is either a problem in addAreas or in the
> > renderers that the content of the inline is not indented in i-p-d.
> > Check getExtraIPD() which doesn't seem to be referenced. This could
> > indicate something. The other problem is the b-p-d. Since fo:inline
> > uses the
> > normal-allocation-rectangle (I've check this time), the
> > KnuthElements seem fine concerning the size they report. As with
> > i-p-d I can imagine that there is a problem with the renderers
> > about painting inlines. The "bpda" of the inlineparent area looks
> > correct to me but it's not painted that way. I think this should
> > all be easily fixable.
> >
> > The real problem IMO is probably block-level content in fo:inlines
> > again. How are these borders to be painted? A border around each
> > inlineblockparent (one for each block inside the inline)? I'm not
> > sure judging from the specification.
> >
> > HTH
> >
> > On 02.09.2005 07:21:49 Manuel Mall wrote:
> > > Vincent, Jeremias,
> > >
> > > thanks for the clarification.
> > >
> > > After looking just a little bit more into it it appears the
> > > current fop version is dealing pretty badly with inline borders
> > > and padding. There seem to be no testcases for it either.
> > >
> > > I'll attach 2 files.
> > > A simple test case.
> > > The pdf output from that as produced by the current trunk
> > > version.
> > >
> > > The output is wrong on a number of points.
> > > 1. The border / padding is overlapping with the text
> > > 2. The top/bottom border / padding should be outside the
> > > allocation rectangle for the fo:inline and therefore extend above
> > > and below the enclosing block.
> > > 3. There is a strange gap between the fo:inline and the
> > > following text. I suspect it has to do with some piece of code
> > > using the correct allocation rectangle and others not.
> > >
> > > Not sure if I am up to fixing this as that may go into the depth
> > > of the Knuth boxes etc.. But if someone if prepared to give me
> > > some pointers on where to start I'll be prepared to give it a go.
> > >
> > > Manuel
> > >
> > > On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> > > > Oh right. Again someone caught me shooting too fast from the
> > > > hip. Damn. I will probably never manage to get that right. :-(
> > > > It's good to have people around to pay attention.
> > > >
> > > > I wondered about the large-allocation-rectangle while reading
> > > > through 6.3.2 but obviously forgot to check the docs for e-g
> > > > and i-f-o. Sorry, Manuel, Vincent is right.
> > > >
> > > > On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > > > > I'm not sure here. The fo:external-graphic uses the
> > > > > large-allocation-rectangle (§ 6.6.5), that comprises padding
> > > > > and border. This makes me say that in Manuel's example the
> > > > > fo:block's bpd should be calculated with the second formula.
> > > > > The fo:block's content forms a line whose
> > > > > line-stacking-strategy is max-height (default). Thus its
> > > > > allocation rectangle should comprise the image's border &
> > > > > padding (§ 4.5). And so does the block.
> > > > >
> > > > > I may be wrong, as this part of the spec is still somewhat
> > > > > unclear to me. WDYT?
> > > > >
> > > > > Vincent
> > > > >
> > > > > Jeremias Maerki a écrit :
> > > > > > Indeed, the normal allocation rectangle of an inline area
> > > > > > is different than the one of a block area. See 4.3.2.
> > > > > > Geometric Definitions in the 1.0 spec.
> > > > > >
> > > > > > Border and padding for an inline area seem to be outside
> > > > > > the allocation rectangle in before and after directions.
> > > > > > Interesting.
> > > > > >
> > > > > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > > > > >>I have a follow-up question on this. If we have something
> > > > > >> as simple(?) as this:
> > > > > >>
> > > > > >><fo:block background-color="orange">
> > > > > >> <fo:external-graphic
> > > > > >> src="../../resources/images/bgimg300dpi.jpg"
> > > > > >> border="solid 5pt"
> > > > > >> padding="5pt"
> > > > > >> background-color="white"/>
> > > > > >></fo:block>
> > > > > >>
> > > > > >>would you expect the whole image including padding and
> > > > > >> borders to be within the bounds of the enclosing block or
> > > > > >> only the actual image to be in the block and the padding
> > > > > >> and borders to "stick out" at the top and bottom. It seems
> > > > > >> xep takes the latter approach and I am very uncertain in
> > > > > >> this area. Or to put it differently is the BPD of the
> > > > > >> enclosing block
> > > > > >> bpd = image height + line-spacing
> > > > > >>or
> > > > > >> bpd = image-height + top_and_bottom_borders +
> > > > > >> top_and_bottom_padding + line-spacing
> > > > > >>?
> > > > > >>
> > > > > >>Manuel
> > > > > >><snip/>
> > > > > >
> > > > > > Jeremias Maerki
> > > >
> > > > Jeremias Maerki
> >
> > Jeremias Maerki
>
> Jeremias Maerki
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
Interesting results if you add the following to your test case:
<fo:block background-color="silver" margin="0pt">
Normal text <fo:inline border="solid 5pt red" padding="5pt" background-color="white">inline with <fo:block>Blah blah</fo:block><fo:block>Blah blah</fo:block>border="solid 5pt red" padding="5pt"</fo:inline> normal finish
</fo:block>
Looks like a little work. The element list generates boxes with height=12000pt
for each of the nested blocks (which seems to be correct), but the
renderer increases the currentBPPosition by (2 * (5pt + 5pt)) after
painting the inlineblockparents. So there is definitely something wrong
with the renderers, too. We probably need to teach them the difference
between the normal-allocation-rectangle and the
large-allocation-rectangle.
On 02.09.2005 08:37:06 Jeremias Maerki wrote:
> The place to start is certainly the InlineLayoutManager. It looks like
> the width of the inline is reported correctly through the KnuthElements,
> but there is either a problem in addAreas or in the renderers that the
> content of the inline is not indented in i-p-d. Check getExtraIPD()
> which doesn't seem to be referenced. This could indicate something. The
> other problem is the b-p-d. Since fo:inline uses the
> normal-allocation-rectangle (I've check this time), the KnuthElements
> seem fine concerning the size they report. As with i-p-d I can imagine
> that there is a problem with the renderers about painting inlines. The
> "bpda" of the inlineparent area looks correct to me but it's not painted
> that way. I think this should all be easily fixable.
>
> The real problem IMO is probably block-level content in fo:inlines again.
> How are these borders to be painted? A border around each
> inlineblockparent (one for each block inside the inline)? I'm not sure
> judging from the specification.
>
> HTH
>
> On 02.09.2005 07:21:49 Manuel Mall wrote:
> > Vincent, Jeremias,
> >
> > thanks for the clarification.
> >
> > After looking just a little bit more into it it appears the current fop
> > version is dealing pretty badly with inline borders and padding. There
> > seem to be no testcases for it either.
> >
> > I'll attach 2 files.
> > A simple test case.
> > The pdf output from that as produced by the current trunk version.
> >
> > The output is wrong on a number of points.
> > 1. The border / padding is overlapping with the text
> > 2. The top/bottom border / padding should be outside the allocation
> > rectangle for the fo:inline and therefore extend above and below the
> > enclosing block.
> > 3. There is a strange gap between the fo:inline and the following
> > text. I suspect it has to do with some piece of code using the correct
> > allocation rectangle and others not.
> >
> > Not sure if I am up to fixing this as that may go into the depth of the
> > Knuth boxes etc.. But if someone if prepared to give me some pointers
> > on where to start I'll be prepared to give it a go.
> >
> > Manuel
> > On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> > > Oh right. Again someone caught me shooting too fast from the hip.
> > > Damn. I will probably never manage to get that right. :-( It's good
> > > to have people around to pay attention.
> > >
> > > I wondered about the large-allocation-rectangle while reading through
> > > 6.3.2 but obviously forgot to check the docs for e-g and i-f-o.
> > > Sorry, Manuel, Vincent is right.
> > >
> > > On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > > > I'm not sure here. The fo:external-graphic uses the
> > > > large-allocation-rectangle (§ 6.6.5), that comprises padding and
> > > > border. This makes me say that in Manuel's example the fo:block's
> > > > bpd should be calculated with the second formula. The fo:block's
> > > > content forms a line whose line-stacking-strategy is max-height
> > > > (default). Thus its allocation rectangle should comprise the
> > > > image's border & padding (§ 4.5). And so does the block.
> > > >
> > > > I may be wrong, as this part of the spec is still somewhat unclear
> > > > to me. WDYT?
> > > >
> > > > Vincent
> > > >
> > > > Jeremias Maerki a écrit :
> > > > > Indeed, the normal allocation rectangle of an inline area is
> > > > > different than the one of a block area. See 4.3.2. Geometric
> > > > > Definitions in the 1.0 spec.
> > > > >
> > > > > Border and padding for an inline area seem to be outside the
> > > > > allocation rectangle in before and after directions. Interesting.
> > > > >
> > > > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > > > >>I have a follow-up question on this. If we have something as
> > > > >> simple(?) as this:
> > > > >>
> > > > >><fo:block background-color="orange">
> > > > >> <fo:external-graphic
> > > > >> src="../../resources/images/bgimg300dpi.jpg"
> > > > >> border="solid 5pt"
> > > > >> padding="5pt"
> > > > >> background-color="white"/>
> > > > >></fo:block>
> > > > >>
> > > > >>would you expect the whole image including padding and borders to
> > > > >> be within the bounds of the enclosing block or only the actual
> > > > >> image to be in the block and the padding and borders to "stick
> > > > >> out" at the top and bottom. It seems xep takes the latter
> > > > >> approach and I am very uncertain in this area. Or to put it
> > > > >> differently is the BPD of the enclosing block
> > > > >> bpd = image height + line-spacing
> > > > >>or
> > > > >> bpd = image-height + top_and_bottom_borders +
> > > > >> top_and_bottom_padding + line-spacing
> > > > >>?
> > > > >>
> > > > >>Manuel
> > > > >><snip/>
> > > > >
> > > > > Jeremias Maerki
> > >
> > > Jeremias Maerki
>
>
>
> Jeremias Maerki
Jeremias Maerki
Re: e-g with padding and borders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Jeremias Maerki a écrit :
> The real problem IMO is probably block-level content in fo:inlines again.
> How are these borders to be painted? A border around each
> inlineblockparent (one for each block inside the inline)? I'm not sure
> judging from the specification.
Here the spec starts being really complicated. I would say you're right, thought
not sure. See the last sentence of § 4.2.2: "Unless otherwise specified, the
traits of a formatting object are present on each of its generated areas, and
with the same value. (However, see sections [4.7.2 Line-building] and [4.9.4
Border, Padding, and Background].)". The referred sections don't seem to hold
for the fo:inline case.
What disturbs me is that when one specifies a border around a chunk of text and
there is line-breaking, this border should appear and the end of the first line
and the beginning of second line, as below:
________________
This is a | chunk of text |
-----------------
______________
| with border | blah blah
---------------
blah blah
What is more intuitive and could be expected by a user is the following:
______________
This is a | chunk of text
---------------
_____________
with border | blah blah
-------------
blah blah
but IIUC this is not allowed by the spec. I ask for confirmation here.
So the example you provided with the 2 <fo:block>blah blah</fo:block> is
rendered correctly in terms of borders (but there should be no space between
them, probably part of the rendering problem you raised).
Vincent
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
The place to start is certainly the InlineLayoutManager. It looks like
the width of the inline is reported correctly through the KnuthElements,
but there is either a problem in addAreas or in the renderers that the
content of the inline is not indented in i-p-d. Check getExtraIPD()
which doesn't seem to be referenced. This could indicate something. The
other problem is the b-p-d. Since fo:inline uses the
normal-allocation-rectangle (I've check this time), the KnuthElements
seem fine concerning the size they report. As with i-p-d I can imagine
that there is a problem with the renderers about painting inlines. The
"bpda" of the inlineparent area looks correct to me but it's not painted
that way. I think this should all be easily fixable.
The real problem IMO is probably block-level content in fo:inlines again.
How are these borders to be painted? A border around each
inlineblockparent (one for each block inside the inline)? I'm not sure
judging from the specification.
HTH
On 02.09.2005 07:21:49 Manuel Mall wrote:
> Vincent, Jeremias,
>
> thanks for the clarification.
>
> After looking just a little bit more into it it appears the current fop
> version is dealing pretty badly with inline borders and padding. There
> seem to be no testcases for it either.
>
> I'll attach 2 files.
> A simple test case.
> The pdf output from that as produced by the current trunk version.
>
> The output is wrong on a number of points.
> 1. The border / padding is overlapping with the text
> 2. The top/bottom border / padding should be outside the allocation
> rectangle for the fo:inline and therefore extend above and below the
> enclosing block.
> 3. There is a strange gap between the fo:inline and the following
> text. I suspect it has to do with some piece of code using the correct
> allocation rectangle and others not.
>
> Not sure if I am up to fixing this as that may go into the depth of the
> Knuth boxes etc.. But if someone if prepared to give me some pointers
> on where to start I'll be prepared to give it a go.
>
> Manuel
> On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> > Oh right. Again someone caught me shooting too fast from the hip.
> > Damn. I will probably never manage to get that right. :-( It's good
> > to have people around to pay attention.
> >
> > I wondered about the large-allocation-rectangle while reading through
> > 6.3.2 but obviously forgot to check the docs for e-g and i-f-o.
> > Sorry, Manuel, Vincent is right.
> >
> > On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > > I'm not sure here. The fo:external-graphic uses the
> > > large-allocation-rectangle (§ 6.6.5), that comprises padding and
> > > border. This makes me say that in Manuel's example the fo:block's
> > > bpd should be calculated with the second formula. The fo:block's
> > > content forms a line whose line-stacking-strategy is max-height
> > > (default). Thus its allocation rectangle should comprise the
> > > image's border & padding (§ 4.5). And so does the block.
> > >
> > > I may be wrong, as this part of the spec is still somewhat unclear
> > > to me. WDYT?
> > >
> > > Vincent
> > >
> > > Jeremias Maerki a écrit :
> > > > Indeed, the normal allocation rectangle of an inline area is
> > > > different than the one of a block area. See 4.3.2. Geometric
> > > > Definitions in the 1.0 spec.
> > > >
> > > > Border and padding for an inline area seem to be outside the
> > > > allocation rectangle in before and after directions. Interesting.
> > > >
> > > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > > >>I have a follow-up question on this. If we have something as
> > > >> simple(?) as this:
> > > >>
> > > >><fo:block background-color="orange">
> > > >> <fo:external-graphic
> > > >> src="../../resources/images/bgimg300dpi.jpg"
> > > >> border="solid 5pt"
> > > >> padding="5pt"
> > > >> background-color="white"/>
> > > >></fo:block>
> > > >>
> > > >>would you expect the whole image including padding and borders to
> > > >> be within the bounds of the enclosing block or only the actual
> > > >> image to be in the block and the padding and borders to "stick
> > > >> out" at the top and bottom. It seems xep takes the latter
> > > >> approach and I am very uncertain in this area. Or to put it
> > > >> differently is the BPD of the enclosing block
> > > >> bpd = image height + line-spacing
> > > >>or
> > > >> bpd = image-height + top_and_bottom_borders +
> > > >> top_and_bottom_padding + line-spacing
> > > >>?
> > > >>
> > > >>Manuel
> > > >><snip/>
> > > >
> > > > Jeremias Maerki
> >
> > Jeremias Maerki
Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
Vincent, Jeremias,
thanks for the clarification.
After looking just a little bit more into it it appears the current fop
version is dealing pretty badly with inline borders and padding. There
seem to be no testcases for it either.
I'll attach 2 files.
A simple test case.
The pdf output from that as produced by the current trunk version.
The output is wrong on a number of points.
1. The border / padding is overlapping with the text
2. The top/bottom border / padding should be outside the allocation
rectangle for the fo:inline and therefore extend above and below the
enclosing block.
3. There is a strange gap between the fo:inline and the following
text. I suspect it has to do with some piece of code using the correct
allocation rectangle and others not.
Not sure if I am up to fixing this as that may go into the depth of the
Knuth boxes etc.. But if someone if prepared to give me some pointers
on where to start I'll be prepared to give it a go.
Manuel
On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> Oh right. Again someone caught me shooting too fast from the hip.
> Damn. I will probably never manage to get that right. :-( It's good
> to have people around to pay attention.
>
> I wondered about the large-allocation-rectangle while reading through
> 6.3.2 but obviously forgot to check the docs for e-g and i-f-o.
> Sorry, Manuel, Vincent is right.
>
> On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > I'm not sure here. The fo:external-graphic uses the
> > large-allocation-rectangle (§ 6.6.5), that comprises padding and
> > border. This makes me say that in Manuel's example the fo:block's
> > bpd should be calculated with the second formula. The fo:block's
> > content forms a line whose line-stacking-strategy is max-height
> > (default). Thus its allocation rectangle should comprise the
> > image's border & padding (§ 4.5). And so does the block.
> >
> > I may be wrong, as this part of the spec is still somewhat unclear
> > to me. WDYT?
> >
> > Vincent
> >
> > Jeremias Maerki a écrit :
> > > Indeed, the normal allocation rectangle of an inline area is
> > > different than the one of a block area. See 4.3.2. Geometric
> > > Definitions in the 1.0 spec.
> > >
> > > Border and padding for an inline area seem to be outside the
> > > allocation rectangle in before and after directions. Interesting.
> > >
> > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > >>I have a follow-up question on this. If we have something as
> > >> simple(?) as this:
> > >>
> > >><fo:block background-color="orange">
> > >> <fo:external-graphic
> > >> src="../../resources/images/bgimg300dpi.jpg"
> > >> border="solid 5pt"
> > >> padding="5pt"
> > >> background-color="white"/>
> > >></fo:block>
> > >>
> > >>would you expect the whole image including padding and borders to
> > >> be within the bounds of the enclosing block or only the actual
> > >> image to be in the block and the padding and borders to "stick
> > >> out" at the top and bottom. It seems xep takes the latter
> > >> approach and I am very uncertain in this area. Or to put it
> > >> differently is the BPD of the enclosing block
> > >> bpd = image height + line-spacing
> > >>or
> > >> bpd = image-height + top_and_bottom_borders +
> > >> top_and_bottom_padding + line-spacing
> > >>?
> > >>
> > >>Manuel
> > >><snip/>
> > >
> > > Jeremias Maerki
>
> Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
The problems reported here with e-g and padding / borders apply equally
to i-f-o. It's not too hard to fix. While doing this I noticed that the
code for the i-f-o LM and e-g LM is logically largely identical
although some bits have been coded slightly differently.
Any concerns if I put a common LM for i-f-o, e-g that into the LM
inheritance hierarchy (working name ForeignContent LM, i.e. content not
native of XSL-FO)?
So we have something like:
i-f-o LM implements ForeignContent LM
e-g LM implements ForeignContent LM
and
ForeignContent LM implements LeafNode LM.
This would allow all the code related to the viewport generation,
content scaling, and rectangle sizing for i-f-o and e-g to be in one
place only.
The i-f-o and e-g LMs would become very small basically only providing
the image or foreignObject area to be placed into the viewport.
Manuel
On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> Oh right. Again someone caught me shooting too fast from the hip.
> Damn. I will probably never manage to get that right. :-( It's good
> to have people around to pay attention.
>
> I wondered about the large-allocation-rectangle while reading through
> 6.3.2 but obviously forgot to check the docs for e-g and i-f-o.
> Sorry, Manuel, Vincent is right.
>
> On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > I'm not sure here. The fo:external-graphic uses the
> > large-allocation-rectangle (§ 6.6.5), that comprises padding and
> > border. This makes me say that in Manuel's example the fo:block's
> > bpd should be calculated with the second formula. The fo:block's
> > content forms a line whose line-stacking-strategy is max-height
> > (default). Thus its allocation rectangle should comprise the
> > image's border & padding (§ 4.5). And so does the block.
> >
> > I may be wrong, as this part of the spec is still somewhat unclear
> > to me. WDYT?
> >
> > Vincent
> >
> > Jeremias Maerki a écrit :
> > > Indeed, the normal allocation rectangle of an inline area is
> > > different than the one of a block area. See 4.3.2. Geometric
> > > Definitions in the 1.0 spec.
> > >
> > > Border and padding for an inline area seem to be outside the
> > > allocation rectangle in before and after directions. Interesting.
> > >
> > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > >>I have a follow-up question on this. If we have something as
> > >> simple(?) as this:
> > >>
> > >><fo:block background-color="orange">
> > >> <fo:external-graphic
> > >> src="../../resources/images/bgimg300dpi.jpg"
> > >> border="solid 5pt"
> > >> padding="5pt"
> > >> background-color="white"/>
> > >></fo:block>
> > >>
> > >>would you expect the whole image including padding and borders to
> > >> be within the bounds of the enclosing block or only the actual
> > >> image to be in the block and the padding and borders to "stick
> > >> out" at the top and bottom. It seems xep takes the latter
> > >> approach and I am very uncertain in this area. Or to put it
> > >> differently is the BPD of the enclosing block
> > >> bpd = image height + line-spacing
> > >>or
> > >> bpd = image-height + top_and_bottom_borders +
> > >> top_and_bottom_padding + line-spacing
> > >>?
> > >>
> > >>Manuel
> > >><snip/>
> > >
> > > Jeremias Maerki
>
> Jeremias Maerki
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
Oh right. Again someone caught me shooting too fast from the hip. Damn.
I will probably never manage to get that right. :-( It's good to have
people around to pay attention.
I wondered about the large-allocation-rectangle while reading through
6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry,
Manuel, Vincent is right.
On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle
> (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's
> example the fo:block's bpd should be calculated with the second formula. The
> fo:block's content forms a line whose line-stacking-strategy is max-height
> (default). Thus its allocation rectangle should comprise the image's border &
> padding (§ 4.5). And so does the block.
>
> I may be wrong, as this part of the spec is still somewhat unclear to me.
> WDYT?
>
> Vincent
>
> Jeremias Maerki a écrit :
> > Indeed, the normal allocation rectangle of an inline area is different
> > than the one of a block area. See 4.3.2. Geometric Definitions in the
> > 1.0 spec.
> >
> > Border and padding for an inline area seem to be outside the allocation
> > rectangle in before and after directions. Interesting.
> >
> > On 01.09.2005 17:29:50 Manuel Mall wrote:
> >
> >>I have a follow-up question on this. If we have something as simple(?)
> >>as this:
> >>
> >><fo:block background-color="orange">
> >> <fo:external-graphic
> >> src="../../resources/images/bgimg300dpi.jpg"
> >> border="solid 5pt"
> >> padding="5pt"
> >> background-color="white"/>
> >></fo:block>
> >>
> >>would you expect the whole image including padding and borders to be
> >>within the bounds of the enclosing block or only the actual image to be
> >>in the block and the padding and borders to "stick out" at the top and
> >>bottom. It seems xep takes the latter approach and I am very uncertain
> >>in this area. Or to put it differently is the BPD of the enclosing
> >>block
> >> bpd = image height + line-spacing
> >>or
> >> bpd = image-height + top_and_bottom_borders + top_and_bottom_padding
> >>+ line-spacing
> >>?
> >>
> >>Manuel
> >><snip/>
> >
> >
> >
> >
> > Jeremias Maerki
> >
Jeremias Maerki
Re: e-g with padding and borders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle
(§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's
example the fo:block's bpd should be calculated with the second formula. The
fo:block's content forms a line whose line-stacking-strategy is max-height
(default). Thus its allocation rectangle should comprise the image's border &
padding (§ 4.5). And so does the block.
I may be wrong, as this part of the spec is still somewhat unclear to me.
WDYT?
Vincent
Jeremias Maerki a écrit :
> Indeed, the normal allocation rectangle of an inline area is different
> than the one of a block area. See 4.3.2. Geometric Definitions in the
> 1.0 spec.
>
> Border and padding for an inline area seem to be outside the allocation
> rectangle in before and after directions. Interesting.
>
> On 01.09.2005 17:29:50 Manuel Mall wrote:
>
>>I have a follow-up question on this. If we have something as simple(?)
>>as this:
>>
>><fo:block background-color="orange">
>> <fo:external-graphic
>> src="../../resources/images/bgimg300dpi.jpg"
>> border="solid 5pt"
>> padding="5pt"
>> background-color="white"/>
>></fo:block>
>>
>>would you expect the whole image including padding and borders to be
>>within the bounds of the enclosing block or only the actual image to be
>>in the block and the padding and borders to "stick out" at the top and
>>bottom. It seems xep takes the latter approach and I am very uncertain
>>in this area. Or to put it differently is the BPD of the enclosing
>>block
>> bpd = image height + line-spacing
>>or
>> bpd = image-height + top_and_bottom_borders + top_and_bottom_padding
>>+ line-spacing
>>?
>>
>>Manuel
>><snip/>
>
>
>
>
> Jeremias Maerki
>
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
Indeed, the normal allocation rectangle of an inline area is different
than the one of a block area. See 4.3.2. Geometric Definitions in the
1.0 spec.
Border and padding for an inline area seem to be outside the allocation
rectangle in before and after directions. Interesting.
On 01.09.2005 17:29:50 Manuel Mall wrote:
> I have a follow-up question on this. If we have something as simple(?)
> as this:
>
> <fo:block background-color="orange">
> <fo:external-graphic
> src="../../resources/images/bgimg300dpi.jpg"
> border="solid 5pt"
> padding="5pt"
> background-color="white"/>
> </fo:block>
>
> would you expect the whole image including padding and borders to be
> within the bounds of the enclosing block or only the actual image to be
> in the block and the padding and borders to "stick out" at the top and
> bottom. It seems xep takes the latter approach and I am very uncertain
> in this area. Or to put it differently is the BPD of the enclosing
> block
> bpd = image height + line-spacing
> or
> bpd = image-height + top_and_bottom_borders + top_and_bottom_padding
> + line-spacing
> ?
>
> Manuel
> <snip/>
Jeremias Maerki
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
I have a follow-up question on this. If we have something as simple(?)
as this:
<fo:block background-color="orange">
<fo:external-graphic
src="../../resources/images/bgimg300dpi.jpg"
border="solid 5pt"
padding="5pt"
background-color="white"/>
</fo:block>
would you expect the whole image including padding and borders to be
within the bounds of the enclosing block or only the actual image to be
in the block and the padding and borders to "stick out" at the top and
bottom. It seems xep takes the latter approach and I am very uncertain
in this area. Or to put it differently is the BPD of the enclosing
block
bpd = image height + line-spacing
or
bpd = image-height + top_and_bottom_borders + top_and_bottom_padding
+ line-spacing
?
Manuel
<snip/>
Re: e-g with padding and borders
Posted by Manuel Mall <mm...@arcus.com.au>.
On Thu, 1 Sep 2005 10:13 pm, Jeremias Maerki wrote:
> This is definitely wrong, you're right. I know how that got through
> the tests: The checks are insufficient. The stuff that is checked is
> definitely ok. But bpd/ipd are not checked. That's the problem.
>
Thanks - I'll fix the problem and the test.
> On 01.09.2005 15:53:46 Manuel Mall wrote:
> > I think the area tree viewport generated by the current version for
> > an e-g with padding and borders is wrong.
> >
> > Here is the fo snippet (from external-graphic_border_padding.xml):
> >
> > <fo:external-graphic
> > src="../../resources/images/bgimg300dpi.jpg"
> > border="solid 5pt" padding="5pt" background-color="white"
> > />
> >
> > and this is the generated viewport:
> >
> > <viewport background="color=#ffffff" bap="10000 10000 10000 10000"
> > border-after="(solid,#000000,5000)"
> > border-before="(solid,#000000,5000)"
> > border-end="(solid,#000000,5000)"
> > border-start="(solid,#000000,5000)"
> > bpd="66080" bpda="86080"
> > ipd="66080" ipda="86080"
> > padding-after="5000"
> > padding-before="5000"
> > padding-end="5000"
> > padding-start="5000">
> > <image bap="0 0 0 0" bpd="0" ipd="0"
> > pos="10000 10000 46080 46080"
> > url="../../resources/images/bgimg300dpi.jpg" />
> > </viewport>
> >
> > The viewport bpd/ipd includes the padding and border width while it
> > should only be the content width of 46080.
> >
> > Am I correct? I am happy to fix it - just would like confirmation
> > that this is actually incorrect. BTW, the generated PDF looks
> > pretty wrong to me as well.
> >
> > Manuel
> >
> > PS: Not sure how that got through the layout engine tests!
>
> Jeremias Maerki
Manuel
Re: e-g with padding and borders
Posted by Jeremias Maerki <de...@greenmail.ch>.
This is definitely wrong, you're right. I know how that got through the
tests: The checks are insufficient. The stuff that is checked is
definitely ok. But bpd/ipd are not checked. That's the problem.
On 01.09.2005 15:53:46 Manuel Mall wrote:
> I think the area tree viewport generated by the current version for an e-g
> with padding and borders is wrong.
>
> Here is the fo snippet (from external-graphic_border_padding.xml):
>
> <fo:external-graphic
> src="../../resources/images/bgimg300dpi.jpg"
> border="solid 5pt" padding="5pt" background-color="white"
> />
>
> and this is the generated viewport:
>
> <viewport background="color=#ffffff" bap="10000 10000 10000 10000"
> border-after="(solid,#000000,5000)"
> border-before="(solid,#000000,5000)"
> border-end="(solid,#000000,5000)"
> border-start="(solid,#000000,5000)"
> bpd="66080" bpda="86080"
> ipd="66080" ipda="86080"
> padding-after="5000"
> padding-before="5000"
> padding-end="5000"
> padding-start="5000">
> <image bap="0 0 0 0" bpd="0" ipd="0"
> pos="10000 10000 46080 46080"
> url="../../resources/images/bgimg300dpi.jpg" />
> </viewport>
>
> The viewport bpd/ipd includes the padding and border width while it should
> only be the content width of 46080.
>
> Am I correct? I am happy to fix it - just would like confirmation that this
> is actually incorrect. BTW, the generated PDF looks pretty wrong to me as
> well.
>
> Manuel
>
> PS: Not sure how that got through the layout engine tests!
Jeremias Maerki