Victor Mote wrote:
Dear FOP Developers:
Hi Victor - welcome back. I was saddened by your decision to leave FOP.
After considering a return to FOP development, and briefly discussing the
pros and cons with those whom I consider to be the FOP development leaders,
I have decided to partially fork FOP
Andreas L. Delmelle wrote:
Hmm.. Yes, but... these properties are not specifically meant for the rows
themselves. They are meant to be propagated to/combined with those defined
on the table-cells contained by it.
Good point.
( IIC, resolving the possible conflicts WRT backgrounds/borders can be
Andreas L. Delmelle wrote:
comments below:
Posting this as a follow-up to my earlier ponderings. If we don't get it
implemented, or postpone this one indefinitely, at least we'll have it
nicely summed up for possible future use... (Who knows, maybe parts of these
remarks can be used to implement
Peter B. West [EMAIL PROTECTED] wrote on 18.05.2004 05:59:20:
project. The situation with FOray is more complicated. I don't know
whether it is Victor's intention to fork from HEAD and continue the
development along the lines he has previously discussed, or to attempt
to integrate HEAD
[EMAIL PROTECTED] wrote:
Some elaborations on this from my side. Please feel free to ignore it
entirely.
Thanks for speaking up. Just because you are not a committer, doesnt mean your
opinion doesnt matter. This is open source way. The project is owned by everyone.
snip/
5. Time goes on, A' and
FOP Devs,
I would appreciate some advice. I have noticed that top/bottom borders dont
work on regular blocks. This is because the PDF Renderer uses block.getWidth()
to determine the length of the border lines. Here is a sinnper of Area Tree
output:
block width=138897 ipd=0
Chris Bowditch wrote:
FOP Devs,
I would appreciate some advice. I have noticed that top/bottom borders
dont work on regular blocks. This is because the PDF Renderer uses
block.getWidth() to determine the length of the border lines. Here is a
sinnper of Area Tree output:
block
Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33:
This is very true, I also have the same concerns, which is why I have
set out
some simple objectives that must be met before the redesign is ready for
an
initial release. See here:
Simon Pepping wrote:
Note in this respect the comment in
LayoutStrategy.java:
/** Useful only for allowing subclasses of AddLMVisitor to be set by those
extending FOP **/
right above
private AddLMVisitor addLMVisitor = null;
I think you should copy that comment to Document.java as well.
[EMAIL PROTECTED] wrote:
Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33:
This is very true, I also have the same concerns, which is why I have
set out
some simple objectives that must be met before the redesign is ready for
an initial release. See here:
Hello!
What wrong with pdf made with cyrillic KOI8-r?
Chris Bowditch [EMAIL PROTECTED] wrote on: 18.05.2004 14:31:39:
What I forgot to say is that I think we should do an initial release of
FOP
after doing just High priority TODO items.
Ok, that changes things, of course.
Yes, ugly output can be caused without border collapse, but yet
Baron Moenghausen wrote:
Hello!
What wrong with pdf made with cyrillic KOI8-r?
Hello,
sorry but I dont understand your question. Could you rephrase it and maybe
elaborate.
Thanks,
Chris
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
snip /
This makes sense - what effect would you expect width on table
cell to have? I maybe missing something, but the width is
derived from table column and cant be overridden for a single cell.
Indeed,
Andreas L. Delmelle [EMAIL PROTECTED] wrote on 18.05.2004
18:09:15:
Indeed, but the columns can be absent in the source FO. In which case
they're actually to be considered present, and their widths are
determined
by the cells in the first row (--or, but I didn't dare consider that
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi Arnd,
snip /
As far as I understand the spec, table-column elements with a column-width
property are mandatory for tables with fixed table layout.
*Vry* good point!
Yup, got me there... I was mixing the
On Tue, May 18, 2004 at 09:16:23AM +0100, Chris Bowditch wrote:
Victor Mote wrote:
Dear FOP Developers:
Hi Victor - welcome back. I was saddened by your decision to leave FOP.
After considering a return to FOP development, and briefly discussing the
pros and cons with those whom I
Simon Pepping wrote:
2. modularize FOP's design
I do understand why you have decided to start FOray. Although
modularisation is a nice feature, I dont see it as a key
goal for FOP.
FOP's primary objective is to achieve a working layout. The main
things needed to achieve this are
Victor Mote [EMAIL PROTECTED] wrote on 18.05.2004 22:12:45:
The real question on modularity was never whether it should be a
priority,
but whether it hurt the project. On open-source projects, priorities are
really set by each individual. You fix the thing that hurts the most at
the
moment,
[EMAIL PROTECTED] wrote:
In my formatter, I have implemented modularized layout. From the start, I
was sceptical, and I was indeed tempted several times to throw the concept
out of the window because it got in the way, but in the end it was always
possible to maintain the separation of concerns
The thing that immediately strikes me about Arnd's development is that
it seems to blow away the theory that incremental modification of an
existing code base is always the better way to go. IIUC, Arnd wrote a
formatter from scratch (except for some fo the font handling) in two years.
Peter
Peter B. West wrote:
The thing that immediately strikes me about Arnd's development is that
it seems to blow away the theory that incremental modification of an
existing code base is always the better way to go. IIUC, Arnd wrote a
formatter from scratch (except for some fo the font handling)
22 matches
Mail list logo
