Re: [XML Graphics - FOP Wiki] New: FopAndJava2D
fop-cvs@xml.apache.org wrote: Date: 2005-02-22T11:07:06 Editor: 81.221.184.65 Wiki: XML Graphics - FOP Wiki Page: FopAndJava2D URL: http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D Documenting the Java2D proposal New Page: = Apache FOP and the Java2D API = This page describes FOP's design around the Java2D API. === PDF, PS etc. through Java2D === The above PrintRenderer can also be used to create PDFs or PostScript files by printing through JPS. The Graphics2D subclasses PDFDocumentGraphics2D and PSDocumentGraphics2D can indirectly be used for that purpose by writing a JPS StreamPrintService. ''(BTW this is the approach Peter West intends to take with his Defoe)'' Name change. The project is now called Folio, although SourceForge hasn't caught up with that yet. Repository now bkbits.net (BitKeeper). bk clone http://folio.bkbits.net/Folio Peter -- Peter B. West http://cv.pbw.id.au/ Project Folio http://defoe.sourceforge.net/folio/
Re: Renaming the AWT Renderer to Java2D Renderer
Glen, We can do it this way. But on second thought, I think it would be better for Renaud to move it in as AWTRenderer, and slowly start factoring out more and more while things are getting settled. BTW, this will take some time to do anyway--it isn't easy because the renderers are so different between 0.20.5 and 1.0. That's what I'm doing now. And yes, it might take some time... [A note for Renaud: I would recommend cutting down on the chatroom English and instead start writing properly/respectfully to us, in the same manner that all of us have been writing to you. Capitalize I, the first word of each sentence, your name, our names[1], greetings, etc. Above all, when people write to you in standard polite English, you shouldn't be responding back with chatroom writing. None of us here do. Thanks!] Glen [1] http://marc.theaimsgroup.com/?l=fop-devm=110625230922690w=2 Your note sounded hard to me. My apologies to you and the other members of the team. In the future i'll use standard English. Please do not take my writing style as a sign of misrespect, as this was NOT my intention. This style is pretty well accepted in Switzerland (in German, we have to capitalize all Words, so this saves a lot of Typing) and i find it personally nicer. If you have other objects like [1] in your stack, please let me know it now (via this maillist or directly to me). As I said in [2], I am pretty new to open-source developpment, so please let me know if i'm doing things the right way. I'm enjoying this project and would like to move forward smoothly (and respectfully of the other members of this team). Regards, Renaud [2] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2080086
RE: Renaming the AWT Renderer to Java2D Renderer
Renaud Richardet wrote: Your note sounded hard to me. My apologies to you and the other members of the team. In the future i'll use standard English. Please do not take my writing style as a sign of misrespect, as this was NOT my intention. This style is pretty well accepted in Switzerland (in German, we have to capitalize all Words, so this saves a lot of Typing) and i find it personally nicer. I doubt that anyone, including Glen, was offended by your style. You did nothing wrong, nothing worthy of a public censure. I will resist the strong temptation to flame the antagonist and simply say that politics are at work as much in open source projects as they are anywhere else. I hope you will not be offended either by what passes for leadership in FOP, or the awkward silence from the rest of the team. Your efforts are appreciated, and I doubt that I am the only subscriber to this list who was embarrassed by the rudeness with which you were treated here. Victor Mote
Re: Renaming the AWT Renderer to Java2D Renderer
On Feb 23, 2005, at 7:28 AM, Victor Mote wrote: Renaud Richardet wrote: Your note sounded hard to me. My apologies to you and the other members of the team. In the future i'll use standard English. Please do not take my writing style as a sign of misrespect, as this was NOT my intention. This style is pretty well accepted in Switzerland (in German, we have to capitalize all Words, so this saves a lot of Typing) and i find it personally nicer. I doubt that anyone, including Glen, was offended by your style. You did nothing wrong, nothing worthy of a public censure. I will resist the strong temptation to flame the antagonist and simply say that politics are at work as much in open source projects as they are anywhere else. I hope you will not be offended either by what passes for leadership in FOP, or the awkward silence from the rest of the team. Your efforts are appreciated, and I doubt that I am the only subscriber to this list who was embarrassed by the rudeness with which you were treated here. Victor Mote Thanks for voicing up Victor... I'd intended to write a private note to Renaud showing the same conviction, but under the ciircumstances, I suspect a public note is more appropriate. Victor, I am grateful for your continued attention to all things FOP... Renaud, I was not offended by your 'tone' of voice. I did take notice of your writing style, but I was not offended. I suspected your tone was one of camaraderie rather than disrespect. I figured at some point you would've modified your writing style to be similar to how others write, but it wasn't a big enough issue to me to send you an e-mail. Just the same, if I had made a comment, it would've been a private note. Glen, I also very much value your contributions to the FOP and XML Graphics community. I sincerely hope that in the future you will show some restraint in your communications style. You come off as gruff occasionally, but you are also a very valued member of the FOP community (in my opinion). One thing I know for certain, is that it would be great if we could all get together for a beer (root beer or ginger ale is acceptable for those trying to cut down!) Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
Jeremias,
This should not be done. If someone has a problem
with it--and I've never heard a complaint--they can
send an email to xsl-editors, for them to adjust the
content model for fo:table accordingly. (If they
don't, they don't.)
Note that the editors are very reasonable about
this--for example, fo:page-sequence-wrapper and
fo:wrapper are allowed to have no children for
programmatic convenience, even though it doesn't make
sense for these items to be empty.
BTW, what is FONode.removeChild() for anyway? Why is
this helpful--we haven't needed such a method for
years.
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
jeremias2005/02/23 14:04:01
Modified:src/java/org/apache/fop/fo FObj.java
FONode.java
src/java/org/apache/fop/fo/flow
TableBody.java
Log:
An empty table-body is illegal but we'll allow it
to make things easier for stylesheet writers.
Empty table-body elements are removed from their
parent so they can't cause any nasty effects in the
LMs.
Revision ChangesPath
1.92 +7 -0
xml-fop/src/java/org/apache/fop/fo/FObj.java
Index: FObj.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FObj.java,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- FObj.java 3 Feb 2005 08:18:27 - 1.91
+++ FObj.java 23 Feb 2005 22:04:01 - 1.92
@@ -170,6 +170,13 @@
}
}
+/** @see
org.apache.fop.fo.FONode#removeChild(org.apache.fop.fo.FONode)
*/
+public void removeChild(FONode child) {
+if (childNodes != null) {
+childNodes.remove(child);
+}
+}
+
/**
* Find the nearest parent, grandparent, etc.
FONode that is also an FObj
* @return FObj the nearest ancestor FONode
that is an FObj
1.54 +10 -0
xml-fop/src/java/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- FONode.java 1 Feb 2005 21:21:28 - 1.53
+++ FONode.java 23 Feb 2005 22:04:01 - 1.54
@@ -198,6 +198,15 @@
}
/**
+ * Removes a child node. Used by the child
nodes to remove themselves, for
+ * example table-body if it has no children.
+ * @param child child node to be removed
+ */
+public void removeChild(FONode child) {
+//nop
+}
+
+/**
* @return the parent node of this node
*/
public FONode getParent() {
@@ -410,5 +419,6 @@
public int getNameId() {
return Constants.FO_UNKNOWN_NODE;
}
+
}
1.38 +8 -1
xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java
Index: TableBody.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- TableBody.java 21 Feb 2005 21:52:14 - 1.37
+++ TableBody.java 23 Feb 2005 22:04:01 - 1.38
@@ -88,6 +88,11 @@
*/
protected void endOfNode() throws
FOPException {
getFOEventHandler().endBody(this);
+if (childNodes == null ||
childNodes.size() == 0) {
+getLogger().error(fo:table-body must
not be empty.
++ Expected:
(table-row+|table-cell+));
+getParent().removeChild(this);
+}
convertCellsToRows();
}
@@ -98,7 +103,9 @@
*/
private void convertCellsToRows() throws
FOPException {
try {
-if (childNodes.size() == 0 ||
childNodes.get(0) instanceof TableRow) {
+if (childNodes == null
+|| childNodes.size() == 0
+|| childNodes.get(0)
instanceof TableRow) {
return;
}
//getLogger().debug(Converting cells
to rows...);
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: Renaming the AWT Renderer to Java2D Renderer
--- The Web Maestro [EMAIL PROTECTED] wrote: One thing I know for certain, is that it would be great if we could all get together for a beer (root beer or ginger ale is acceptable for those trying to cut down!) I know...sad thing is, you're the closest committer to me and California is thousands of miles away! (We can meet halfway though...perhaps Pittsburgh would be good... ;) Glen
Re: Renaming the AWT Renderer to Java2D Renderer
On Feb 23, 2005, at 3:51 PM, Glen Mazza wrote: I know...sad thing is, you're the closest committer to me and California is thousands of miles away! (We can meet halfway though...perhaps Pittsburgh would be good... ;) Glen With my luck, we'd still be on opposite sides of the continent! Would that be Pittsburgh, CA or Pittsburgh, PA? Actually, I'll be in Park City, UT this weekend and next (flying back to CA to work in between!). Don't worry, though, I'll think of FOP while I'm drinking! But I will try to keep away from my keyboard and mouse when there's a beer in the other hand! Wouldn't want to accidentally commit anything! ;-) Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
--- Glen Mazza [EMAIL PROTECTED] wrote: Jeremias, This should not be done. If someone has a problem with it--and I've never heard a complaint--they can send an email to xsl-editors, for them to adjust the content model for fo:table accordingly. (If they don't, they don't.) To elaborate, I also frequently have problems with certain content models, but what I do is send requests to the xsl-editors list[1] when I have them (for example, [2, #61], and several others). I think it would be best for you to do that before considering making the change with FOP. It may also encourage others to endorse your suggestion on the ML. But making the change without informing the W3C of what you see as an error doesn't help improve the standard. Also, IMO we should be encouraging unhappy users to register their complaints with the W3C so that they will indeed make these changes. (10, 15 complaints, they will!) In this way, FOP plays the role of a true reference implementation, with a nice circular, ongoing feedback with the W3C, and all FOP-accepted stylesheets will be guaranteed to work with other processors. We validate also to show newbie users what they are doing wrong. It gives nice correction and feedback to the user, just like compilation errors in Java give feedback to newbie developers. Validation serves a good purpose. [1] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/ [2] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0011.html Note that the editors are very reasonable about this--for example, fo:page-sequence-wrapper and fo:wrapper are allowed to have no children for programmatic convenience, even though it doesn't make sense for these items to be empty. And in #61, you can see I don't like empty fo:page-sequence-wrappers or fo:wrappers either. ;) BTW, what is FONode.removeChild() for anyway? Why is this helpful--we haven't needed such a method for years. Sorry, I was wrong here--we have indeed needed such a method, until about December ([3], emails 9, 7, 6). We used to have addLayoutManager() in the FO's in which the FO would determine whether or not it was empty, and if not, attach itself to a Layout Manager. (Email #9) I kind of preferred this implementation, as it allowed us to keep the internal state of each FO internal, rather than need to expose its internal variables to another object that would subsequently read inside it to make the empty-or-not determination for the FO. Simon moved us away from that (Email #7 of [3]) because he didn't want the FO's to have knowledge of layout managers, and wanted to move us from (1) having the FO decide whether or not to attach itself to a LM to (2) having a layout manager decide whether or not to process an empty FO. This is not my preferred implementation, but it seems an acceptable interpretation. But your removeNode() function seems to be bouncing back to the original implementation now: let the FO decide. Can we make a decision and settle on one or the other here? Do we really have to do both? Also, my main problem with Simon's implementation, was that (as mentioned above) the FO's needed to expose their internal state more to the LayoutManagerMaker object so the latter could determine if it needed to process that FO. I think Simon saw that a little as well, and what I recommended in Email #6 was that we have an boolean FONode.isEmpty() that the LayoutManagerMakers can read, and if it returns true, to not process the FO. Question: can we use a boolean isEmpty() instead of your removeNode()? We can then much better encapsulate each FO (i.e., instead of having a LMM read variable a, b, and c of an FO to see if it needs processing, it can just check isEmpty()). Sorry for the long post. Thanks, Glen [3] http://marc.theaimsgroup.com/?t=11028610291r=1w=2
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
FOP 0.20.5 ignores an empty table-body, no error message. XEP 4 displays a validation error and continues. AltSoft Xml2PDF does the same. FOP CVS HEAD now does the same. The justifications for both changes are in the commit message. If you prefer a hard exception in the case of an empty table-body then add a flag on the user agent for strict vs. relaxed validation testing. As for removeChild(): Remove that method yourself and try to fix the layout managers. You'll quickly see that my fix is probably the cleanest and quickest solution for fixing the problem if we are to allow empty table-bodies. It removes the trouble maker before it can cause any problems in the layout engine. And: As for suggesting a change in the spec. I don't want that. 1. We have to cope with what we have: XSL 1.0. 2. Empty table-bodies make no sense but it makes life easier for stylesheet writers not to have to work around them. I have nothing more to say about this. I want to spend my time on more productive things now. On 24.02.2005 00:01:05 Glen Mazza wrote: Jeremias, This should not be done. If someone has a problem with it--and I've never heard a complaint--they can send an email to xsl-editors, for them to adjust the content model for fo:table accordingly. (If they don't, they don't.) Note that the editors are very reasonable about this--for example, fo:page-sequence-wrapper and fo:wrapper are allowed to have no children for programmatic convenience, even though it doesn't make sense for these items to be empty. BTW, what is FONode.removeChild() for anyway? Why is this helpful--we haven't needed such a method for years. Jeremias Maerki
