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
Speaking of extensions, I'd like to resurrect the layout extensions that
were part of the code used to start the Knuth branch, but I want to be
sure I'm allowed to do it.
The set of extensions (a couple of new properties, and some new value for
an existing one) is aimed to give the user more
+1 from me, especially since you'll document it properly and because it
has the nice side-effect that we get to see more of your great work!
On 02.09.2005 09:35:41 Luca Furini wrote:
Speaking of extensions, I'd like to resurrect the layout extensions that
were part of the code used to start
Jeremias Maerki wrote:
For those who don't want to run BatchDiffer themselves, I've uploaded a
ZIP full of PNGs, one per layout engine test case combined from output
from the PDF, PS and Java2D renderers.
Just an idea ... what about an option to have the output from two
renderers and the XOR
Already implemented. :-) I borrowed the code from Batik. See the
create-diffs
parameter in the config file (documented in the Javadocs of BatchDiffer)
which allows to switch the generation of diff images on and off.
http://wiki.apache.org/xmlgraphics-fop/VisualTestingFacility
On 02.09.2005
[Luca]
Speaking of extensions, I'd like to resurrect the layout extensions
That isn't exactly use of the term extension which I'm using and which
I think Jeremias is using in the ExtensionPoints wiki. Your extensions
are additional useful features, when I talk about extensions it is the
On 02.09.2005 10:24:12 Finn Bock wrote:
[Luca]
Speaking of extensions, I'd like to resurrect the layout extensions
That isn't exactly use of the term extension which I'm using and which
I think Jeremias is using in the ExtensionPoints wiki. Your extensions
are additional useful
Luca,
I'm speaking here as a (future) Fop user. Just to let you know that I'm
definitely wanting to support you in this area. I think your extensions would
make Fop an extremely powerful typesetting system, that would eventually beat
TeX in the quality of page makup. It's all the more
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
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 |
-
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36475.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36476.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36476.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36477.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36477.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36480.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36480.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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 /
24 matches
Mail list logo
