Re: (Jeremias, Keiron) Re: [VOTE] Move StructureHandler and LayoutHandler classes
Sorry for not being clear. I also meant the layoutmanager package. On 26.06.2003 00:37:25 Glen Mazza wrote: Should LayoutHandler go into the Layout (Jeremias) package or LayoutManager package (Keiron)? (Personally, I don't care--99% for me is getting them out of apps.) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/rtflib/testdocs CreateTestDocuments.java TestDocument.java
vmote 2003/06/25 23:41:48
Modified:.build.xml
src/java/org/apache/fop/rtf/renderer RTFHandler.java
src/java/org/apache/fop/rtf/rtflib/rtfdoc RtfBookmark.java
RtfContainer.java RtfElement.java
RtfExternalGraphic.java RtfFile.java RtfHeader.java
RtfJforCmd.java RtfListTable.java RtfTableRow.java
src/java/org/apache/fop/rtf/rtflib/testdocs
CreateTestDocuments.java TestDocument.java
Log:
Get rtflib (jfor) files to compile.
Revision ChangesPath
1.83 +0 -10 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -r1.82 -r1.83
--- build.xml 20 Jun 2003 15:56:51 - 1.82
+++ build.xml 26 Jun 2003 06:41:47 - 1.83
@@ -118,12 +118,6 @@
exclude name=org/apache/fop/pdf/PDFEncryptionJCE.java unless=jce.present/
/patternset
- !-- jfor RTF library has been moved here but needs tweaking before it compiles
--
- !-- remove this once the RTF library compiles --
- patternset id=exclude-rtflib
-exclude name=org/apache/fop/rtf/rtflib/**/*.java/
- /patternset
-
patternset id=base-sources
include name=**/*.java/
exclude name=**/*${ignore_this}/
@@ -438,10 +432,6 @@
patternset refid=exclude-jce-dependencies/
patternset refid=exclude-jai/
patternset refid=exclude-jimi/
-
- !-- remove this once the RTF library compiles --
- patternset refid=exclude-rtflib/
-
classpath refid=libs-build-classpath/
patternset refid=base-sources/
/javac
1.6 +6 -6 xml-fop/src/java/org/apache/fop/rtf/renderer/RTFHandler.java
Index: RTFHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/rtf/renderer/RTFHandler.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RTFHandler.java 18 Jun 2003 02:10:32 - 1.5
+++ RTFHandler.java 26 Jun 2003 06:41:48 - 1.6
@@ -79,12 +79,12 @@
import org.apache.fop.fo.flow.TableRow;
// JFOR
-import org.jfor.jfor.rtflib.rtfdoc.RtfAttributes;
-import org.jfor.jfor.rtflib.rtfdoc.RtfFile;
-import org.jfor.jfor.rtflib.rtfdoc.RtfSection;
-import org.jfor.jfor.rtflib.rtfdoc.RtfText;
-import org.jfor.jfor.rtflib.rtfdoc.RtfParagraph;
-import org.jfor.jfor.rtflib.rtfdoc.RtfDocumentArea;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfAttributes;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfFile;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfSection;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfText;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfParagraph;
+import org.apache.fop.rtf.rtflib.rtfdoc.RtfDocumentArea;
/**
* RTF Handler: generates RTF output using the structure events from
1.2 +2 -2
xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc/RtfBookmark.java
Index: RtfBookmark.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc/RtfBookmark.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RtfBookmark.java 20 Jun 2003 16:08:21 - 1.1
+++ RtfBookmark.java 26 Jun 2003 06:41:48 - 1.2
@@ -119,7 +119,7 @@
*/
public void writeRtfContent () throws IOException
{
- this.getRtfFile ().getLog ().logInfo (Write bookmark ' + bookmark +
'.);
+// this.getRtfFile ().getLog ().logInfo (Write bookmark ' + bookmark +
'.);
// No content to write
}
1.3 +4 -4
xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc/RtfContainer.java
Index: RtfContainer.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc/RtfContainer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RtfContainer.java 24 Jun 2003 17:47:14 - 1.2
+++ RtfContainer.java 26 Jun 2003 06:41:48 - 1.3
@@ -97,9 +97,9 @@
// warn of this problem
final RtfFile rf = getRtfFile();
-if(rf.getLog() != null) {
-rf.getLog().logWarning(msg);
-}
+//if(rf.getLog() != null) {
+// rf.getLog().logWarning(msg);
+//}
// TODO this should be activated to help detect XSL-FO constructs
// that we do not handle properly.
1.3 +3 -3
xml-fop/src/java/org/apache/fop/rtf/rtflib/rtfdoc/RtfElement.java
Index: RtfElement.java
Re: Spec drives me crazy: column-count and blocks with mixed spans
Peter, thanks for the answer. I have always *assumed* that column balancing is implied whenever top-level block children of a flow have different span attributes, because it's the only approach that makes sense. If your second scenario were intended, then the 'span=all' block could not share the page with the previous 'span=none' blocks unless there were less than one column's worth of text. I.e. Yes, that sure makes sense, but it's not really anywhere in the spec, is it? You can still argue the spec makes sense without column balancing - at least you can use span=all blocks before span=none blocks. That leaves open the question of whether, on the last page of a page-sequence, the columns should be balanced. My intuitive approach would be to balance always. However, there seems to be another attribute required for column spill behaviour, especially for the last page of a page-sequence. I assume you really mean the end of the flow (or page-sequence) here, right? last page could also be something like: ABC DDD DDD or even ABC DDD EFG Personally, I'd prefer no balancing for the end of the flow. Reason: For columns that contain mostly text, that looks awfully strange if you can't have at least 2 paragraphs in each column. Since the default behaviour really seems to be unspecified, and since there's no property to specify it, I believe overall less harm is done if you don't balance at the end of the flow. This is because then you can always trick the renderer into balancing by making the end not the end. Just put an fo:block with invisible content and span=all at the end. Of course, a property for that would be nice, but at least then you can have both. How about that? -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/lib jfor-0.7.1.jar jfor.LICENSE.txt
vmote 2003/06/26 00:03:52
Modified:.build.xml
Removed: lib jfor-0.7.1.jar jfor.LICENSE.txt
Log:
Remove jfor libs and references.
Revision ChangesPath
1.84 +0 -1 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- build.xml 26 Jun 2003 06:41:47 - 1.83
+++ build.xml 26 Jun 2003 07:03:51 - 1.84
@@ -63,7 +63,6 @@
include name=lib/batik.jar/
include name=lib/avalon-framework*.jar/
include name=lib/jimi*/
-include name=lib/jfor*.jar/
/fileset
fileset dir=${basedir} id=dist.src
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RTF] Jfor integration
Bertrand Delacretaz wrote: obviously these are needed - sorry about that, I have added them now. I'm just fixing the licenses now, but the files are there already. No apology needed. Thanks for adding them. I have just committed the changes needed to compile, and have also removed the jfor libs reference (in build.xml) thereto, so I think we're rolling. My approach was simply to comment out code that had unfound dependencies (logging, jpeg, jfor versions), so that we can see what used to be there -- logging jpeg can be added back later. My simple test doc still works. Let me know if you see anything I have missed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Spec drives me crazy: column-count and blocks with mixed spans
From: Arnd Beißner [EMAIL PROTECTED] snip/ Since the default behaviour really seems to be unspecified, and since there's no property to specify it, I believe overall less harm is done if you don't balance at the end of the flow. This is because then you can always trick the renderer into balancing by making the end not the end. Just put an fo:block with invisible content and span=all at the end. Of course, a property for that would be nice, but at least then you can have both. this is how RenderX handle column balancing on the last page. Its off by default and if the user should need it, then they recommend putting an empty block with span=all at the end of the flow as you've suggested. _ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: (Jeremias, Keiron) Re: [VOTE] Move StructureHandler and LayoutHandler classes
Good--that's where it will go then (barring an onslaught of -1's between now and this weekend) BTW, I believe my original rationale for placing in the Area package was by looking at the imports in LayoutHandler--it seemed to be very heavily dependent on the particular implementation of the Area Tree being used. I wasn't focusing on its function/purpose. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Sorry for not being clear. I also meant the layoutmanager package. On 26.06.2003 00:37:25 Glen Mazza wrote: Should LayoutHandler go into the Layout (Jeremias) package or LayoutManager package (Keiron)? (Personally, I don't care--99% for me is getting them out of apps.) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alternative API proposal (was: startup refactoring)
Jeremias Maerki wrote: I have done so now. I've added a new (sub)page to the Wiki to avoid making the FOPAvalonization page even longer. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA PIProposalJM While writing down my thought about the API I have come to the realization that I cannot make up my mind about the inner context classes Victor has come up with. But I think he's quite close: - Session: Looks like my and Jörg's FOProcessor to me. The user interacts with this class to configure FOP and do processing runs. I think your name is fine. I am confused about whether it is an interface (as written) or a class (I don't see any implementations). I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user. Since I don't understand Avalon, I am not sure how factoring it into/out of this affects the API, but if that is needed, it seems like it should be done in an implementation of FOProcessor instead of creating separate Factories. - Document and RenderContext: I'm not sure but I think these two should be merged. I've called it ProcessorContext in my proposal at first, but then chose not to include them in the proposal right now because I didn't quite know what to put in there. The thing I know is that we need a central data object that keeps references while the FOProcessor implementation coordinates the processing (data separated from logic). RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that. I think it is a good idea, and suspect that whatever difficulties have existed in implementing this in the past are probably a result of our current tight coupling between FOTree, layout, AreaTree, and Rendering, which is of course what I am trying to unravel. Your DocumentMetadata class holds information in it that would live in my Document concept. That is information that is common to (but not necessarily used by) by all output media, and does not need to be set for each output media. It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused. - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. In my proposal I've separated the logic from the data again (with JAXP as role-model) and made the Renderer a totally normal Avalon service that is being looked up by MIME type in the background. The FOPResult classes account for the differences of output types. The FOProcessor impl is responsible to establish the link between FOPResults and Renderer. For AWT (I'd like to call it Java2D from now on if you guys agree. That's the official name of the API after all.) I've tried to introduce an interface that clients can use to interact with the Java2D renderer. Your FOPResult is I think roughly equivalent to what I am calling RenderType or Renderer (somewhere along the way, I started calling mine RenderType to make a more clear distinction between it and the workhorse Renderers), and if I understand what you are doing, I think our goals are the same. FOPResult is more of a control class, and the Renderer is a workhorse class. So, I don't have anything more concrete on the inner glue that keeps the whole process together but maybe my proposal brings some new ideas. I'd like to hear your thoughts about my proposal (flaws, nodding, missing things etc.). I hope that we can find a common path for the whole thing. Important to me is to have a good terminology and an API that conforms to the requirements I've written down on the FOPAvalonization page. Here are the issues that I am still uncomfortable with: 1. complexity. In addition to the Factory issue already mentioned, I think there is some benefit to arranging the data more intuitively for the user. From the user's standpoint, there is input and output (ie. 2 classes). It makes sense to have a third (Session/FOProcessor) primarily to facilitate reuse. IMO, if the user has to interact with more than 3 classes to get the work done, we are unnecessarily complex. (My 4th class, RenderContext, is not exposed to the user). 2. reuse. I see no downside to arranging our objects to allow reuse, even if we decide we don't want to facilitate it. This doesn't directly affect the API (we can have 15 or 50 classes supporting those exposed to the user). Sorry to be so slow responding. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs commit: xml-fop checkstyle1.3.0-head
Peter B. West wrote: pbwest 2003/06/25 10:01:01 Removed: .checkstyle1.3.0-head Log: Name changed to checkstyle3.1.1-head Thanks for all of your efforts here. Is this file reliable, or is it a work in progress? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Victor Mote wrote: J.Pietschmann wrote: Could you outline your API ideas on the Wiki? Sure (give me a couple of days). Again, my point is not to push for a particular API or framework, but only to show that the control concepts (PDF encryption was the example given IIRC) can be added to the appropriate classes as needed. OK, I have clarified some items and added some (informal) API information to the main API wiki, toward the bottom of the Startup Concepts Proposal section: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal (was: startup refactoring)
On 26.06.2003 18:40:58 Victor Mote wrote: Jeremias Maerki wrote: I have done so now. I've added a new (sub)page to the Wiki to avoid making the FOPAvalonization page even longer. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA PIProposalJM While writing down my thought about the API I have come to the realization that I cannot make up my mind about the inner context classes Victor has come up with. But I think he's quite close: - Session: Looks like my and Jörg's FOProcessor to me. The user interacts with this class to configure FOP and do processing runs. I think your name is fine. I am confused about whether it is an interface (as written) or a class (I don't see any implementations). It's an API. You don't necessarily see implementing classes in the specification. Compare to JAXP. Theoretically, RenderX could implement the same API and we would have a common API for XSL-FO processing. It would even be interesting to do an implementation of that API based on the maintenance branch. It would probably not support all the features but JAXP implementations also don't do that always. I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user. Since I don't understand Avalon, I am not sure how factoring it into/out of this affects the API, but if that is needed, it seems like it should be done in an implementation of FOProcessor instead of creating separate Factories. It's not an Avalon-specific reason why I specified the factory. For one, it's almost the same as in JAXP (The whole API is, BTW). The distinction between FOProcessorFactory and FOProcessor is the following: FOProcessorFactory has a configuration (where do the fonts come from, what's the caching strategy etc.etc.). You will want to have one such object per environment where FOP is used. FOProcessor could be argued to be superfluous if it weren't for the add/removeEventListener methods which allow you to register a listener to get events on a particular processing run (start page-sequence, new page, content clipped, end page-sequence, this kind of things). I haven't come up with more, yet, but I can imagine that this class could get additional methods later. Basically you distiguish the basic environment from the processor run. You wouldn't want to reload all the configuration stuff each time you want to run FOP. A nice side-effect is the AvalonFOProcessorFactory that should fit nicely as an component for use in Avalon-enabled system (mainly Cocoon). - Document and RenderContext: I'm not sure but I think these two should be merged. I've called it ProcessorContext in my proposal at first, but then chose not to include them in the proposal right now because I didn't quite know what to put in there. The thing I know is that we need a central data object that keeps references while the FOProcessor implementation coordinates the processing (data separated from logic). RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that. From the first discussion we had I got the impression that it's not worth the pains right now. In the worst case you simply hold the stuff from RenderContext in the ProcessorContext. I think it is a good idea, and suspect that whatever difficulties have existed in implementing this in the past are probably a result of our current tight coupling between FOTree, layout, AreaTree, and Rendering, which is of course what I am trying to unravel. Your DocumentMetadata class holds information in it that would live in my Document concept. That is information that is common to (but not necessarily used by) by all output media, and does not need to be set for each output media. It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused. Of course, it can be reused. Nothing prevents you from passing in the same DocumentMetadata into the FOPResult. But nobody will want to do that anyway because metadata like title will probably change with each document being processed. I think we don't talk about the same thing. As I said before, what I'm trying to do is separate the inner workings from the API as well as possible. Things from FOPResult (including the metadata) will probably be placed in the RenderContext so you'll have access to it if necessary. I see DocumentMetadata only as a pass-through thing to the Renderer. - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. In my proposal I've separated the logic from the data again (with JAXP as role-model) and made the Renderer a totally normal Avalon service that is being looked up by MIME type in the background. The
RE: Alternative API proposal (was: startup refactoring)
Jeremias Maerki wrote: I think your name is fine. I am confused about whether it is an interface (as written) or a class (I don't see any implementations). It's an API. You don't necessarily see implementing classes in the specification. Compare to JAXP. Theoretically, RenderX could implement the same API and we would have a common API for XSL-FO processing. It would even be interesting to do an implementation of that API based on the maintenance branch. It would probably not support all the features but JAXP implementations also don't do that always. Well, its a whole lot more than an API and there are some implementing classes in your spec. However, thanks for clarifying. I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user. Since I don't understand Avalon, I am not sure how factoring it into/out of this affects the API, but if that is needed, it seems like it should be done in an implementation of FOProcessor instead of creating separate Factories. It's not an Avalon-specific reason why I specified the factory. For one, it's almost the same as in JAXP (The whole API is, BTW). The distinction between FOProcessorFactory and FOProcessor is the following: FOProcessorFactory has a configuration (where do the fonts come from, what's the caching strategy etc.etc.). You will want to have one such object per environment where FOP is used. FOProcessor could be argued to be superfluous if it weren't for the add/removeEventListener methods which allow you to register a listener to get events on a particular processing run (start page-sequence, new page, content clipped, end page-sequence, this kind of things). I haven't come up with more, yet, but I can imagine that this class could get additional methods later. Basically you distiguish the basic environment from the processor run. You wouldn't want to reload all the configuration stuff each time you want to run FOP. OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor is roughly equivalent to Document (I don't care about the terminology, I'm just trying to find where we thinking the same and where we are not). RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that. From the first discussion we had I got the impression that it's not worth the pains right now. In the worst case you simply hold the stuff from RenderContext in the ProcessorContext. OK. Since it doesn't affect the API, we can always add it back later if needed. I think it is a good idea, and suspect that whatever difficulties have existed in implementing this in the past are probably a result of our current tight coupling between FOTree, layout, AreaTree, and Rendering, which is of course what I am trying to unravel. Your DocumentMetadata class holds information in it that would live in my Document concept. That is information that is common to (but not necessarily used by) by all output media, and does not need to be set for each output media. It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused. Of course, it can be reused. Nothing prevents you from passing in the same DocumentMetadata into the FOPResult. But nobody will want to do that anyway because metadata like title will probably change with each document being processed. I think we don't talk about the same thing. That is not reuse. The metadata example is a trivial one. A Collection of Fonts used and Fonts to be embedded would be a more important one. However, I don't care. You are correct that we aren't talking about the same thing. As I said before, what I'm trying to do is separate the inner workings from the API as well as possible. Things from FOPResult (including the metadata) will probably be placed in the RenderContext so you'll have access to it if necessary. I see DocumentMetadata only as a pass-through thing to the Renderer. - Renderer: You guys hate me for that, I know, but I still refuse to give it so much visibility in these discussions. In my proposal I've separated the logic from the data again (with JAXP as role-model) and made the Renderer a totally normal Avalon service that is being looked up by MIME type in the background. The FOPResult classes account for the differences of output types. The FOProcessor impl is responsible to establish the link between FOPResults and Renderer. For AWT (I'd like to call it Java2D from now on if you guys agree. That's the official name of the API after all.) I've tried to introduce an interface that clients can use to interact with the Java2D renderer. Your FOPResult is I think roughly equivalent to what I am
Re: Alternative API proposal (was: startup refactoring)
On 26.06.2003 20:13:06 Victor Mote wrote: Well, its a whole lot more than an API and there are some implementing classes in your spec. However, thanks for clarifying. Only two classes (DefaultFOProcessorFactory and AvalonFOProcessorFactory) to show how the two world can be made more or less compatible. OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor is roughly equivalent to Document (I don't care about the terminology, I'm just trying to find where we thinking the same and where we are not). I guess so. Of course, it can be reused. Nothing prevents you from passing in the same DocumentMetadata into the FOPResult. But nobody will want to do that anyway because metadata like title will probably change with each document being processed. I think we don't talk about the same thing. That is not reuse. The metadata example is a trivial one. A Collection of Fonts used and Fonts to be embedded would be a more important one. However, I don't care. You are correct that we aren't talking about the same thing. Then you mean reuse in the context of producing multiple output formats in one renderung run? Right. but I think RenderType is not the right name for this because it only suggests to be information about which renderer is to be used. It omits all the nice parameters you want to pass over. I don't understand your last statement, but I agree that FOPResult is a better name than RenderType. Let's try different wording: The name RenderType suggests that it is a enumeration or a parameter, but it's more than that. Hmmm. The whole thing seems pretty heavyweight to me (at least compared to my proposal). Since my real interest is Control and not API, I think the most productive thing for me to do is to simply defer on the API issues to those of you who care more about them. As long as we can build whatever Control infrastructure under that API that we want to (and it looks like we can), and if you guys are happy with the API, we can defer that part of the discussion until another day. It may very well be that when I see how your vision is implemented, I will find the Control structures that (I think) I need and that we are done anyway. I think we're getting in the right direction. I think, my API proposal would enable a stable API and you can concentrate on what's necessary to do inside FOP to handle the whole processing. You can even experiment over time, changing the inner glue without changing the API. And a stable and flexible API is one of the most important things to me. We changed the Driver class too many times. Hopefully, my proposal could improve this. Just trying to decouple... But I disagree with the heavyweight thing. It's only the most necessary things well separated by topic. Expand on your proposal to enable all the functionality my proposal covers. I wonder how lightweight yours stays. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal (was: startup refactoring)
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I don't understand your last statement, but I agree that FOPResult is a better name than RenderType. Let's try different wording: The name RenderType suggests that it is a enumeration or a parameter, but it's more than that. Errr...I may not understand everything here, but aren't our inputs *just*: 1) xsl-fo stream (file, DOM Document, or inputStream) 2) render type (*is* either an enumeration directly, or could be represented as such--PDF, PS, etc.) Shouldn't we be leery of render options where one specifies properties of how the output should look outside of what is specified by the XSL-FO file? (If there are output properties that cannot be specified sufficiently by XSL-FO 1.0, well, that's what FOP extensions or XSL-FO 2.0 would be for, correct?) Just curious what others are thinking here. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal (was: startup refactoring)
Victor Mote wrote: I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user. It has something to do with the GoF Factory pattern. This means you can choose the implementation of the FOProcessorAPI by setting a Java property, or some similar mechanism at run time instead of choosing it at compile time. Granted, this seems of not much use given that FOP will be the only implementation at least for some time. There is another aspect: the FOProcessorFactory holds a default configuration and is a mechanism to quickly create preconfigured FOProcessor objects. You just can't use a single FOProcessor, because it holds a state while rendering and is therefore not MT safe in itself. Unless you can live with blocked threads this means you have to create a FOProcessor for every thread. Furthermore you might want to keep FOProcessor objects some time around after rendering has finished in order to inquire the number of rendered pages or whatever useful data the processor can supply then. RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that. I think we have a few slightly more pressing problems: - getting layout up to conformance - make FOP MT safe - improving the API to ease embedding (including Java2D embedding) - improve performance and reduce memory consumption Adding multiple output streams is certainly fun but I suspect the bulk of the current users would be more interested in one of the points above. And somehow I have the feeling that your approach could easily get in the way, in particular I wouldn't like if it would *increase* memory usage in general. It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused. Why can't it be reused? 1. complexity. In addition to the Factory issue already mentioned, I think there is some benefit to arranging the data more intuitively for the user. Users should be able to recognize certain patterns, like the ones used in JAXP. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal (was: startup refactoring)
Glen Mazza wrote: Shouldn't we be leery of render options where one specifies properties of how the output should look outside of what is specified by the XSL-FO file? PDF encryption? Printer options? Text encoding? MIF version? (If there are output properties that cannot be specified sufficiently by XSL-FO 1.0, well, that's what FOP extensions or XSL-FO 2.0 would be for, correct?) I don't think the WG will accept output format specific stuff in the FO source. I personally don't think this is a good idea either. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alternative API proposal (was: startup refactoring)
Jeremias Maerki wrote: That is not reuse. The metadata example is a trivial one. A Collection of Fonts used and Fonts to be embedded would be a more important one. However, I don't care. You are correct that we aren't talking about the same thing. Then you mean reuse in the context of producing multiple output formats in one renderung run? Yes. Even if we think we don't want that now, we should have the flexibility to add it later. Hmmm. The whole thing seems pretty heavyweight to me (at least compared to my proposal). Since my real interest is Control and not API, I think the most productive thing for me to do is to simply defer on the API issues to those of you who care more about them. As long as we can build whatever Control infrastructure under that API that we want to (and it looks like we can), and if you guys are happy with the API, we can defer that part of the discussion until another day. It may very well be that when I see how your vision is implemented, I will find the Control structures that (I think) I need and that we are done anyway. I think we're getting in the right direction. I think, my API proposal would enable a stable API and you can concentrate on what's necessary to do inside FOP to handle the whole processing. You can even experiment over time, changing the inner glue without changing the API. And a stable and flexible API is one of the most important things to me. We changed the Driver class too many times. Hopefully, my proposal could improve this. Just trying to decouple... I suspect that the reason the Driver class had to change so often is that it was doing duty for three different hierarchical concepts by my count. As long as we have all three of them accounted for with your proposal, I'm OK with it (although see one afterthought see below). But I disagree with the heavyweight thing. It's only the most necessary things well separated by topic. Expand on your proposal to enable all the functionality my proposal covers. I wonder how lightweight yours stays. Except for Avalonization (which I admit I don't understand, but which I understood not to be a factor here), I don't see what functionality your model provides over mine. On the Avalonization issue, I guess the easy way to get to the heart of the matter is to simply ask whether Avalonization can be implemented with the model I have proposed or not. I did have one afterthought that I think I should mention. The JAXP thing caught me a bit off-guard, and I only just now sorted out in my mind why. I don't use these tools often enough or in enough detail to keep this fresh in my mind (but I think I have the concepts straight), so please correct me if I am wrong. If I want to use Xalan, for example, I could use a Xalan interface, or I could use a Xalan implementation of the JAXP interface. You mentioned in an earlier posting that the functionality between the two didn't necessarily need to match up. This implies (and makes sense when you think about interfaces) that it is a lowest-common-denominator. There may be times when, to get the full richness of an implementation, you have to use things that are specific to it because the higher-level interface couldn't and shouldn't force all implementations to implement that feature. FOP and RenderX might (and probably already have) evolve(d) to meet different use-cases. So it makes sense to me to use a simple lightweight API for FOP (if possible), and if we want to build an industry-standard API like that which you have proposed, that it be done in a separate project or at least package, and probably be done in concurrence with the other implementors. That would be my preference, but I do not feel strongly enough about it to do much more than mention it. I think this distinction probably also explains the different wavelengths that we seem to be on. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alternative API proposal (was: startup refactoring)
OK, thanks for the enlightenment. --- J.Pietschmann [EMAIL PROTECTED] wrote: Glen Mazza wrote: Shouldn't we be leery of render options where one specifies properties of how the output should look outside of what is specified by the XSL-FO file? PDF encryption? Printer options? Text encoding? MIF version? (If there are output properties that cannot be specified sufficiently by XSL-FO 1.0, well, that's what FOP extensions or XSL-FO 2.0 would be for, correct?) I don't think the WG will accept output format specific stuff in the FO source. I personally don't think this is a good idea either. J.Pietschmann __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alternative API proposal (was: startup refactoring)
J.Pietschmann wrote: Victor Mote wrote: I guess I don't understand the need for FOProcessorFactory, which seems to be an unnecessary complication for the user. It has something to do with the GoF Factory pattern. This means you can choose the implementation of the FOProcessorAPI by setting a Java property, or some similar mechanism at run time instead of choosing it at compile time. Granted, this seems of not much use given that FOP will be the only Hmmm. I missed that in the goals section. implementation at least for some time. There is another aspect: the FOProcessorFactory holds a default configuration and is a mechanism to quickly create preconfigured FOProcessor objects. You just can't use a single FOProcessor, because it holds a state while rendering and is therefore not MT safe in itself. Unless you can live with blocked threads this means you have to create a FOProcessor for every thread. Furthermore This aspect of it could/should be entirely hidden from the user. IOW, I wouldn't make the API more complex just to achieve this. Also, the alternative to sharing shareable data and blocking thread access it to duplicate the data and the processing of it. I'll certainly leave that issue to you performance gurus. you might want to keep FOProcessor objects some time around after rendering has finished in order to inquire the number of rendered pages or whatever useful data the processor can supply then. RenderContext is only useful if you are trying to reuse an AreaTree for multiple output options. I am frankly confused right now about whether the dev team even wants to try to do that. I think we have a few slightly more pressing problems: - getting layout up to conformance - make FOP MT safe - improving the API to ease embedding (including Java2D embedding) - improve performance and reduce memory consumption I am not trying to implement multiple output options, but merely to make sure we have the flexibility to do so. And frankly, I don't care if it ever gets implemented. What *is* important, but on which I seem not to be making any progress in explaining, is that each of the major processing tasks in FOP should have a high-level controlling class that is responsible for it. I see all four of the items you mention as being dependent on that. Adding multiple output streams is certainly fun but I suspect the bulk of the current users would be more interested in one of the points above. And somehow I have the feeling that your approach could easily get in the way, in particular I wouldn't like if it would *increase* memory usage in general. I agree with your first statement. On the second, I wouldn't like Jeremias's proposal either if it caused a nuclear holocaust :-). I don't see why you would suggest that my proposal would use more memory. I am quite sure it would use less, but not enough to even mention. It looks like you are pushing the data that I envisioned in Document and RenderContext down to RenderType/FOPResult. The net effect is that it can't be reused. Why can't it be reused? See answer in my response to Jeremias (which crossed your inquiry in the mail). 1. complexity. In addition to the Factory issue already mentioned, I think there is some benefit to arranging the data more intuitively for the user. Users should be able to recognize certain patterns, like the ones used in JAXP. Well, I don't think anyone is ever going to want to put a GUI on top of Xalan, but I'll bet it will happen with FOP. The use case for FOP as it is right now is fairly analagous to JAXP, i.e. a non-interactive process, but I don't expect that to stay the same. Also, see my response to Jeremias about the JAXP issue (also crossed in the mail). I'm not opposed to that pattern, I'm just not sure it makes sense as our API. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: Alternative API proposal (was: startup refactoring)
J.Pietschmann wrote I think we have a few slightly more pressing problems: - improving the API to ease embedding (including Java2D embedding) What has to be embedded? Adding multiple output streams is certainly fun but I suspect the bulk of the current users would be more interested in one of the points above. And somehow I have the feeling that your approach could easily get in the way, in particular I wouldn't like if it would *increase* memory usage in general. Multiple output streams are here with FOP 0.x.x The AWT viewer uses the area tree as page cache and it's print function again. I'm experimenting with a new Graphics2D renderer. The attached description gives some hints to configuration/parametrization requirements. Directions, orientations, i18n will be the next topics. All I know at the time is that present renderers need heavy upgrades. Hansuli Anderegg Title: JPS Renderer/Viewer FOP Renderer/Viewer based on Java Printing System, Graphics2D Project: JPS Renderer/Viewer Author: J.U. Anderegg E-Mail: [EMAIL PROTECTED] The Java Printing System enables applications to: Print Java 2D graphics, text and images. Control document-composition functions such as soft collating, reverse order printing, and booklet printing. Invoke printer-specific functions such as duplex (two-sided) printing and stapling. Print on all platforms, including Windows and Solaris. Data stream generation by platform printer drivers. Highlights Silent/interactive operation (page/printer/file dialogs) Output to printer or file Supported printers, data streams: PCL, AFP, Postscript, Text, PDF (PDFWriter required) Accurate output control by setting page/printer properties of drivers Several renderings per run Image Formats: JPEG, PNG, GIF (with JAI Image I/O Tools 1.0-rc also BMP, TIFF) SVG Support Embed HTML, RTF and TXT documents Orientation switch portrait/landscape within document Controls per print job Destination file Media sizes, bins, trays Page orientation Sides: simplex/duplex handling Print quality Chromaticity: color/monochrom Copies Finishings NumberUp, Imposition Environment Tested with Win2K, FOP 0.20.5rc2, Java 1.4.2, JAI Image I/O Tools 1.0-rc, Batik-1.5 Compatibility Images are handled by Image I/O, FOP's image handling is overridden. Installation install FOP, Java 1.4, Batik-1.5 and optionally JAI Image I/O Tools copy file FOPjps.zip to disk install printers select national language versions so that font names match set properties according to your needs edit renderer configuration file see description below sample: rendercfg00.txt edit printer configuration files copy the printer names correctly from your list of printers lookup attribute codes in Java source Print2DAttr.java see description below samples: prtcfgxx.txt platform fonts other than "Helvetica", "Times", "Courier", "serif", "sans-serif", "monospace": generate font metrics modify the FOP user configuration run procedure replace path names with your path names set the national language option for your JVM so that font names match sample: execSingle.bat, execMulti.bat program: org.apache.fop.render.jps.Run2D Use URL's: e.g. file:///C:... arguments argument 0: user configuration file 'single file formatting' or 'batch formatting' single file formatting preview: interactive mode argument 1: xsl-fo input file argument 2: renderer configuration file argument 3: 'view' - viewer is launched silent mode arguments 3, 4, ...: An arguments for each output. Tokens are separated by commas. token 0: printer configuration file optional token 1: [,destination = print file] multiple FO files formatting argument 1: 'controlfile', URL URL: file containing lines same as 'formatting a single FO file' above Renderer Configuration Files // in colunm 1-2 comment debugdisplay platform printer and font info, trace processing SVGimageResolution=resolutionresolution: requested image resolution adjustPrinterResolutionIf specified, the lowest resolution from (1200, 600, 300, 150, 72) fitting into the area is selected. Otherwise the image is scaled to fit the area. HelveticaMap=Arial TimesMap=Times New Roman CourierMap=Courier New SymbolMap=Symbol ZapfDingbatsMap=ZapfDingbats Font maps, substitution for standard fonts. This applies also to sans-serif --> Helvetica serif --> Times monospace --> Courier Printer Configuration Files // in colunm 1-2comment copies=nn: numbers of copies printer=printerNameprinterName: printer name, your platform knows attributes=n1 n2 n3 n.: attribute code as specified in Java source Print2DAttr.java Embedding RTF, HTML and TXT Documents HTML 3.2 is supported. RTF about at the level of WordPad. Additional pages are inserted: specify block break-before="page" Document specification: external-graphic src=""SVGimageResolution". The viewbox is scaled proportionally. SVG instream-foreign-objects need the width and height attributes.
Re: Spec drives me crazy: column-count and blocks with mixed spans
Arnd Beißner wrote: Peter, thanks for the answer. I have always *assumed* that column balancing is implied whenever top-level block children of a flow have different span attributes, because it's the only approach that makes sense. If your second scenario were intended, then the 'span=all' block could not share the page with the previous 'span=none' blocks unless there were less than one column's worth of text. I.e. Yes, that sure makes sense, but it's not really anywhere in the spec, is it? You can still argue the spec makes sense without column balancing - at least you can use span=all blocks before span=none blocks. No, it's not specified that I can see. However, the restriction above would be highly artificial. That leaves open the question of whether, on the last page of a page-sequence, the columns should be balanced. My intuitive approach would be to balance always. However, there seems to be another attribute required for column spill behaviour, especially for the last page of a page-sequence. I assume you really mean the end of the flow (or page-sequence) here, right? Yes. There's only one flow per page-sequence. last page could also be something like: ABC DDD DDD or even ABC DDD EFG Personally, I'd prefer no balancing for the end of the flow. Reason: For columns that contain mostly text, that looks awfully strange if you can't have at least 2 paragraphs in each column. Since the default behaviour really seems to be unspecified, and since there's no property to specify it, I believe overall less harm is done if you don't balance at the end of the flow. This is because then you can always trick the renderer into balancing by making the end not the end. Just put an fo:block with invisible content and span=all at the end. Of course, a property for that would be nice, but at least then you can have both. How about that? Very sensible. I had in mind my preferred method of dynamic balancing, but even with that model, it is simple enough to undo the balancing on the last page of a sequence. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop checkstyle1.3.0-head
Victor, Definitely a w.i.p. It throws up too many exceptions at the moment, and needs to be pruned back by those with a better grasp of the style requirements. Btw, are you using JBuilder with FOP? If so, could you add some notes to the IDE Wiki when you get some spare time? Peter Victor Mote wrote: Peter B. West wrote: pbwest 2003/06/25 10:01:01 Removed: .checkstyle1.3.0-head Log: Name changed to checkstyle3.1.1-head Thanks for all of your efforts here. Is this file reliable, or is it a work in progress? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
pietsch 2003/06/26 17:16:28 Modified:src/java/org/apache/fop/fo/pagination Root.java Log: Test commit from Eclipse: removed unused import. Revision ChangesPath 1.3 +3 -5 xml-fop/src/java/org/apache/fop/fo/pagination/Root.java Index: Root.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/Root.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Root.java 25 Mar 2003 23:34:11 - 1.2 +++ Root.java 27 Jun 2003 00:16:28 - 1.3 @@ -51,12 +51,10 @@ package org.apache.fop.fo.pagination; // FOP -import org.apache.fop.fo.FObj; -import org.apache.fop.fo.FONode; -import org.apache.fop.fo.FOText; - -// Java import java.util.List; + +import org.apache.fop.fo.FONode; +import org.apache.fop.fo.FObj; /** * The fo:root formatting object. Contains page masters, page-sequences. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
lib/jimi in distribution
Devs, I just noticed include name=lib/jimi*/ in the dist.bin.lib fileset of build.xml in HEAD. Is that supposed to be there? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alternative API proposal (was: startup refactoring)
J.Pietschmann wrote: Victor Mote wrote: I don't see why you would suggest that my proposal would use more memory. I am quite sure it would use less, but not enough to even mention. Well, your approach to decoupling layout and rendering seems to include building a full area tree, or something equivalent. FOP was implemented this way before 0.20.1. What you might see as tight coupling is the result of improving the situation. I have been misunderstood somewhere. There may be times when building a full area tree (and writing to disk if necessary) is appropriate, esp. if it were going to be reused. That is a dead issue. If the area tree is only used once, then PageSequence is the largest chunk that might need to be built, and then only if patient processing is used. I do not intend to force anyone to do anything different than is now done in terms of how memory is managed, or even the general flow of the processing. What I am asking for is that control of those decisions be made at a higher level, which keeps the code modular and gives us more options. I don't want layout starting the process of rendering a page, but rather to notify the control mechanism that a page is ready, and letting the control mechanism decide whether to cache it, render it, whether that should be done in a separate thread, etc. IOW the performance smarts are in the high-level control objects. I'm sorry if that was not clear before. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
