Luca,
I need your advice again.
I changed Text LM so it knows if it has to cater for extra
'borderandpadding' at the beginning and end of lines. I then added the
sequence of glue, penalty and boxes you suggested to the "normal space
with default justification" case - and hooray it works fine.
Luca,
thanks great stuff - that gives me a lot to work with.
Manuel
On Tue, 6 Sep 2005 06:48 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > These two paragraphs confuse me - sorry. My understanding was:
> >
> > discard = start/end borders/padding only at the start and end of
> > the whole fo:in
Manuel Mall wrote:
These two paragraphs confuse me - sorry. My understanding was:
discard = start/end borders/padding only at the start and end of the
whole fo:inline
retain = as discard plus start/end borders/padding on the start and end
of every line the fo:inline spans.
Sorry, you are
Luca,
thanks for taking the time to respond. Comments inline.
On Tue, 6 Sep 2005 05:26 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > 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
Manuel Mall wrote:
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
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
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
BlockStackingLa
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 co
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:
> > > Another question for the "Knuth" experts. It appears the inline
> > > LMs
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
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 rel
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,
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,
___
On Sep 2, 2005, at 17:44, Vincent Hennebert wrote:
Hi,
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
followi
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 |
-
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
> > jud
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
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
>
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 sl
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
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 thi
Interesting results if you add the following to your test case:
Normal text inline with Blah
blahBlah blahborder="solid 5pt red"
padding="5pt" normal finish
Looks like a little work. The element list generates boxes with height=12000pt
for each of the nested bl
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 se
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 f
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 a
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-strateg
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
I have a follow-up question on this. If we have something as simple(?)
as this:
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
;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_
erated 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):
>
>src="../../resources/images/bgimg300dpi.jpg"
> border="solid 5pt" padding="5pt" backgrou
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):
and this is the generated viewport:
The viewport bpd/ipd includes the padding and border width while it
31 matches
Mail list logo