Re: Skype-conference on page-breaking?

2005-03-03 Thread Simon Pepping
On Thu, Mar 03, 2005 at 08:34:54PM +0100, Jeremias Maerki wrote:
 I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
 Simon in the Netherlands than to call someone in Lucerne via PSTN. 
 
 Anyway, I'd like to ask if we could hold to a brainstorming conference
 call on page breaking either Sunday evening or next Monday or Tuesday
 somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
 are Simon, Finn and Luca. I'm happy to call either of you on your normal
 phone via SkypeOut if you don't have broadband. I hope I can get at
 least one of you three on the line. Others are invited to listen in and
 contribute, of course. Max. number in the conference is four people with
 Skype.

Sunday evening is OK. Monday and Tuesday after working hours is OK. I
could be available from 16.00 hrs, but I would prefer after 19.00 hrs
CET. There is no way I can do this at the office.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Simon Pepping
On Thu, Mar 03, 2005 at 08:19:24AM -0700, Victor Mote wrote:
 Jeremias Maerki wrote:
 
  While looking for material on page breaking I found several 
  references to this document:
  
  http://wwwlib.umi.com/dissertations/fullcit/8124134
  
  Does anyone know if it's worth ordering and waiting for it? 
  The unfortunate thing is that they don't seem to have a PDF 
  version that I could download immediately for a reasonable fee.
 
 Wow. This looks like it is very valuable. I have ordered it for my own use,
 and I'll be glad to give you a book review when it arrives to help you
 decide whether it is worthwhile for you or not.

I do not know it. It sounds like I should buy it as well.
 
 Note that Stanford is Knuth's school, the date year is the same as that of
 Chapter 3 of Knuth's Digital Typography, and that the author is the
 co-author of that article. It may be possible to infer the same information
 from looking at the TeX source code. Also, another source of similar
 information would be Volume I of Knuth's Computers and Typesetting, aka
 The TeXbook. It is essentially a commentary on TeX, by Knuth. Chapter 15
 is entitled How TeX Makes Lines into Pages.

Note that The TeXbook is TeX's user guide. Yes, Knuth's users are
quite advanced. It was my first book in the direction of computers,
and one of the most inspirational I have read.

The TeX program is described in 'TeX The Program'. That text is weaved
into the program code according to Knuth's literate programming
system. It can be freely extracted from the program code. A TeX
distribution like TeXLive contains the tools to do this. I intend to
do so soon. If you want to do it yourself, TeXLive is available from
the TUG website, www.tug.org. The TeX source code itself is available
from the CTAN repository, but I fear that you have to do some work to
set up all the tools. It is up to yourself to decide whether knowing
TeX's implementation is useful. It is a best-fit algorithm. There is
no look-ahead. For example, TeX is not able to balance two facing
pages (or two columns on a page, which for TeX is the same). I guess
that a dissertation like that cited above contains much more
information than implemented in TeX.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2005-03-02 Thread Simon Pepping
On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
 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.  

Your new validation code invalidates valid fo files. If you would have
run the layoutengine tests, you would have noticed. The test file
table-body1.xml no longer passes. I have committed a correction. I
have also made TableFooter use TableBody's validation code, as
TableHeader does.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Skype-conference on page-breaking?

2005-03-01 Thread Simon Pepping
On Tue, Mar 01, 2005 at 03:09:46PM +0100, Jeremias Maerki wrote:
 To speed things up could we hold a conference (using Skype, for example)
 to discuss further details on page-breaking? I'd volunteer to sum up any
 results during that discussion for the archives. I have Finn on my Skype
 radar already.

I do not have a broadband connection, and therefore no Skype or other
VoIP.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: page-breaking strategies and performance

2005-03-01 Thread Simon Pepping
On Tue, Mar 01, 2005 at 03:02:38PM +0100, Jeremias Maerki wrote:
 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?

That is a good idea.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: page-breaking strategies and performance

2005-03-01 Thread Simon Pepping
On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
 Jeremias Maerki wrote:
 
  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.
  
  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.
 
 This is an excellent idea. It has from time to time gone under the moniker
 LayoutStrategy or pluggable layout. To do it without duplicating everything
 requires that the other pieces of the system be modularized, the concerns
 separated so that they can be reused. The upside is tremendous and the cost
 pays for itself in developer productivity.

The idea of having two page breaking strategies is OK. But it is also
a goal that is yet far over the horizon.

I hope this is smaller than having pluggable layout. We should try to
express the layout constraints in a simple language, which can be used
by the algorithms of both strategies. Knuth's model is an effort to
achieve that, and a PageLayoutManager which receives the Knuth
elements and invokes the appropriate algorithm goes with it.

Such a setup should not only enable multiple page breaking strategies,
but also help us implement a simple strategy to start with, and
gradually evolve it to a higher level of sophistication.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2005-02-25 Thread Simon Pepping
On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza wrote:
 
 Jeremias, I'm going to veto (-1) your change.  I would
 like the content model restored to the XSL standard
 and the FONode.removeNode() method removed.

I support Jeremias' change, and vote +1.
 
 Technical reasons:
 
 2.)  You failed to explain how an empty fo:table-body
 could possibly be of use to stylesheet writers, or how
 it would simplify their work.  I was able to debunk
 what you wrote in my response[2].  All you did say was
 that it is illegal and not useful, basically
 strengthening my argument.

An application should serve its users. It may try to educate them
regarding valid input, but it should not be obnoxious about it. If the
interpretation of the input is unequivocal, the application may warn
the user, but should continue. 

I am not sure that an empty table-body falls in this category. If the
other elements of a table are there, an empty table-body feels like a
genuine error, which may not silently be passed over. Especially for
unattended environments a warning is rather weak, and easily goes
unnoticed. Could this present users with documents in which tables are
missing without the author being aware of it?

On the other hand, if ignoring an empty table-body has been the actual
situation for a long time, this is not the time for Jeremias to change
that. Therefore, I am in favour of leaving Jeremias' change as it is,
and wait for someone else to implement a more proper solution.
 
 3.)  As I explained to you, due to the new
 relationship between FO's and LM's, our architecture
 no longer supports FO's deciding whether or not to be
 attached to a LM.  I gave you the opportunity to
 discuss moving back to the older architecture, but you
 chose to ignore it--instead challenging me to find a
 better way.  That was my question: do we need to move
 back to the old method?

It is the task of the FO module to create a data structure that
represents the fo input, so that the LM module can use it as its input
for the layout. That data structure is the FO tree with the property
values. The FO module should do everything that is needed for this
task: validating input, sending corresponding warning or error
messages to the user, deciding that a piece of input does not require
representation in the data structure and possibly removing
corresponding data that has already been created. Therefore I believe
that FONode.removeChild() is a proper task for the FO module.

You have a tendency to react to other people's coding by saying that
this is not the ideal final solution. If a person is solving one
problem, he cannot solve all related problems at the same time. Such
problems can be tackled at another time, and perhaps by another team
member. So, please, do not say that a solution is not everything, but
take the opportunity and tackle the problem that remains. Or, if you
have no time, watch it sit there and suffer. :)
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Markers added to the wrong page

2005-02-13 Thread Simon Pepping
Jeremias,

I have looked into the problem in more depth. The wrong retrieved
marker is not only due to the bogus area, but also to the flawed logic
of dealing with retrieve-position for the markers in
PageViewport.addMarkers. Even if block 5 adds a bogus area to page 1,
block 5 would not qualify for last-ending-within-page.

A correct implementation of the retrieve-position logic requires that
the traits is-first and is-last are correctly set. These find a place
in BreakPoss, but not all LMs set the traits correctly. A bogus area
would again upset the markers, because it would falsely take the trait
is-first.

If you create markers5c such that block 4 takes two lines (and change
the region before to: retrieve-position=first-including-carryover),
you have another failing test case.

BPs for bogus areas can be recognized by their position:
BP.getPosition().getPosition() == -1. Probably it is a good idea to
suppress BPs for bogus areas altogether: if (over 
childBreaks.size() == 0) return null.

Note that for empty blocks also a BP without areas is returned, with
position = -2. I am not sure whether they make sense. They do not
generate an area due to a special condition in addAreas. If it is
possible to add markers to an empty block, such BPs are necessary,
although the position of the markers around a page break is undefined.

This is a nasty case:

fo:blockfo:block/Several lines of text/fo:block

when the text 'Several...' starts on the new page. There would again
be an empty area on the previous page. It would again be recognized by
!BP.generatesAreas(), but it would again falsely take the trait
is-first.

On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
 Team, 
 
 I've just checked in markers5a and markers5b which look very closely
 which marker is added to which page for every block.
 
 As I'm still somewhat in the process of getting to know the layout
 engine I don't have a quick answer to that although I'm making progress
 in understanding. Here's what I found out so far:
 
 The reason for the bad markers is the addMarkers call, for example in
 BlockLayoutManager.addAreas(). When the LM finds out that the next area
 won't fit on the current page it creates a BreakPoss signalling that
 state. The problem now is that addAreas() also gets these BreakPoss
 instances which aren't visible in the generated document but are still
 generating an (empty) Area (on the page preceeding the one where the
 Area will really come to rest). That causes one marker too many to be
 added to a page.
 
 The same BTW applies to addID() calls which also remembers IDs on the
 wrong pages.
 
 What I'm currently doing is trying to really (!) understand the whole
 BreakPoss mechanism so I can figure out a reliable way to find out how
 to avoid this bug. Two possibilities:
 1. Don't generate bogus areas at all.
 2. Just suppress addMarkers() and addID().
 
 I'm currently wondering if the generated BreakPoss instances should get
 an additional flag (or two) which controls the generation of the area
 and the addMarkers()/addID() calls. addMarkers()/addID() may be
 necessary in certain circumstances while on the other side no area is
 generated (empty block with only markers).
 
 You can easily see these bogus areas when you output to the area tree
 renderer or in build/test-results/layoutengine when running the Ant
 build.
 
 I'll continue investigating but would appreciate any ideas you might
 have.
 
 Jeremias Maerki
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl


testcases

2005-02-12 Thread Simon Pepping
Jeremias,

Note that you can use the ancestor axis:
xpath=//text[. = 'line1']/ancestor::pageViewport/@nr 
instead of 
xpath=//text[. = 'line1']/../../../../../../../../../@nr

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl


Re: Problems with layoutengine test files

2005-02-09 Thread Simon Pepping
Jeremias,

On Mon, Feb 07, 2005 at 10:29:10AM +0100, Jeremias Maerki wrote:
 Simon,
 
 can you tell me which parser and XSLT processor combination gave you
 these problems? I'd like to reproduce the problem so I can be sure I fix
 them correctly. Thanks.

Sun's SDK 1.4.2, crimson and Xalan Java 2.5.2: error
endorsed dirs: Xerces-J 2.4.0, Xalan Java 2.5.2: succes
endorsed dirs, FOP's libraries: Xerces-J 2.2.1,  Xalan Java 2.4.1:
error

Error: There was 1 error:
1) 
text-decoration1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1)java.lang.RuntimeException:
 Expected XPath expression to evaluate to 'line-through', but got 'li' (XPath: 
//flow/block[3]/lineArea/inlineparent[1]/text)

Regards, Simon

 On 06.02.2005 13:54:54 Simon Pepping wrote:
  Hi Jeremias,
  
  I have errors with the layoutengine test files, for example:
  
  text-decoration1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1)java.lang.RuntimeException:
  Expected XPath expression to evaluate to 'line-through', but got 'li'
  (XPath: //flow/block[3]/lineArea/inlineparent[1]/text)
  
  This is due to the fact that the text may be split over more than one
  text area. Indeed, whether I get the error depends on which parser
  version I use; different parsers may produce different arrangements of
  text over text areas.
  
  If you change the test to:
  
  eval expected=line-through 
  xpath=//flow/block[3]/lineArea/inlineparent[1]/
  
  the error disappears. I think XObject.str() applies the XPath string
  function, which returns the string-value of the first node. If you
  evaluate the parent node 'inlineparent', you get the string-value of
  all of its children, which is usually what you want to have.
  
  There are many such cases in the test files. I think you should modify
  all cases where you test on the content of a text area.
 
 
 Jeremias Maerki
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl


Problems with layoutengine test files

2005-02-06 Thread Simon Pepping
Hi Jeremias,

I have errors with the layoutengine test files, for example:

text-decoration1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1)java.lang.RuntimeException:
Expected XPath expression to evaluate to 'line-through', but got 'li'
(XPath: //flow/block[3]/lineArea/inlineparent[1]/text)

This is due to the fact that the text may be split over more than one
text area. Indeed, whether I get the error depends on which parser
version I use; different parsers may produce different arrangements of
text over text areas.

If you change the test to:

eval expected=line-through 
xpath=//flow/block[3]/lineArea/inlineparent[1]/

the error disappears. I think XObject.str() applies the XPath string
function, which returns the string-value of the first node. If you
evaluate the parent node 'inlineparent', you get the string-value of
all of its children, which is usually what you want to have.

There are many such cases in the test files. I think you should modify
all cases where you test on the content of a text area.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl


Re: Markers added to the wrong page

2005-02-06 Thread Simon Pepping
Jeremias,

I do not have much time to look into your problem, so I will just try
to give a quick answer.

In my view the current BP setup is not able to generate good page
break decisions. It only can do a first-fit algorithm. From your
account, BPs are also overloaded to signal the completion of a page
while they do not really end an area. Your hack is a hack indeed, but
from a quick inspection I would say that it properly marks the
overloaded nature of BPs.

I have written down a proposal for a different strategy of page break
decision. I put my description on the wiki,
http://wiki.apache.org/xmlgraphics-fop/PageLayout. I believe it serves
two goals:
1. Enabling smarter page break algorithms.
2. Simplifying the addAreas calls, and esp. its iteration over the
collected BPs.

I have not had time to implement this, and therefore also no time to
detect the flaws in my proposal. I would not mind if someone else
would implement it.

Regards, Simon

On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
 Team, 
 
 I've just checked in markers5a and markers5b which look very closely
 which marker is added to which page for every block.
 
 As I'm still somewhat in the process of getting to know the layout
 engine I don't have a quick answer to that although I'm making progress
 in understanding. Here's what I found out so far:
 
 The reason for the bad markers is the addMarkers call, for example in
 BlockLayoutManager.addAreas(). When the LM finds out that the next area
 won't fit on the current page it creates a BreakPoss signalling that
 state. The problem now is that addAreas() also gets these BreakPoss
 instances which aren't visible in the generated document but are still
 generating an (empty) Area (on the page preceeding the one where the
 Area will really come to rest). That causes one marker too many to be
 added to a page.
 
 The same BTW applies to addID() calls which also remembers IDs on the
 wrong pages.
 
 What I'm currently doing is trying to really (!) understand the whole
 BreakPoss mechanism so I can figure out a reliable way to find out how
 to avoid this bug. Two possibilities:
 1. Don't generate bogus areas at all.
 2. Just suppress addMarkers() and addID().
 
 I'm currently wondering if the generated BreakPoss instances should get
 an additional flag (or two) which controls the generation of the area
 and the addMarkers()/addID() calls. addMarkers()/addID() may be
 necessary in certain circumstances while on the other side no area is
 generated (empty block with only markers).
 
 You can easily see these bogus areas when you output to the area tree
 renderer or in build/test-results/layoutengine when running the Ant
 build.
 
 I'll continue investigating but would appreciate any ideas you might
 have.
 
 Jeremias Maerki
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl


Re: commit to fop

2005-01-17 Thread Simon Pepping
Hi Renaud,

On Sun, Jan 16, 2005 at 11:46:10PM +0100, Renaud Richardet wrote:
 
 *** documentation ***
 please could you tell me about the state of the following documentations:
 - xml.apache.org/fop/dev: this documentation refers to 0.20, right?

dev/implement.html is a short writeup of the then plans for FOP
HEAD. When you see layout managers mentioned, it is about FOP HEAD.

design/index.html is Keiron Liddle and Karen Lease's documentation at
the start of the work on FOP HEAD. Much of it is still relevant.

 - cvs/... /xdocs/DnI: simon, thanks a lot for your xdoc DnI, it really
 helped me diving into the code. some parts of it have changed. i
 started to update it and made a patch for chapter 4.1 , you can find
 it attached to bug 33126. if it's useful for you, i'll continue.

I am glad it helped you. I wrote it previous winter, and have not
documented the changes of last summer. During that time Glen
restructured the top level of FOP. Finn restructured the properties
part.

You are welcome to contribute to the documentation, both making it up
to date again, and filling the gaps. I am about to rebuild my
system. After it is up and running again, I will have a look at your
contributions.

 - fop-wiki (http://wiki.apache.org/xmlgraphics-fop/FOPProjectPages)
 seems pretty up to date. please tell me if  FOPProjectTasks and
 FOPWorkEstimates are up to date.

A few weeks ago I published some updates to the documentation on the
wiki, see
http://wiki.apache.org/xmlgraphics-fop/FOPImplementationNotes.

 - are there some more key-docs?
 
 *** plans ***
 (thinking loud)
 i plan to start with some documentation update. i see there is a brand
 new site at xmlgraphics.apache.org/ to do.
 what about rtf-rendering? is peter herweg still active on it?
 i'm open, so please give me some hints on where i could start

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop build.xml

2005-01-13 Thread Simon Pepping
On Wed, Jan 12, 2005 at 09:02:37PM +0100, Jeremias Maerki wrote:
 Uhm, the classpath was quite ok like it was. If you look into the
 fop-transcoder-allinone.jar, it contains all classes (or at least should
 contain all classes) that are needed to run the transcoder tests. That
 JAR is for people who don't like all the little dependency JARs.
 
 Why did you do the change in the first place? What was the problem?

Where else do I find the SAX2 driver class
org.apache.xerces.parsers.SAXParser?

 [echo] Running basic functionality tests for fop-transcoder-allinone.jar
[junit] Testsuite: org.apache.fop.BasicTranscoderTestSuite
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.204 sec

[junit] - Standard Error -
[junit] java.io.IOException: SAX2 driver class 
org.apache.xerces.parsers.SAXParser not found
[junit] at 
org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
[junit] at 
org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
[junit] at 
org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown Source)
[junit] at 
org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(Unknown Source)
[junit] at 
org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source)
[junit] at 
org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source)
[junit] at 
org.apache.fop.AbstractBasicTranscoderTestCase.testGenericPDFTranscoder(AbstractBasicTranscoderTestCase.java:70)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:324)
[junit] at junit.framework.TestCase.runTest(TestCase.java:154)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:118)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:326)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:560)
[junit] -  ---
[junit] Testcase: 
testGenericPDFTranscoder(org.apache.fop.BasicPDFTranscoderTestCase):  
Caused an ERROR
[junit] null
[junit] Enclosed Exception:
[junit] SAX2 driver class org.apache.xerces.parsers.SAXParser not found
[junit] org.apache.batik.transcoder.TranscoderException: null
[junit] Enclosed Exception:
[junit] SAX2 driver class org.apache.xerces.parsers.SAXParser not found
[junit] at 
org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source)
[junit] at 
org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source)
[junit] at 
org.apache.fop.AbstractBasicTranscoderTestCase.testGenericPDFTranscoder(AbstractBasicTranscoderTestCase.java:70)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Simon

 On 12.01.2005 20:50:37 spepping wrote:
  spepping2005/01/12 11:50:36
  
Modified:.build.xml
Log:
Fixed an error in the classpath of one of the junit tests

Revision  ChangesPath
1.113 +1 -0  xml-fop/build.xml

Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.112
retrieving revision 1.113
diff -u -r1.112 -r1.113
--- build.xml 6 Jan 2005 19:20:37 -   1.112
+++ build.xml 12 Jan 2005 19:50:36 -  1.113
@@ -696,6 +696,7 @@
   formatter type=brief usefile=false/
   classpath
 pathelement location=${build.dir}/test-classes/
+path refid=libs-basic-run-classpath/
 fileset dir=build
   include name=fop-transcoder-allinone.jar/
 /fileset

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-11 Thread Simon Pepping
On Tue, Jan 11, 2005 at 09:25:50AM +0100, Jeremias Maerki wrote:
 
 On 10.01.2005 22:00:01 Simon Pepping wrote:
  There does not seem to be a need to add
  the inherited value later; the property maker already has done so. See
  IndentPropertyMaker.compute(PropertyList). It uses
  propertyList.getInherited(baseMaker.propId).getNumeric()) to get the
  inherited value. Earlier FOP developers understood this part well.
 
 I understand, but I think you're talking exclusively about the property
 resolution phase (right?) while I found that I need the computed value
 of the margin property (not only the explicit one as is currently the
 case) and the inherited start-indent for the layout manager code and to
 set traits correctly.

PropertyList().get(Constants.PR_START_INDENT) gets the computed value,
that is, the value after property refinement. It is not the raw value
stated in the FO file; FOP does not store that at all. FOP tries to do
property refinement immediately. If that is not possible because the
computed value depends on a trait of an area, FOP stores an
expression, which can be computed at layout time.

I see no mention in section 5 of the spec that the trait value for
start-indent is different from the computed property value.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java

2005-01-11 Thread Simon Pepping
On Tue, Jan 11, 2005 at 12:07:53AM -, [EMAIL PROTECTED] wrote:
 gmazza  2005/01/10 16:07:53
 
   Modified:src/java/org/apache/fop/fo Constants.java
 FOPropertyMapping.java PropertySets.java
src/java/org/apache/fop/fo/flow MultiCase.java
src/java/org/apache/fop/fo/pagination/bookmarks
 Bookmark.java BookmarkTitle.java BookmarkTree.java
   Log:
   2.) Switch from makeEnumProperty to slightly more intuitive 
 getEnumProperty in FOPropertyMapping.

It does really make a property value, which is held as in the member
enums in the property maker:

private Property makeEnumProperty(int enumValue, String text) {
if (enums == null) {
enums = new Property[ENUM_COUNT+1];
}
if (enums[enumValue] == null) {
== enums[enumValue] = new EnumProperty(enumValue, text); ===
}
return enums[enumValue];
}

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-10 Thread Simon Pepping
/
 
 
 
 Jeremias Maerki
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [RT] FOP RTF edition

2005-01-06 Thread Simon Pepping
On Wed, Jan 05, 2005 at 03:09:09PM -0800, Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  I'd like to test the waters and see what you guys
  think about separately
  releasing the RTF part, or in other words: FOP RTF
  edition. 
 
 My $0.02:  Looks like busywork--I don't see how this
 would help you or any other committer.
 
 I would be concerned about burdening current
 committers with this work, as well as scaring away
 prospective ones.  The deep thinkers that are needed
 to get layout et al done are generally not attracted
 to the mundane tasks that a FOP RTF would require.

I believe that releasing is a good thing as soon as we have a usable
product. But it is true that I am not very attracted to such a task at
the moment. Whether instead I am thinking deeply is quite another
matter :)

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java

2005-01-05 Thread Simon Pepping
On Mon, Jan 03, 2005 at 02:20:25PM +0100, Jeremias Maerki wrote:
 I'm trying to understand what's going on here. One thing that strikes me
 as odd is that PropertyList.convertAttributeToProperty() always
 contructs Properties based on the parentFO. Normally, this is probably
 ok since most calculation bases are the parent FOs but in the case of
 content-width/height it's the context FO itself that provides the base
 (the intrinsic image size).

PropertyList.convertAttributeToProperty() calls prop =
propertyMaker.make(this, attributeValue, parentFO). If I remember
correctly, the parentFO is only used if the attribute value is
'inherit'. Otherwise it converts the attribute value into a property
value object. See my description in
http://www.leverkruid.nl/FOP/html/ch09s02.html.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: fo.InlineLevel -- make abstract?

2005-01-05 Thread Simon Pepping
I agree as well.

Regards, Simon

On Tue, Jan 04, 2005 at 09:39:14AM +0100, Jeremias Maerki wrote:
 I think, you are right. They should be abstract.
 
 On 04.01.2005 00:47:29 Glen Mazza wrote:
  Any problem with making fo.InlineLevel an abstract
  class?  Any reason why you made it instantiable--or
  was this just an oversight?  (Actually, anyone know
  why we're not making FObj and FObjMixed abstract as
  well?  I might be missing something here...)
 
 
 
 Jeremias Maerki
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Tweaking the FO class hierarchy

2004-12-29 Thread Simon Pepping
Jeremias,

On Tue, Dec 28, 2004 at 10:32:01PM +0100, Jeremias Maerki wrote:
 I'm currently playing around with external-graphic and
 instream-foreign-object as you may have seen. It's my attempt to dive
 into the whole layout engine thing.
 
 I realize that there are a lot of similarities (and redundancy) between
 the two classes (and even their LM counterparts). I wonder if I should
 create a common (abstract) base class for the two. Is there anything
 that speaks against that other than it may be appropriate to check for
 additional refactoring possibilities? I'm not planning on reworking the
 whole thing, just to improve what I stumble upon.

I know nothing that speaks against that.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Simon Pepping
Glen,

In my view the FO system knows nothing about the LM system. That is
how the LM system can be pluggable. The FO system sets itself up and
waits if any subsequent system finds it useful. Its only connection
with the subsequent system is that it sends FO events to its
FOEventHandler.

The LM system, OTOH, knows about the FO system, because that is its
input. _This_ LM system chooses not to create a LM when it finds that
the FOText node is empty. Another LM system may do otherwise.

It is true that the use of endIndex and startIndex is too
detailed. Those details may be hidden behind a method hasText(),
similar to FObj.getChildren() returning null or not, which is used by
other LMMakers.

Regards, Simon

On Mon, Dec 27, 2004 at 07:36:31AM -0800, Glen Mazza wrote:
 This doesn't seem appropriate--the business logic to
 determine whether or not a layout manager is needed
 for a particular FO should be within that FO object,
 where it reads its own private variables--in whatever
 manner it is internally constucted--and makes its own
 determination.
 
 Otherwise (1) you're forcing the logic below to be
 repeated in everyone else's subclasses of the Maker
 method, also (2) it forces the internal state of each
 FO (endIndex, startIndex) to be public, furthermore,
 you're forever constraining all implementations of
 FOText objects to have these method variables. 
 Someone could completely wish to redo FOText, and not
 have a startIndex and endIndex indicators.  With this
 design, this is no longer possible.
 
 Why not retain the addLayoutManager() method within
 each FO, but just have it call this mapping function
 to determine which LayoutManager object to create? 
 Why did you consider it better to strip out the
 addLayoutMangers() from the FO's?
 
 Glen
 
 --- [EMAIL PROTECTED] wrote:
 
 +public static class FOTextLayoutManagerMaker
 extends Maker {
   +public void make(FONode node, List lms) {
   +FOText foText = (FOText) node;
   +if (foText.endIndex - foText.startIndex
  0) {
   +lms.add(new
 TextLayoutManager(foText));
   +}
   +}
   +}
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Simon Pepping
Glen,

On Mon, Dec 27, 2004 at 06:55:01AM -0800, Glen Mazza wrote:
 Simon,
 
 Why aren't these fatal errors--what's the gain in
 having FOP continue running in an invalid state?
 
 One-in-a-million bugs like these that occur for
 inexplicable reasons should raise an
 IllegalStateException and halt.  FOP should not
 continue running after catastrophic failures.

Mostly, because that is not the problem I am solving at the moment. I
reimplemented the LM creation system. In so doing the fact that a
single LM is not guaranteed was exposed more clearly. I have contained
its effect by catching the exception, and have not explored the stack
of methods that may need to declare the throwing of an exception. That
is a problem in its own right, to be solved at another moment.

Regards, Simon
 
 Glen
 
 --- [EMAIL PROTECTED] wrote:
 
+} catch (FOPException e) {
+log.error
+(Failed to create a
  StaticContentLayoutManager for flow 
+ + flow.getFlowName()
+ + ; no static content will be
  laid out:);
+log.error(e.getMessage());
+return;
+}
 lm.initialize();
 lm.setRegionReference(reg.getRegion());
 
 ..
 
 if (pageSequence.getMainFlow() != null) {
-PageSequenceLayoutManager pageSLM =
-(PageSequenceLayoutManager)
+PageSequenceLayoutManager pageSLM;
+try {
+pageSLM =
  (PageSequenceLayoutManager)

 
 getLayoutManagerMaker().makeLayoutManager(pageSequence);
+} catch (FOPException e) {
+log.error(Failed to create a
  PageSequenceLayoutManager; no pages will be laid
  out:);
+log.error(e.getMessage());
+return;
+}
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2004-12-26 Thread Simon Pepping
On Sat, Dec 25, 2004 at 01:08:11AM -, [EMAIL PROTECTED] wrote:
 gmazza  2004/12/24 17:08:11
 
   Modified:src/java/org/apache/fop/layoutmgr LayoutManagerMapping.java
src/java/org/apache/fop/render/pdf PDFRenderer.java
   Log:
   More XSL 1.1-like terms for PDF bookmarks used, minor bug in 
 TableLayoutManagerMaker fixed.

Sorry for the regression, and thanks for spotting and fixing it. I
have also taken measures to avoid the tabs.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: remove Runnable from PageSequenceLayoutManager?

2004-12-15 Thread Simon Pepping
On Tue, Dec 14, 2004 at 04:39:20PM -0800, Glen Mazza wrote:
 Team,
 
 PageSequenceLayoutManager implements Runnable,
 theoretically to allow for the layout of each page
 sequence on separate threads.  The more complex
 logical aspects needed for this to happen (e.g., idref
 resolution, page numbering) though are not
 implemented, rendering this feature not very useful. 
 We're not using Runnable now, and so I'd like to yank
 it before the upcoming release--it is easy to place it
 back in later if we do this in the future releases
 (although the more extensive logic will still need to
 be developed).  Thoughts?  Objections?

It is true that nothing has been done to make threading a reality. I
do not object to your removing the Runnable interface.

Are you a fan of Extreme Programming? They seem to teach you to avoid
adding future features.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Large files.

2004-12-15 Thread Simon Pepping
On Mon, Dec 13, 2004 at 02:26:40PM -0700, Victor Mote wrote:
 Simon Pepping wrote:
 
  The code you presented seems to be an algorithm implementing 
  an iterator over a tree. Because it maintains its state, it 
  can be stopped and resumed at will, provided you keep a 
  reference to it.
 
  If LMIter would have a reference to its parent LMIter, and 
  could return to it after having processed all the siblings, 
  it would realize such a construct. One could stop the 
  iteration, retain a reference to the active LMIter, and resume later.
  
  Not being dependent on the Java stack would make the 
  programming much more robust. One would have more freedom to 
  insert actions, without the fear to lose the iteration state 
  if one would not carefully return to the same function.
  
  Such a construct would be equally suitable to pull parsing. 
  The LMIter call to the LM method preLoadNext would request 
  more child fo nodes, which the parser would provide on this demand.
  
  Do you want to traverse the FO tree, without relying on the 
  Java stack, and drive the layout process from there by firing 
  node events?
 
 Hi Simon:
 
 You responded to my last posting in this thread, but your questions seem to
 be directed to Finn, so I will let him answer them. Please let me know if I
 have misunderstood.

Victor,

You are right. I replied to the last message in the thread, but it
contains questions to Finn. Sorry for being unclear.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Large files.

2004-12-13 Thread Simon Pepping
The code you presented seems to be an algorithm implementing an
iterator over a tree. Because it maintains its state, it can be
stopped and resumed at will, provided you keep a reference to it.

If LMIter would have a reference to its parent LMIter, and could
return to it after having processed all the siblings, it would realize
such a construct. One could stop the iteration, retain a reference to
the active LMIter, and resume later.

Not being dependent on the Java stack would make the programming
much more robust. One would have more freedom to insert actions,
without the fear to lose the iteration state if one would not
carefully return to the same function.

Such a construct would be equally suitable to pull parsing. The LMIter
call to the LM method preLoadNext would request more child fo nodes,
which the parser would provide on this demand.

On Mon, Dec 13, 2004 at 08:29:43AM -0700, Victor Mote wrote:
 Finn Bock wrote:
 
  Did you notice that if a FOTree (or a fragment of it) is 
  serialized to a preorder sequential representation with end 
  markers, the preorder, postorder and child events can be 
  fired directly from the input stream?
  
  IOW the event based layout can work both of a normal 
  parent/children linked tree and a sequential tree.
 
 Hmmm. I must have totally misunderstood your original point, which I think
 you expressed much better in your second paragraph above. I certainly didn't
 mean to argue against event-based layout, which, in general, I support, but
 rather against the idea that an FOTree node can necessarily be laid out when
 it is first encountered. And I think I understand now why you have done the
 massive propagation of properties -- am I correct in understanding that you
 are essentially flattening the tree so that inheritance must be captured
 before that flattening takes place? Or are you simply making that an option
 now?

Do you want to traverse the FO tree, without relying on the Java
stack, and drive the layout process from there by firing node events?
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Retrieve-marker and removal of leading and trailing spaces

2004-12-08 Thread Simon Pepping
Hi,

I also noted a problem with the removal of leading and trailing spaces
in connection with retrieve-marker:

fo:static-content flow-name=xsl-region-after
  fo:block text-align=start
fo:inline color=redfo:retrieve-marker retrieve-class-name=class 
retrieve-boundary=page 
retrieve-position=first-starting-within-page//fo:inline and
blue: fo:inline color=bluefo:retrieve-marker 
retrieve-class-name=class retrieve-boundary=page 
retrieve-position=first-starting-within-page//fo:inline
  /fo:block
/fo:static-content

The spaces before `and' and after `blue:' are removed. This is probably
due to the fact that the space removal mechanism does not recognize
that fo:retrieve-marker elements may generate text.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Another problem with Marker.rebind()

2004-12-08 Thread Simon Pepping
I noticed another problem with Marker.rebind(): When the same marker
is retrieved more than once, the first rebind is overwritten with the
second. See this example:

fo:static-content flow-name=xsl-region-after
  fo:block text-align=start
fo:inline color=redred: fo:retrieve-marker 
retrieve-class-name=class retrieve-boundary=page 
retrieve-position=first-starting-within-page//fo:inline,
fo:inline color=blueblue: fo:retrieve-marker 
retrieve-class-name=class retrieve-boundary=page 
retrieve-position=first-starting-within-page/./fo:inline
  /fo:block
/fo:static-content

Both markers are printed in blue. Perhaps it would be a solution to
clone the subtree below the marker to retrieve-marker, and rebind that
copy. That would be another example of layout dependent data in the FO
tree. If every retrieve-marker would always discard its existing
subtree and copy the subtree under the retrieved marker in
LM.preloadnext(), this would prevent later runs with the same FO tree
from reusing markers that would pertain to the layout of an earlier
run.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Marker.rebind()

2004-12-07 Thread Simon Pepping
Hi,

I have just committed a patch which fixes bug 32253. One problem
remains: the text in the marker does not always have the right
properties, e.g. the right size. This is probably due to the fact that
Marker.rebind() does not rebind the whole subtree below a marker.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: More questions on line breaking.

2004-12-03 Thread Simon Pepping
On Thu, Dec 02, 2004 at 08:42:30PM +0100, Finn Bock wrote:
 Hi
 
 Some more questions.
 
 1) What is inactiveList doing. Nodes are added but never used.

It contains all feasible breakpoints except those that are still
active, i.e., are still in scope as the start of a line ending at the
currently considered breakpoint. At the end of the loop the active
list only contains nodes pertaining to the end of the paragraph. From
the best one of them the breakpoints of the paragraph are calculated
by tracing back to the beginning through the inactive list.

See the code in LineLM after the comment
// use the chosen node to determine the optimum breakpoints

in the line
bestActiveNode = bestActiveNode.previous;
the previous node is held in the inactive list.

The article with the algorithm was originally published in: Donald
E. Knuth and Michael F. Plass, Breaking Paragraphs into Lines,
Software---Practice and Experience 11 (1981) 1119-1184. It should be
possible to find this journal in academic libraries.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-12-03 Thread Simon Pepping
Hi,

The NIST test suite has no example of an fo:block within an fo:inline
element. Neither does the XSL spec have an example. Apparently the
construction is not very popular.

I have read through the XSL spec, sections 4.4. Block Areas, 4.5. Line
Areas, 4.6. Inline Areas, and especially 4.7.2. Line building and
4.7.3. Inline building. See esp. items 1, 3, and 5 of the rules for
the partitioning. I believe the following areas should be created:

A block inside another block

fo:blockNormal text 
  fo:blockinner block/fo:block 
normal text./fo:block

creates:

Block area -+-- Line area +-- Character areas
|
+-- Block area  +-- possibly Line area etc.
|
+-- Line area +-- Character areas

A block inside an inline inside a block

fo:blockNormal text 
  fo:inline background-color=lightgreeninline text 1
fo:blockinner block/fo:block 
inline text 2/fo:inline 
normal text./fo:block

creates:

Block area -+-- Line area +-- Character areas
| +-- Inline area -- Character areas
|
+-- Line area +-- Inline area -- Block area +-- Line area etc.
|
+-- Line area +-- Inline area -- Character areas
  +-- Character areas

The fo:inline creates three inline areas, one with the text 'inline
text 1', one with the block area, and one with the text 'inline text
2'. The outer block arranges the inline areas from its PCDATA and
those returned by its fo:inline child into lines.

Note also that the inner block area behaves as a child of the inline
area with respect to such traits as the border and the background
traits.

As a conclusion I believe InlineLM must be modified to handle the BPs
returned by a block-area generating child. Perhaps it should wrap them
in a Knuth Box of the appropriate width, or in a new class of Knuth
Element, which LineLM would know that it should be placed on a line of
its own.

Regards, Simon

--
Simon Pepping
home page: http://www.leverkruid.nl



Re: Knuth linebreaking questions

2004-12-02 Thread Simon Pepping
On Thu, Dec 02, 2004 at 12:16:55PM +0100, Finn Bock wrote:
 and point #4 uses the user-definable threshold; where should this constant
 be stored? Inside the code of LineLM or in a configuration file?
 
 An extension attribute?
 
fo:block fox:knuth-threshold=5 ... /fo:block
 
 I suspect that the other knuth parameters should be specified the same 
 way. But it is not a high priority IMO.

It is not a layout specification in the fo file, it is a fine-tuning
of the algorithm applied by a particular FO Processor. It should be in
the user configuration. It may be specified in the configuration file,
or it may be specified by the calling application in the configuration
object FOUserAgent.userConfig. In the configuration file it should be
something like:

line-layout
  hyphenation-threshold5/hyphenation-threshold
  other parameters
/line-layout

FOUserAgent should get appropriate methods to extract the layout
part of the configuration and pass it on to a client class,
e.g. LineLM. Cf. FOUserAgent.getUserRendererConfig().

TeX's terms are pretolerance and tolerance for the two values of
maxAdjustment.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Knuth linebreaking questions

2004-12-01 Thread Simon Pepping
On Tue, Nov 30, 2004 at 07:27:29PM +0100, Luca Furini wrote:
 Finn Bock wrote:
 
  3) What is the reasoning for doing hyphenation only after threshold=1
  fails. Naive common sense tells me that if the user specify hyphenation
  we should do hyphenation before finding line breaks.
 
 Finding hyphenation points is time-expansive (all words must be
 hyphenated, not only the ones near a line's end), the sequence of
 elements becomes longer, there are more feasible breaking points, and a
 line ending with a - is less beautiful; so I thought that if a set of
 breaking points could be find without hyphenation.
 
 I just took the hyphenate property as a suggestion instead of an order! :-)

This is the practice in TeX too. It may be considered as a
satisfactory implementation of hyphenate=true: Take hyphenation into
account, when your line layout algorithm considers it a better
solution to hyphenate these lines. This algorithm does not think it
necessary to try hyphenation when there is a non-hyphenated solution
with an amount of demerits below a certain threshold.

Note that in TeX such thresholds are user-adjustable parameters. I
think they should eventually be so in FOP too, for those of us who
have the most exquisite taste of line layout.
 
 Note that the same algorithm with the same threshold could find a
 different set of breaking points with and without hyphenation, because the
 elements are different. Without hyphenation, spaces could need a little
 higher adjustment, for example.
 
  4) I've compared your code to tex_wrap
  http://oedipus.sourceforge.net/texlib/
  and the main difference is in the way new KnuthNodes are added to the
  active list. Is the BestRecords part of Knuth or is it your own
  invention? Why is it only fitness_class'es in BestRecord that is higher
  then minDemerits + incompatibleFitnessDemerit that is added to
  activeList? Why not all fitness_class'es in BestRecords?
 
 At the moment I don't have the book at hand, but I am quite sure it's
 *not* an invention of mine! :-)
 
 As far as I can remember, the Knuth book uses 4 different variables, named
 C1, ... C4 :-( (or maybe D or A, anyway not a very self-documenting name!)
 and I just created this structure to store them.
 
The algorithm distinguishes four classes of lines: tight, normal,
loose, very loose. When two consecutive lines are not of the same or
of two adjacent classes, it gives a penalty of
incompatibleFitnessDemerit. If the line of class i leading to
breakpoint b does not have an amount of demerits best.getDemerits(i)
which is less than the minimum demerits of all four classes (there is
one best line of each class leading to breakpoint b),
best.getMinDemerits(), plus incompatibleFitnessDemerit, it can never
be selected. The optimization omits it from the list of best
breakpoints. Knuth mentions that it saves him 25% of executions of his
loop, in his computational experiments.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2004-12-01 Thread Simon Pepping
On Wed, Dec 01, 2004 at 11:48:27AM +0100, 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.
 
 I'm sure you will agree that this is well deserved, given all the 
 energy that Jeremias has been pouring tirelessly in FOP, Batik, the XML 
 federation and probably many things here that I don't know about.

Congratulations, Jeremias, and thank you for your efforts.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Simon Pepping
On Fri, Nov 19, 2004 at 08:14:35PM +0100, Andreas L. Delmelle wrote:
  -Original Message-
 Hi,
 
 My very first thought was a) too, but then again, I'm still wondering what
 the intention is of allowing this sort of block-inline-block nesting in the
 first place.
 I'm unsure what the difference *should* be between the above and the case
 where the inner block is *not* nested inside an fo:inline...

Not much I think. An inline in a block is usually used to specify
different properties for its content.

 Since it is allowed by the spec: what is the intended effect of having a
 block/list-block/table nested inside an inline?
 
 Maybe something like this makes it clearer:
 fo:block font-size=40pt
   A
   fo:inline font-size=6pt
 fo:block
 !-- add a long text here --
 /fo:block
   /fo:inline
   B
 /fo:block
 
 which is then supposed to be rendered as two very large letters 'A' and 'B'
 with, for example, a story in very small letters in between. (Although one
 could argue that a similar effect can be achieved by a three column table
 where the first and third column contain the two large letters, and the
 second column contains the story...)

I do not think that is the correct layout. It should be a large A on a
line, followed by any text with which the inline would start (none in
your example). Then the block would have its own full text width block
area. Then there would be more lines with the ending text of the
inline (none in your example) and a large B.

The layout you describe can be achieved using an inline-container, I
believe.
 
 If this was the intention, then the proposed 'handing off the BlockLM to the
 ancestor BlockLM' wouldn't work... :-(

There may well be several ways in which the user can specify a certain
layout.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Simon Pepping
On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote:
 A block inside another block
 
 fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block
 
 creates 3 different paragraphs:
 - Normal text
 - inner block
 - normal text.
 and each paragraph's layout is unrelated to the other paragraphs' layout 
 (there are 3 LineLM).

The 'normal text' is not indented, which makes it a 'continuation paragraph'.
 
 A block inside an inline inside a block
 
 fo:blockNormal text fo:inline background-color=lightgreeninline text 1
 fo:blockinner block/fo:block inline text 2/fo:inline normal
 text./fo:block
 
 creates:
 a) 3 different paragraphs too:
 - Normal text inline text 1
 - inner block
 - inline text 2 normal text.
 or
 b) a single paragraph with all the text:
 - Normal text inline text 1 inner block inline text 2 normal text.
 ???
 
 I'd say a), but I'm not sure.
 If this were true, there should be 3 different LineLMs.

I would say so too. I think that is what the spec prescribes for
fo:block. The fo:block is positioned w.r.t. the current reference
area, not w.r.t. the containing fo:inline. That makes it very similar
to the first example.

I believe the above is in fact a common layout pattern. It describes a
displayed equation in the middle of a paragraph. The second example
adds some layout characteristics, like specifying a different color,
font size, etc.
 
 This is the LM tree at the moment:
 
  BlockLM1
 |
  LineLM1
 |
-+-
|||
 TextLM  InlineLM  TextLM
 Normal text   |  normal text.
 |
-+-
|||
 TextLM   BlockLM2 TextLM
 inline text 1 | inline text 2
  LineLM2
 |
  TextLM
   inner block
 
 LineLM1 tries to have get elements from all its chidren, and fails.
 
 But, even if it could be given the elements representing inner block, it
 could layout them wrongly, because of the block properties: the inner
 block could have different alignment, borders, margins, indents, 
 
 So, the LM tree could be:
 
 BlockLM1
   --+-
   | ||
LineLM   BlockLM2  LineLM
--+--|   -+-
|   ||   | |
 TextLM InlineLM  LineLM InlineLMTextLM
 Normal text  ||   |normal text.
||   |
 TextLM   TextLM  TextLM
inline text 1   inner block   inline text 2
 
 This modified tree can be easily obtained from the previous one:
 - the new BlockLM is created
 - if the LM which should add it to its children list is an InlineLevelLM
 or a LineLM, the new BlockLM is given to its parent, i.e. it will become a
 child of the nearest BlockLM ancestor
 - an instance of the LM which could not handle the new BlockLM (in the
 example, InlineLM son of LineLM) must be created in order to handle inline
 siblings of the inner fo:block.

The third LineLM is not easy to program. Moreover, it has to know the
requirement that it does not start with an indent.

I think the first hierarchy is preferable and can be made to handle
the situation as follows.

The LineLM needs to be able to deal with paragraphs and blocks.

InlineLM's getNextKnuthElements should signal the end of the paragraph
(same as forced linefeed?) if it encounters a block-area generating
child LM. The next call to it should call the child LM's
getNextBreakPoss method, and return the BPs for the lines in the
block. InlineLM's getNextKnuthElements would return KnuthElements and
BPs. How can these return types be mixed?

LineLM's getNextBreakPoss would collect the returned KnuthElements in
paragraphs, and determine the BPs in it. It would store the BPs
received from its children unmodified.

The inner block would create its own areas, with proper alignment,
borders, margins, indents, etc.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-18 Thread Simon Pepping
On Wed, Nov 17, 2004 at 10:03:54PM +0100, Andreas L. Delmelle wrote:
  -Original Message-
  From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
 
 snip /
  That would definitely solve the second case, but still leaves the first.
 
 
 Hmm.. On second thought, that would ultimately depend on:
 - the parent of fo:retrieve-marker
 - the child of fo:marker
 
 if
 
 fo:inline
   fo:retrieve-marker .../
 /fo:inline
 
 is combined with
 
 fo:marker
   fo:block.../fo:block
 /fo:marker

That is a good catch.
 
 It boils down to the first case, so that seems to be the most important one
 to solve.

Indeed. Something like ICLM is needed, which creates an inline area
containing the block areas. 

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-17 Thread Simon Pepping
On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote:
 Simon Pepping wrote:
 
  Marker extends FObjMixed, which adds InlineStackingLM. This is a
  problem. In the new model there should be a strict separation between
  LMs implementing InlineLevelLM and those that do not. InlineStackingLM
  does not, and probably should not do.
 
 I still have to really understand InlineStackingLM, I find it very
 enigmatic! It generates inline areas, but it has LineLM as a subclass ...

I think it is only there as a common superclass of InlineLM and
LineLM. No FO object should add this LM in its addLM method. Perhaps
it should get a private constructor. Currently FObjMixed and
BiDiOverride use it.
 
 Maybe it should implement both getNextBreakPoss and getNextKnuthElements:
 looking at the retrieve-marker's parent and / or at the marker's children
 should be enough to decide whether to call the one or the other.
 
 Anyway, I was wondering whether it is really necessary to add a new LM.
 
 If the fo tree is
 
   fo:page-sequence
   ---+---
   | |
   fo:static-content  fo:flow
   | |
  ...   ...
   | |
  ret. marker's parentmarker's parent
   | |
   fo:retrieve-markerfo:marker
  ---+---
  | |
chld1  chld2
 
 at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree):
 
  ...
   |
parentLM
   |
   RetrieveMarkerLM
   |
   InlineStackingLM
---+---
| |
   chldLM1   chldLM2
 
 but, as a marker can only have children which could replace its
 retrieve-marker, wouldn't it be better to have just:
 
  ...
   |
parentLM
---+---
| |
   chldLM1   chldLM2

I have been thinking along the same lines. fo:wrapper does a similar
thing.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-16 Thread Simon Pepping
 --- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:53 ---
 ...but this leads to yet another CCE, this time in 
   RetrieveMarkerLM.getNextKnuthElements() line 82

I figured that the InlineLevelLM methods would only be invoked if
replaceLM is an InlineLevelLM, and otherwise getNextBreakPoss would be
invoked. Apparently I am wrong, and this warrants more study than a
quick solution. I do not have time to investigate this in more depth
during this week. The same for the block-inline-block error.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 32253] - Marker bugs

2004-11-16 Thread Simon Pepping
 --- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:59 ---
 ...due to the retrieved LM being an InlineStackingLM?? Where does that come 
 from? Shouldn't that be a TextLM?
 
Marker extends FObjMixed, which adds InlineStackingLM. This is a
problem. In the new model there should be a strict separation between
LMs implementing InlineLevelLM and those that do not. InlineStackingLM
does not, and probably should not do.

The recently committed patch does raise a few questions. I think they
are good questions, which need to be answered in order to implement a
paragraph layout algorithm like Knuth's. Sorry for the inconvenience
in the mean time.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Absent markers throw a ClassCastException in LineLM

2004-11-15 Thread Simon Pepping
On Sun, Nov 14, 2004 at 10:11:01PM +0100, Andreas L. Delmelle wrote:
 
 
 Hi,
 
 (Reporting this here, since for some reason can't connect to
 nagoya.apache.org... is it just me or does anyone else have this problem
 too?)
 
 While running some tests after updating to include Luca's latest patch
 (bugzilla 31206), I get a ClassCastException in LineLM.getNextBreakPoss()
 line 409:
 
 while((curLM = (InlineLevelLayoutManager) getChildLM()) != null)
 
 This seems to be due to an fo:retrieve-marker that cannot find a
 corresponding fo:marker in the current page, since I get the message
 
 found no marker with name: {marker-class-name}
 
 immediately before the Exception is thrown.

Before committing Luca's patch I noticed the same problem with
BasicLinkLM. There the solution was to make BasicLinkLM extend
InlineLM, so that it implements InlineLevelLM.

All LMs which are a child of LineLM should implement
InlineLevelLM. LineLM collects all child LMs of a block which generate
inline areas, and indeed, generating inline areas should be synonym
with implementing InlineLevelLM. This presumes that there is a strict
separation between block and inline area generating LMs.

For RetrieveMarkerLM that separation is not so clear. I think it has
to implement InlineLevelLM, otherwise it cannot act as a child of
LineLM, at the penalty that you noticed.

Regards, Simon
 
-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: commenting the Knuth code/centering issue

2004-11-11 Thread Simon Pepping
Luca,

On Thu, Nov 11, 2004 at 07:03:33PM +0100, Luca Furini wrote:
 
 I have tried to add some comments to the Knuth[Element, Box, Glue,
 Penalty] classes.
 
 As I am not sure they are clear enough (I'm not even sure they are written
 in a proper English! :-) ) I'd like to hear your opinions before
 committing them.

These comments are fine.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: remove LayoutManager.initialize()?

2004-11-10 Thread Simon Pepping
On Wed, Nov 10, 2004 at 06:37:28AM -0800, Glen Mazza wrote:
 Team,
 
 Does anyone have a problem if I worked towards
 removing the initialize() method from our
 LayoutManager interface?  The relatively few cases in
 our LM subclasses where we are using it each appear to
 show that they can initialize themselves -- the method
 is currently only being used to query traits from an
 already available FObj, so the need for external
 initialization isn't apparent to me.
 
 I'd rather we move towards subclass-specific
 initialize() methods for those LM subclasses that need
 them (currently, appears to be about zero), with
 comments added as to why external initialization is
 preferable for those LM's.  This would help in better
 understanding the layout process.

I think it is a hook for doing those initialization actions which for
some reason cannot be done in the constructor. I have no idea which
actions that could be. If you can move all required actions for a new
LM object into the constructor, I have no objection to the removal of
this method.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/documentation/content/xdocs/dev book.xml

2004-11-09 Thread Simon Pepping
On Mon, Nov 08, 2004 at 01:43:51PM -0800, Clay Leeds wrote:
 I suspect this could be a problem for the Forrest site-generation 
 process[1]:
 
   Specifying menus with book.xml
 
   Historically, menus in Forrest have been generated from a
   book.xml file, one per directory. This mechanism is
   still available, and if a book.xml is found, it will be
   used in preference to the menu generated by the site.xml
   file. The book.xml  files can use site: URIs to ease
   the maintenance burden  that led to obsolescence of
   book.xml files. In general, however, we recommend that
   users avoid book.xml files.
 
 Is it possible for you to rename that file so it doesn't conflict? (I'm 
 hoping it is trivial for you to change that file name. Perhaps 
 fop-=dni-book.xml or something). If not, I'll see if I can come up with 
 some other solution, although my guess is that any workaround will 
 preclude it from having the same look  feel as the rest of the FOP web 
 site.

A shame; I thought book.xml was the right name for this file. Renamed
to DnI.xml.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/documentation/content/xdocs/dev book.xml

2004-11-08 Thread Simon Pepping
Clay,

On Sun, Nov 07, 2004 at 08:48:23PM -0800, Clay Leeds wrote:
 Simon,
 
 Does the book.xml file in your DnI section serve any specific purpose 
 (DnI-related), or is it to follow the common coding/forrest convention? 
 I ask, because the use of book.xml is deprecated in Forrest-0.6 in 
 favor of the site-wide src/documentation/content/xdocs/site.xml file.

book.xml is the top-level file that calls in all the chapters. It
is indispensible, it is _the_ book, so to speak. I compared it with
the book files you have removed. I see that it has a different
purpose. The other book files seem to define menus.

Regards, Simon
 
 On Nov 7, 2004, at 8:26 PM, [EMAIL PROTECTED] wrote:
 clay2004/11/07 20:26:29
 
   Removed: src/documentation/content/xdocs book.xml
src/documentation/content/xdocs/design book.xml
src/documentation/content/xdocs/design/alt.design 
 book.xml

 src/documentation/content/xdocs/design/alt.design/properties
 book.xml
src/documentation/content/xdocs/dev book.xml
   Log:
   removed all book.xml files (except DnI)
 
 Web Maestro Clay
 -- 
 Clay Leeds - [EMAIL PROTECTED]
 Webmaster/Developer - Medata, Inc. - http://www.medata.com/
 PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: commenting the Knuth code/centering issue

2004-11-05 Thread Simon Pepping
On Thu, Nov 04, 2004 at 02:59:52PM -0800, Glen Mazza wrote:
 --- Luca Furini [EMAIL PROTECTED] wrote:
 
 [BTW, I'm considering getting that Digital Typography
 book by Knuth you had mentioned earlier.  Do you
 recommend it?  (I was thinking that given all the time
 I spend on FOP I should start looking a little more at
 the scientific aspects of this work.)]

I have it. The chapter on the line breaking algorithm is very
enlightening.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl




Re: Form Extension

2004-11-01 Thread Simon Pepping
On Mon, Nov 01, 2004 at 08:50:06AM -0800, Clay Leeds wrote:
 Florian,
 
 On Oct 31, 2004, at 7:17 AM, Florian Hecht wrote:
 Hi FOP devs,
 
 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.
 
 At the moment the module for fop consists of a jar archive with the 
 classes and a new batch file to start the processing (I'm not using 
 the fop class as a starter, because I need to create a different 
 renderer). The system works so far and is able to generate all of the 
 form elements named above. Submit and reset buttons work as they're 
 supposed to. I didn't test every layout situation for the form 
 elements, so it might produce unexpected layout in some cases. As I 
 said it's a proof of concept implementation and not a final product.
 
 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.
 
 Before you post on fop-user perhaps you/we should transfer it to a more 
 'permanent' server (since your e-mail will be in the FOP archives in 
 perpetuity). I'm thinking that a good to place for this extension is on 
 the 'Objects For Formatting Objects' Sourceforge project page[2] 
 (assuming that Simon Pepping and/or other FOP committers agree). 
 However, before we do that, we need to ensure it has the proper 
 licensing. Please go to Apache Software Grants page for information on 
 how to transfer[3].

I think it is a good project to be hosted by the OFFO project. The
purpose of the OFFO project is to keep FO-related OS projects
available for users and prospective developers.

In view of the fact that you do not wish to develop it further, it
should work out of the box for fop-0.20.5. Are you willing to answer
questions from users?

It would be good if you have some developer documentation, to give a
prospective maintainer a headstart. 

It would be best if you release it under the Apache2 License. However,
OFFO is able to host projects under any OSI approved Open Source
license. You need to send the grant to me as the project maintainer; I
will deposit it with the OFFO project.

Note that I am not offering to do maintenance or to learn enough about
the project to answer user questions. Currently OFFO does not have CVS
services, but they can be set up if there is an interest.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: rarr; in DnI documentation

2004-10-26 Thread Simon Pepping
Clay,

Sorry for not answering earlier. I have a couple of other things to do
these weeks.

On Thu, Oct 21, 2004 at 02:25:12PM -0700, Clay Leeds wrote:
 I'd also like to resolve the error in Forrest if possible, so the rest 
 of this POST deals with that.
 
 I suspect the problem is related to the fact that properties.xml 
 references a dtd like this:
 
 !--
 !DOCTYPE chapter PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
  docbookx.dtd
 --
 
 A couple of things I note here:
 1. It's commented out

It is commented out so it should not have any influence. It is there
so that I can uncomment and use it during editing.

 2. this is a relative/local link, but the 'docbookx.dtd' is not local
(I also tried 
 'http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd' and
'http://www.oasis-open.org/docbook/xml/4.2/' and as expected neither 
 works.)

Because it is only used during editing I have not bothered to make it
absolute. The file book.xml has an absolute path for the DTD, and that
is the one that matters.

 3. fwiw, iso-num.ent is at
http://www.oasis-open.org/docbook/xml/4.2/ent/iso-num.ent

The dtd that one uses, should have correct relative links to the
entities files. In that way they are loaded without anyone having to
bother about them.

 I'm not very 'up' on DocBook, so this may be how it's 'supposed' to 
 work. Nevertheless, rarr; is the only thing in 'properties.xml' that 
 doesn't validate during the /forrest/ run (unless I replace rarr; with 
 #8594; or #x2192;).

Once the document and the stylesheets have been written, nothing is
very docbook specific. Only correct absolute paths or good catalogs
matter at that stage. Nevertheless, docbook is a very complex DTD that
uses the whole DTD machinery. I am glad it works.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-26 Thread Simon Pepping
Luca,

I will try to look at your patch later this week.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: rarr; in DnI documentation

2004-10-21 Thread Simon Pepping
Clay,

I am a bit surprised. The docbook dtd clearly defines the entity
rarr; in iso-num.ent:
!ENTITY rarr   #x2192; !-- RIGHTWARDS DOUBLE ARROW --
Why does not the forrest build see this? Does it not read the DTD?

I do not like character entities in decimal numbers. I can never
figure out what they refer to. IMO character codes should be given in
hexadecimal notation; all Unicode documentation uses this. Then it
becomes #x2192; as shown above.

Regards, Simon

On Tue, Oct 19, 2004 at 11:57:00AM -0700, Clay Leeds wrote:
 Simon,
 
 One of the characters in your documentation is causing problems in the 
 Forrest build process.
 
 I'd like to swap the rarr; (amp;rarr;) characters with either 'gt;' 
 (amp;gt;) or '--gt;' (--amp;gt;)?
 
 Or... after some looking I found the rarr; numeric entity: #8594; 
 [amp;#8594;].  I found the rarr; in a bunch of places but the numeric 
 entity took a while...
 
 xml-fop/src/documentation/content/xdocs/DnI/properties.xml Lines 
 2243-2248:
 
 listitem
   
 paraliteralpcBase.getDimension/literal;
 dimension: type of integer, int rarr; 0, length rarr; 1; used by
 literalPercentBase/literal and literalNumericProperty/literal;
 literalLengthBase/literal has a dimension of 1/para
 /listitem
 
 Do you have any objections to this change?
 
 listitem
   
 paraliteralpcBase.getDimension/literal;
 dimension: type of integer, int #8594; 0, length #8594; 1; used by
 literalPercentBase/literal and literalNumericProperty/literal;
 literalLengthBase/literal has a dimension of 1/para
 /listitem
 
 Thanks!
 
 Web Maestro Clay
 -- 
 Clay Leeds - [EMAIL PROTECTED]
 Webmaster/Developer - Medata, Inc. - http://www.medata.com/
 PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Meta info [was: Printing from multiple trays with FOP generated output]

2004-10-09 Thread Simon Pepping
On Sat, Oct 09, 2004 at 03:55:08PM +0200, Jeremias Maerki wrote:
 That's a good idea. I don't think RenderX could do anything against us
 adding such a similar feature, unless they have a patent filed on that
 particular feature which will (hopefully!!!) be difficult. Sooner or
 later we will need something like that. Dave White is quite right to ask
 for an extension to control trays. It would be cool to add tray infos
 and similar things to page masters.
 
 In the end it will probably have to result in something similar as EXSLT
 where for widely accepted features a common syntax is defined. BTW, if I
 remember correctly.ah yes: http://exslfo.sourceforge.net/

We might also implement rx:meta-info instead of forcing users to
produce fox:meta-info or rx:meta-info depending on their intended FO
processor.
 
 On 09.10.2004 15:33:35 Glen Mazza wrote:
  Incidentally, RenderX has a nice extension called
  rx:meta-info that holds the PDF document information
  of Author, Producer, Title, etc.  We provide that
  functionality programmatically to the user by
  providing methods in FOUserAgent, but the RenderX
  method seems better because nondevelopers can use it
  as well.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2004-09-27 Thread Simon Pepping
On Fri, Sep 24, 2004 at 05:00:45PM +0200, Jeremias Maerki wrote:
 Chris,
 
 Those who currently work on layout, how do you choose your work area?

My interest in FOP's layout is mostly theoretical. I cannot get
enthousiastic about todo lists, time schedules and time estimates.

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.

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.

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.

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.
 
 One big problem I currently see is testing properly. We don't have a
 good set of tests that we can simply run. The example document are all a
 big mess demonstrating several features at once. Sometimes I don't even
 understand how it should (!) look. Personally, I'd add one important,
 high priority task to the list: (Finally) creating a good test/QS
 environment along with several simple documents each training a single
 feature. Attached to this task should/could be the Java2D renderer which
 we can used to easily create comparable bitmaps. I don't believe in MD5
 checking of PDF at this stage. That may be good as soon as we're in the
 maintenance phase again.

I agree. When I make a change to the layout system that might have
far-ranging bad effects if I miss something, I try to convince myself
with extensive logging. Good tests would be more
satisfactory. Unfortunately, I do not yet know anything about unit
testing, so I cannot write such tests.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: XML Graphics: board concerns

2004-09-21 Thread Simon Pepping
On Mon, Sep 20, 2004 at 09:59:21PM +0200, Jeremias Maerki wrote:
 Batik and FOP devs,
 
 Does anyone of the Batik and FOP committers have an objection against
 inviting Bertrand and Keiron into the XML Graphics PMC?

I have no objection and agree with your proposal: vote +1.
 
Thanks for following this up.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/documentation/content/xdocs/design layout.xml

2004-09-21 Thread Simon Pepping
On Tue, Sep 21, 2004 at 09:28:10AM -, [EMAIL PROTECTED] wrote:
 cbowditch2004/09/21 02:28:10
 
   Modified:src/documentation/content/xdocs/design layout.xml
   Log:
   update todo list
   
   +  tr
tdJustified Text/td
tdHigh/td
tdThis has been completed, thanks largely to Luca Furini. Although 
 there is still issue 28706

I applied a patch and closed bug 28706. I believe this issue has been
superseded by Luca's contributions, as you already expected. I think
you may remove the remark about the issue.

Note that justification has only been implemented for the PDF
renderer. It may be easily implemented by other renderers who can do
the actual justification themselves, given the required dimensions.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo CharIterator.java FOText.java OneCharIterator.java RecursiveCharIterator.java AbstractCharIterator.java

2004-09-19 Thread Simon Pepping
On Sun, Sep 19, 2004 at 06:46:51PM -, [EMAIL PROTECTED] wrote:
 gmazza  2004/09/19 11:46:51
 
   Modified:src/java/org/apache/fop/area AreaTreeModel.java
 StorePagesModel.java
src/java/org/apache/fop/fo CharIterator.java FOText.java
 OneCharIterator.java RecursiveCharIterator.java
   Removed: src/java/org/apache/fop/fo AbstractCharIterator.java
   Log:
   1.)  Removed unused getTitle() within AreaTreeModel; I believe can be obtained
   from fo.pagination.PageSequence object where needed.

PageSequence is an FO node. It can at best provide the title FO
node. getTitle() provides the Title area. Perhaps it is there for the
convenience of renderers?
   
   2.)  Combined AbstractCharIterator and CharIterator interface into single
   abstract CharIterator class.
   
Don't you believe in the separation of Interface and abstract
implementing superclass? If AbstractCharIterator adds nothing to the
interface, it is better to remove this abstract superclass. It does
implement a few methods, though.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



[VOTE] Luca Furini for Committer

2004-09-14 Thread Simon Pepping
Team,

I propose that we make Luca Furini a member of the FOP team.

On 18 March Luca submitted his first patch, which solved a few
problems concerning hyphenation. A few more insightful patches for our
inline layout and hyphenation systems followed. On 20 May Luca
surprised us by a patch which contained a partial implementation of
the line breaking algorithm of Donald E. Knuth and Michael
F. Plass. Later he submitted a more complete implementation in which
he solved the problem of moving the desired requests and data down and
up the stack of inline layout managers. This patch has now been
applied. For his complete list of patches, see [1].

Luca's presence in the FOP team will make a difference to FOP.

Here is my +1 vote.

Regards, Simon

[1] 
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDemail1=lfuriniemailtype1=substringemailreporter1=1emailcc1=1emaillongdesc1=1email2=uniboemailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Fopshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

2004-09-13 Thread Simon Pepping
On Tue, Sep 07, 2004 at 08:47:07PM +0200, Jeremias Maerki wrote:
 
 Question to everyone: We currently don't have a multi-threaded design
 like Peter West's approach. Can anyone think of a reason that all the
 FO-building and layouting process for one processing run may run within
 more than one thread? I don't think threre is one if the SAX event
 delivery is always within one thread (big if). If there isn't I believe
 we could make use of a ThreadLocal to put some shared data that will be
 easily accessible from all involved components. Initialize the
 ThreadLocal in startDocument() and clear it in endDocument(). I realize
 there's a certain risk involved but it could really shorten the access
 ways for shared data especially for the FO tree, if that's really a
 problem (I'd also like to know if it really is. Anyone?).

PageLayoutManager has a seed for multithreading; it implements
Runnable. The idea is to let each page sequence run in its own
thread. It has not been worked out. Using a ThreadLocal for
FOInputHandler would make this more difficult. This is not a typical
usage case for ThreadLocal as mentioned in the java documentation. I
do not find it an attractive idea.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Project offo distributes hyphenation pattern files for FOP

2004-09-13 Thread Simon Pepping
On Mon, Sep 13, 2004 at 08:03:08AM -0700, Clay Leeds wrote:
 Thanks for setting this up, Simon. Please let me know if there is 
 anything I can do to help.

Thanks for the offer. It was some work to set this up, although I
could build mostly on Jeremias' earlier work. I expect that from now
on the project will not give me much work. The only thing that needs
to happen, is a nicer design for the home page and the page
hyphenation.html. Perhaps a challenge for the web master?

It might be a good idea if you or someone else of the FOP team would
also be a project administrator, to make it less dependent on one
person.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Project offo distributes hyphenation pattern files for FOP

2004-09-13 Thread Simon Pepping
On Sun, Sep 12, 2004 at 11:35:42AM +1000, Peter B. West wrote:
 Moved from fop-user.
 
 Simon,
 
 Under which license have you set up the SourceForge project?

I stated that contributions with any OSI-approved license or in the
Public Domain were acceptable. The discussion to get the idea
explained and this license statement accepted was lengthy. I took care
to state each license carefully in the covering page
http://sourceforge.net/offo/hyphenation.html. For a large part thanks
to Jeremias earlier work.

Simon 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: foray integration

2004-09-09 Thread Simon Pepping
Victor,

I share Jeremias' point of view. I see no problem in your informing
Bugzilla users of FORay's fixing certain bugs, although I can see that
it is a somewhat strange situation. Let us see it as a sign that we do
not wish to hurt each other's work, but see each other's project as
parallel efforts to realize a valuable open source formatting objects
processor.

As I said earlier, I wish to spend my time on the layout system in the
trunk, which leaves me no time to port FORay's code back into FOP.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: BreakPoss class

2004-09-09 Thread Simon Pepping
On Thu, Sep 09, 2004 at 02:11:46PM +, Gil Loureiro wrote:
 Hi,
 
 Found following URL http://www.leverkruid.nl/FOP/book.pdf
 I expect that is explained there, sorry.

I wrote that documentation. It describes the new code of FOP, FOP
1.0dev, aka the development version. I see that that is not explained;
the text behaves as if that is the only version of FOP. I will change
that some time.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: remove layout package?

2004-09-05 Thread Simon Pepping
On Sun, Sep 05, 2004 at 05:00:07AM -0700, 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 have no problem with your proposal.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug29124] - New line breaking algorithm

2004-09-03 Thread Simon Pepping
On Fri, Sep 03, 2004 at 10:23:27AM +0200, Luca Furini wrote:
 
 Simon Pepping wrote:
 
  You mention that you have not implemented the Knuth algorithm for
  ContentLM. Would it be difficult to do that?
 
 No, I have almost done.
 I think I will be able to attach a patch including this fix this
 afternoon.

I would rather commit the current patch, and then get a new patch
w.r.t. the committed code.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Handling of text-align=justify when nesting blocks

2004-09-02 Thread Simon Pepping
On Wed, Sep 01, 2004 at 10:10:52PM +0200, [EMAIL PROTECTED] wrote:
 fo:block id=outer text-align=justify
 TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
  TEST ENDS A. 
 fo:block id=inner
 whatever
 /fo:block
 TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
  TEST ENDS B.
 /fo:block
 
 The line 2 ( TEST ENDS A.) is the last line before the block inner 
 starts, but it's not the last line of the block with id outer. The last 
 line of the block outer is: ( TEST ENDS B.).
 
 Get my point, or am I still being unclear?
 
 Can we safely assume the rec. means block area here instead of just 
 block? I think we can't, since then that would mean that the last line 
 on a page (or column) would also be formatted left-aligned instad of 
 justified even if it's not the last line of the block (block as in 
 fo:block).

It sounds like you are right. This would apply to a displayed formula
in a paragraph. Nobody would want a layout in which the last line
before the display is justified, so there seems to be a problem here.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 29124] - New line breaking algorithm

2004-09-01 Thread Simon Pepping
On Wed, Sep 01, 2004 at 10:40:16AM +0100, Chris Bowditch wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2004-08-31 18:44 
 ---
 FOP team,
 
 If I would apply this patch, we would get the following regressions:
 
 - 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?

The current code breaks the paragraphs into lines. It makes short
lines.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: validateChildNode prevents extensions.

2004-08-29 Thread Simon Pepping
On Sun, Aug 29, 2004 at 08:15:38PM +0200, J.Pietschmann wrote:
 Glen Mazza wrote:
 You have a new FO, you're going to need to code for
 them--including ordering and cardinality--in those
 parents that accept them,
 
 This does *not* necessarily mean that *you* should arrange
 that the extension writer has to replace core FO classes.
 In fact do either:
 1. Declare FOP wont support extensions except in
  instream-foreign-object, ever, or
 2. Provide hooks so that extension writers can get their
  extensions running with FOP, with or without extensive
  validation of the extended content model, but at least
  *without* having to rewrite and replace core FO classes.

My thoughts are along the same lines that Jörg has argued. I think we
should do option 2. vCN() should be written such that it allows this.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 29124] - New line breaking algorithm

2004-08-28 Thread Simon Pepping
On Sat, Aug 28, 2004 at 10:06:49AM -, [EMAIL PROTECTED] wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2004-08-28 10:06 ---
 Sorry again, I didn't notice that cvs error.

I think it can be noticed easily in a shell that separates stdout from
stderr. Otherwise it is hard to see in the output stream.
 
 I'm going to attach the right (?) patch :-)
 (for some strange reasons wincvs' diff shows Simon's latest changes too, I 
 hope this is not a problem ...)

For some reason the diff is made against the older revisions:

retrieving revision 1.11
diff -w -u -r1.11 ContentLayoutManager.java
--- layoutmgr/ContentLayoutManager.java 13 Jul 2004 00:16:22 -  1.11
+++ layoutmgr/ContentLayoutManager.java 28 Aug 2004 09:55:24 -

The current revision is 1.12, dated 26 Aug.

I failed to apply this patch. When I apply it to the older version of
the code, I get inconsistent code. When I apply it to the newer
version, I get errors by the patch program. Can you try to generate a
new patch?

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Setting up the output format

2004-08-16 Thread Simon Pepping
I like the way all constants are collected in one class. I do not like
the fact that many classes implement this interface. The jdee debugger
is much hindered by it, because it makes each object very large, with
so many constants. Why is Constants not just imported?

Regards, Simon

On Sun, Aug 15, 2004 at 04:48:48PM -0700, Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  One thing I didn't really like was the fact the Fop
  class implements
  Constants. 
 
 Well, the render constants used to be redundantly
 defined in both CommandLineOptions.java and
 Driver.java.  I centralized them, and defined them in
 one place, fo.Constants, where we keep our other
 system-only constants--for properties, FO's, etc. 
 (fo.Constants was originally created from Finn's work
 with the properties--I just added these constants to
 it.)
 
  From a user's POV this renders the code
  completion (in
  Eclipse, for example) virtually useless as there are
  simply too many
  (unused) items.
  
 
 Yes, the Constants class is somewhat large--it has
 render types, fo and properties constants.  But it's
 not unmanageable, and the issue of Eclipse showing too
 many constants is going to be relevant in most of the
 application.  It is implemented both by the FO's and
 the LM's, and every class needs just a little bit of
 that file--a few FO's or a few properties, etc.
 
 But it has not been a problem to me, I work on the
 code rather heavily.  Neither have Finn, Simon or
 Chris mentioned this--and by virtue of working in
 Layout and FOTree, they would presumably come across
 this problem much more often.  

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Setting up the output format

2004-08-16 Thread Simon Pepping
On Sun, Aug 15, 2004 at 04:48:48PM -0700, Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Today, I've had some quality time with FOP again. 
 
 Good.  I think you finding quality time, however, at
 this date is not completely coincidental--I think the
 dropping of several classes and refactoring of a ton
 of code in that package has made it very simple to
 start looking at and quickly (re-)understanding the
 code base.  (pat self on back/)

Indeed, it is -:) It is also a nice report of what you have been doing
and the direction you have been working in. Are you going to write
this down more in extenso?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 29124] - New line breaking algorithm

2004-08-12 Thread Simon Pepping
On Thu, Aug 12, 2004 at 08:23:14AM -, [EMAIL PROTECTED] wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2004-08-12 08:23 ---
 I'm going to attach an updated patch, including HyphContext (which I forgot to 
 include in the previous versions, sorry) and a few changes to fix a couple of 
 bugs.
 
 I used linux's diff between the modified files and the original ones (updated 
 yesterday, 11 August); for some reasons (maybe I use some wrong options) 
 wincvs's diff did not include new files and did not use the latest version of 
 the original files, so finding lots of difference due to recent cvs commits.

Perhaps you cannot include new files, because as an anonymous CVS user
you cannot add files (cvs add).
 
Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 29124] - New line breaking algorithm

2004-08-12 Thread Simon Pepping
On Thu, Aug 12, 2004 at 12:27:38PM +0200, Luca Furini wrote:
 
 The point is that the XSL recommendation states that the default
 word-spacing value is normal, meaning The normal inter-word space, as
 defined by the current font and/or the UserAgent, not zero.
 At the moment, the SpaceVal variable in the TextInfo object used by the TLM
 has
  .getSpace().min == .getSpace().max == 0
 even if the word-spacing property was not set in the fo document.
 
 So, the right question is: how can the TLM see if the word-spacing property
 value is normal?

TextInfo derives that value from the value of the word-spacing
property.

That must be an error in the property handling by FOP. In
FOPropertyMapping 0pt is used as the default value. Apparently
normal should be the default value. I am not sure how this can be
done for a space property. Something similar happens for length
properties, which can have the default value auto. I think normal
should be a keyword. Apparently, the actual value can only be
calculated at layout time, when the font is known.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [Bug 29124] - New line breaking algorithm

2004-08-10 Thread Simon Pepping
On Tue, Aug 03, 2004 at 12:41:52PM -, [EMAIL PROTECTED] wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:41 ---
 These are the new methods added; at the moment, I added them to the 
 LayoutManager interface, but maybe it could be better to create a new 
 interface implementd only by LM returning inline areas.

I think it is, but that can come later.
 
 - word spacing and letter spacing are now fully implemented, they can both 
 have MinOptMax values; but I am still thinking about how to differentiate a 
 user-defined zero value from a default zero value ...

You cannot. A default value is a user-defined value supplied by the
system to save the user the trouble of always having to enter a
value. It is just a convenience, and you cannot attach a different
meaning to it.
 
 - text-align-last is partially implemented; text-align-last = justify works 
 only if text-align = justify too; this is because Knuth's algorithm doesn't 
 provide for a different alignment for the last line.

TeX uses glue to achieve this, \parfillskip. It is the special amount
of glue appended to the last line. In the TeXbook, p. 99, Knuth
describes it as 'the special trick that allows the final line of a
paragraph to be shorter than the others'. Setting \parfillskip to 0
removes this ability. Usually \parfillskip has infinite
stretchability.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-03 Thread Simon Pepping
On Tue, Aug 03, 2004 at 04:45:58AM -0700, Glen Mazza wrote:
 --- Chris Bowditch [EMAIL PROTECTED] wrote:
  Its the
  getNextBreakPoss/addAreas methods in TextLM and 
  LineLM that are scarey.
  
 
 Yes, that code is very complex (I wasn't able to fix a
 problem with the space-after property despite much
 effort), and I'm not sure there's anything that can be
 done to make it simpler.  Fortunately, some (Simon,
 Luca) appear to be able to work better with it.

The getNextBreakPoss/addAreas methods in TextLM and LineLM are scary
indeed, probably because they try to deal with so many cases. I
believe Luca's patch made the logic much cleaner. Unfortunately, that
method has not yet been extended to the descendant LMs.

And that seems a more important problem, the difficulty of programming
the LM setup with its two passes, getNextBreakPoss and addAreas, over
the LM tree. I believe it must be made simpler to allow a decent Java
programmer to add code to the layout system. It is an aspect I want to
pay attention to, but I will take it slowly and cautiously.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



[Bug 29124] - New line breaking algorithm

2004-08-03 Thread Simon Pepping
On Tue, Aug 03, 2004 at 12:41:52PM -, [EMAIL PROTECTED] wrote:
 --- Additional Comments From [EMAIL PROTECTED]  2004-08-03 12:41 ---
 
 Hi all
 
 At long last, I have finished the patch implementing Knuth's line breaking 
 algorithm; it took me more than I expected, mainly because of a long sequence 
 of hw and sw troubles ... Murphy's laws are not something to laugh at! :-)

That is great. Congratulations with the successful completion of this
work. I will look at it soon, but since I will have holidays, it will
take a bit longer. I am curious to see how you negotiated all the
descendant LMs. 

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-02 Thread Simon Pepping
I would rather remain silent in this acrimonious debate, but I suppose
that would not help.

I am in favour of a modular view of FOP:
- input specification
- layout
- rendering

I am in favour of reusability of the components. It would be good if
the layout engine could be applied to different input specs, and if
the renderers could be applied to the area tree resulting from a
different layout engine. Therefore I am not in favour of removing the
AddLMVisitor code.

But reusable modules require a good interface between them, and I am
not sure FOP has that. The current visitor pattern code in FOP is
rather dead, without a proponent in the FOP team, and without active
usage for it. Therefore I will not defend the code.

The visitor pattern should not be in the way of understanding the
layout code. The layout engine should be understandable in and by
itself, without the need to see how it is connected to the FO
tree. The visitor pattern is almost entirely contained in LMIter. This
class presents a sort of iterator which provides the next child LM,
and encapsulates how this is precisely achieved.

All in all, I am much more concerned about a clean separation of
modules. If they have a clear API between them, pluggability can
follow.

My vote is 0.

Regards, Simon

On Mon, Aug 02, 2004 at 11:31:59AM -0700, 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.
 
 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.
 
 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]  
 
 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.)
 
 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.
 
 Glen
 
 [1]
 http://www.extremeprogramming.org/rules/refactor.html
 
 
 --- Chris Bowditch [EMAIL PROTECTED] wrote:
  
  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
  
  
 
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Committing documentation

2004-07-29 Thread Simon Pepping
On Wed, Jul 28, 2004 at 01:24:22PM -0700, Clay Leeds wrote:
 On Jul 28, 2004, at 11:51 AM, Simon Pepping wrote:
 On Sun, Jul 25, 2004 at 12:51:56PM -0700, Clay Leeds wrote:
 As I understand it, you're primarily doing documentation that is more
 developer and/or embedded oriented, which is one of the reasons why I
 would want to have a new 'Documentation' tab.
 
 Indeed, it is. Does this mandate a specific directory to commit the
 files into? Or shall I create a directory in
 src/documentation/content/xdocs? Or in src/documentation/content/?
 
 Regards, Simon
 
 Good question. Actually, I was 'putting it out there(tm)' as to whether 
 or not other committers thought that was a good idea. Therefore, I'm 
 not sure where it should go *yet*.
 
 As for how it goes in, double-check the FAQ docbook section[1] (IIRC 
 you did the docs in docbook?). If you need more help, let me know.
 
 Web Maestro Clay
 
 [1]
 http://forrest.apache.org/faq.html#docbook

Thanks for the pointer. I have done what it requires, writing the
documentation in Docbook XML 4.2. When the time is there, the
map:match element should be added to the site map, and the docbook
stylesheets should be reachable.

I will commit the work to src/documentation/content/xdocs/DnI. That
stands for 'Design and Implementation', into which I have changed the
title.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Committing documentation

2004-07-28 Thread Simon Pepping
On Sun, Jul 25, 2004 at 12:51:56PM -0700, Clay Leeds wrote:

 As I understand it, you're primarily doing documentation that is more 
 developer and/or embedded oriented, which is one of the reasons why I 
 would want to have a new 'Documentation' tab.

Indeed, it is. Does this mandate a specific directory to commit the
files into? Or shall I create a directory in
src/documentation/content/xdocs? Or in src/documentation/content/?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Building site with forrest

2004-07-28 Thread Simon Pepping
Clay,

Thanks for your reply.

On Sun, Jul 25, 2004 at 12:46:03PM -0700, Clay Leeds wrote:
 Simon,
 
 I have been working at getting the xml-fop web site working for many 
 months (at first using forrest-0.5.1, and more recently with 
 forrest-0.6 since they're about to release a new version). More 
 recently, I've had some success, but I'm currently working with the 
 forrest-dev list to get them resolved--and we've made progress[1]  
 [1a].

I appreciate that that is not an easy problem to solve.
 
 (More comments inline)
 
 On Jul 25, 2004, at 11:41 AM, Simon Pepping wrote:
 I have tried to build the site with forrest, without much success. I
 had a few problems:
 
 1. Validation error. I solved this problem by creating an OASIS 
 catalog.
 
 I solved this by essentially replacing the xml-fop/.../sitemap.xmap 
 file with a 'clean' version from forrest. I then added the  FOP 
 ADDITIONS  section.

When online, validation succeeds because the system ids point to the
CVS. Offline, most validation succeeds due to forrest's catalog, which
points to local copies of the DTDs. This does not work for
compliance.xml, which uses its own DTD. There is an SGML Open Catalog
for it, but apparently that is not used. I added an OASIS XML catalog,
and now the local copy of the DTD in my CVS working directory is used.
 
 2. Files in build/webapps/content are missing. These problems can be 
 solved
by copying src/documentation/content into webapps, or by replacing
in sitemap-0.5.xmap all source references to content/ with
{project:content}, whatever that may mean.
 
 I don't recall why a sitemap-0.5.xmap was created, but I removed it 
 completely.

It is still in our CVS repository. And it is the sitemap which forrest
uses in my local build.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: (Copyright question) Re: Committing documentation

2004-07-26 Thread Simon Pepping
I completely agree with Christian's comment and extract of the CLA. I
have signed it and thereby it applies to any work I commit to FOP's
repository. That is my intention with the documentation.

I wrote 'copyright the Authors', with the idea that every contributor
adds his name as an author. But that is indeed probably not right. I
will change it to ASF. The files themselves already have the Apache
License 2 text.

Regards, Simon

On Mon, Jul 26, 2004 at 04:16:18AM -0700, Glen Mazza wrote:
 I believe the key word below is transferable, i.e.,
 before checking any work in, it still needs to be
 copyright The Apache Software Foundation at the time
 of it being cvs committed.  Dirk-Willem, might you
 know more about this?  (Original comments in [1]
 below.)
 
 But I noticed Simon already updated it to The
 Authors--all it needs to be next (I think) is ASF and
 we're done:
 http://www.leverkruid.nl/FOP/documentation-html/index.html
 
 We already have a dubious copyright notice in one of
 our source files [2, lines 36-37], dubious because the
 file has changed so many times by other people over
 the years that it is unknown whether the copyright
 holder actually still owns any of the code.  I'm
 inclined against adding non-ASF copyrighted work to
 our repository, because once you have it there, it is
 difficult to get rid of, no matter how out-of-date
 that copyright gets.  If anyone is not ready to
 transfer the copyright to their work, then it
 shouldn't be in our repository.
 
 Glen
 
 [1]
 http://marc.theaimsgroup.com/?l=fop-devm=109079517313375w=2
 
 [2]
 http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/render/rtf/ListAttributesConverter.java?annotate=1.7
 
 
 --- Christian Geisert [EMAIL PROTECTED]
 wrote:
  Glen Mazza wrote:
   Simon, a word of caution*, I believe that anything
   that goes into the Apache repository will need to
  be
   copyright The Apache Software Foundation and only
  The
   Apache Software Foundation.  (Just look at the
  bottom
  
  No, the contribution is covered by the CLA (which
  you should have read 
  and signed too ;-)
  
  See http://www.apache.org/licenses/#clas, paragraph
  2:
  
  You hereby grant to the Foundation a
  non-exclusive, irrevocable,
  worldwide, no-charge, transferable copyright
  license to use,
  execute, prepare derivative works of, and
  distribute (internally
  and externally, in object code and, if included
  in your
  Contributions, source code form) your
  Contributions.  Except for the
  rights granted to the Foundation in this
  paragraph, You reserve all
  right, title and interest in and to your
  Contributions.
  
  
  Christian
  
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Building site with forrest

2004-07-25 Thread Simon Pepping
I have tried to build the site with forrest, without much success. I
had a few problems:

1. Validation error. I solved this problem by creating an OASIS catalog.

2. Files in build/webapps/content are missing. These problems can be solved
   by copying src/documentation/content into webapps, or by replacing
   in sitemap-0.5.xmap all source references to content/ with
   {project:content}, whatever that may mean.

3. File src/documentation/content/xdocs/site.xml is missing. I did not
   solve that problem.

Building the target htmldoc causes even more errors.

Are these two indeed broken, or am I doing something wrong?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: fox validation

2004-07-25 Thread Simon Pepping
Thanks. I did not know about the change. It certainly is a better
writing style.

I am still finishing the details of my documentation. After that I
want to work on the layout.

Regards, Simon

On Fri, Jul 23, 2004 at 09:20:50PM -0700, Glen Mazza wrote:
 Yes, the way I see it, one of FOP's successes will be
 our close adherence to JAXP.  Another one will be a
 very strict and solid FO validation component--a firm
 handshake that hopefully will paint FOP as a
 Tomcat-like reference implementation for XSL.
 
 BTW, Simon, and everyone else, there's about 30 or so
 validateChildNodes() left to be written--many of them
 quite complex.  Feel free to help out if you'd like!
 
 Glen
 
 --- J.Pietschmann [EMAIL PROTECTED] wrote:
  Simon Pepping wrote:
   The code in Root shows that fox:bookmarks is the
  only allowed fox
   child of fo:root. It is not clear that that is
  true. The web page
   extensions.html does not even mention
  fox:bookmarks. The example file
   examples/fo/basic/pdfoutline.fo clearly embeds
  fox:outline elements in
   fox:bookmarks. The docbook stylesheets authors
  place fox:outline
   elements directly in fo:root. FOP-0.20.5 has no
  problem with this
   arrangement. Even if it is true, it creates
  compatibility problems.
  
  This was changed in the redesign, outlines for
  bookmarks must now
  be put into a fox:bookmark. Yes, this is
  incompatible but cleans up
  pathological cases like
fo:root
  fox:outline.../fox:outline
  fo:layout-master-set ... /
  fox:outline.../fox:outline
  fo:page-sequence
  /fo:page-sequence
  fox:outline.../fox:outline
  fo:page-sequence
  /fo:page-sequence
/fo:root
  Some bookmarks in the above case wont be rendered,
  and it's quite
  difficult to reliably check for this condition. If
  there can only
  be a single fox:bookmark, error checking is much
  easier. Some would
  also claim it enforces better writing style.
  
  J.Pietschmann
  
  
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Committing documentation

2004-07-25 Thread Simon Pepping
I am preparing my documentation for check-in into the repository. What
would be a suitable place. A directory in
src/documentation/content/xdocs? Would that be in the way of the
forrest build of the web site?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



fox validation

2004-07-23 Thread Simon Pepping
When I render an fo file that is generated with the docbook
stylesheets, I get this validation error:

java.lang.IllegalArgumentException: Error(2/12476): fox:outline is not a valid child 
element of fo:root.
org.apache.fop.apps.FOPException: java.lang.IllegalArgumentException: Error(2/12476): 
fox:outline is not a valid child element of fo:root.
at org.apache.fop.apps.FOFileHandler.render(FOFileHandler.java:103)
at org.apache.fop.apps.Fop.main(Fop.java:55)

The code in Root shows that fox:bookmarks is the only allowed fox
child of fo:root. It is not clear that that is true. The web page
extensions.html does not even mention fox:bookmarks. The example file
examples/fo/basic/pdfoutline.fo clearly embeds fox:outline elements in
fox:bookmarks. The docbook stylesheets authors place fox:outline
elements directly in fo:root. FOP-0.20.5 has no problem with this
arrangement. Even if it is true, it creates compatibility problems.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: SAXParserFactory vs. TransformerFactory (was: Re: cvs commit: ....)

2004-07-20 Thread Simon Pepping
On Mon, Jul 19, 2004 at 03:50:44PM -0700, Glen Mazza wrote:
 I agree; however we are none the worse off for Simon's
 SAXParser example, and we even got a more powerful
 DefaultHandler object in our API as a bonus.
 
 Glen
 
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
  I simply think that the
  Transformer pattern is very
  universal and quite easy to use and understand.

My reason for insisting on the SAXParser example is that it can be
programmed with only knowledge of the javax.xml.parsers package, and
no knowledge of javax.xml.transform. People with no experience in
embedding transformations may find a SAXParser example easier to
apply. That was my own situation until this thread.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java

2004-07-16 Thread Simon Pepping
Glen,

I can see Jeremias' argument for a single pattern to deal with all
situations, but I am pleased to see the SAX solution illustrated by an
example in this simplest case of all.

Perhaps it is a good idea to illustrate the transformer solution in
ExampleFO2PDF, and the outlying SAX parser solution in
ExampleFO2PDF-SAX.

Regards, Simon

On Thu, Jul 15, 2004 at 08:59:21PM -0700, Glen Mazza wrote:
 Thanks, Simon--I didn't think of this way of solving
 the problem--I just modified Jeremias' previous DOM
 example. However, I placed the method below
 temporarily in the example and committed it before
 returning to the Transformer version.  This way, we
 have a working example should we ever need to document
 this style (perhaps on a web page, so users are at
 least aware of it) in the future.
 
 Glen
 

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2004-07-16 Thread Simon Pepping
On Fri, Jul 16, 2004 at 05:10:32AM -, [EMAIL PROTECTED] wrote:
   Log:
   Moved user-defined ElementMapping initialization from Driver to FOUserAgent.
   Moved only string method, the version we use internally--probably sufficient
   for others' work as well.  (Note: an additional unused FOUserAgent object will
   be created in driver during command-line use--cp. its no-param constructor vs.
   setUserAgent() call in apps.Fop; this will need to be ironed out at some time.)
   

Introduce a constructor Driver(FOUserAgent foUserAgent)? It is good to
enable our own CLI and embedding apps to first construct the user
agent with all desired features and then create a driver with it.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Combined the AreaTree and FOTreeHandler (was: Re: cvs commit: etc.)

2004-07-15 Thread Simon Pepping
Glen,

Thanks for your lengthy reply. It makes more sense now. Although I
keep the feeling that this change brings the FO tree building and area
tree building modules closer together than I would prefer.

On Tue, Jul 13, 2004 at 04:20:16PM -0700, Glen Mazza wrote:
  AreaTreeHandler
  throws
  SAXExceptions. This is a parser based exception
  type.
  
 
 Indeed--needs them just as much as MIFHandler and
 RTFHandler do.

This parser based exception penetrates the app rather deeply. It would
be better if here all traces of the particular FO file input method
would have vanished.

 Also, in merging the two I was able to remove a lot of
 code that dealt with communication between the
 two--moving out this administrative code dropped the
 combined size by about a third (IIRC 500265LOC
 before, 465LOC after.) It does help in comprehension.

Communication may be a means of separating parts of an app from each
other. And often it is worth the extra lines of code.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java

2004-07-15 Thread Simon Pepping
On Wed, Jul 14, 2004 at 10:42:29PM -, [EMAIL PROTECTED] wrote:
 gmazza  2004/07/14 15:42:29
 
   Modified:examples/embedding/java/embedding ExampleFO2PDF.java
   Log:
   Updated FO-PDF example to use JAXP.
   +// Setup JAXP using identity transformer
   +TransformerFactory factory = TransformerFactory.newInstance();
   +Transformer transformer = factory.newTransformer(); // identity 
 transformer
   +
   +// Setup input for XSLT transformation
   +Source src = new StreamSource(fo);
   +// Resulting SAX events (the generated FO) must be piped through to 
 FOP
   +Result res = new SAXResult(driver.getContentHandler());
   +
   +// Start XSLT transformation and FOP processing
   +transformer.transform(src, res);

This is as much JAXP:

Driver.run:
render(FOFileHandler.createParser(), source);

FOFileHandler.createParser:
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();

Why is having a transformer object in between better?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Combined the AreaTree and FOTreeHandler (was: Re: cvs commit: etc.)

2004-07-13 Thread Simon Pepping
On Tue, Jul 13, 2004 at 12:16:22AM -, [EMAIL PROTECTED] wrote:
 gmazza  2004/07/12 17:16:22
   Log:
   1.) Combined the AreaTree and FOTreeHandler into a new AreaTreeHandler
   object.  FOTreeHandler was primarily acting as an AreaTreeHandler,
   and AreaTree had a 1-to-1 relationship with it.  Comments most welcome.

This change seems to cross the border between FO tree and area tree. 

AreaTree had no reference to the fo package (apart from a reference to
fo.extensions). AreaTreeHandler extends a class in the fo package and
refers to fo/PageSequence.

FOInputHandler implements a number of methods of the SAX
contenthandler, which is between the fo file and the FO tree. The area
package now inherits these methods. AreaTreeHandler throws
SAXExceptions. This is a parser based exception type.

FOTreeHandler.endPageSequence is the FO tree's activation of a new
episode of area tree building. Now the area tree activates itself,
based on an event in the FO tree.

I believe this change violates the separation between the FO tree and
the area tree. I think that separation is a good idea and should be
maintained.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: [PROPOSAL] API Changes

2004-07-12 Thread Simon Pepping
On Sat, Jul 10, 2004 at 06:16:37PM -0700, Glen Mazza wrote:

 1.)  Drop the apps.Driver class and incorporate its
 remaining code into apps.Fop.
 
 Reason:  Fop appears to be a better self-documenting
 class name within user's embedded code.  It's also a
 neat name for a product.  User's code would move from
 looking like this:

 2.)  Shall we roll the dice?  I wonder if we should go
  100% JAXP for 1.0, i.e. coding just like this [1] for
 SAXSources and [2] for DOMSources, and removing the
 older methods from Driver where one would be using
 XSLTInputHandler.  We're currently that way with [2]
 (As of yesterday ;), the question is should we go that
 way with [1] now?

I am positive to both ideas.

 --- J.Pietschmann [EMAIL PROTECTED] wrote:
  Have another look at the API proposals in the old
  Wiki.
   
 
 http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
  
 
 Well, a bit too expansive for my (personal) tastes, at
 least for 1.0--but to be candid, much of it I still
 don't understand.  Regardless, the resources we have
 for 1.0 IMO should be focusing on other areas
 (fo's/layout/renderers) at this time.  Perhaps another
 reason for my recommendation for a spartan API
 similar to what we now have for 0.20.5.  
 
 Our inputs I see for 1.0:
 
 --XSL FO document (or xml/xslt)
 --preferred render type
 --FOUserAgent and UserConfiguration, whatever portions
 of functionality/coding in each.
 
 That should be enough for us in 1.0, no?  Those more
 elaborate API goals appear best discussed post-1.0,
 presumably once more vital parts of the system have
 been addressed.  
 
 More thoughts, anyone?  Simon, what would you be
 comfortable with API-wise in 1.0?

I agree with these priorities. Such a FOP would perhaps not have a
better API than the maintenance code, but it would be an
implementation of the redesign and thus end the unfortunate split
between maintenance and development.

I have not yet had the time to read Jörg's proposals, but I think I
would have the same conclusion: move it forward until there is more
time.

Perhaps it is indeed wise, as Glen concluded, to leave the API much as
it is, in view of the fact that we do not yet have a final view on
it. However we do it, we will go through two phases: implement the new
layout, and implement a new API, and there will be a time between the
two. 

I think moving to JAXP now is desirable, for all the reasons one
follows a standard API.

Note that the Xalan and other people call the javax.xml.transform part
TrAX. AFAIK, javax.xml.parsers is also in JAXP.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: adding fonts to fop applet

2004-07-12 Thread Simon Pepping
On Fri, Jul 09, 2004 at 03:05:11PM -0700, Glen Mazza wrote:
 Thanks, Simon.  Its good that we have people of your
 skill on our team.

Thanks for the compliment.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Still need DOM Tree processing?

2004-07-05 Thread Simon Pepping
On Mon, Jul 05, 2004 at 11:20:26AM -0700, Glen Mazza wrote:
 Thanks for the information.  Working with a DOM tree
 saves one the step of needing to place input data into
 XML first.  So retaining this functionality in 1.0
 will keep the flexibility to users in how they can
 approach a report-generation task.  I guess we should
 keep it in then.

I support that decision. It is one more entry point for apps. Of
course they can fire off their own SAX events, but if they have a DOM
tree and FOP does it for them, that is nice.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Documentation finished

2004-07-01 Thread Simon Pepping
On Wed, Jun 30, 2004 at 02:04:30PM -0700, Glen Mazza wrote:
 On second thought, I would hold off on this; I just
 noticed you copywrited the document under your name;
 hence it would probably be improper to include the
 current FOP system documentation from Keiron/Kelly or
 other former/current committers.

That is not a problem. I never publish anything without a copyright
holder. If it goes to FOP CVS and other contributions are merged, then
the copyright holder is just changed, like with source code.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Documentation finished

2004-06-30 Thread Simon Pepping
Hi Clay,

On Mon, Jun 28, 2004 at 11:54:10AM -0700, Clay Leeds wrote:
 Looks pretty good. As you indicated, there are a few areas to be 
 improved (e.g., 'TO BE IMPROVED and 'no data' sections), and some 

I spent quite some time to this documentation. The chapter on
properties took quite a bit more work than I expected. Now I want to
take a break. I will look at those passages later.

 issues with formatting (I think they're related to the 
 text-align='justify' setting--perhaps the document would read better 
 with default (i.e., 'left') justification?), but by and large this 


I suppose you refer to the section titles like
'LineLayoutManager.getNextBreakPoss'. I noticed that these can be
mended using hyphenate=false, but it is hard to specify that through
DocBook. I think I will change those titles, and set text-align=left
for the section titles. Otherwise I am quite pleased with the
justification.
 
 looks like it will be a valuable addition to the FOP arsenal! One other 
 addition I'd like to see is that the fo:region-before include the 
 Chapter '#' in addition to the Title.

I will see if I can customize the DocBook style sheets to do
that. There are a few other things that may benefit from
customization.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Documentation finished

2004-06-30 Thread Simon Pepping
On Mon, Jun 28, 2004 at 02:31:27PM -0700, Glen Mazza wrote:
 Before doing so, it would probably be good if you
 could look at our System design pages
 (http://xml.apache.org/fop/design/index.html), if you
 haven't already, and add to your document anything
 from them that is still relevant and useful but
 missing from your document.

I have read them but I have not checked whether I have included
everything that is relevant. As I replied to Clay, I now want to take
a break from this work, and try to do some coding. I will take your
suggestion up later.
 
 That way, when we add your document to our website, we
 can rid of the system design pages.  (Most of them are
 obsolete with the changing architecture anyway.)  That
 way, we will just have one official Docbook-based
 document to maintain.

Much of it is still remarkably relevant, esp. regarding FO trees and
Layout system.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Java text geometry

2004-06-30 Thread Simon Pepping
Christian,

On Tue, Jun 29, 2004 at 07:58:41PM +, Christian Z. wrote:
 Hi Peter!
 
 else. So, just ask, if there are questions. Furthermore I'm currently
 talking to the ExTeX people. IMO ExTeX will be _very_ similar to FOP in
 the end effect, but currently has different priorities. And of course it
 will be based on TeX in some kind not XSL. Cause they want to eliminate
 TeX's drawbacks (including multilingual text) it perhaps makes sense to
 get in touch with them too. BTW: They would like to use the Batik code
 for reading TTF-files. I think there are Batik members here too? Perhaps
 one of you could drop them a line...

ExTeX, isn't that the name devised for NTS, but never used? Who are
using that now? Is there development in that area?
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Documentation finished

2004-06-28 Thread Simon Pepping
Hi,

I finished my documentation of the FOP architecture and code. Well,
more or less; this is version 0.9. Maybe I'll add a short introduction
or some such. See http://www.leverkruid.nl/FOP/index.html.

How can this be contributed to the FOP website? The documentation
consists of a number of Docbook 4.2 XML files. Could this be part of
the wiki? Or could it be in CVS?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



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

2004-06-21 Thread Simon Pepping
On Sat, Jun 19, 2004 at 03:30:30PM +0200, Jeremias Maerki wrote:
 Hi everyone,
 
 Berin thankfully pushed again and I'm taking the time for another round.
 Considering what I think is the general opinion, here's what I propose:
 
 1. We create that XML Graphics PMC taking Batik and FOP under the new
 umbrella. I hope I don't have to explain again that nothing will change
 for our users. We will still use the XML project's infrastructure.

I have not followed the discussion and do not know the advantages or
disadvantages. Therefore I am neither in favour of nor against this
proposal.
 
 3. I propose the following FOP people for the minimal initial PMC: Peter
 B. West, Jörg Pietschmann, Glen Mazza. I'd also propose at least some of
 the more junior committers but I don't know how anyone feels about that.
 Please propose any additional candidates as you see fit. I don't propose
 myself but I'm available if anyone proposes me.

Sounds fine with me. I do care about organizational matters, as a
necessary evil. But I have little time to spend on FOP, and I would
not like to fragment it over multiple concerns. Therefore I prefer not
to be a candidate. I have not been long enough on the project anyway.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: cvs commit: xml-fop/src/java/org/apache/fop/tools/anttasks Fop.java

2004-06-20 Thread Simon Pepping
Glen,

On Sun, Jun 20, 2004 at 12:35:17PM -, [EMAIL PROTECTED] wrote:
 gmazza  2004/06/20 05:35:17
 
src/java/org/apache/fop/render AbstractRenderer.java

   Index: AbstractRenderer.java
   ===
   RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java,v
   retrieving revision 1.27
   retrieving revision 1.28
   diff -u -r1.27 -r1.28
   --- AbstractRenderer.java   20 Jun 2004 07:46:13 -  1.27
   +++ AbstractRenderer.java   20 Jun 2004 12:35:17 -  1.28
   @@ -87,7 +87,7 @@
/**
 * logging instance
 */
   -protected static Log logger = LogFactory.getLog(Renderer);
   +protected static Log logger = LogFactory.getLog(FOP);

/**
 * producer (usually FOP)

I am not happy with this change. Especially debug and trace logging
may produce large amounts of output. Then it is an advantage if one
can select for which classes or packages one wants to see the
logging. That is possible if we use a separate logger per package, and
for classes that may produce a lot of log output, even a separate
logger per class. You can see my logging strategy in my recent patch.

In that patch I have also started to use the trace level for very
detailed logging.

Let us discuss a common logging strategy.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



  1   2   >