Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)

2003-11-25 Thread Christian Geisert
Victor Mote wrote:
+1
+1

Christian



Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)

2003-11-25 Thread Jeremias Maerki
+1

On 24.11.2003 23:03:41 Victor Mote wrote:
 Glen Mazza wrote:
 
  [Incidentally, this someone else can be Peter
  himself at this stage...I'd like to see a little bit
  more FOP-DEV/-USER ML communication from him, however
  the quality  quantity of his patches have been very
  good.  I'm open for making him committer should others
  also feel this way at this time.]
 
 +1

Jeremias Maerki



DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer

2003-11-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775

[PATCH] padding-left in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2003-11-25 08:58 ---
Glen-thanks, just some final comments on this:

1) AbstractRenderer. The PDF Renderer does override renderBlockViewport 
method, but the code in the super class method is copied to a large extent. I 
realise that this does not mean all the renderers will override the same 
methods or if they have copy the code from the super class. However you can 
argue that perhaps all renderers should follow the same pattern WRT to these 3 
methods. If they dont then the code in the abstract renderer ends up becoming 
spagetti like with redundant/duplicated bits.

I understand and respect your reasoning here, I'm not going to bring it up 
again-just added the above notes for clarification really.

2) Yes I knew it would work for nested blocks-I wasnt sure what the desired 
behaviour was for background color-thanks for finding the relavant part in the 
spec. Also thanks for doing padding-end, I was going to do that as my next 
patch-it should have been quite easy-just a tweak to BLM to reduce the IPD.


Re: Column Balancing

2003-11-25 Thread Chris Bowditch
Barnaby Shearer wrote:

snip/

(I am using FOP 0.20.5 on the Sun JDK 1.4 under windows XP)
Thanks for the analysis but FOP 0.20.5 is frozen code I'm afraid. FOP
has been redesigned to support keeps (on all FOs) and development is
focused on the redesigned branch in CVS Head. Column balancing will be
addressed in the new code.
Thanks,

Chris








Re: Task list Was: Re: Font variant SmallCaps

2003-11-25 Thread Chris Bowditch
J.Pietschmann wrote:
Chris Bowditch wrote:

but my motivation is just to get something rather than nothing. 


You are bored? Oh!
Thanks for the suggestions. I think you misunderstood though, I'm far
from bored, my employers keep me busy. Just trying to help get layout 
unbroken.

Some tasks:
- Implement text-align-last
- Implement text-align=justify
- Fix table headers.
- Fix content rectangle computation for background filling
- Fix bottom borders (and perhaps other too)
- implement region precedence
- Implement background images for regions
- Implement background image attachment
- Implement relative positioning
- implement multi column layout
- fix footnotes for multi column layout
Blimey even RenderX struggle with that one!

snip/

Chris






Re: [VOTE] Properties API

2003-11-25 Thread Jeremias Maerki
I've read your proposal with great interest. I still have to say that
I'm still not knowledgeable in the property-resolving area that I can
cast a vote here. But it sounds good, nothing that disturbs me. I hope
that the people with intimate knowledge in this area all participate and
bring up any issue if they see anything problematic.

On 25.11.2003 00:17:35 Victor Mote wrote:
 Proposal:
 I propose

Jeremias Maerki



RE: Column Balancing

2003-11-25 Thread Barnaby Shearer
Hi,

In case anyone else has a similar problem there is a simple (and very
obvious) fix:

In: BodyAreaContainer.resetSpanArea(), After line:

newHeight += 2 * 15600;

Add:

if(newHeightgetRemainingHeight()) {
newHeight = getRemainingHeight();
}

You can then tweak the newHeight safety margin till it works with your
content, without the columns overlapping the footer.

Yes, I don't know why it took me so long to see this ether.

Barnaby

 My material contains a lot of tables with keep-together's and
external graphics. The image/table which are just too big to fit in the
estimated height of the first column are correctly move into the second
column, but this causes the second column to become longer then the
estimated maximum span height, this in turn causes fop to insert a page
break and move the end of the second column to the next page. However
this looks very odd as often 80% of the original page is still blank.
Fop already has a safety margin built into
BodyAreaContainer.resetSpanArea() to address this problem, however it is
set to small for my content.

 You can easily overcome this problem by increasing the safety margin
which is added to maxHeigh in resetSpanArea() (from 2 * 15600, to 2 *
45600 in my case). This has the added benefit that it causes the first
column be about 4cm longer then the second before each span, which adds
some much needed white space to my layout.

 However this introduces a new problem (which must be present to a
lesser degree anyway), the safety margin added in resetSpanArea() is
added after the check to see if the span's content fits on the page,
this means that if the content already filled the page, the span's new
height is increased by the safety margin and overlaps with the footer.

 As far as I can see there are two ways to work around this:

 Disable the column balancing when the contence of a span overflows
the page - simple set the column heights to the avaible size and then
fit as much content into column one followed by column two. (This must
be what happens on the last page of a flow).

(In fact the solution is even easier, simply don't let the column height
grow bigger then the page. The code already handles moving anything that
doesn't fit onto the next page.)

 Change where the safety margin is added so that it is taken into
account when checking if the content fits on the page. This would cause
some unforinate white space at the bottom right of every page but I
could live with this. 

 Whilst these sound fairly simple, my Java experience is limited and I
have not been able to follow though the fop structure to workout where
to implement these changes - could anyone give my any guidance on where
to start and/or which of the approaches might be easer to implement
given the way fop works.


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

2003-11-25 Thread vmote
vmote   2003/11/25 07:29:38

  Modified:src/documentation/content/xdocs resources.xml
   src/documentation/content/xdocs/dev tools.xml
  Log:
  add some cvs and xsl-fo resources
  
  Revision  ChangesPath
  1.33  +2 -1  xml-fop/src/documentation/content/xdocs/resources.xml
  
  Index: resources.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/resources.xml,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- resources.xml 12 Nov 2003 15:29:59 -  1.32
  +++ resources.xml 25 Nov 2003 15:29:38 -  1.33
  @@ -68,6 +68,7 @@
 li[online article] jump 
href=http://www.sun.com/software/xml/developers/slides-dtd/;Using Formatting Objects 
with the Slides DTD/jump, by Paul Sandoz./li
 li[online article] jump 
href=http://www.xml.com/pub/a/2001/01/17/xsl-fo/index.html;Using XSL Formatting 
Objects/jump, by J. David Eisenberg./li
 li[online reference] jump 
href=http://zvon.org/xxl/xslfoReference/Output/index.html;XSL FO reference/jump, 
by Miloslav Nic./li
  +  li[online reference] jump 
href=http://www.dpawson.co.uk/xsl/sect3/index.html;Dave Pawson's XSL-FO 
FAQ/jump./li
 li[online book] jump 
href=http://www.dpawson.co.uk/xsl/sect3/bk/index.html;An introduction to XSL 
Formatting Objects/jump, by Dave Pawson. See hardcopy version below./li
 li[book] jump 
href=http://www.oreilly.com/catalog/xslfo;XSL-FO/jump, by Dave Pawson, O'Reilly 
amp; Associates, 2002, ISBN 0-596-00355-2. See online version above./li
 li[book] jump 
href=http://www.phptr.com/browse/product.asp?product_id={CEA527AF-412D-49DA-8C1F-46E0A519B8D8};Definitive
 XSL-FO/jump, by G. Ken Holman, Prentice Hall PTR, 2003, ISBN 0-131-40374-5./li
  
  
  
  1.9   +14 -1 xml-fop/src/documentation/content/xdocs/dev/tools.xml
  
  Index: tools.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/dev/tools.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- tools.xml 13 Nov 2003 18:01:49 -  1.8
  +++ tools.xml 25 Nov 2003 15:29:38 -  1.9
  @@ -77,6 +77,19 @@
 liOn a Linux/Unix machine, you will want to redirect the output from 
the above command into a file. If you are using GNU WinCVS, you can cut the output 
from the console window and paste it into a file. The -w ignores whitespace 
differences. The -u puts the diff in universal format. You may wish to use the 
-N option as well, which is supposed to treat new files as if there were an old 0 
byte file -- in other words, it is supposed to include the new file in the patch. 
However, it only operates on files that have been added to the CVS repository, which 
cannot be done without commit access./li
   /ul
 /section
  +  section id=cvs-doc
  +titleDocumentation/title
  +ul
  +  li[online resource] jump href=http://www.cvshome.org;The CVS Home 
Page/jump./li
  +  li[electronic manual] jump 
href=http://www.cvshome.org/docs/manual;The Cederqvist/jump (official CVS 
manual).
  +Note that this manual applies to the command-line version of CVS./li
  +  li[book] jump href=http://www.oreilly.com/catalog/cvs;Essential 
CVS/jump, by Jennifer Vesperman (O'Reilly amp; Associates)./li
  +  li[book] jump href=http://www.oreilly.com/catalog/cvspr2;The CVS 
Pocket Reference/jump, by Gregor N. Purdy (O'Reilly amp; Associates)./li
  +  li[book] Open Source Development with CVS, by Moshe Bar and Karl Franz 
Fogel (Paraglyph Press, ISBN 1-932111-81-6)./li
  +  li[book] jump href=http://www.oreilly.com/catalog/rcs;Applying RCS 
and SCCS/jump, by Dan Bolinger and Tan Bronson (O'Reilly amp; Associates).
  +RCS is used by CVS for its file operations (CVS is kind of a wrapper around 
RCS)./li
  +/ul
  +  /section
   /section
   section id=ide
 titleIntegrated Development Environments (IDEs)/title
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Properties API

2003-11-25 Thread John Austin
Note: I added a page to the wiki for this thread.
http://nagoya.apache.org/wiki/apachewiki.cgi?PropertiesRedesign

After thinking about the proposal, I'm not sure it solves anything. 

There are two aspects to the redesign of Property handling in FOP.

  * Interface means the external points of contact for Property data
  * Interface determines impact of changes on other components of
the system.
  * Implementation means the internal construction of classes 
  * Implementation determines performance characteristics of the
program.

The discussion favours the proposal.

Interface
The current proposal asks that FOP will employ Java-Bean-like accessors
for the properties of Formatting Objects visible to the FOTree. As an
example: 

 getMaxWidth?() for the property max-width 

There are between 250 and 380 of these methods required and they could
be generated automatically from an XML-based list of properties. This
list could be derived (if not generated) from the XSL-FO Specification
itself. Some kind of simple adapter class can be used to equate the
proposed interface to the existing one:

 class PropertyAdapter? extends Property{ // Ugh! just f'rinstance

  // repeat the following about 380 times:
  final public Property getMaxWidth?() { // use final to inline and annoy
return get(max-width);
  }
 }

There is no statement defining the current interface. This will be
determined from existing code.


Implementation
The proposal makes no suggestion for implementation and my earlier
submission is not relevant except as an indication that this issue is
linked to performance.


-- 
John Austin [EMAIL PROTECTED]


Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)

2003-11-25 Thread Oleg Tkachenko
Victor Mote wrote:

[Incidentally, this someone else can be Peter
himself at this stage...I'd like to see a little bit
more FOP-DEV/-USER ML communication from him, however
the quality  quantity of his patches have been very
good.  I'm open for making him committer should others
also feel this way at this time.]
+1

--
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel


RE: [VOTE] Properties API

2003-11-25 Thread Victor Mote
John Austin wrote:

 After thinking about the proposal, I'm not sure it solves anything.

Perhaps not. If the purpose of building a house is to supply shelter, then
building a foundation would seem also not to solve anything. However, it is
kind of a necessary first step toward the ultimate goal. All the proposal
attempts to do is to separate the interface from the implementation. Right
now the interface is pretty tightly tied to the implementation. Changes that
you might make to the implementation would require (I think) changes to the
LayoutStrategys and to the Renderers. Also, as Glen has pointed out, there
is business logic that can be pulled out of these code modules back into FO
Tree where they more properly belong, and where duplication and confusion
can be minimized.

 There are two aspects to the redesign of Property handling in FOP.

   * Interface means the external points of contact for Property data
   * Interface determines impact of changes on other components of
 the system.
   * Implementation means the internal construction of classes
   * Implementation determines performance characteristics of the
 program.

 The discussion favours the proposal.

I don't understand what you are saying here.

 Interface
 The current proposal asks that FOP will employ Java-Bean-like accessors
 for the properties of Formatting Objects visible to the FOTree. As an
 example:

  getMaxWidth?() for the property max-width

 There are between 250 and 380 of these methods required and they could
 be generated automatically from an XML-based list of properties. This
 list could be derived (if not generated) from the XSL-FO Specification
 itself. Some kind of simple adapter class can be used to equate the
 proposed interface to the existing one:

  class PropertyAdapter? extends Property{ // Ugh! just f'rinstance

   // repeat the following about 380 times:
   final public Property getMaxWidth?() { // use final to inline and annoy
 return get(max-width);
   }
  }

Sorry -- I was not clear here. I meant to suggest that these methods be
added to FObj (and its subclasses to the extent necessary).

 There is no statement defining the current interface. This will be
 determined from existing code.


 Implementation
 The proposal makes no suggestion for implementation and my earlier
 submission is not relevant except as an indication that this issue is
 linked to performance.

Again, I am not sure what you are saying here. The proposal deliberately
does *not* address implementation. I am quite glad to have you address the
performance aspects of implementation, but I think it is a separate issue
from the interface. We can (and should, IMO) fix the interface before or at
least during any changes to the implementation. All I am trying to do is to
hide the implementation from the rest of the system.

Your earlier submission *is* relevant to implementation side of the
question, just not to the question that I raised, which is totally
interface, and which I consider to be foundational to the changes that you
are contemplating. The changes you are considering would need to conform to
the interface being discussed. Now, if something in my proposal is harmful
to the implementation(s) that you are considering, that is definitely
relevant.

Since FO Tree (and Properties) kind of works right now, we have been paying
much more attention to other parts of the FOP code. Your questions and
interest are forcing us to address it sooner than we would have. Obviously,
one of our highest priorities should be to make other developers as
productive as possible. Also, to a certain extent, we have been waiting on
Peter West's work, hoping that his efforts can be useful in all of this. I
am still hoping to hear from Peter on this, but in the meantime, I am trying
to do some housekeeping that IMO will be important to clear the decks for
you.

Sorry to be so dense -- I may just not be used to your style of writing.
Please let me know if I am missing something.

Victor Mote



RE: [VOTE] Properties API

2003-11-25 Thread John Austin
Victor, I was mostly backing away from my earlier posting which was 
off-target.

On Tue, 2003-11-25 at 13:26, Victor Mote wrote:
 John Austin wrote:
 
  After thinking about the proposal, I'm not sure it solves anything.

 you might make to the implementation would require (I think) changes to the
 LayoutStrategys and to the Renderers. Also, as Glen has pointed out, there
 is business logic that can be pulled out of these code modules back into FO
 Tree where they more properly belong, and where duplication and confusion
 can be minimized.

In order to adapt Peter's ideas, I would need identify the current
Interface(s). Ideally a re-implementation of Property handling would be
invisible outside of those classes.

All the proposal addresses is the signature of some accessors. It does
not identify the set of property-related classes. I think an adapter
class could convert the current interface to the proposed interface.

This could be useful if it covers the entire properties interface.

  The discussion favours the proposal.
 
 I don't understand what you are saying here.

All/most other postings agreed with the proposal. 

   class PropertyAdapter? extends Property{ // Ugh! just f'rinstance
 
// repeat the following about 380 times:
final public Property getMaxWidth?() { // use final to inline and annoy
  return get(max-width);
}
   }
 
 Sorry -- I was not clear here. I meant to suggest that these methods be
 added to FObj (and its subclasses to the extent necessary).

Just a for-instance sketch of an Adapter. Reference to properties has to
come from somewhere. I used Inheritence as a convenience.

  There is no statement defining the current interface. This will be
  determined from existing code.
 
  Implementation
  The proposal makes no suggestion for implementation and my earlier
  submission is not relevant except as an indication that this issue is
  linked to performance.
 
 Again, I am not sure what you are saying here. The proposal deliberately
 does *not* address implementation. I am quite glad to have you address the
 performance aspects of implementation, but I think it is a separate issue
 from the interface. We can (and should, IMO) fix the interface before or at
 least during any changes to the implementation. All I am trying to do is to
 hide the implementation from the rest of the system.

What else is needed to 'get' properties ? Your accessors just have the 
property name. 

 Since FO Tree (and Properties) kind of works right now, we have been paying
 much more attention to other parts of the FOP code. Your questions and
 interest are forcing us to address it sooner than we would have. Obviously,

Don't feel forced. You CAN ignore me. I appreciate your efforts to clue
me in.

 one of our highest priorities should be to make other developers as
 productive as possible. Also, to a certain extent, we have been waiting on
 Peter West's work, hoping that his efforts can be useful in all of this. I
 am still hoping to hear from Peter on this, but in the meantime, I am trying
 to do some housekeeping that IMO will be important to clear the decks for
 you.

I support your Interface-view of properties but would like to have the
scope of the Property interface mapped out to include more than the
accessors. Of course, if these accessors and some references all ready
held by FObj, can do the trick, lets get on with it!

-- 
John Austin [EMAIL PROTECTED]


Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)

2003-11-25 Thread J.Pietschmann
Victor Mote wrote:
[Incidentally, this someone else can be Peter
himself at this stage...I'd like to see a little bit
more FOP-DEV/-USER ML communication from him, however
the quality  quantity of his patches have been very
good.  I'm open for making him committer should others
also feel this way at this time.]


+1
+1

J.Pietschmann



FOP documentation

2003-11-25 Thread Simon Pepping
Hello,

I am making an effort to understand FOP's architecture and program
code. In this process I have compiled a number of documentation
notes. It is a loose collection of notes on various aspects of the
program, liberally illustrated with object dumps and stack traces as
provided by jdb. The structure of the notes very much
reflects my discovery and growing understanding of the various parts
of FOP. I will add to this collection as I study more parts of
FOP.

These documentation notes are very much a work in progress. I do
not claim that I understand FOP; I am trying to. Therefore you should
not believe what these notes say. If you do, and you act accordingly,
you do so at your own risk.

The notes can be found at: http://www.leverkruid.nl/FOP/index.html

Regards,
Simon Pepping

-- 
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl



RE: [VOTE] Properties API

2003-11-25 Thread Victor Mote
John Austin wrote:

 In order to adapt Peter's ideas, I would need identify the current
 Interface(s). Ideally a re-implementation of Property handling would be
 invisible outside of those classes.

I think we have a one-time cost of changing the interface. IOW, I think any
changes that you make to the way Properties are handled will require changes
to Layout and Render. I just want to make sure that it is handled so that
any future changes can be handled transparently.

 All the proposal addresses is the signature of some accessors. It does
 not identify the set of property-related classes. I think an adapter
 class could convert the current interface to the proposed interface.

Yes, that is absolutely true. Or the existing interface can simply become
the back-end to the new one (at least until the implementation changes). All
of that is negotiable as a separate issue.

class PropertyAdapter? extends Property{ // Ugh! just f'rinstance
  
 // repeat the following about 380 times:
 final public Property getMaxWidth?() { // use final to
 inline and annoy
   return get(max-width);
 }
}
 
  Sorry -- I was not clear here. I meant to suggest that these methods be
  added to FObj (and its subclasses to the extent necessary).

 Just a for-instance sketch of an Adapter. Reference to properties has to
 come from somewhere. I used Inheritence as a convenience.

I think I must not be following you here. Since properties are logically
attached to FO Object instances, it made sense to me that the methods for
getting them should live there as well. So the 250-380 methods would go (I
think) into FObj and subclasses. If the adapter needs to have a similar
number of methods, which is what I think you are suggesting, that is OK. I
just want to make it clear that the part of this that would be visible to
the rest of FOP would *only* be the stuff in FObj and subclasses.

 What else is needed to 'get' properties ? Your accessors just have the
 property name.

That, of course, depends on the implementation. Right now, they would be
looked up in the PropertyList. However, there are conversions that need to
take place. I am thinking, for example, that lengths should always return a
millipoint value, to simplify Layout and Render.

  Since FO Tree (and Properties) kind of works right now, we have
 been paying
  much more attention to other parts of the FOP code. Your questions and
  interest are forcing us to address it sooner than we would
 have. Obviously,

 Don't feel forced. You CAN ignore me. I appreciate your efforts to clue
 me in.

I understand, and forced is too strong a word. However, I think we are all
very, very, VERY eager to help develop new developers. Your observations
about FOP's performance and the causes ring true, and it makes sense to help
make you productive. Three months ago, I would not have been as excited
about this project, because we still had a lot of overlap between FO Tree
and Layout. That has mostly been factored out, and cleaning up the interface
for Properties is IMO a logical extension of that work.

 I support your Interface-view of properties but would like to have the
 scope of the Property interface mapped out to include more than the
 accessors. Of course, if these accessors and some references all ready
 held by FObj, can do the trick, lets get on with it!

As far as the interface to the remainder of FOP goes, I think the signatures
of the accessors is all of it. I can't think of anything else. If I want the
max-width property, I should be able to do something like:
int maxWidth = someFObj.getMaxWidth();

The current implementation might look like this:
public class FObj {

public int getMaxWidth() {   //WARNING -- unchecked or tested!!
return properties.get(max-width).getLength().getValue();
}

A subclass that doesn't use max-width might override with:
public int getMaxWidth() {
return FObj.INVALID_PROPERTY;
}

A future implementation might have very different internals, but would have
the same signature.

Victor Mote



DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer

2003-11-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775

[PATCH] padding-left in PDF Renderer





--- Additional Comments From [EMAIL PROTECTED]  2003-11-25 22:53 ---
The PDF Renderer does override renderBlockViewport method, but the code in the 
super class method is copied to a large extent.

Oh--I wasn't looking in PDFRenderer for the redundancy.  I was looking at  
renderBlocks(), renderBlock(), and renderBlockViewPort() of AbstractRenderer--
i.e., where you told me to look in your elaboration below.  (I had assumed, 
then, that the duplication was among those three methods.)

I asked you:  Please clarify *which* methods had the duplication so I can zoom 
in immediately to what you are talking about--patches--until applied--rarely 
immediately inform us of that!  

Your response did not answer that question--worse, it put me on the wrong 
track.  That sentence you wrote above--finally explaining where the duplication 
was--I wish you had written that instead.  It would have saved me a lot of time 
and energy.  Try to be more precise next time...

[At any rate, it would appear the child classes would be the better place to 
remove redundant code, not the base, so I probably would have skipped the 
changes anyway.]  

Thanks,
Glen


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

2003-11-25 Thread chrisg
chrisg  2003/11/25 17:12:46

  Modified:src/documentation/content/xdocs book.xml
  Log:
  Added link to the Wiki
  
  Revision  ChangesPath
  1.27  +1 -0  xml-fop/src/documentation/content/xdocs/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/book.xml,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- book.xml  10 Jul 2003 17:12:37 -  1.26
  +++ book.xml  26 Nov 2003 01:12:46 -  1.27
  @@ -40,6 +40,7 @@
 menu-item label=Examples href=examples.html/
 menu-item label=Mailing Lists href=maillist.html/
 menu-item label=Bugs href=bugs.html/
  +  menu-item label=Wiki 
href=http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectPages/
 menu-item label=License href=license.html/
 menu-item label=Other href=resources.html/
   /menu
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Property classes and eventually, new Property handling.

2003-11-25 Thread John Austin
After my last post I went away to play in the code for a while.

Mostly to see what is necessary to isolate a minmal set of
classes related to Property handling.

What I found is:

1) Property is ubiquitous: every client class knows what package
   it lives in. As a planning point, I better think about keeping
   a Property class (or prepare to make a lot more changes and
   lose a few friends). 

2) PropertyList and PropertyListBuilder are used in fewer places.
   but they are used a lot. PropertyList is referenced 129 times  
   and PropertyListBuilder only 8 times. Most of these references 
   are in the Property class. If they can be hidden, the problem
   is bounded by the Property class.

One way to discover the scope of an API is to rename a class or a
package. Doing so breaks all of the compile units that depend on
the renamed class(es). Restoring the missing interfaces restores
the system if the restoration obeys the previous class contracts.

As I suspected, automated code generation for properties is
do-able. There are more than 17,000 lines in files generated
through Ant target: 'codegen'. Many of these are clients of the
Property class. Changes here can be localized to the XSL files
that generate the code.

-- 
John Austin [EMAIL PROTECTED]


Re: Property classes and eventually, new Property handling.

2003-11-25 Thread Peter B. West
John Austin wrote:
After my last post I went away to play in the code for a while.

Mostly to see what is necessary to isolate a minmal set of
classes related to Property handling.
What I found is:

1) Property is ubiquitous: every client class knows what package
   it lives in. As a planning point, I better think about keeping
   a Property class (or prepare to make a lot more changes and
   lose a few friends). 

2) PropertyList and PropertyListBuilder are used in fewer places.
   but they are used a lot. PropertyList is referenced 129 times  
   and PropertyListBuilder only 8 times. Most of these references 
   are in the Property class. If they can be hidden, the problem
   is bounded by the Property class.
In alt.design individual classes in fop.fo.properties extend 
fop.fo.Property, but these classes are singletons, providing access to 
what is effectively static information about the properties.

The multitude of property instances is represented by the interface 
fop.datatypes.PropertyValue, the abstract class AbstractPropertyValue 
and the class PropertyValueList, which implements PropertyValue, and the 
other classes in fop.datatypes which generally extend AbstractPropertyValue.

One way to discover the scope of an API is to rename a class or a
package. Doing so breaks all of the compile units that depend on
the renamed class(es). Restoring the missing interfaces restores
the system if the restoration obeys the previous class contracts.
As I suspected, automated code generation for properties is
do-able. There are more than 17,000 lines in files generated
through Ant target: 'codegen'. Many of these are clients of the
Property class. Changes here can be localized to the XSL files
that generate the code.
The classes in fop.fo.properties (apart from Property.java itself) 
*could* be generated by XSLT.  I used perl, one-off.  If I need to make 
global changes, I'll use perl again.  If I need to change, add or delete 
individual classes, I'll do it manually, based on a like-minded class if 
necessary.  Should take about two minutes.  How dramatically is the set 
of properties in XSL-FO going to change?

And now for a little digression on code generation.  My own view of code 
generation by XSLT transformation can be summed up as:

* the canonical source is the Java code.
* transformations are a tool for developer convenience.
* they should be used to generate files which are then committed like 
any others.
* transformation is generally a one-off process, only to be re-used in 
extremis.
* it is the developer's responsibility to ensure that any re-generation 
does not lose patches to the previously generated and committed source.

Using this approach, the source you extract from CVS is the source you 
compile.  If you apply a fix to that source, you know that it can go 
directly into the codebase.

An example is src/codegen/xml-lang.xml, which is transformed by 
src/codegen/xml-lang.xsl into 
org/apache/fop/datatypes/CountryLanguageScript.java.  All that I could 
find about countries, languages and scripts is in xml-lang.xml. The 
result is checked-in to CVS, and will be part of the code base of any 
checkout.  How often is this information going to change?  Only if there 
are major changes to the information content of the relevant documents 
will the structure of the files need to be revisited, and it is no 
particular hardship to manage such cases.

Yes, there are situations in which it is *extremely* convenient to use 
code-munging - the Java 1.3/1.4 situation springs to mind.  The CPP was 
extremely convenient too, for similar reasons.  XSLT is much more 
powerful than CPP.  Why is there no equivalent of CPP in Java?  Why are 
we going to such trouble to create a situation which has even greater 
capacity for obfuscation that CPP?  Because we're smarter than the 
developers of Java?  Or because we have short memories?

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


RE: [VOTE] Properties API

2003-11-25 Thread Glen Mazza
--- Victor Mote [EMAIL PROTECTED] wrote:
 Also, as Glen
 has pointed out, there
 is business logic that can be pulled out of these
 code modules back into FO
 Tree where they more properly belong, and where
 duplication and confusion
 can be minimized.
 

A few more ideas:

(1.) You may find that most of the properties that
need to be pulled out of the renderers and layout are
actually Area Tree object traits, so renderers 
layout will probably also benefit from having the Area
Tree having these types of accessor functions.

Now whether you're inclined (1) to allow Area Tree
objects direct access to property list items (like the
FOObj's will have) in order to do whatever business
logic needed to determine a trait, or (2) provide
additional accessor functions--for potentially
non-refined properties--in the FOObj's to shield the
Area Tree from the property manager, both have their
benefits.  I suspect you're more comfortable with (2),
which I can be OK with.  Getting the properties out of
layout and the renderers is more important for me, the
Area Tree less a priority.

(2.) Just as an FYI, as to the issue of whether the
FO's themselves have traits--from our previous
discussion, you were saying that elements have
attributes, FOs have properties and Area Tree elements
have traits, I believe.  That fact is confirmed in the
second paragraph of the Ch. 3 of the spec[1]. 
However, somewhat confusingly, if you look at the
second, third, and fourth diagrams in 1.1.2,
Formatting[2], the spec also refers to traits as the
refined/finished properties of the refined formatting
object tree.  So in some cases, they do consider 
traits to be both at the finished FO tree and the area
tree.

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice3.html#fo-jc-intro
 

[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N742-Formatting

(3.) Another option for us, is that rather than create
all--or most--of the accessor functions first, and
*then* recode the renderers, layout, and possibly area
tree to eliminate any property manager references--it
may be better to work in the other direction.  Hunt
down references in the renderers, layout, and area
tree (in that order, I suspect) to the property
manager, and then create new accessor functions,
one-by-one, to replace those property manager
references found.

This way, we may need to implement only 50 or 60
accessor functions right now, also, we can pound out
the necessary lessons learned and layout/renderer
code changes needed while trying to replace the
properties references (for example, the layout manager
classes are sometimes not very good at allowing you to
reference the actual FO item or Area Tree object being
processed.  BlockLayoutManager, for example, does not
make it easy to reference the Area.Block being
processed.) 

Later, when we're ready to implement new
layout/renderer functionality requiring new accessor
functions, we can then add them to the FObj's/Area
Tree as needed.

(4.) Finally, there is a question of replacing the
property string constants with enumerations, which I
believe *all* of us support as a performance booster. 
Any benefits to getting this out of the way *before*
we add the accessor functions?

Anyway, after reading your responses to my concerns as
well as others' concerns, I'm now +1.

Glen


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


Re: Property classes and eventually, new Property handling.

2003-11-25 Thread Glen Mazza
--- Peter B. West [EMAIL PROTECTED] wrote:
 
 And now for a little digression on code generation. 
 My own view of code 
 generation by XSLT transformation can be summed up
 as:
 

Why, Peter, you're in disagreement with everyone else
on this issue!  (So what else is new? ;)

 * the canonical source is the Java code.
 * transformations are a tool for developer
 convenience.
 * they should be used to generate files which are
 then committed like 
 any others.
 * transformation is generally a one-off process,
 only to be re-used in 
 extremis.

BTW, what is a one-off process?

 * it is the developer's responsibility to ensure
 that any re-generation 
 does not lose patches to the previously generated
 and committed source.
 

Glen

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


Re: Property classes and eventually, new Property handling.

2003-11-25 Thread Peter B. West
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:

And now for a little digression on code generation. 
My own view of code 
generation by XSLT transformation can be summed up
as:



Why, Peter, you're in disagreement with everyone else
on this issue!  (So what else is new? ;)
Everyone else *here*, I think.  I'm sure there are some others out there 
who agree with me.  When they're released, we'll have a get-together.

* the canonical source is the Java code.
* transformations are a tool for developer
convenience.
* they should be used to generate files which are
then committed like 
any others.
* transformation is generally a one-off process,
only to be re-used in 
extremis.


BTW, what is a one-off process?


Needed once - for the initial generation of the Java source.  From then 
on, required changes are minimal enough (or general enough) to be 
handled bu direct manipulation of the Java source.

* it is the developer's responsibility to ensure
that any re-generation 
does not lose patches to the previously generated
and committed source.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

2003-11-25 Thread Peter B. West
Victor Mote wrote:
I am confused by the distinction that you make between fop.PDFFont and
fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless
it is a renderer-specific class for getting a Type1Font (for example) into
the PDF output. But I think that should be a method in the Type1Font class.
I have spent more time than I should have trying to figure out why fonts are
(or were) renderer-specific. I may still be missing something important. (I
*do* understand why they are renderer-context specific, i.e the difference
between the AWT context and the others).
I'm fuzzy with this stuff, but isn't renderer-context a new notion? 
What you are calling renderer-context was previously only associated 
with the renderer as such, wasn't it?  I'm assuming that the 
renderer-context is something that amalgamates font metrics.  Renderers 
share a context if, among other things, their fonts share common 
metrics.  Is this what you mean?

Another idea on the AWT font issue is to allow the user to register the
location of the AWT font just like they would any other font. This would be
equivalent to saying use the AWT metrics for this font, but get the
physical font from a certain file. The problem there is, of course, that
you introduce another possible layer of errors (can find the AWT metrics but
not the physical file, or vice versa), but I think that would be quite
managable.
Speaking of errors: can find the AWT metrics, but they don't match the 
metrics of the font file.

p
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html