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
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 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:inline
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
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
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
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
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,
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
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
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=whiteinline with fo:blockBlah
blah/fo:blockfo:blockBlah blah/fo:blockborder=solid 5pt red
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
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
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
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
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 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
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 |
-
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 /
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
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
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
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
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
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
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
26 matches
Mail list logo
