+1
On 24.11.2003 23:03:41 Victor Mote wrote:
Glen Mazza wrote:
[Incidentally, this someone else can be Peter
himself at this stage...I'd like to see a little bit
more FOP-DEV/-USER ML communication from him, however
the quality quantity of his patches have been very
good. I'm open
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Barnaby Shearer wrote:
snip/
(I am using FOP 0.20.5 on the Sun JDK 1.4 under windows XP)
Thanks for the analysis but FOP 0.20.5 is frozen code I'm afraid. FOP
has been redesigned to support keeps (on all FOs) and development is
focused on the redesigned branch in CVS Head. Column balancing will
J.Pietschmann wrote:
Chris Bowditch wrote:
but my motivation is just to get something rather than nothing.
You are bored? Oh!
Thanks for the suggestions. I think you misunderstood though, I'm far
from bored, my employers keep me busy. Just trying to help get layout
unbroken.
Some tasks:
-
I've read your proposal with great interest. I still have to say that
I'm still not knowledgeable in the property-resolving area that I can
cast a vote here. But it sounds good, nothing that disturbs me. I hope
that the people with intimate knowledge in this area all participate and
bring up any
Hi,
In case anyone else has a similar problem there is a simple (and very
obvious) fix:
In: BodyAreaContainer.resetSpanArea(), After line:
newHeight += 2 * 15600;
Add:
if(newHeightgetRemainingHeight()) {
newHeight = getRemainingHeight();
}
You can then tweak the newHeight safety
vmote 2003/11/25 07:29:38
Modified:src/documentation/content/xdocs resources.xml
src/documentation/content/xdocs/dev tools.xml
Log:
add some cvs and xsl-fo resources
Revision ChangesPath
1.33 +2 -1
Note: I added a page to the wiki for this thread.
http://nagoya.apache.org/wiki/apachewiki.cgi?PropertiesRedesign
After thinking about the proposal, I'm not sure it solves anything.
There are two aspects to the redesign of Property handling in FOP.
* Interface means the external points
Victor Mote wrote:
[Incidentally, this someone else can be Peter
himself at this stage...I'd like to see a little bit
more FOP-DEV/-USER ML communication from him, however
the quality quantity of his patches have been very
good. I'm open for making him committer should others
also feel this way
John Austin wrote:
After thinking about the proposal, I'm not sure it solves anything.
Perhaps not. If the purpose of building a house is to supply shelter, then
building a foundation would seem also not to solve anything. However, it is
kind of a necessary first step toward the ultimate goal.
Victor, I was mostly backing away from my earlier posting which was
off-target.
On Tue, 2003-11-25 at 13:26, Victor Mote wrote:
John Austin wrote:
After thinking about the proposal, I'm not sure it solves anything.
you might make to the implementation would require (I think) changes to
Victor Mote wrote:
[Incidentally, this someone else can be Peter
himself at this stage...I'd like to see a little bit
more FOP-DEV/-USER ML communication from him, however
the quality quantity of his patches have been very
good. I'm open for making him committer should others
also feel this way
Hello,
I am making an effort to understand FOP's architecture and program
code. In this process I have compiled a number of documentation
notes. It is a loose collection of notes on various aspects of the
program, liberally illustrated with object dumps and stack traces as
provided by jdb. The
John Austin wrote:
In order to adapt Peter's ideas, I would need identify the current
Interface(s). Ideally a re-implementation of Property handling would be
invisible outside of those classes.
I think we have a one-time cost of changing the interface. IOW, I think any
changes that you make
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
chrisg 2003/11/25 17:12:46
Modified:src/documentation/content/xdocs book.xml
Log:
Added link to the Wiki
Revision ChangesPath
1.27 +1 -0 xml-fop/src/documentation/content/xdocs/book.xml
Index: book.xml
After my last post I went away to play in the code for a while.
Mostly to see what is necessary to isolate a minmal set of
classes related to Property handling.
What I found is:
1) Property is ubiquitous: every client class knows what package
it lives in. As a planning point, I better think
John Austin wrote:
After my last post I went away to play in the code for a while.
Mostly to see what is necessary to isolate a minmal set of
classes related to Property handling.
What I found is:
1) Property is ubiquitous: every client class knows what package
it lives in. As a planning
--- Victor Mote [EMAIL PROTECTED] wrote:
Also, as Glen
has pointed out, there
is business logic that can be pulled out of these
code modules back into FO
Tree where they more properly belong, and where
duplication and confusion
can be minimized.
A few more ideas:
(1.) You may find that
--- Peter B. West [EMAIL PROTECTED] wrote:
And now for a little digression on code generation.
My own view of code
generation by XSLT transformation can be summed up
as:
Why, Peter, you're in disagreement with everyone else
on this issue! (So what else is new? ;)
* the canonical
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
And now for a little digression on code generation.
My own view of code
generation by XSLT transformation can be summed up
as:
Why, Peter, you're in disagreement with everyone else
on this issue! (So what else is new? ;)
Everyone
Victor Mote wrote:
I am confused by the distinction that you make between fop.PDFFont and
fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless
it is a renderer-specific class for getting a Type1Font (for example) into
the PDF output. But I think that should be a method in
22 matches
Mail list logo
