Re: [VOTE] Peter Herweg for committer (WAS: problem applying latest RTF patch)
+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
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
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
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
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
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
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
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)
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
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
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)
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
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
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
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
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.
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.
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
--- 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.
--- 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.
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
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
