Re: future of FOP

2005-03-07 Thread Chris Bowditch
Jeremias Maerki wrote:
snip/
I understand that IBM is quite big in the document business. It would be
very interesting if IBM committed to supporting FOP like they do for
other open source projects here at the Apache Software Foundation. As
far as I know IBM even has its own implementation of XSL-FO although I
don't know if it's actively maintained.
I guess you mean the alphaworks XFC project? It is not maintained at all. I 
posted a are you still alive question back in 2003, still waiting for a 
reply ;-)

Chris



Re: page-breaking strategies and performance

2005-03-02 Thread Chris Bowditch
Jeremias Maerki wrote:
Hi Jeremias,
I finally have Knuth's Digital Typography and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that best-fit is probably
the obvious strategy to select, especially if TeX is happy with it.
Obviously, it can't find the optimal solution like this but the
additional overhead (memory and CPU power) of a look-ahead/total-fit
strategy is simply too much and unnecessary for things like invoices and
insurance policies which are surely some of the most popular use cases
of XSL-FO. Here, speed is extremely important. People writing
documentation (maybe using DocBook) or glossy stock reports have
additional requirements and don't mind the longer processing time and
additional memory requirements. This leads me to the question if we
shouldn't actually implement two page-breaking strategies (in the end,
not both right now). For a speed-optimized algorithm, we could even
think about ignoring side-floats.
We have dozens of customers using an XSL-FO solution and I can confirm 
invoices and insurance policies are a common use case for XSL-FO. A lot of 
companies have performance as a priority and we have no one using side floats 
or even thinking about using them, so optimizing for speed by ignoring side 
floats sounds like a good idea! But this is just my 2 cents and may conflict 
with other people's wishes.

Obviously, in this model we would have to make sure that we use a common
model for both strategies. For example, we still have to make sure that
the line layout gets information on the available IPD on each line, but
probably this will not be a big problem to include later.
An enhanced/adjusted box/glue/penalty model sounds like a good idea to
me especially since Knuth hints at that in his book, too. There's also a
question if part of the infrastructure from line breaking can be reused
for page breaking, but I guess rather not.
Probably best to re-create an algorithm from scratch for page breaking but 
line breaking can be reviewed for ideas.

As for the plan to implement a new page-breaking mechanism: I've got to
do it now. :-) I'm sorry if this may put some pressure on some of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since I don't want to work with a series of patches like
you guys did earlier, I'd like to create a branch to do that on as soon
as we've agreed on a strategy. Any objections to that?
If we are going to branch the code for this then we need to make sure we have 
a plan to merge the branch back once we are confident in the new page breaking 
algorithm. This plan (which should be agreed before branching takes place) 
should include an acceptance procedure, e.g. will a single -1 be able to 
prevent the code being merged back? We dont want to end up with another 
alt-design, which eventually moved to source forge!!!

Chris


Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-03-02 Thread Chris Bowditch
Glen Mazza wrote:
Hi Glen,
OH!!!  lightBulb state=on wattage=25/ 

Yes, you're right, Chris--now I see the issue.  I
implemented validation for about 80% of the FOs, but
80% is not 100%.  fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.  
I'm glad this issue has finally been resolved, thanks for taking the time to 
research a bit deeper.

Sorry, Jeremias, I thought you had just gratuitously
*removed* the validation from fo:table-body -- I
should have researched that it wasn't there to begin
with.
Well, that would have been a bit rude, but like you said there wasnt any 
validation on fo:table-body. Now hopefully we are all a bit more comfortable 
with the situation.

Thanks,
Glen
Chris



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-25 Thread Chris Bowditch
Jeremias Maerki wrote:
On 25.02.2005 07:21:25 Glen Mazza wrote:
snip/
For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even if it's just a short message.
Jeremias:
your change gets +1 from me.
Glen:
All Jeremias was doing was changing the code to prevent a rather nasty NPE in 
the event of an empty fo:table-body. Surely you cannot be arguging that the 
NPE be restored?!?

Chris
snip/


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Chris Bowditch
Jeremias Maerki wrote:
snip/
So here are the proposed changes:
- Package org.apache.fop.render.awt becomes org.apache.fop.render.java2d
- AWTRenderer.java becomes Java2DRenderer.java (AWT*.java -
Java2D*.java)
I think the viewer subpackage can stay as is under the renamed package.
Any objections?
None from me.
Chris


Re: FOP 0.15 Double Byte Support

2005-02-11 Thread Chris Bowditch
m r dantuluri wrote:
Hi,
I am using FOP 0.15 Version. The PDF files rendered by FOP gives junk 
charecters for double-byte languages like korea, japan etc.
FOP 0.15 is ancient. I am fairly confident that I can go as far to say it is 
unsupported. Please upgrade to 0.20.5.

When I search in the net I found that we need to edit userconfig.xml and 
needs to write the code to load the xml file using 
org.apache.fop.apps.Options java file.
When I searched in my disk, I could not find userconfig.xml, arial.xml 
(xml files for the fonts).
We packaged apache related jar files into one jar file. when I look into 
the jar file I could not find the class file with 
org.apache.fop.apps.Options and org.apache.fop.configuration.*;
Probably because you have a 4 year old version of FOP. The website and all our 
documentation refers to 0.20.5.

Is FOP 0.15 version supports Double byte languages or not?
If supports, what are the steps i need to follow.
Where can I get more information about FOP 0.15.
Please help me in finding the solution for this.
BTW: the fop-dev mailing list is for developers talking about coding FOP. 
Questions on how to use fop should be directed at the fop-user mailing list. 
All the developers subscribe to both lists.

Chris


Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Chris Bowditch
Jeremias Maerki wrote:
Just to be clear. This ArrayOutOfBoundsException is not the same problem
I've described in my earlier post. I just happened to run into both
problems at the same time. Running normal-breaking2.xml with the current
code (without my patch) will result in a document with 1 page and the
linefeeds displayed as #. So, this test will fail because of the
single check in the test case.
If someone has an idea about the ArrayOutOfBoundsException, all the
better. I'm currently trying to debug that thing.
Jeremias: Have you seen the following bug which appears to be the same 
problem?
http://issues.apache.org/bugzilla/show_bug.cgi?id=32174
snip/
Chris


Re: Problem with newlines in TextLayoutManager

2005-02-02 Thread Chris Bowditch
Jeremias Maerki wrote:
Luca (and maybe Finn),
Not forgetting Simon :-)
snip/
Is there some reason why my patch below would make anything worse? It
seems to fix my problem here and all my test cases still pass (at least
the ones that passed before).
I dont know the answer to your question. However, I wondered if you have 
reviewed the comments/todo list left by Luca in bugzilla?

http://issues.apache.org/bugzilla/show_bug.cgi?id=27901
This bug is still open, but there are some others which may help understand 
what is going on here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=28021
http://issues.apache.org/bugzilla/show_bug.cgi?id=28130
Hope this helps a bit,
Chris



Re: start-indent inheritance

2005-01-14 Thread Chris Bowditch
Jeremias Maerki wrote:
There seems to have been some discussion about this in the CR phase:
http://www.w3.org/2001/08/28-XSL-PR-DOC.html (see comment 20)
It would seem that in the case of reference-area generating FOs
start-indent should simply be inherited (comment 20, item 3). In my
example the start-indent of the block-container would be 10pt, which is
then inherited by the orange block. This amounts to an effective 20pt
indent for the orange block and oops, AltSoft is suddenly right. I'm
confused.
I would say that in the absence of any clear right or wrong in the spec and 
different interpretations by different commercial renderers, I would suggest 
that implementing the easiest approach would be the best way to go.

Chris


Re: replace extension bookmarks with XSL 1.1 ones?

2004-12-17 Thread Chris Bowditch
Glen Mazza wrote:
They're coming very close (I suspect in a few weeks at
the latest) to having a Last Call version--would it
be acceptable for you at that stage?  I don't mind
waiting a little longer.
Second edition of working Draft was released today :-)
snip/
Chris


Re: Good news: Jeremias has been elected as an ASF member!

2004-12-01 Thread Chris Bowditch
Christian Geisert wrote:
Bertrand Delacretaz wrote:
Hi FOP people,
I have the great pleasure to announce that Jeremias Maerki has been 
elected as an ASF member at the last member's meeting during ApacheCon.
This is good news indeed for both Jeremias and the FOP project!
Chris


Re: AreaFactory patch

2004-11-03 Thread Chris Bowditch
Andreas L. Delmelle wrote:
snip/
Hi fellas,
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
*solid* argument pleading against the proposed change. Of course, something
like LM Makers can be added later on --the proposed AreaFactory shouldn't
hinder that.
All we heard up to here is a few vague concerns about so-called increased
complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern
for chrissake! It doesn't bite... or does it? Anyone?
Well, Im not trying to start a fire fight here. And its true that the 
requested change is a simple Factory pattern. I agree the concept is simple. 
But what I object to is people keep adding loads of pluggable this and 
pluggable that to a system whose basics arent yet finished.

So all I am trying to say is lets hold off on pluggable interface A, B and C, 
until the basics are finished. I dont think this is a vague arguement.

It may also be worthwhile stepping back from implementations here and consider 
what are the business reasons for adding the pluggable LMs? Just because a 
newbie on the list says he needs them, he doesnt say why, we have just 
accepted that maybe he does. I think we should ask what the business usecase 
is? Is it related to XSL-FO in anyway, we dont know. If theres a good business 
case, then I wont object. But so far, no business requirements have been stated.

snip/
Chris


Re: AreaFactory patch

2004-11-02 Thread Chris Bowditch
Glen Mazza wrote:
snip/
Personally speaking, I am much more amenable to adding
some complexity (LM Makers, for example, or opening up
our validation) if it helps out Finn's work, because
of the sheer weight of contributions he adds to Fop. 
(We slow him down, we slow down Fop.)  Making these
changes for someone who isn't submitting
contributions, however, is less of a concern for me. 
If a user is going to propose a change that would slow
down system development, we should be getting some
work to compensate for it, at least during this time
while we are still building the system.

My inclination is to have him place this patch in
Bugzilla, and let's wait until we have others
requesting it (vs. those who would rather have LM's
pluggable.)  In the meantime, I think it would be best
for everyone to keep layout as simple as we can until
it is done.  I am open to others' opinions however.
I'm definitely in agreement with you on this one Glen. Lets keep Layout simple 
whilst its still unfinished. Pluggable LMs can be added once we have an 
initial release.

Chris


Re: Form Extension

2004-11-02 Thread Chris Bowditch
Clay Leeds wrote:
On Oct 31, 2004, at 7:17 AM, Florian Hecht wrote:
I' ve developed a form extension for XSL-FO for an university project. 
 It's an extension to FO like the fox extensions. With it you can 
declare and define the usual form elements like edit fields, radio 
buttons, check boxes, combo boxes, list boxes, comment fields and 
buttons. They are inserted into a document as inline objects, so that 
they flow like normal text. As a proof of concept I've extended 
fop-0.20.5 to support my form extension. I'm using the system around 
ExtensionObj to make fop understand my elements and I've extended the 
PDFRenderer to generate PDF documents that contain forms, that can be 
filled out and submitted just like normal HTML forms.

This is an oft-requested (once every couple of months counts as 
'oft-'...) feature. Thank you for this information! This is exciting, 
and I can imagine it almost certainly being a tool others may want.
Hi Clay - yes I concur with you. This feature is asked for quite frequently by 
some of our clients.

snip/
The reason why I'm announcing this is that I will finish the project 
in a couple of days and I don't think I will develop the form 
extension any further. Maybe someone will find the sources usefull as 
a starting point or is even willing to develop it further. The sources 
and the precompiled jar archive can be found at my homepage [1]. I've 
also got an example fo document with my extension there, together with 
the resulting PDF file. So anyone who's interested can take a quick 
look at it. The paper I'm writing on this project will be released in 
couple of days (in German though, Studienarbeit) together with a 
little documentation on the form extension in English.

I just wanted to let you know. If you have any questions, just ask me. 
Any feedback is welcome.
Thanks for letting us know. I am mildly excited about this. However, I fear I 
wont be able to use it unless it is ported to HEAD.

Thanks,
Chris


Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Chris Bowditch
Clay Leeds wrote:
snip/
When I look at the FOP Compliance page, I see a couple of items which 
are implemented (I assume this page is in reference to the 
0_20_2-maintain CVS branch--I am I correct in this assumption?).
Hi Clay - yes compliance page does refer to 0.20.5 functionality.
snip/
Chris


Re: [PATCH] PDFTextPainter.java in fop-0_20_2-maintain Branch

2004-10-13 Thread Chris Bowditch
Schmitt, Christian (ext.) wrote:
 Hi,
 while updating our project I found this one bug where the
 color for SVG text elements wasn't set correctly.
 The patch below should fix that.
Hi Christian,
thanks for submitting your patch. I have created a bugzilla entry and attached 
your patch to it. You can find it here:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31692
In future I would be grateful if you can follow the procedure for submitting 
patches:

http://xml.apache.org/fop/dev/index.html#patches
Chris



Re: Valid version of the PDF specification?

2004-10-11 Thread Chris Bowditch
Glen Mazza wrote:
OK -- PDF 1.4 it is.  I agree with supporting Acrobat
V5.  However, I don't see backwards compatibility
concerns as much of an issue here, given the Acrobat
Reader is free and pretty easy to download. 
Glen,
you are right that AR is free and easily available. However, large 
organisations have a tendency to lock down users PC's to prevent downloading 
for security reasons and object to rolling out new versions of software to 
1 PC's for obvious reasons.

Chris


Re: AFP Renderer on Sourceforge

2004-09-29 Thread Chris Bowditch
Townsend, Pete wrote:
Dear fop-dev,
The AFP renderer has now been added to sourceforge
http://afp-renderer.sourceforge.net and a release is available for download
compatible with FOP 0.20.5, please could you close the patch on bugzilla
31213 (or direct them to the above link) so that people don't get hold of an
out of date version. If Web Maestro Clay could add a link to the sourceforge
site that would be great, and perhaps publicise to your user mailing list?
There is some basic documentation which I'll continue to enhance, and I plan
to migrate to the latest release when available. At that point I'll be in
contact again to see if you wish to take the renderer in house.
Hi Pete,
thanks very much for preparing this. It is likely that I will be asked by 
company to integrate this into the maintenance code at some point. I would 
prefer to integrate it into the development branch, but I have to do want my 
company tells me!

Thanks once again,
Chris


Re: How much work is left before we can release HEAD?

2004-09-28 Thread Chris Bowditch
Simon Pepping wrote:
snip/
My interest in FOP's layout is mostly theoretical. I cannot get
enthousiastic about todo lists, time schedules and time estimates.
Thats understandable.
I would like to see keep and break properties implemented. They are
the raison d'ĂȘtre of the new design. I do not think they can be
implemented with the current design, because there is no arbitrator of
the page length. The problem should be solved in a manner similar to
the way Luca solved the inline layout problem: All possible break
points should be returned to a high-level object, probably the Flow
LM. This then applies a certain algorithm, keeping lengths and keeps
and breaks into account, to determine the best break point. The
structure for this procedure must be added to the current design.
Oh I thought this was one of the key points that Keiron addressed when he 
wrote the layout code in HEAD. Sounds like my estimate may be a bit longer then.

I am also interested in block stacking constraints. They exercise the
ability to relate the layout produced by one LM with the traits of the
areas produced by other LMs. Perhaps it can be done using the layout
context, perhaps one should navigate the LM tree to gather the
required data.
Finally I hope it will be possible to make the structure of the layout
module simpler. I believe it is the complexity of this module that has
hindered progress the most. With my recent change to LMIter I tried to
come closer to the semantics of a collection and an iterator, and make
it easier to create more iterator objects for the children of an LM
without disturbing the state of the one used in getNextBreakPoss. I
hope more such changes are possible and will make it easier to
understand the layout module.
Simplifying the LMIter objects is one way Joerg identified of making layout 
easier to work on.

I do not know if this is a lot of work or not. To me it seems a
lot. Perhaps you may argue that this is not required for a 0.3
release. But to me it is rather essential to the new design. Without
it we might as well remain with the maintenance layout system.
keeps and breaks are essential for a 0.3 release. As you said yourself they 
are the whole reason the redesign was started in the first place. I'm not sure 
block stacking constraints are essential.

I understand that the new design for renderers has been more
successful, and may be a reason to want a release of the development
code.
This is not a good enough reason for a release.
snip/
Chris


Re: [VOTE] Luca Furini for Committer

2004-09-25 Thread Chris Bowditch
J.Pietschmann wrote:
Simon Pepping wrote:
I propose that we make Luca Furini a member of the FOP team.
+1 for me too.
Chris


Re: [VOTE:RESULT] Luca Furini for Committer

2004-09-24 Thread Chris Bowditch
Jeremias Maerki wrote:
Looks like we don't get any more votes. Let's see:
+1 from:
Simon Pepping, Clay Leeds, Jeremias Maerki, Oleg Tkachenko, Finn Bock,
Glen Mazza, Christian Geisert, Joerg Pietschmann, Bertrand Delacrétaz. 
(9 votes)
cough, cough. I did vote too. Sorry to be picky, but I want to make it clear 
that I think Luca really deserves committership. Congratulations, Luca.

Chris


Re: [VOTE:RESULT] Luca Furini for Committer

2004-09-24 Thread Chris Bowditch
Jeremias Maerki wrote:
Sorry, Chris, I don't have your vote on my radar [1]. Must have gone
lost somewhere.
Thats Ok, I cant find it in the archives either, but it is in my sent items - 
odd really.

Chris


How much work is left before we can release HEAD?

2004-09-22 Thread Chris Bowditch
Team,
I have been trying to work out what is left to do be done before we can do an 
initial release of HEAD, 0.3, say. I know some of you will prefer to aim for a 
1.0 and get everything right first time, but please bear with me.

I have consolidated the layout issues from [1] and [2] The infrastructure 
items listed in [1] I feel are good enough for a 0.3 release. This is largely 
thanks to work from Glen, Finn, Simon, Luca, Peter, Jeremias and the other 
committers. Sorry if Ive missed anyone.

Anyway, i have created a wiki containing the work items along with my opinion 
of priority and a finger in the air time estimates:

http://nagoya.apache.org/wiki/apachewiki.cgi?FOPWorkEstimates
I would very much appreciate some feedback.
Chris
[1] http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectTasks
[2] http://xml.apache.org/fop/design/layout.html#status-todo


Re: [Proposal] I volunteer to help with 0.20.6

2004-09-10 Thread Chris Bowditch
Anton Tagunov wrote:
Hi, gang!
I'm Anton Tagunov, a committer with Avalon and Excalibur
apache projects. I'm afraid I have not been much active
withing these projects lately, but I've still got the commit
priviliges and an active apache account.
Welcome.
I have a full understanding of current situation @fop:
0_20_2 branch has been frozen and all efforts have been
directed at reacheing 1.0 release. On the other hand there
has not been a release for quite a while. The only thing
available to users is 0.20.5. And I do know that a massive
refactoring has happened on the path to 1.0. And I do know
that 0.20.5 code is a bit messy which in the beginning
caused the refactoring.
Well, thats not the full picture. Refactoring was started because it is too 
difficult to implement keep-* properties into the maintenance code because of 
it architecture. Hence a new architecture was thought up and hey presto: work 
begins on 1.0.

However, being practicle we (I work for Deutsche Bank now)
definetely need fop NOW. We do use 0.20.5. And we do have
local patches for it. I feel these patches may be of a
certain value to others too. Also I would also like to
leverage public review available with open source. Besides
we do have at least several patches against 0.20.5 flying
around cvs.
What a small world. My company is working with Deutsche bank (London) on a 
project involving FOP. At the moment they are our only customer who still work 
 with FOP. Most of our customers must have XEP to get keep-* properties. This 
is the one area that FOP really falls down on. If FOP had keep-* properties it 
would be used much more. That is why we must focus our energies on the redesign.

snip/
The mantra of 0.20.6 would be: no new features, not much
labor, go for low-hanging fruit and fix what is easy to fix
and for what patches are already available.
That should be relatively easy. Piece of cake.
In a way I agree with you, and it looks like you will be taking on most of the 
work for yourself, and thus minimising the distraction from HEAD development. 
But I would much rather you concentrated on HEAD. Doing more development of a 
frozen architecture is only going to encourage more users for a dead code base.

On the upside FOP project which has not had releases for
quite a while while gains some more visibility and showes it
is alive. 0.20.6 announcements will be accompanied with a
big fat comment that it is just a bug-fix and the real
paradize is expected with 1.0.
1.0 isnt a real paradise, more like a 0.3. Just 0.20 plus keep-* properties. 
Well, thats the goal. In reality theres going to be some regression on 0.20.x 
functionality.

I do understand the nature of software development. I do
understnad you're at 1.0-dev. I honestly hope some day I
will find enought time and enery to dig into that. But being
practical this is what I can offer fop community right now:
assistance in 0.20.6 release. Low-hanging fruit. Light bug
fixing.
I have to say I think I'm against doing a 0.20.6. I dont like being negative 
toward someone who wants to improve the code, but I think its for the best if 
1.0 stands a chance. And I know whats it like not having much time, most of 
the other committers are in the same boat. Yet we have all made at least some 
contributions towards the 1.0 effort. I would like to see you doing the same.

snip/
Chris


Re: [Proposal] I volunteer to help with 0.20.6, part II

2004-09-10 Thread Chris Bowditch
Anton Tagunov wrote:
amendment:
It really is not such a nonsense as it may seem, Tomcat
3.x.y piecfully co-exist with 4 and 4 coexists with 5.
The trouble is everyone always focuses on 0.20.x to the detriment of 1.0 
development. Going for the low hanging fruit in 0.20.x may help fix a few 
minor issues but you cant escape from the fact that keep-* properties cant be 
implemented there.

To reduce mess in the cvs if this proposal is wellcomed we
could create a svn subdir, something like
fop-0-20-2-maintain.
No one said there is a mess in CVS. I dont think there is a need to create a 
separate directory. A branch is fine.

Let me repeat again: I will ask PMC not to vote for the
release if I get bogged down into anything but most
simplisting bug fixing. Just go through Bugzilla and apply
most evident and simple patches. And then ask people: has
anthing become worse since 0.20.5.
The concern with allowing development of 0.20.x is not that we introduce 
regressions or that there are large changes. Simply, that it distracts from 
the real goal of FOP: getting the few simple bits finished in 1.0 so that we 
can do a release. And we really arent that far away. I reckon a developer with 
a good knowledge of the layout code could plug the main gaps in about 3-4 
months solid work.

(What really killed me in 0.20.5 were troubles with table
rendering when cells do have a background. And awt renderer
produced pour-quality images cause it used int-based
Graphics interface not a double-based one. And I have patch
for that too. But some other patches as simple is that are
floating around, some hyphenation patch.)
Chris



Re: remove layout package?

2004-09-06 Thread Chris Bowditch
Glen Mazza wrote:
Team,
With the recent removal (who did that? ;) of the
unused layout.AreaClass and layout.TextState classes,
the fop.layout package is now empty save for its
hyphenation subpackage.
I'd like to drop the layout package and make
hyphenation a top-level package (i.e.,
org.apache.fop.hyphenation).  Comments?
I agree.
As a newbie last year, having both a layout and a
layoutmgr package was confusing [1]--so another
benefit for this change is to eliminate confusion for
people just starting to look at the code.
This also confused me for a moment too.
Chris



Re: foray integration

2004-09-02 Thread Chris Bowditch
Victor Mote wrote:
FOP Devs:
I checked in with Chris Bowditch recently to see how his foray work was
coming, and he indicated that he has not had, and probably will not have in
the near future, enough time to complete the evaluation and make a
recommendation to you.
Victor is right, I dont have the time to integrate FORay into FOP at the moment.
Does anyone else wish to take up this project? It would seem to me to
involve the following:
1. Determine whether the idea of FOP and foray working together is a
workable idea from FOP's standpoint. If not, stop.
2. Do some alpha testing of documents to see whether foray works.
3. Consider whether the API is suitable, and likely to be robust enough for
future expansion.
4. Determine whether FOP developers will do a 0.21 release out of
maintenance branch code. If not, skip to step 7.
5. Apply the fop-maint piece of foray as a large patch to the maintenance
branch.
6. Start into a release cycle.
7. Consider applying the foray API to FOP's trunk.
I think most of these should be pretty trivial except #7.
foray's current status is here:
http://www.foray.org/release.html
Victor has done some extremely good work on the font side of things. I think 
it would be very beneficial if we could integrate his work into FOP's HEAD. 
The ability to read the metrics on the fly would be a massive improvement on 
the current font system in HEAD. It would be a great shame if this work was 
ignored.

Chris


[Fwd: DO NOT REPLY [Bug 29124] - New line breaking algorithm]

2004-09-01 Thread Chris Bowditch
--- Additional Comments From [EMAIL PROTECTED]  2004-08-31 18:44 ---
Thanks for the new patch. I could apply it without problems, and
testing it goes well.
You mention that you have not implemented the Knuth algorithm for
ContentLM. Would it be difficult to do that?
FOP team,
If I would apply this patch, we would get the following regressions:
- ContentLM does not show its content. A leader with
  leader-pattern=use-content results in a blank area of the right
  size.
Doesnt sound like it will be difficult to fix after the patch is applied.
- When for an exceptionally difficult paragraph no set of breaking
  points can be found, the whole paragraph is printed on a single
  line. This occurs, for example, when in a narrow typesetting width
  only a single word or a part of it fits in a line.
I would think that strange effects like this are possible today. Can you see 
what the output would look like in such a scenario with the current code?

I am working towards applying this patch despite these
regressions, for these reasons:
- This patch is a good piece of work, and a step forward for FOP's
  layout.
Agreed.
- It becomes increasingly hard to maintain this patch outside of CVS.
I know how you feel. I found it hard work before when I examined Luca's 
earlier Knuth patch.

Chris




Re: AFP Renderer

2004-08-10 Thread Chris Bowditch
Glen Mazza wrote:
There are already other AFP Renderers for FOP
0.20.5--actually Hansuli has it in our resources page:
http://xml.apache.org/fop/resources.html
I agree with Pete here - this AFP renderer is too disjointed and has a few 
limitations which make it too unpractical.

And--amazing what Google searches turn up--Keiron also
created one for FOP apparently:
http://www.aftexsw.com/personal/resume.html
Interesting, I never knew that either!
But if you wish to donate code to the ASF, you are
welcome to submit it as a patch--in either 0.20.5 or
1.0 format.  (I caution though that the 1.0 rendering
system architecturally is not finalized.)  We can
possibly leverage it along with the others in the
future.
The fact that we don't have native support for it
already, however, could mean that there were licensing
issues involved with its inclusion (or the fonts it
uses, perhaps).  This may be an IBM-only technology
for which you must use IBM-only products--I don't
know.
I dont think there are any licensing issues. AFP is a widely used print 
format. I have worked on software products dealing with AFP before.

Chris


Re: AFP Renderer

2004-08-10 Thread Chris Bowditch
Jeremias Maerki wrote:
Hehe, and then there was the one by UBS which I asked them to make OSS
and they declined even after killing the project.
I don't think there's a big legal problem around AFP, it's probably more
the technology itself that has the attribute may cost a bit more on it.
:-) While it would be great to have an AFP renderer we also have to see
how to support it. Pete seems to imply a code dump (Once I move on to
the next project it is unlikely to happen.) so a little warning sign
may be asked for. How many of us understand AFP? I don't. Yet. ;)
I wouldnt go as far as saying I understand AFP, but I have worked on a AFP 
Parser before, and I feel I understand it as well as PDF, i.e. if I dont know 
what a command does I just look it up in the appropriate reference manual.

Chris


Re: AFP Renderer

2004-08-10 Thread Chris Bowditch
Glen Mazza wrote:
My primary goal is not to get this committed.  But
if you have code you wish to donate to the ASF, just
do so via Bugzilla.  It doesn't matter which
format--it is the logic in the code that is being
sought.  No guarantees, however, as to it ever getting
committed into FOP, because we don't have significant
demand for it, and as Jeremias said, there is a time
factor involved with maintaining renderers.  There is
also the issue of the damage done to the FOP's
reputation as a whole should it ship with renderers
that operate only partially or incorrectly.
Well, FOP already has renderers in this state: PCL and Text.
I believe Demand for AFP is there. We certainly have customers who want it. 
And the fact so many people have written their own AFP Renderers in house 
confirms this.

Today is the first I've ever heard of AFP, and I've
been on the project for eighteen months, so it has to
be given lower priority compared to the other output
types that we *do* get demand for--PDF, PS, PCL, and
AWT.  And so we'll need to hear substantive demand
from the user community first--else it should remain
external (perhaps added to our resource page, as we
currently do in such cases) to the project.
Well the external AFP Renderer on the Resources page, just isnt very 
practical. Even if we never get round to committing Pete's AFP Renderer, at 
least if it is available as a Patch in bugzilla, its a better starting point 
than the external one by Hansuli Anderegg.

Chris


Re: AFP Renderer

2004-08-10 Thread Chris Bowditch
Townsend, Pete wrote:
Glen, 

I'll get this added as a patch (via Bugzilla as Chris suggested). The
developer forum can then decide if this is something you wish to take
forward (perhaps someone can get feedback from the user community as to
whether it would be desirable). It has saved us a huge amount of effort,
previously we had to define duplicate print templates (one for PDF and the
other for mainframe AFP/IPDS) - so as one member of that community I can
vouch for its desirability. Also if you search the web you will see that
many commercial products will convert AFP/IPDS to PDF or vice versa so the
demand is certainly there and the addition of this capability is likely to
increase the user base.
Thanks for persevering with this. It really will be useful. I know there are 
many commercial products that work with AFP, I have worked on one such product 
before.

I appreciate that an additional renderer adds an overhead, hence offering my
services to support it. It has taken a lot of pressure from myself to get
agreement by my company to release to ASF - they are likely to be reluctant
to have the code released elsewhere (i.e. on a resource page) - we have a
very sensitive legal department! 
If you could add a patch to bugzilla that would be great. It would be better 
still if you have the time to convert it to work with HEAD, but if you dont 
then 0.20.5 will do and ill try and have a go at getting it converted to HEAD.

Chris


Re: AFP Renderer

2004-08-10 Thread Chris Bowditch
Keiron Liddle wrote:
Well I did it for an internal project and was never allowed to release
the code so it has remained unchanged and closed for some time now. I
still believe that all is needed is for someone to start put the code
into the public. The basic format (although binary and a bit difficult
to understand) is not that hard once you get the idea.
Not sure what you mean by someone put it into the public? Presumably you mean 
the company you were working for, rather than one of the FOP committers?

Its a shame that so many companies hate the thought of others benefiting from 
code written by their developers.

Chris


Re: generating PDFs in non-english

2004-08-09 Thread Chris Bowditch
Nuno Lopes wrote:
Hello,
I was trying to make some PDFs of the PHP manual when I got some problems.
The manual is written in docbook and then I have a XSL sheet. I can generate
the manual in english, portuguese, french,... but not in russian.
Firstly, please post user related questions to the user list. The Development 
list is for code related issues. The developers are all subscribed to the user 
list anyway.

When I open the file I only get #. What am I doing wrong?
I've tried using FOP directly with XML, and with a FOP file generated by
xsltproc, but noone works.
This means that the font-family you are using does not have any glyphs for the 
russian code points. It is a FAQ, with more details on the web site:

http://xml.apache.org/fop/faq.html#pdf-characters
Chris


Re: AFP Renderer

2004-08-09 Thread Chris Bowditch
Townsend, Pete wrote:
Dear FOP Developers,
Could you let me know whether you'd be interested in adding a AFP renderer
to the project. I really think it would be worthwhile as many enterprise
scale projects use AFP printing and being able to use a formatted object so
they can be rendered as AFP or PDF is very advantageous.
Yes, yes, yes! Couldnt agree more. AFP would be very useful.
I'd be grateful if someone could respond as I only have a limited window of
opportunity to get the code into the public domain. Once I move on to the
next project it is unlikely to happen.
I suppose you based the AFP Renderer on the maintenance code (0.20.5)? A shame 
since no more releases will be done from this branch. It may be possible to 
modify the patch to work with the current development code (CVS HEAD)

The patch process is fairly straight forward. Use a CVS client to generate a 
difference file between the CVS code and your code. If you based your AFP 
Renderer on the maintenance code then be careful, you will be to do a 
difference against the branch fop-0_20_2-maintain. Then submit a new bugzilla 
entry with title [PATCH] and attach (not copy  paste) the difference file to 
the bugzilla entry.

Chris
P.S: I never saw your original post. Dont know how it slipped past me.


Re: [GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance failed

2004-08-04 Thread Chris Bowditch
Glen Mazza wrote:
I'll take care of it by this weekend, if not much
sooner.
Thanks Glen, where would we be without you!
Chris


Re: Redesign

2004-08-03 Thread Chris Bowditch
Clay Leeds wrote:
On Aug 2, 2004, at 1:48 AM, Chris Bowditch wrote:
Clay Leeds wrote:
snip/
Just to be sure, are these amongst the changes you're looking for:

Hi Clay, yes these are the changes I was looking for. If you could 
apply the changes manually I would be most grateful. Thanks,

Chris

Done. Keep in mind, I *manually* edited the page (vi is my friend!), and 
that's how I made the update. I actually deleted the 3 TRs in the TABLE 
(the 2 modified indicated below, and the one between), and then pasted 
the updated version. If there were other changes you made to that file, 
they didn't make it in.
Hi Clay - thanks for that. The changes I made were all to the TODO table.
Web Maestro Clay
p.s. It was a bit of a rush editing the live xml.apache.org site... I 
probably shouldn't like it that much! :-D
Glad you enjoyed it!
Chris


Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-03 Thread Chris Bowditch
Glen Mazza wrote:
Well, the number of patches and enhancements made to
layout/rendering has only been about 2-3 per month in
the 12 months that we've had AddLMVisitor.  FOP won't
finish at that rate, and that *will* affect the users.
I agree that FOP wont finish at its current rate of development! Not sure how 
to change this and still keep a roof over my head. LOL

In the 24 months preceding that change (i.e., the
original design I'm recommending we return to), I
believe it was several times higher, perhaps an
average of 25 changes per month.  Also, the developers
at that time seemed to obtain a much higher grokkage
of the layout/rendering code base.
The statistics dont tell the full story. The reason the patch rate was so much 
higher before the Visitor pattern was introduced is because Keiron (one of the 
main architects of the redesign) was allowed to work on FOP as part of his 
paid job, and he seemed to disappear not long before Victor started his 
modularization efforts. Also because the maintenance code had not yet been 
frozen (of course, you might not be including patches to branches in your 
statistics)

Nice things happen when you drop the IQ needed to work
in the code--and simplifications have a habit of
begetting more simplifications, as relationships that
were previously obscured/unknown become clearer.[1]  
I tend to agree, but I personally dont find the Vistor pattern the reason the 
code is so complex. Its the getNextBreakPoss/addAreas methods in TextLM and 
LineLM that are scarey.

In other words, I may be able to propose even more
simplifications after this on things I currently can't
see with the code as it is.  Let's try to get this
system down to something that a 12 year old can finish
in a weekend.  (I believe Victor has one he can lend
us as a guinea pig.)
Ouch!
At any rate, given that most FO's generate and/or
return areas (per the Rec), I don't have a problem
with one selecting and initializing its own
LayoutManager.  That is basically what happens anyway,
even with the middle man in between.
I dont have a problem with that either. I remain -0 on this change.
Chris


Re: Redesign

2004-08-02 Thread Chris Bowditch
Clay Leeds wrote:
snip/
Just to be sure, are these amongst the changes you're looking for:
Hi Clay, yes these are the changes I was looking for. If you could apply the 
changes manually I would be most grateful. Thanks,

Chris

Justified Text
High
This has been completed, thanks largely to Luca Furini. Although there 
is still issue 28706 that requires further analysis.

Multi-column layout
High
Get Markers Working
High
Main Problem is markers can be added to wrong page. LEWP is returning 
first on Next page!


If so, I can manually upload the changes to xml-site/targets/fop/
Web Maestro Clay
.



Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-02 Thread Chris Bowditch
Victor Mote wrote:
J.Pietschmann wrote:

Well, the real stakeholders (aka users) are probably more 
interested in working footnotes, or multi-column layout.

I don't understand. More interested in working footnotes or multi-column
layout than what? Is removing AddLMVisitor an advancement in getting
footnotes or multi-column layout working better? Are you reminding us of
your neutrality on modularity? Or are you saying that this kind of question
is irrelevant? Please let me remind you that I was responding to a direct
question.
I think Joerg was saying that the details of the code are irrelevant to the 
end user. I tend to agree with this point, and see no benefit in removing tbe 
AddLMVisitor stuff. So I have to vote -0 as well.

Chris


Re: Redesign

2004-07-30 Thread Chris Bowditch
Andrej Czapszys wrote:
Please excuse my ignorance, but what is the current status of the 
redesign, and how might I help out?  The website explanation wasn't very 
clear.  
The website is great for the maintenance versions of FOP 0.20.x, but is a
little unclear with regards to the redesign (sorry Clay - I dont have any
specifics to hand)
In particular, extreme memory usage and inability to auto-size 
tables have been bugging me.  The current stable version of FOP is 
great, but I'd like to help improve these areas and others.  Is there a 
current TODO and/or complete status list?  
Follow the below link where you will find a list of items that need doing
before the redesigned code can be released. Issues such as memory and auto
table layout would be nice to have, but the redesign has more serious problems
that need dealing with first.
http://xml.apache.org/fop/design/layout.html#status-todo
Of course, this is largely just my opinion and you are welcome to work on any
area you choose. And any contribution you make will be greatly received.
Or can someone help me out in 
this regard?   Also, what are the current high priority issues from your 
perspective?
I'm kind of a Roadmap personality in that I'd like to know where 
contributors would like the project to be in X months.  
Well, I'd like to see the HIGHs on that list fixed in the redesigned layout so
we can do a release of the redesigned code, and get out of the rut that FOP is
stuck in!
snip/
Chris



Re: FOray 0.1 release

2004-07-14 Thread Chris Bowditch
Victor Mote wrote:
FOP Devs:
I am pleased to announce the release of FOray 0.1 alpha 1. This release is
only useful to FOP developers. Some useful information about the release can
be found in these places:
http://foray.sourceforge.net/module/font/index.html
http://foray.sourceforge.net/module/font/release.html
Since it is developers-only, I have not prepared any downloadable packages.
You will need to use CVS to get the code. This is available here:
http://sourceforge.net/cvs/?group_id=109663
Hi Victor: Great that you've managed to create a Font API.
Probably the most efficient way to proceed is for Chris to do the initial
evaluation work. I can support him off-line, and probably will need to add
some doc as a result of his work. Then any others who wish to look at it
will have an easier time.
Yes, I will gladly take a look at some point over the next few days.
snip/
Implied within FOray itself is a desire on my part to start getting code
released again. I realize that there are several views of how best to get
that done, and that FOray might be viewed as a distraction by some. If that
is the prevailing view, and FOP has no desire to release this code under any
circumstances, then you can save Chris a lot of trouble by reaffirming the
status quo now. This will put the burden on FOray to start releasing
essentially a competing product, which I am not eager to do. (This may
happen eventually anyway if I have time to pursue the modular design that I
think is important, but it is just as likely that a FOP 1.0 release will
make such an effort unnecessary). As a friend of FOP I have opinions on
what you should do, but my role here is different, and I will try to remain
neutral, providing information when needed. I'm really just a guy trying to
get some work done -- if it helps you, good; if not, that is OK too.
I am clear on FORay's stance with regard to FOP, and I also hope that some of 
your work can benefit FOP too. Thats why I dont mind evaluating what you've 
done so far.

Chris


Re: Validity checking

2004-06-25 Thread Chris Bowditch
Peter B. West wrote:
Hi Peter - did you have a good honeymoon?
Fopsters,
I notice that Glen has been progressively adding validity checking to FO 
elements.  I'll take this opportunity to draw the attention of recent 
foppers to an earlier discussion of the relative merits of push vs. pull 
parsing in FOP.  Alt-design (which I think I will just call FAD in 
future) uses pull parsing.  The discussion went on over a more than one 
thread, e.g., 
http://marc.theaimsgroup.com/?l=fop-devm=103507639220269w=4 and 
re-surfaced in the discussion of marker handling in FAD, 
http://marc.theaimsgroup.com/?l=fop-devm=105455437221298w=4
Yes, I had noticed Glen gradually adding validity checking to FOs, and its a 
very worth while task. Thanks Glen!

I have read all those Threads at the time, and I dont think I can add anything 
to them that hasnt already been said before. On the one hand, Alt-design 
appears to have a very pure design that is hard to fault, and I think your 
dedication to developing it is very admirable. But at the same time, I cant 
help thinking that it is distracting effort away from HEAD. I realise HEAD has 
its faults, but it is an improvment on the maintenance code, and does what it 
set out to do, overcome design limitations that prevent keep-* properties 
being implemented.

The best encapsulation is probably the following discussion of the 
general principles, and their application to validation, with a nice 
instance of the effects of this validation in the case of 
simple-page-master.
http://marc.theaimsgroup.com/?l=fop-devm=103785986329929w=4
Chris



Re: [PROPOSAL] Finally creating the XML Graphics PMC....

2004-06-22 Thread Chris Bowditch
Glen Mazza wrote:
Reconsidered.  OK, I'll join, and reinstate my first
proposal, that of you joining the PMC and (yes) being
its head.
Hi Glen,
glad that you reconsidered, I agree with Jeremias, the PMC needs you. It also 
needs Jeremias, so I second your proposal to have Jeremias on the PMC.

Chris



Re: cvs commit: xml-fop/src/java/org/apache/fop/render/pdf PDFRenderer.java

2004-06-17 Thread Chris Bowditch
Jeremias Maerki wrote:
Chris, please check the settings of your IDE not to allow tab characters.
Thanks!
Hi Jeremias,
I cant simply turn off Tabs as I need them for my paid work! I would like to 
be able to run checkstyle to check for this sort of mistake, but have run into 
some problems with it.

It seems our config files were originally written for 2.4, with a 
checkstyle-3.1.1-Head file being provided in CVS for 3.x versions. However, I 
could only find 3.4 available for download anywhere, and the config file 
layout seems to have changed again since 3.1.

If no one knows where I can download either 2.4 or 3.1, then I will have to 
read up and find a way to convert our config file to the new XML format.

Chris



Re: Offline

2004-06-17 Thread Chris Bowditch
Peter B. West wrote:
Fopfellows,
I will be offline for the next week.  I'm marrying Jenni tomorrow, and
honeymooning in the frozen south of the South Island of New Zealand for
a week.  I'll post some photos to my web site when I get back.
Peter - congratulations! Enjoy your well deserved break.
Chris



Re: [Fwd: CVS and Subversion]

2004-06-14 Thread Chris Bowditch
Glen Mazza wrote:
Noted.  My instinct would be for us to wait about 6-9
months after several other projects move over.  If no
problems with them, or at least no major problems,
then I think it would be fine for us to switch
products if other committers would like.
However, this will still require someone SVN-loving
enough to do the heavy lifting of migrating our source
code over.  CVS is still quite fine with me, so I'm
not motivated enough to bother with migrating it.
I'm in agreement with you Glen. I'm not motivated to do the migratation and 
relearn tools, etc. Lets wait and see how many other projects migrate.

Chris



Re: InlineLMs

2004-06-01 Thread Chris Bowditch
Simon Pepping wrote:
Inline area generating LMs and Inline area containing LMs
and their corresponding FO nodes
=
In the listings below the LMs are followed by the FO nodes that
generate them.
Thanks for the summary Simon.
snip/
Note that Luca's patch causes a loop on this block. The null
implementation of AbstractLayoutManager.getNextKnuthElement causes
this. It should be modified to finish the LM:
Great stuff. Do you think Luca's patch is ready to be committed with this 
change? Or is more testing required?

Thanks,
Chris



Re: column balancing

2004-05-28 Thread Chris Bowditch
A.M. wrote:
Replying off-list:
huh?
I'm not sure I really have a choice concerning the fop version. 
Considering I needed column balancing yesterday, I'll take the route 
that gives me balanced columns ASAP. I haven't looked at the PDF 
rendering code yet, so (neglecting your desire for the dev version to 
move forward) would you argue that it would be easiest to add column 
balancing to the maintenance version or to the dev version? If I can add 
it quickly to the maintenance version, I would be happy to add the same 
functionality to the dev version later. Thanks.
Thats understandable. Yes, it will be less hassle for you to add column 
balancing into the maintenance code. Just dont expect your changes to make it 
into the code base. If you are able to give us some help with the development 
version later that will be greatly appreciated.

Chris



Re: column balancing

2004-05-27 Thread Chris Bowditch
[EMAIL PROTECTED] wrote:
A.M. [EMAIL PROTECTED] wrote 27.05.2004 16:27:29:

Excuse me for being annoying with the column balancing issue (from 
fop-user), but it's something that we crucially need. I would like to 
offer my time to implement this- however it's not clear to me which 
block attributes are relevant to this. Could someone point me to the 
page of the spec covering this? (Column balancing is unfortunately the 
only thing keeping us from FOP.) Thanks.

As far as I can see, column balancing is not really defined as a mechanism
in the XSL recommendation. My interpretation so far is that to do column
balancing if a spanned block follows on the same page and not to do it
if no spanned blocks follows, is one of several allowed user agent
behaviours - and the one that makes the most sense as a default.
If your or someone else finds something in the XSL recommendation
that more precisely defines what should happen, I would be grateful
for a pointer as well.
What Arnd says make sense. I would like to add that any development help you 
can give will be gratefully received. However, you need to be aware that the 
maintenance branch 0.20.5 has been frozen, so any patches you submit to 0.20.5 
code are unlikely to make it into the code base. I'm not sure that multi 
column layouts work at all in the development version, but you are more than 
welcome to help. If you have any questions at all, please dont hesitate to ask.

Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Simon Pepping wrote:
snip/
No exceptions. I ran Luca's test fo files successfully.
Strange how you and I always get such different results. It doesnt run with 
any file despite changing the language to en. I always get NPE on LLM:249. 
Looking at the code it would appear to be a mistake as NPE will occur if 
text-indent is not specified on any block. I tried placing a IF statement 
around this line, but got a NPE elsewhere.

I dont understand how you can run Luca's files. The NPE seem to be limited to 
LLM and TLM, which I copied complete from Luca's patch. Did you manage to 
apply the patch file with LLM/TLM, or did you copy the complete files? There 
must be some differences in our code, or am I going mad?!?

snip/
I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
I have to agree that the patch is far from ready. I in no way mean to cast a 
bad light on Luca's work. Luca must be congratulated for his efforts thus far, 
but we cannot accept a patch that will take the redesign effort backwards. 
With more testing and the bugs fixed, this patch will take the redesign 
forwards with a much cleaner approach to line breaking. I hope Luca will be 
happy to work on his patch some more locally.

If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
I have to agree with Glen on this point, -1 for creating another branch. I 
have replied in more detail in another posting.

Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Peter B. West wrote:
snip/
Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree immediately 
before a branch.
Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel the 
project is at the wrong stage in its development for another branch right now. 
Branches invariably mean splitting development focus. Right now I want to 
focus on fixing the High priority issues with layout so we can do a release. 
If we flail around for another year or so then FOP may be dead in the water as 
other projects overtake it.

Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Luca Furini wrote:
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.
I have proved that textIndent is definitely null when it is not specified on 
the block.

snip/
While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):
I assume you mean the LLM constructor?
  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...
and if blockProps.firstIndent returns null? Which it appears to be if the user 
doesnt specify on a block.

I hope this can help you; thanks for testing my patch.
After adding an IF test around the code that uses textIndent to avoid NPE, I 
then get the following error:

25-May-2004 09:11:43 org.apache.fop.layoutmgr.LineLayoutManager getNextBreakPoss
WARNING: No set of breaking points found with maxAdjustment = 1.0
Exception in thread main java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:385)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
at org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss(FlowLayou
tManager.java:81)
Thanks,
Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Luca Furini wrote:
You are completely right; by the way, what other child LMs could the LLM
have?
I'm just guessing, but I think anything that can appear inline, i.e. 
hyperlinks, leaders, etc. Block level stuff like Tables and graphics can not 
be children of the LLM.

I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...
I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.
No need to apologize or thanks us, your efforts are most appreciated.
I'll work on this patch for some more time, and I'll let you know of the
progress.
Thank you, please let us know if you need any assistance or further feedback,
Chris



Commits

2004-05-25 Thread Chris Bowditch
Team,
thanks to everyone who agreed to hold off commits until the fate of Luca's 
patch had been decided. I think everyone is in agreement that this first patch 
needs more work, so I will re-sync with CVS. Therefore, it is safe to make 
commits to HEAD once more.

Thanks,
Chris



Re: can't find default configuration file

2004-05-25 Thread Chris Bowditch
Clay Leeds wrote:
BTW, Anyone else seeing sporadic mail issues? I didn't actually 
*receive* Andreas' message. (I noticed in MARC, and am responding before 
I go home).
Hi Clay - I noticed that the mailing lists were very slow yesterday, with 
responses appearing in MARC well before I received them. Seems to be back to 
normal today though.

Chris



Re: Fixing break-* properties

2004-05-25 Thread Chris Bowditch
Andreas L. Delmelle wrote:
Hi Andreas,
its great to have you trying to help with layout.
Adding the necessary activation code to the FObjs to pass these properties
to Layout is easy enough, but I'm still having a bit of difficulty in
'seeing' what needs to be done to handle this in the respective LMs
getNextBreakPoss()... How is LayoutContext involved in this (or isn't it)?
Well I believe you need to create a BP with the FORCE flag set and watch for 
this in the PageLM.

Chris



Re: Justification and line breaking

2004-05-24 Thread Chris Bowditch
Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had 
trouble compiling, due to BLM using the old constructor for LLM with FObj as 
the first argument. This is easily corrected, but I would have expected a 
change to BLM in your patch file. Also I found a few calls to getLogger in the 
LMs, which dont compile. I hit the problem of not being able to call getLogger 
in the LM code myself recently. So I added a getLogger method to AbstractLM.

Once compiled I tried testing with a complex document, but that fell over. 
Previously it was working, albeit without markers. I then tried one of your 
more simple test cases and that fell over too. Here is the stack trace, which 
is the same for both documents:

Exception in thread main java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next 
couple of days? I would be grateful if you could hold off for a couple of days 
whilst the problems with this large patch are resolved. I dont want to have to 
re-apply the changes. Let me know if this causes any problems

Chris



Re: Justification and line breaking

2004-05-24 Thread Chris Bowditch
Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had
trouble compiling, due to BLM using the old constructor for LLM with FObj as
the first argument. This is easily corrected, but I would have expected a
change to BLM in your patch file. Also I found a few calls to getLogger in the
LMs, which dont compile. I hit the problem of not being able to call getLogger
in the LM code myself recently. So I added a getLogger method to AbstractLM.
Once compiled I tried testing with a complex document, but that fell over.
Previously it was working, albeit without markers. I then tried one of your
more simple test cases and that fell over too. Here is the stack trace, which
is the same for both documents:
Exception in thread main java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next
couple of days? I would be grateful if you could hold off for a couple of days
whilst the problems with this large patch are resolved. I dont want to have to
re-apply the changes. Let me know if this causes any problems
Chris




Re: Markers

2004-05-21 Thread Chris Bowditch
Andreas L. Delmelle wrote:
Just gathering my thoughts here...
Thanks for your feedback. I need all the help I can get!
If I interpret the related code in BLM correctly, then the childLMs are all
created (and call their addAreas() ) after the first marker has been added
( line 265: addMarkers(true,true); )
addMarkers( true, true ); translates to
parentLM.addMarkerMap( markers, true, true ); (see
AbstractLayoutManager.java line 360 )
This latter stops at page-level, in PageLayoutManager, it becomes:
curPage.addMarkerMap( markers, true, true );
So, IIC, this makes it conceivable that a marker is added to page 1, then
subsequently the childLMs signal a BP, maybe breaking the page, but
certainly leaving the marker where it was initially added.
No, because as you say above addAreas is being called and this doesnt not 
generate BPs, BPs are generated by the getNextBreakPoss method on each LM. 
This is why I am puzzled, the page boundaries are decided when the 
getNextBreakPoss methods are called. By the time, addArea methods are called, 
the page boundaries have already been decided

snip/
Chris



Re: FOray integration to FOP

2004-05-21 Thread Chris Bowditch
Victor Mote wrote:
FOP Devs:
I apologize for intruding again. After thrashing around for a bit, I
No need to apologize, your input is welcome.
concluded that there were an overwhelming number of good reasons for me to
import the entire FOP maintenance branch into the FOray repository, then
delete and modify as necessary for FOray integration. One of the biggest
benefits is that it will greatly simplify any integration that FOP decides
to do with Foray. Specifically, I don't have to be in the business of trying
to coordinate such integration, and you don't have to listen to me trying to
do that. Just come get it if you want it. The good news is that I will
essentially be doing the maintenance branch integration for you -- there
shouldn't be much to do except decide whether you want it or not. I have
posted greater detail here:
http://foray.sourceforge.net/fop/index.html
This approach allows FOray and FOP to ignore each other most of the time.
However, I obviously hope that you will check in from time to time to see
whether we have anything useful for you. Please let me know if I can help in
any way.
This approach makes a lot of sense.
I will probably unsubscribe fop-dev in the next few days, so if I don't
respond here, contact me off-line or through FOray.
I will check up on FOrays progress from time to time, to see if theres 
anything that we need to do.

I wish you every success with FOray.
Chris



Re: Justification and line breaking

2004-05-21 Thread Chris Bowditch
Hi Luca,
May I start by thanking you for your hard work in submitting the patch for 
Knuth's Line breaking algorithm.

I'm just starting to look at your patch now. First thing that strikes me, and 
this was pointed out to me before I became a committer. Please try to avoid 
commenting out large chunks of code. If the code is no longer needed please 
delete it. If we need to go back to the old code, we can always get the 
previous versions from CVS.

Second thing, are you just ignoring word spacing and letter spacing at the 
moment? I think one of the other FOP Dev's hit the problem of how do we tell 
if property was specified or is it just the default before? Hopefully they 
will speak up with a work around. If we do go without the letter spacing 
property, then they really ought to stay as NotYetImplemented in the 
FOPropertyMapping and just put come comments into the code to explain why it 
cant be implemented ATM.

I'll comment again once Ive done some testing. Thanks,
Chris




Applying Large Patches (was Re: Justification and line breaking)

2004-05-21 Thread Chris Bowditch
FOP Devs,
I'm trying to apply Luca's patch and running into problems. The hunks in the 
first 9/10 files get applied okay, but when the patch program gets to 
LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for 
some reason the patch program thinks it has found the start of another file 
and errors with File not found. Skip this file [n]: 

Has anyone else got any experience of working with such large and patches? Any 
advice on how to proceed would be appreciated.

Thanks,
Chris



Re: Applying Large Patches (was Re: Justification and line breaking)

2004-05-21 Thread Chris Bowditch
Jeremias Maerki wrote:
Chris,
I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java, too, you could sort out the rest manually.
Eclipse IMO has a very good patch facility. You'd probably get farther
that way.
On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.
Thanks for the quick reply Jeremias. I think the easiest solution will be for 
Luca to supply his complete LineLayoutManager.java and TextLayoutManager.java 
(the two files that have more than 1000 lines changed) Would you mind 
attaching them to the patch Luca?

Thanks,
Chris



Re: Incremental vs rewrite

2004-05-20 Thread Chris Bowditch
Simon Pepping wrote:
That was basic work. The basis of the property subsystem is good,
and shorthands all work, I think. But it is another question which
properties are really implemented w.r.t. their effect on the layout. I
do not think we have a good overview. See Glen's experimental
approach: Transform a set of documents and see what you think is not
right, which is the best we seem to be able to do right now.
Thanks for the confirmation Simon. Transforming documents and seeing what 
doesnt work is the approach I have been taking. Currently trying to see why 
markers dont work properly.

Chris



Re: Incremental vs rewrite

2004-05-20 Thread Chris Bowditch
Peter B. West wrote:
My understanding is that thanks to the property work earlier this year 
by Glen, Finn and Simon, that properties are 95% there, including 
shorthands. Admittely I didnt follow their work very closely, so could 
be wrong about this. Im sure Glen will interject and correct me on 
this if I'm wrong.

I do get burned when the work on properties is mentioned without any 
acknowledgment of the influence that alt-design has had on HEAD's 
properties development.
Sorry Peter,
Chris



Re: Just do it

2004-05-20 Thread Chris Bowditch
Jeremias Maerki wrote:
Guys,
my comment on this is: Commit it if you think it's an improvement. It
may be a bit different if it concerned design questions, but with small
fixed and improvements I'd rather you guys just did it. If it turns
out to be a mistake it can easily be corrected. That's why we have peer
review here. You guys block yourselves with this strategy and Arnd gets
even more of a head-start. :-)
Hi Jeremias,
you are right of course. I was just worried I might have broken something 
else, but I'm sure that will show up in time. It certainly works for the 
documents I have tested. Now committed 

Chris



Re: Trait.ID_AREA

2004-05-20 Thread Chris Bowditch
Tibor Vyletel wrote:
Hi guys,
 
In previous versions (builds) of FOP areas have had set ID_AREA trait in 
order to allow identification of original FONodes (and XML elements) 
they had been created from. Why is this feature missing in recent builds 
(1.0DEV)? Is there any other possibility how to connect Area -- FONode 
-- XML Element data entities?
I suspect that the ID_AREA property has been removed from FObj as a result of 
the property re-work. Perhaps one of the property gurus will be able to 
comment further.

Polite request: please dont post to the list in HTML, its considered bad 
etiquette.

Chris



Markers

2004-05-20 Thread Chris Bowditch
FOP Devs,
I'm currently trying to get Markers working. The problem I have is that the 
first marker on page 2 is actually being added to the markers on Page 1.

the markers are added to pageViewport in the BLM.addAreas method. Now my 
understanding is that addAreas are called once the BPs have been processed and 
the areas are about to be rendered. So how is this possible?

Any thoughts will be appreciated?
Thanks,
Chris



Re: ANN: FOray

2004-05-19 Thread Chris Bowditch
Victor Mote wrote:
Simon Pepping wrote:

I sympathize with this goal as well. I realize that that is 
not quite in line with my reaction to Glen's recent patch. I 
agree with Chris and Glen that it is not currently a key goal 
for FOP. And since we do not have a strong proponent and 
architect of a modular design, there is little point in 
leaving bits and pieces in the code. But in the longer run, I 
consider putting the FOP code in a modular structure as a 
desirable thing.

If you guys are as close to having LayoutManager working as has been stated
in this thread (and I hope you are), then I agree that modularization would
not be the top priority. It is not an end in itself, but a means to an end.
When FOP was internally forked 2 1/2 years ago, the only thing that needed
to be rewritten from scratch was layout, but the whole project was forked
instead. Modularization would have prevented that, and allowed releases to
continue even though a chasm was being created and filled simultaneously.
The whole nature of refactoring anything is that you do it before you do the
real work. That is where FOray starts.
That decision 2.5 years ago has cost FOP dearly. It is also much easier to see 
in hindsight. Given where FOP is today, I just want to see the last 5 issues 
fixed/implemented and we can do a release and get FOP back on track.

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, and that might be different for each developer. If I am working on
A, and you are working on B, as long as your work on B isn't bad for the
project as a whole, I have no right to complain. Nobody has yet put forth a
good argument against modularization, but it was opposed anyway. So now
we'll have a chance to test it in the real world.
I dont recall modularizarion being opposed. It was more a case of Joerg saying 
it would be a challenge and no one else stepping up to support your proposals. 
 From my point of view this was mainly due to me thinking FOPs priority is to 
get the last few bits of layout done so a release is possible. I'm certainly 
not against modularization, I think it would be beneficial, but would prefer 
to see effort going into finishing layout at this time. Once weve done an 
initial release from the development code, then modularization will be a more 
attractive proposal.

Generally you are right in what you say that priorities are down to 
individuals. But given the situation FOP is currently in, I hope most people 
can see why I think No.1 priority is to finish layout.

Consider this -- what if the XSL spec hadn't been split into two pieces?
Would the part that we call Xalan today have its development stalled because
layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be
smart enough to break the implementation into the two projects that it is in
today? All we are really talking about here is the principle of
encapsulation writ large.
Modularization is in general a good idea, I just think its not the right time 
to be doing this within FOP. Perhaps modularization should have been done 2.5 
years ago before branching the project.

Chris



Re: Justification and line breaking

2004-05-19 Thread Chris Bowditch
Luca Furini wrote:
I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite strange that the
LineLayoutManager should make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)
bug 28706 is still a bit of mystery to me, well at least the disappearing 
text, as I dont have an example of it.

At the moment, lines are built one at a time, and in normal cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last short BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.
So, I have tried to implement Knuth's line-breaking algorithm [1], which
calculates breaking points after having gathered information about a whole
paragraph.
Here are a few advantages of this algorithm:
- first of all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing
Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.
this sounds like a really good idea, and would be very pleased if you could 
open a new bug in bugzilla and attach your patch. It will probably need a 
lengthy review involving plenty of testing and cleaning up.

Chris



Re: Incremental vs rewrite

2004-05-19 Thread Chris Bowditch
Clay Leeds wrote:
Be warned that the RenderX testsuite files require a relatively high 
degree of spec compliance. Shorthands are used everywhere, all table
examples require auto-layout, and so on. I confess that I learned a
few more things about FO when testing with these files...

Sounds like a good exercise for someone like me, to transform those 
shorthand items into 'longhand'...
My understanding is that thanks to the property work earlier this year by 
Glen, Finn and Simon, that properties are 95% there, including shorthands. 
Admittely I didnt follow their work very closely, so could be wrong about 
this. Im sure Glen will interject and correct me on this if I'm wrong.

snip/
Chris



Re: ANN: FOray

2004-05-18 Thread Chris Bowditch
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 into a sourceforge project called
FOray:
http://foray.sourceforge.net/
Ive taken a look and it all seems to make sense.
The main reason for this is that, at the moment anyway, my development goals
are quite different from those of FOP's development team. It is likely that
my return to FOP development would be a net disruption to the project, which
is not my intent. Instead, my hope is that this vehicle will allow me to
continue to get my real work done and still cooperate with the FOP
development team.
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 listed here:

http://xml.apache.org/fop/design/layout.html#status
I hope that no one will think that I am recruiting here. I simply thought it
would be rude for you to hear about this some other way. I wish you all
success.
No I dont think that, it is very polite of you to let us know. I cant speak 
for the team as a whole, but I hope that we will be able to cooperate to a 
high extent.

Chris



Re: Table processing question

2004-05-18 Thread Chris Bowditch
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
settled, for a large part, at FOTree building time. )

I also have a hunch that this would be very convenient WRT managing
rowspans... In that case, TableCells could be added to the TableRow
directly, but only temporarily, to defer their finishing (?)
Conversely, what about column spans specific just to one row !?!

They will be stored in the table-cells, just as they are now.
Another good point.
doesnt mean dont consider optimization, I just mean working layout takes
priority over an optimized one.
And it looks like it will be harder to achieve a working layout
with your suggested changes.

Something I'm very concerned about, which is why I haven't started any work
on it yet... wanted to gather your opinions first.
Theres no harm in doing work locally and then formulating a patch for review.
Right now, I just have a very clear-cut idea on what exactly needs to be
done, and if I'm not mistaken, the required changes to Layout will be
minimal (see the upcoming follow-up message: will post that one later
tonight). For the most part, it will work exactly as it does now, only the
code for *creating* the Row and Cell LM's will need a little adjusting
(serveTableRow() and serveTableCell() in AddLMVisitor?)
Chris



Re: Table processing question - follow-up

2004-05-18 Thread Chris Bowditch
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 the starts-row and ends-row properties for
table-cells)
snip/
If we manage to make it possible for the Layout Managers to deal with the
latter, this would allow us to support tables with or without explicitly
defined rows with greater ease (i.e. one strategy fitting both situations).
Difference: in a 700-row table, you'd only have one TableRow FObj instead of
700 that remain referenced until the page-sequence is completed...
(admitted: it does enlarge the TableCell objects a bit...)
Yes, just what I was thinking. TableCell would be quite complicated. Although 
it is hard to gauge by just talking about it.

snip/
While we're at it, add an implementation for the starts-row and ends-row
properties. Still mapped to fop.fo.properties.ToBeImplementedProperty, so
for starters, change the mapping in fop.fo.FOPropertyMapping to make an
EnumProperty for them. In fop.fo.flow.TableCell, add the necessary code to
the doSetup() method to make it possible to actually use them... (is there
another step I'm missing?)
(Come to think of it: the 'width' property for table-cells seems also
unimplemented for the moment)
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.

Modifications in Layout: as already indicated, I think there are not that
many. It will continue to work as it does now. It's only the LM *creation*
process that will need a little tweaking... As there will always be a
TableRow child present, even if there was none specified in the source FO,
the first Row LM will be created anyway. It will just be a matter of adding
the Cell LMs as children of the current Row LM, and generating a new Row LM
when the Cell in question starts a row.
So, for those of you that have read closely (--and have been able to keep
awake ;) ):
Indeed, it seems as if I'm making things more complicated, since the rows
are removed in the FOTree, but are re-introduced in Layout... This is
because, AFAICT, the problem with big tables is mainly the creation of the
FObj's, so this goes a little step towards solving that one. On top of that,
while building the FOTree, it is hardly ever necessary to peek into
preceding/following Rows, so the work over there (IMHO) doesn't really
*need* multiple TableRow objects for one TableBody.
There may be a need to peek at surrounding rows when implementing 
border-collapse algorithms. Not sure if this peeking will need to be done in 
FO Tree or layout or both.

Just food for thought... hope someone enjoys :)
On the whole a very well thought out idea. I dont want you to think I'm 
discouraging you. You have answered my initial concerns, so why dont you go 
ahead and make the changes locally and then create a patch for review. It will 
be easier to discuss pros/cons in more depth by looking at the patch file.

Chris



Re: ANN: FOray

2004-05-18 Thread Chris Bowditch
[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 B progress further.
6. Someone comes up with a carefully refactored version of A' and B is 
stopped.
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:

http://xml.apache.org/fop/design/layout.html#status-todo
We have in fact completed the first item. Once we have completed the other 
tasks the redesign wont be far behind 0.20.5. Once we do a release, I believe 
the project will gain some momentum.

So what happened was: I now have an XSL formatter that is in my estimation 
further
along than the FOP redesign and that does most things that 0.20.5 does and 
a lot of
things that 0.20.5 does not. I confess that so far, I did borrow the 
TrueType font
reader from FOP. What am I going to do with it? Well, it's not really 
decided yet.
The most likely scenario is to make it a commercial product. BTW: why was 
I fast?
I'm good (like you), I had experience in many of the areas involved, and - 
very
important - I didn't need to discuss my architectural decisions because I 
did it
alone. I had fun.
I'm impressed. You must have a lot of spare time, and be a very talented 
programmer. I would be grateful if you could help with any of the tasks listed 
above, so we can get a release of the redesign and overcome FOP's current dilema.

Model A: Let one strong developer with resonable time on his hands drive 
the
development of the redesign until it has so far progressed that it's 
usable
for people currently using 0.20.5.

Model B: Refactor the maintenance branch. This keeps more users and 
therefore
more possible contributors on the bandwagon. Refactoring is tedious and 
needs
experience, but you get that experience quickly and the motivation stays 
over
time. Also, the maintenance branch source code is not *that* bad. Yes, it
badly needs refactoring in most places, but it's not beyond repair.
The redesign project is further along than you might think. 2003 was really 
bad for the redesign, absolutely zilch progress was made on layout. However, 
there has been some progress since the end of last year. So if we can just 
finish the tasks listed above, FOP should be back on the road to success. I'm 
certainly not keen to drop the redesign so close to the finish line. Perhaps 
12 months ago I would have been inclined to agree, but not now.

snip/
Like two years ago, I still don't feel all that comfortable about speaking
up on this. After all, it's *your* project, and what the f*** do I have to
say about it. Ok, this time I decided to do it. Please don't be offended
- it's really meant as a personal opinion from an interested bystander.
I hope you can accept it as such.
I'm glad you have spoken up. And this goes for any other silent folks out 
there considering the same options. Please speak up - every opinion counts, 
the project belongs to the community, not just to the committers.

Chris



Borders on Blocks

2004-05-18 Thread Chris Bowditch
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 height=274960
  block width=0 ipd=138897 height=250351
block width=0 ipd=138897 height=250351
  block width=0 ipd=138897 height=22000
lineArea height=22000
  text tsadjust=0 
props=font-size:2;font-family:F5;color:#00;Home Insurance/text
/lineArea

Notice how ipd=0 for the top level (static content) block and then width and 
ipd swap around for regular fo:blocks. Question is, is this wrong, or should 
the PDF Renderer be changed to consider either IPD or width properties of block?

Thoughts will be appreciated.
Chris



Re: Borders on Blocks

2004-05-18 Thread Chris Bowditch
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 width=138897 ipd=0 height=274960
  block width=0 ipd=138897 height=250351
block width=0 ipd=138897 height=250351
  block width=0 ipd=138897 height=22000
lineArea height=22000
  text tsadjust=0 
props=font-size:2;font-family:F5;color:#00;Home Insurance/text
/lineArea

Notice how ipd=0 for the top level (static content) block and then width 
and ipd swap around for regular fo:blocks. Question is, is this wrong, 
or should the PDF Renderer be changed to consider either IPD or width 
properties of block?
I think I have solved this mystery. The second level block shown above was a 
BC with the optional width property not specified. The assigning of width/ipd 
for a block is done in Block.getParentArea where IPD is always copied and 
width is based on either IPD or parent width. I have modified this logic a bit 
so that if the parent width is used, it will fall back to IPD if it is zero.

It fixes my problem, but I'll wait for any comments before committing this change.
Chris



Re: ANN: FOray

2004-05-18 Thread Chris Bowditch
[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:

http://xml.apache.org/fop/design/layout.html#status-todo
One comment on the todos:
- border-collapse is both important and difficult. I am still fiddling 
with
details of the spec. I suggest ugrading the priority. Not supporting
border-collapes yields ugly output.
What I forgot to say is that I think we should do an initial release of FOP 
after doing just High priority TODO items.
Yes, ugly output can be caused without border collapse, but yet RenderX's XEP 
doesnt have border collapse,
so I dont see an immediate need for it. After all, output only looks ugly if 
you specify borders on every cell edge,
with careful writing of the FO, the output can still look good without border 
collapse.

Well, unfortunately not so much spare time, but as I said, doing it
alone really, really helps. And I very much tried to aggregate as
much spare time as possible into full dev-only days. That helps, too.
With the same background, most of you committers could have done the
same. If you look at it, most successful projects initially had
1 or 2 people at the start who did the core work, and then others
joined to make it complete. If I had joined the redesign team, FOP
wouldn't be much farther than it is now, because most of my time
would have gone to discussions, which in turn would also have taken
up other committer's time.
Perhaps, but perhaps not. As long as you dont make major changes, then its 
possible to proceed without seeking group consent on every little item. Thats 
what I'm trying to do. Work towards a working layout a bit at a time using the 
existing redesigned framework.

What I *can* offer to contribute is discussion about the FO spec or about
implementing PS oder PDF output. This is a concern that we probably share
and that needs discussion in any case. However, for actual implementation
discussions I feel a little reluctant. If my pet project becomes a product
in the future, we will have the same issues coming up here that we had 
with
the RenderX guy speaking up here recently. This is not what I want - 
though
I think what he did was perfectly ok, well-meaning and to be applauded. If
I recall correctly, the uproar was resolved, the RenderX guy got his 
deserved
apology, but the consensus was that the FOP code should be kept clean 
from
competitor's code or even ideas. If I remember that correctly and this 
still
stands, then I would rather not discuss algorithms here.
Fair enough. That was an unfortunate affair, and one I'm keen not to repeat.
Chris



Re: cyrillic

2004-05-18 Thread Chris Bowditch
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



Re: Table processing question

2004-05-17 Thread Chris Bowditch
Andreas L. Delmelle wrote:
snip/
Now, I'm wondering, since the spec states that an fo:table-row doesn't
generate any reference areas and since it can contain only TableCells,
whether it wouldn't be more interesting (heap-wise :) ) to create just one
TableRow object per TableBody, use it to process the TableCell objects in
sets, but add the latter objects directly to the TableBody and reset the
TableRow every time. IIC, a similar adjustment should then also be made to
the Row LM.
Definitely worth considering.
IOW: as I understand it, right now processing the TableBody iterates over
the TableRows (i.e. simply catches the SAX events and blindly maps them to
the corresponding Tree structure), as opposed to using a TableRow (catching
a first SAX Event into a mutable member variable?) and iterate over groups
of TableCells. Since the spec does provide for the starts-row property for
fo:table-cells, it shouldn't be that difficult to set these to true to allow
the Body and Row LM to determine which Cells are returned by the
fo:table-row... The properties of the fo:table-row can be stored in the
separate TableCells where applicable (there are no properties specifically
meant for fo:table-rows; this occasion could also be used to settle
background and border issues).
Huh? This is not true. Follow the link you provided to the spec. table-rows 
can have background and border properties (when border-collapse is on)

I also have a hunch that this would be very convenient WRT managing
rowspans... In that case, TableCells could be added to the TableRow
directly, but only temporarily, to defer their finishing (?)
Conversely, what about column spans specific just to one row !?!
If I judge correctly this could save a significant amount in memory usage in
case of tables with a large number of rows, and could make implementing the
table layout algorithms as defined in the CSS spec a lot easier (--at least,
it seems more natural, since it's possible that there are no fo:table-rows
specified at all, to consider them as optional, rather than having to
perform all sorts of ugly tricks to be able to process a fo:table without
them --which is a wall I bounced into)
OTOH: I do see a challenge in the break-* and keep-* properties on
table-rows, but I guess these could as well be stored in the row-starting
cells somehow.
yes, keep-* properties also apply to rows. On reflection I'm inclided to say 
it looks easier to stay as we are at the moment. Your idea is definitely worth 
considering, but since its primary goal is optimization, and at this time our 
primary objective really should be to get a working layout. That doesnt mean 
dont consider optimization, I just mean working layout takes priority over an 
optimized one. And it looks like it will be harder to achieve a working layout 
with your suggested changes.

snip/
Chris



Re: Justification

2004-04-26 Thread Chris Bowditch
J.Pietschmann wrote:

Simon Pepping wrote:

Summarizing, you mean that

1. the layout system should calculate the justification and add
   corresponding word and space areas to the area tree;


Eh, not quite. The problem is that the actual justification can
only be done after page number citations have been resolved.
Justification has now been implemented without the need for creating separate 
text areas for each word and without the renderer having to compute the split 
positions/spacing itself. Overall I'm rather pleased with Luca's solution. 
Although its yet to be applied to the postscript renderer, and it may not be 
so elegant there, because I'm not sure if postscript has commands for varying 
spaces between words.

However, I realise that justification doesnt work for page citations, or 
leaders. But as I have said before its great that it works for 90% of the text!

snip/

Chris




Offline

2004-04-08 Thread Chris Bowditch
Team,

just to let you know that I will be off line until Monday 19th April.

Best regards,

Chris




Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors

2004-04-05 Thread Chris Bowditch
Simon Pepping wrote:

I believe the reason why justification still doesnt work after correcting the 
issues you've found is because TextLM.addAreas doesnt create separate areas 
for each word - it creates one big area in some cases for whole line, so there 
is no opportunity to add space adjust for justification.


The layout managers only do the calculations. The renderers need to do
the real work, i.e. apply the calculation to the line to be
rendered. The LM can help by splitting up the line in a number of text
areas, or the renderer can scan the unsplit text areas and apply
stretching to the white space in it. There was a discussion about this
topic on this list some time ago.
Yes, I was the one who started the previous discussion. Joerg was pushing for 
the Renderers to do the splitting too. But I disagree with this approach 
because the LMs have already worked out the BPs, why make the Renderers do it 
again. This is very inefficient approach dont you think?

I believe changing the TextLM.addAreas to generate an area for each BP if 
justification is on is the most efficient way of implementing justification.

Chris




[Fwd: DO NOT REPLY [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly]

2004-04-05 Thread Chris Bowditch
Comments most welcome.

Glen,

In general I like your solution. However, I did a bit of testing with inlines 
and the effects are very serious. Valid non-whitespace characters from the 
enclosing block are simply deleted if there is whitespace at the start of the 
fo:inline.

Chris




Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors

2004-04-05 Thread Chris Bowditch
Chris Bowditch wrote:

Simon Pepping wrote:

I believe the reason why justification still doesnt work after 
correcting the issues you've found is because TextLM.addAreas doesnt 
create separate areas for each word - it creates one big area in some 
cases for whole line, so there is no opportunity to add space adjust 
for justification.


The layout managers only do the calculations. The renderers need to do
the real work, i.e. apply the calculation to the line to be
rendered. The LM can help by splitting up the line in a number of text
areas, or the renderer can scan the unsplit text areas and apply
stretching to the white space in it. There was a discussion about this
topic on this list some time ago.


Yes, I was the one who started the previous discussion. Joerg was 
pushing for the Renderers to do the splitting too. But I disagree with 
this approach because the LMs have already worked out the BPs, why make 
the Renderers do it again. This is very inefficient approach dont you 
think?

I believe changing the TextLM.addAreas to generate an area for each BP 
if justification is on is the most efficient way of implementing 
justification.

Just want to add that I realise changing TextLM.addAreas isnt the only other 
change required to get jusitification working. The Renderers will need 
changing too, but I'm against the renderers computing their own splits, just 
give them each word as its own area if justification is on.

Chris




Applying patches

2004-04-02 Thread Chris Bowditch
Team,

sorry but another newbie committer question:

I downloaded a patch program from the internet. Not sure if there is a 
specific one I need, or whether they all conform to a standard. When I try to 
run the patch program with unified patch file in the xml-fop directory, it 
cant figure out the locations of the files its supposed to be patching. I 
thought it would just read the following line:

RCS file: 
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/TextLayoutManager.java,v

I tried telling it to strip the first 2 components of the path, but no difference.

I need a patch program for windows. Can anyone offer advice? I ended up 
applying the patch manually.

Chris




Re: Applying patches

2004-04-02 Thread Chris Bowditch
Jeremias Maerki wrote:

Hi Chris,

I'm applying the patches directly in Eclipse which provides graphical
helpers to resolve problems like this. Patches can even be copy/pasted.
I've had problem with the patch.exe myself in the past, but since I'm
using Eclipse I've had almost no problems anymore.
Thanks Jeremias and Christian. I'm not about to switch to Eclipse, as we are a 
JBuilder shop, but changing the Index entry to include the full path solved my 
problem.

Thanks,

Chris

snip/




Re: How to work with Commons Logging in FOP

2004-04-02 Thread Chris Bowditch
Glen Mazza wrote:

Chris Bowditch wrote:
snip/

-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog 
We would need to add this to FOP.sh or FOP.bat in CVS

It might be more efficient to store this information in the Ant build 
file instead--I believe the .sh/.bat files just reference that file anyway.
Thanks Glen,

of course you are correct.

Chris




Re: Applying patches

2004-04-02 Thread Chris Bowditch
Glen Mazza wrote:

I use this tool (I couldn't find a patch program in WinCVS):
http://marc.theaimsgroup.com/?l=fop-devm=105874140111833w=2
Two other notes to read:
http://marc.theaimsgroup.com/?l=fop-devm=106961785412734w=2
http://marc.theaimsgroup.com/?l=fop-devm=106962776820285w=2
to apply the patch, I use:  patch  somepatch.txt.

Only annoying issue is that, with the version I'm using, I need to 
change the source files from Windows to Unix line endings before 
proceeding.  I use JEdit to do that.
Hi Glen,

thanks for the links they are useful.

Chris




Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow Block.java

2004-04-02 Thread Chris Bowditch
Christian Geisert wrote:

cbowditch (at) apache.org wrote:

cbowditch2004/04/02 05:50:52

  Modified:src/java/org/apache/fop/fo/flow Block.java
  Log:
  Applied Luca Furini's patch from bugzilla entry 28021.
  Corrections to behaviour of whitespace-treatment property
Revision  ChangesPath
  1.14  +404 -391  xml-fop/src/java/org/apache/fop/fo/flow/Block.java


Uh, looks like there went something wrong with the linefeeds.
And keyword substitution is wrong (ko instead of kkv)
Uh Oh! You are right. Ive fixed the file, so now how do I fix this in CVS, 
just re-commit the file??

Chris




Re: [VOTE] Simon Pepping for Committer

2004-04-01 Thread Chris Bowditch
Glen Mazza wrote:

Here's my +1.
Simon has certainly shown a great understanding of the redesigned layout and 
has helped me improve my understanding at times. I think committership is long 
overdue, and if Glen hadnt proposed this Vote, I would have done.

+1

Chris




Re: [VOTE] Switch from Avalon to Commons-Logging

2004-03-24 Thread Chris Bowditch
Glen Mazza wrote:

snip/

Accordingly, I think it's time now for us to do the
same for FOP.  I'd like us to drop the Avalon library
for 1.0, and switch to Jakarta Commons-Logging [4] as
a replacement for Avalon's logging component.  For
1.0, I propose having FOP join Batik, Xalan, Xerces,
AntennaHouse, RenderX, Struts, Axis, and (upcoming)
Cocoon in no longer shipping with Avalon, nor
requiring its users to import that library into their
applications in order to use FOP.  Here's my +1.
Im not going to vote straight away, ill wait for some of the other 
committers to speak up. I do agree with your thought process.

Commons-logging offers the same type of logger options
[5] that Avalon logging does:  The user has a choice
of no logger, stderr logger, Log4J, and JDK 1.4
logging.  They can also create additional logging
types.  Commons-logging is currently being used by
major open-source applications such as Tomcat,
Tapestry, Apache Axis and Jakarta Struts, and *many*
others [6], so we'll be moving into very good company.
Yes I agree.

Another huge advantage I see for FOP in particular is
exceptional integration with Struts applications.  For
Struts developers, the same commons-logging instance
that they presently use for their application coding
can be passed into FOP during PDF generation.  No more
needing to create a separate Avalon logging instance
in their code, or (possibly) needing to have two
different output logging files, one for each logging
instance.  This will look very nice architecturally
for both FOP and Struts.
Yes another very good point.

I'll be more than happy to take care of the conversion
for us--I'll make the change via a patch for us to
review before committing.
Thoughts? Votes?
In the last couple of years there has been a lot of discussion on this 
list about avalon and getting FOP to work with parts of avalon other 
than just logging. As far as I am aware FOP still uses avalon only for 
logging. But a lot of more experienced committers have often spoke in 
the past of using other features of avalon to FOP's great advantage. 
What those features are or advantages are I dont know. Hence, ill wait 
to hear from others before casting a vote. You could always check the 
archives to get an idea.

Chris



Re: Hyphenation

2004-03-17 Thread Chris Bowditch
Luca Furini wrote:

Hi all!

I am an italian student of the University of Bologna.

I have tried to solve a few problems concerning hyphenation, in
particular:
- show the '-' at the end of the hyphenated lines
- use the fo:hyphenate property to enable hyphenation, instead of the
  alignment
- specify the hyphenation character using the fo:hyphenation-character
  property
Thanks for trying. Unfortunately we need a bit more information for your 
suggested change to make it to the code base.

Most importantly, which version of the code are you trying to fix? 
Maintenance or HEAD?

Secondly, could you please follow the procedure for submitting patches, 
described here:

http://xml.apache.org/fop/dev/index.html#patches

Please include sample FO files that demonstrate before and after effects 
of your changes.

Thanks very much,

Chris




Re: temporarily inactive

2004-03-15 Thread Chris Bowditch
Glen Mazza wrote:

Team,

I'll be taking a few weeks off the project, there's some things I want 
to study and get out of the way right now.  I'll be back to coding soon!
Thanks for letting us know Glen. I just want to thank you for all your 
work to date on FOP. It takes FOP another step closer to getting a 
working redesign.

Chris



Re: CMYK- jpg

2004-03-12 Thread Chris Bowditch
Naveen M V wrote:

Hi All,

I need to generate PDF files using XSL-FO transformation and embed
CMYK -jpeg for printing. I am using fop-0.20.5. Can any body help.
When you say printing are you using the Postscript renderer? Everything 
that is currently known about JPEG graphics is on the website, here:

http://xml.apache.org/fop/graphics.html#jpeg

Have you tried it? What result did you get? The website seems to 
indicate it should be okay, but I have a feeling that it may be specific 
to PDF.

Chris




Re: Thanks Jeremias

2004-03-03 Thread Chris Bowditch
Peter B. West wrote:

Thanks again, Jeremias, for all of the licensing housekeeping.  I'm 
sorry I didn't get around to giving you a hand with this.  Does anything 
(apart from the hyphenation mess) remain to be done?

Peter
I would also like to thank Jeremias for sorting out the licensing, not 
the nicest of jobs, so three cheers for Jeremias, hip hip :-)

Chris




Re: Cocoon appears to be switching to 1.4

2004-03-03 Thread Chris Bowditch
Glen Mazza wrote:

They're currently voting on the Cocoon side[1] to set
1.4 as the minimum JDK for their next 2.2 release.  So
far it looks good for approval.
I'm not so sure it does, look at the 3rd mail in the thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107813002510299w=2

and this sparks off a debate about how many users still require 1.3, etc.

This would be good news for us, as it would remove one
of the major risks (incompatibility with Cocoon)
involved with adopting 1.4 on our side.
I know Ive moaned about this in the past, but I'm concerned that 
upgrading FOP to JDK 1.4 will make FOP unavailable to x% of the 
potential users. Now if x% is a significant figure then FOP becomes in 
danger of failing in a manner similar to xmlroff.

I hope Tony Graham and any one else out there whos using xmlroff doesnt 
take offence at me saying this, but Ive been following the xmlroff 
project, and there seems to about 1 mail/month on their user list. I 
believe this is because xmlroff is unavailable to a significant % of the 
potential user base, i.e. it doesnt run on windows. I can tell you now 
if it did run on windows our company would be using it, and possibly 
contributing towards it.

Anyway, my point is simply that if x% is significant then we should hold 
off on this, and I will vote -1. However, if x% is very small then i'll 
vote +0. So before making a decision I propose we do some research to 
find out what x% is?! Which is the conclusion that cocoon-dev appear to 
come to, in the discussion thread above.

Chris




Re: [VOTE] Clay Leeds for Committer

2004-03-01 Thread Chris Bowditch
Glen Mazza wrote:

snip/

The updates and issues he has brought up to us this
week, I'm sure he would be happy to take care of for
us, just as soon as we provide him write access.  I
also hope he develops a psychological concept of
ownership of our website over time, resulting in it
looking increasingly top-notch.
So let me start off the voting: +1.
+1 from me too.

Chris




Newbie Commiter Questions

2004-03-01 Thread Chris Bowditch
I know this subject has come up before, but I still cant quite get 
things working after trawling through the archives.

I'm using WinCVS 1.3 and Putty to connect to the cvs.apache.org. My 
understanding was that using SSH keys was optional but strongly 
encouraged. So I had a go at creating the private/public key pairs, and 
put the public key into .ssh directory on my apache home, and specified 
the private key file to Putty, but when I click open in Putty and 
enter userid/password I get a message saying

Trying public key authentication.
Key is of wrong type (PuTTY SSH2 private key)
Any ideas, what this means? I specified SSH2 (RSA) when I generated my 
keys. I noticed in the archives that some people have authorized_keys 
and others have authorized_keys2 file, which do I need? I tried both, 
but I still got the same message.

Thinking that SSH is not strictly required for write access, I had a go 
at updating my description on the Team page, but WinCVS says:

cvs [server aborted]: commit requires write access to the repository

Any help would be appreciated.

Chris




  1   2   >