cvs commit: xml-fop/src/java/org/apache/fop/xml SyncedXmlEventsBuffer.java
pbwest 2004/01/18 23:09:19
Modified:src/java/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design
SyncedXmlEventsBuffer.java
Log:
Added pushBack(XmlEvent) to conform with XmlEventSource interface.
Revision ChangesPath
No revision
No revision
1.1.2.5 +12 -2
xml-fop/src/java/org/apache/fop/xml/Attic/SyncedXmlEventsBuffer.java
Index: SyncedXmlEventsBuffer.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/xml/Attic/SyncedXmlEventsBuffer.java,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- SyncedXmlEventsBuffer.java16 Jan 2004 15:32:58 - 1.1.2.4
+++ SyncedXmlEventsBuffer.java19 Jan 2004 07:09:19 - 1.1.2.5
@@ -135,6 +135,16 @@
}
/**
+ * Push back an event into the buffer; generally this will be an
+ * evnet previously obtained by a ttget/tt from the buffer.
+ * This implementation supports a single entry pushback buffer.
+ * @param event to push back
+ */
+public void pushBack (XmlEvent event) {
+super.pushBack(event);
+}
+
+/**
* Get the next event of the given type from the buffer. Discard
* intervening events.
* @param eventType - the ttint/tt event type.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/xml XmlEventSource.java
pbwest 2004/01/18 23:10:54 Modified:src/java/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design XmlEventSource.java Log: Added public void pushBack(XmlEvent) Revision ChangesPath No revision No revision 1.1.2.2 +9 -2 xml-fop/src/java/org/apache/fop/xml/Attic/XmlEventSource.java Index: XmlEventSource.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/xml/Attic/XmlEventSource.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- XmlEventSource.java 16 Jan 2004 15:41:20 - 1.1.2.1 +++ XmlEventSource.java 19 Jan 2004 07:10:54 - 1.1.2.2 @@ -67,6 +67,13 @@ public XmlEvent getEvent() throws FOPException; /** + * Push back an XmlEvent. The next call to codeget()/code will + * retrieve this event. Only one level of pushback is supported. + * @param event to be pushed back + */ +public void pushBack(XmlEvent event); + +/** * @return true if source is exhausted */ public boolean isExhausted(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/xml ArrayXmlEventsBuffer.java
pbwest 2004/01/18 23:12:01 Added: src/java/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design ArrayXmlEventsBuffer.java Log: FIrst cut of fixed, re-usable XmlEvent buffer Revision ChangesPath No revision No revision 1.1.2.1 +185 -0 xml-fop/src/java/org/apache/fop/xml/Attic/ArrayXmlEventsBuffer.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comments on new property maker implementation
[Finn Bock]
You should perhaps also be aware that the values
in a static array gets
assigned to the array one element at a time. So
static int[] a = {
101,102,103,104,105,106,107,108 };
becomes in bytecodes:
Method static {}
0 bipush 8
2 newarray int
4 dup
5 iconst_0
[Glen Mazza]
Hmmm...Are you saying that declaring a static array
isn't much (any?) faster than manually creating one?
I would guess that it is a bit faster than the typical bytecode for
manually created arrays since the above uses 'dup' instead of
'getstatic' or 'aload' to push the array on the stack.
I didn't realize that there is code being run for
static arrays--I would have thought the compiled
bytecode just includes the array internally, and not
the code to create it. (i.e., if you opened the
bytecode you would see an array 101 102 103 104...
sitting someplace.)
Arrays can't be stored in the constant pool so there is no place to put
the data except as bytecode.
http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html#20080
It should perhaps be noted that constant instances of String is not
really stored in the constant pool either. The pool just stores the
utf-8 representation of the string constant, and each literal string is
initialized as a new pool String object based on that (as UTF-16ish).
Isn't that how C works, at least?
I think so, but C has hardware support for code and data segments so C
can make better use of it.
Sigh...I guess I *didn't* know bytecode by heart after
all! ;-)
I didn't bring it up to discourage the use of static initialized arrays.
If it makes sense to put something in a static array we should do so
without concern of compiletime vs. runtime. After all, the
initialization is only performed once per classloader.
regards,
finn
Re: Comments on new property maker implementation
You should perhaps also be aware that the values in a static array gets assigned to the array one element at a time. So [J.Pietschmann] That's an unpleasant surprise. I was always under the impression statically initialized data was stored along with the string constants, like in C. This means a generated perfect has table wouldn't have much of an advantage over, let's say, a simple binary tree loaded with the values in proper order so that the tree becomes automatically balanced (without rotations like rb-trees do). I would guess that doing ~6 string compares to navigate the binary tree (with 148 color keywords) is slower than one string hash, ~1.2 int compares and one string compare. But I haven't measured it, so you might be well be right. Many keyword sets for other properties are much smaller and could perhaps benefit from a more suitable collection type. It would make sense, however, to properly initialitze initial size values for the various hashmaps currently used. Indeed. Rehashing a HashMap is very fast tho, so I wouldn't expect a major speedup, but it all adds up. regards, finn
DO NOT REPLY [Bug 26187] - pdf created is wrong (some text is overwritten)
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=26187. 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=26187 pdf created is wrong (some text is overwritten) --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 09:07 --- can you please attach the fo file to the bug, instead of just pasting the text of the fo file into the bug report. Text in the bug report gets word wrapped and consequently the xml is garbled.
DO NOT REPLY [Bug 26187] - pdf created is wrong (some text is overwritten)
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=26187. 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=26187 pdf created is wrong (some text is overwritten) --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 12:43 --- Its a bug in the PDF renderer. As a workaround, either sort the block containers in increasing left position or add a thin white border to the containers (this will output PDF code which ends a block and causes the start of the next block container to be properly recognized). I wonder, however, why you don't use a table instead.
RE: Comments on new property maker implementation
-Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] [ Glen : ] Sigh...I guess I *didn't* know bytecode by heart after all! ;-) I didn't bring it up to discourage the use of static initialized arrays. If it makes sense to put something in a static array we should do so without concern of compiletime vs. runtime. After all, the initialization is only performed once per classloader. Well, (sorry to disappoint you, Peter) I don't know my BC by heart, but IIRC the real difference would be in the size of the compiled classes... See also a little trick I stumbled upon for for-loops. It's common(?) knowledge that testing for a value to be greater than (or equal to) another value, is the same as testing whether the result of their subtraction is greater than (or equal to) zero --rewriting this effectively saves a processor instruction per comparison. If you subsequently combine the test and the decrementing of the counter, you can slightly reduce the size of the compiled class further. In short: for( int i = 0; i j ; ++i ) is better written as ( = faster; that is: it will save a few hundred millisecs in large loops, the few that might just be enough to give the average user the impression that the software is actually any faster than before ) for( int i = j; i 0; --i ) and even better ( leads to even more compact compiled classes; performance-boost is negligeable with current hardware, but might turn out to be an advantage --albeit a minor one - when this class has to be loaded from a network location ) for( int i = j; --i = 0; ) Cheers, Andreas
Properties question ( again? )
Hi, While strolling through the table classes, I wondered about the following: fop.fo.flow.Table line 157:CommonBackground bProps = propMgr.getBackgroundProps(); line 193:this.BackgroundColor = this.propertyList.get(PR_BACKGROUND_COLOR).getColorType(); How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor Anyone? TIA Cheers, Andreas
Quote of the Day
A Harvard Professor on the influence of sleep on human learning: When I hear Bill Gates bragging about how his programmers can code up to 72 hours in a row, without any sleep, I always think to myself: 'Yes, and the result is Microsoft Windows...' :) don't make it too late, fellas! Cheers, Andreas
Re: Properties question ( again? )
Andreas L. Delmelle wrote: fop.fo.flow.Table line 157:CommonBackground bProps = propMgr.getBackgroundProps(); line 193:this.BackgroundColor = this.propertyList.get(PR_BACKGROUND_COLOR).getColorType(); I thought porpertyList had been retired in HEAD? How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. J.Pietschmann
RE: Properties question ( again? )
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] I thought porpertyList had been retired in HEAD? That's what I initially thought, but got a bit confused... Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. Ok. Probably means reviewing a few patches submitted recently. Thanks for the quick response. Cheers, Andreas
Re: Properties question ( again? )
[J.Pietschmann] I thought porpertyList had been retired in HEAD? PropertyListBuilder was recently removed from HEAD. [Andreas L. Delmelle] How should I see this? Is one of the two superfluous? Do they complement each other? Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor That is also my feeling. regards, finn
Re: Quote of the Day
On Mon, 2004-01-19 at 16:17, Andreas L. Delmelle wrote: When I hear Bill Gates bragging about how his programmers can code up to 72 There's the world's richest hermit again. Maybe he'll end up nuttier than Howard Hughes. -- John Austin [EMAIL PROTECTED]
Re: Comments on new property maker implementation
Finn Bock wrote: I would guess that doing ~6 string compares to navigate the binary tree (with 148 color keywords) is slower than one string hash, ~1.2 int compares and one string compare. But I haven't measured it, so you might be well be right. Many keyword sets for other properties are much smaller and could perhaps benefit from a more suitable collection type. I meant setup effort, although a binary tree will most likely do additional memory management. You are right about the lookup. Just for curiosity, where do you get the 1.2 int comparisions? A perfect hash should not have collisions. It might also be interesting how a trie or ternary tree (as used for hyphenation patterns) would compare to hash maps for keywords (in terms of setup costs, lookup costs and memory). I have doing a study of various Java implementations on my todo list but didn't quite get around to do this. J.Pietschmann
cvs commit: xml-fop/src/documentation/content/xdocs team.xml
gmazza 2004/01/19 15:56:50 Modified:src/documentation/content/xdocs team.xml Log: Updated team page--moved Finn, Andreas, Chris and Peter to active status; set Victor and Keiron to inactive status, removed former contributor section in favor of going back to giving credit within source files. Revision ChangesPath 1.25 +22 -31xml-fop/src/documentation/content/xdocs/team.xml Index: team.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/team.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- team.xml 1 Jan 2004 18:31:03 - 1.24 +++ team.xml 19 Jan 2004 23:56:50 - 1.25 @@ -12,8 +12,14 @@ section id=commit-active titleActive Committers/title ul +lilink href=mailto:[EMAIL PROTECTED]Finn Bock/link (FB)/li +lilink href=mailto:[EMAIL PROTECTED]Chris Bowditch/link (CB)/li +lilink href=mailto:[EMAIL PROTECTED]Andreas Delmelle/link (AD)/li li id=cglink href=mailto:[EMAIL PROTECTED]Christian Geisert/link (CG)/li -li id=klllink href=mailto:[EMAIL PROTECTED]Keiron Liddle/link (KLL)/li +lilink href=mailto:[EMAIL PROTECTED]Peter Herweg/link (PH) is helping to +integrate the jfor project's RTF support into the upcoming FOP 1.0 version. +Born in 1978, he has been serving as an application developer for a small +industrial company in Germany since 1999./li li id=jmlink href=mailto:[EMAIL PROTECTED]Jeremias M#x00E4;rki/link (JM) is a software engineer from Lucerne, Switzerland. He is currently enjoying a longer period of independence and is having fun working on open source projects like Apache FOP. He's also @@ -21,10 +27,6 @@ /li li id=gmlink href=mailto:[EMAIL PROTECTED]Glen Mazza/link (GM) is an information systems analyst with EDS in Arlington, Virginia, USA./li -li id=wvmlink href=mailto:[EMAIL PROTECTED]Victor Mote/link (WVM) is the founder and -manager of fork href=http://www.outfitr.com;Enterprise Outfitters/fork, a business -software company, and of fork href=http://www.portagepub.com;Portage Publications/fork, -a republisher of old documents. Both are located in Colorado Springs, Colorado, USA./li li id=jplink href=mailto:[EMAIL PROTECTED]J#x00F6;rg Pietschmann/link (JP)/li li id=otlink href=mailto:[EMAIL PROTECTED]Oleg Tkachenko/link (OT)/li li id=pbwlink href=mailto:[EMAIL PROTECTED]Peter B. West/link (PBW)/li @@ -38,13 +40,6 @@ Newfoundland. While developing a taste for good seafood, he still isn't ready for seal flipper (even if it's fresh). He is currently assisting the FOP project on memory and performance issues./li -lilink href=mailto:[EMAIL PROTECTED]Finn Bock/link/li -lilink href=mailto:[EMAIL PROTECTED]Chris Bowditch/link/li -lilink href=mailto:[EMAIL PROTECTED]Andreas Delmelle/link/li -lilink href=mailto:[EMAIL PROTECTED]Peter Herweg/link is helping to -integrate the jfor project's RTF support into the upcoming FOP 1.0 version. -Born in 1978, he has been serving as an application developer for a small -industrial company in Germany since 1999./li lilink href=mailto:[EMAIL PROTECTED]Clay Leeds/link is a web/WAP/Palm developer from Laguna Beach, California, USA. A recent XML/XSL-FO convert, he has been nit-picking FAQs amp; assorted web @@ -72,30 +67,26 @@ li id=sglink href=mailto:[EMAIL PROTECTED]Stanislav Gorkhover/link/li li id=fjlink href=mailto:[EMAIL PROTECTED]Fotis Jannidis/link/li li id=kllink href=mailto:[EMAIL PROTECTED]Karen Lease/link/li +li id=klllink href=mailto:[EMAIL PROTECTED]Keiron Liddle/link/li +li id=wvmlink href=mailto:[EMAIL PROTECTED]Victor Mote/link/li li id=jnlink href=mailto:[EMAIL PROTECTED]Jordan Naftolin/link/li li id=aslink href=mailto:[EMAIL PROTECTED]Arved Sandstrom/link/li li id=eslink href=mailto:[EMAIL PROTECTED]Eric Schaeffer/link/li li id=awlink href=mailto:[EMAIL PROTECTED]Art Welch/link/li /ul /section -section id=contribute-former - titleFormer Contributors/title - ul -li id=mllink href=mailto:[EMAIL PROTECTED]Mark Lillywhite/link/li - /ul -/section section id=expertise titleAreas of Expertise/title table tr th/ thCG /th - thKLL/th - thJM /th - thGM /th - thWVM/th - thJP /th - thOT /th + thFB/th +
DO NOT REPLY [Bug 6997] - Row-spanned row data breaks over a page within a column
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=6997. 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=6997 Row-spanned row data breaks over a page within a column --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 00:42 --- Created an attachment (id=10014) Possible fix for row-span breaks across a page
cvs commit: xml-fop/src/java/org/apache/fop/fo/expr PropertyInfo.java
gmazza 2004/01/19 17:14:33
Modified:src/codegen constants.xsl
src/java/org/apache/fop/fo Constants.java
src/java/org/apache/fop/fo/expr PropertyInfo.java
Log:
Interfaces now in alphabetical order and detached from generic interfaces
in autogenerated fo.properties.*; patch from Finn Bock--unneeded method in
PropertyInfo.
Revision ChangesPath
1.3 +71 -11xml-fop/src/codegen/constants.xsl
Index: constants.xsl
===
RCS file: /home/cvs/xml-fop/src/codegen/constants.xsl,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- constants.xsl 17 Jan 2004 19:29:45 - 1.2
+++ constants.xsl 20 Jan 2004 01:14:33 - 1.3
@@ -101,14 +101,6 @@
package org.apache.fop.fo;
-import org.apache.fop.fo.properties.GenericBoolean;
-import org.apache.fop.fo.properties.GenericBorderStyle;
-import org.apache.fop.fo.properties.GenericBreak;
-import org.apache.fop.fo.properties.GenericCondBorderWidth;
-import org.apache.fop.fo.properties.GenericCondPadding;
-import org.apache.fop.fo.properties.GenericKeep;
-import org.apache.fop.fo.properties.GenericSpace;
-
public interface Constants {/xsl:text
// element constants
@@ -141,7 +133,75 @@
/xsl:call-template
// Enumeration Interfaces
-xsl:apply-templates select=document(propfile)//property[not(@type='generic')]/
+
+public interface GenericBooleanInterface {
+int TRUE = Constants.TRUE;
+int FALSE = Constants.FALSE;
+}
+
+public interface GenericBorderStyleInterface {
+int NONE = Constants.NONE;
+int HIDDEN = Constants.HIDDEN;
+int DOTTED = Constants.DOTTED;
+int DASHED = Constants.DASHED;
+int SOLID = Constants.SOLID;
+int DOUBLE = Constants.DOUBLE;
+int GROOVE = Constants.GROOVE;
+int RIDGE = Constants.RIDGE;
+int INSET = Constants.INSET;
+int OUTSET = Constants.OUTSET;
+}
+
+public interface GenericBreakInterface {
+int AUTO = Constants.AUTO;
+int COLUMN = Constants.COLUMN;
+int PAGE = Constants.PAGE;
+int EVEN_PAGE = Constants.EVEN_PAGE;
+int ODD_PAGE = Constants.ODD_PAGE;
+}
+
+public interface GenericCondBorderWidthInterface {
+public interface Conditionality {
+int DISCARD = Constants.DISCARD;
+int RETAIN = Constants.RETAIN;
+}
+}
+
+public interface GenericCondPaddingInterface {
+public interface Conditionality {
+int DISCARD = Constants.DISCARD;
+int RETAIN = Constants.RETAIN;
+}
+}
+
+public interface GenericKeepInterface {
+public interface WithinPage {
+int AUTO = Constants.AUTO;
+int ALWAYS = Constants.ALWAYS;
+}
+public interface WithinLine {
+int AUTO = Constants.AUTO;
+int ALWAYS = Constants.ALWAYS;
+}
+public interface WithinColumn {
+int AUTO = Constants.AUTO;
+int ALWAYS = Constants.ALWAYS;
+}
+}
+
+public interface GenericSpaceInterface {
+public interface Precedence {
+int FORCE = Constants.FORCE;
+}
+public interface Conditionality {
+int DISCARD = Constants.DISCARD;
+int RETAIN = Constants.RETAIN;
+}
+}
+
+xsl:apply-templates select = document(propfile)//property[not(@type='generic')]
+ xsl:sort select=name/
+/xsl:apply-templates
xsl:text
}
@@ -177,7 +237,7 @@
xsl:if test=use-generic
xsl:text extends /xsl:text
xsl:value-of select=use-generic/
-xsl:text.Enums/xsl:text
+xsl:textInterface/xsl:text
/xsl:if
xsl:text {/xsl:text
xsl:for-each select=enumeration/value
1.5 +226 -170 xml-fop/src/java/org/apache/fop/fo/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Constants.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Constants.java17 Jan 2004 19:29:46 - 1.4
+++ Constants.java20 Jan 2004 01:14:33 - 1.5
@@ -51,14 +51,6 @@
package org.apache.fop.fo;
-import org.apache.fop.fo.properties.GenericBoolean;
-import org.apache.fop.fo.properties.GenericBorderStyle;
-import org.apache.fop.fo.properties.GenericBreak;
-import org.apache.fop.fo.properties.GenericCondBorderWidth;
-import org.apache.fop.fo.properties.GenericCondPadding;
-import org.apache.fop.fo.properties.GenericKeep;
Re: [PATCH] abandoning code-generated Property.Maker
Worked great--thanks! Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: Glen Mazza wrote: xsl:apply-templates select=document(propfile)//property[not(@type='generic')] / ) ... I am not an XSLT guru--offhand, does anyone know of a simple way to get the interfaces to appear alphabetically? It ought to be xsl:apply-templates select... xsl:sort select=name/ /xsl:apply-templates Substitute in the xsl:sort's select whatever is the sort key. J.Pietschmann __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination RegionBody.java
gmazza 2004/01/19 17:33:58
Modified:.build.xml
src/java/org/apache/fop/fo BoxPropShorthandParser.java
FObj.java Property.java PropertyList.java
src/java/org/apache/fop/fo/expr FopPropValFunction.java
FromParentFunction.java InheritedPropFunction.java
NearestSpecPropFunction.java
src/java/org/apache/fop/fo/flow TableRow.java
src/java/org/apache/fop/fo/pagination RegionBody.java
Added: src/java/org/apache/fop/fo FOPropertyMapping.java
Log:
FOPropertyMapping.java no longer autogenerated, moved from fop.fo.properties
to fo package in preparation for new property maker implementation.
Revision ChangesPath
1.98 +2 -4 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- build.xml 17 Jan 2004 19:29:45 - 1.97
+++ build.xml 20 Jan 2004 01:33:57 - 1.98
@@ -355,10 +355,8 @@
write out to (many) files other than the one specified --
style in=${foproperties.xml} style=${properties.xsl}
out=${build.gensrc}/${replacestring}/fo/properties/fo_${ignore_this}/
-style in=${foproperties.xml} style=${build.codegen}/fo-property-mapping.xsl
-
out=${build.gensrc}/${replacestring}/fo/properties/FOPropertyMapping.java/
-!--style in=${foproperties.xml}
style=${build.codegen}/prop-val-enum-interfaces.xsl
-
out=${build.gensrc}/${replacestring}/fo/properties/propertyListing.java/--
+!--style in=${foproperties.xml}
style=${build.codegen}/fo-property-mapping.xsl
+
out=${build.gensrc}/${replacestring}/fo/properties/FOPropertyMapping.java/--
style in=${encodings.xml} style=${charlist.xsl}
out=${build.gensrc}/${replacestring}/fonts//CodePointMapping.java/
!--
1.5 +0 -1 xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java
Index: BoxPropShorthandParser.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BoxPropShorthandParser.java 26 Dec 2003 23:41:47 - 1.4
+++ BoxPropShorthandParser.java 20 Jan 2004 01:33:57 - 1.5
@@ -49,7 +49,6 @@
* Software Foundation, please see http://www.apache.org/.
*/
package org.apache.fop.fo;
-import org.apache.fop.fo.properties.FOPropertyMapping;
/**
* Shorthand property parser for Box properties
1.32 +0 -1 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.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- FObj.java 14 Jan 2004 00:00:37 - 1.31
+++ FObj.java 20 Jan 2004 01:33:57 - 1.32
@@ -59,7 +59,6 @@
import org.apache.fop.apps.FOPException;
import org.apache.fop.fo.flow.Marker;
-import org.apache.fop.fo.properties.FOPropertyMapping;
import org.xml.sax.Attributes;
import org.xml.sax.Locator;
1.16 +0 -1 xml-fop/src/java/org/apache/fop/fo/Property.java
Index: Property.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Property.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Property.java 10 Jan 2004 20:40:07 - 1.15
+++ Property.java 20 Jan 2004 01:33:57 - 1.16
@@ -61,7 +61,6 @@
import org.apache.fop.fo.expr.Numeric;
import org.apache.fop.fo.expr.PropertyParser;
import org.apache.fop.fo.expr.PropertyInfo;
-import org.apache.fop.fo.properties.FOPropertyMapping;
import org.apache.fop.apps.FOPException;
import java.util.Vector;
1.27 +0 -2 xml-fop/src/java/org/apache/fop/fo/PropertyList.java
Index: PropertyList.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/PropertyList.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PropertyList.java 17 Jan 2004 19:29:46 - 1.26
+++ PropertyList.java 20 Jan 2004 01:33:57 - 1.27
@@ -57,8 +57,6 @@
// FOP
import org.apache.fop.apps.FOPException;
import org.apache.fop.fo.Property.Maker;
-import org.apache.fop.fo.properties.FOPropertyMapping;
-
/**
* Class containing the collection of properties for a given FObj.
1.1
cvs commit: xml-fop/src/java/org/apache/fop/render/xml XMLRenderer.java
gmazza 2004/01/19 17:52:51
Modified:src/java/org/apache/fop/render/xml XMLRenderer.java
Log:
Block height/width elaboration for XML Renderer--Patch by Finn Bock.
Revision ChangesPath
1.14 +3 -2 xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java
Index: XMLRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- XMLRenderer.java 17 Jan 2004 19:29:46 - 1.13
+++ XMLRenderer.java 20 Jan 2004 01:52:51 - 1.14
@@ -366,10 +366,11 @@
* @see org.apache.fop.render.AbstractRenderer#renderBlock(Block)
*/
protected void renderBlock(Block block) {
-String prop = ;
+String prop = width=\ + block.getWidth() +
+ \ height=\ + block.getHeight() + \;
Map map = block.getTraits();
if (map != null) {
-prop = props=\ + getPropString(map) + \;
+prop = prop + props=\ + getPropString(map) + \;
}
writeStartTag(block + prop + );
super.renderBlock(block);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Properties question ( again? )
Please fix it whenever you get write access. Glen --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Shouldn't the latter be rewritten as : this.BackgroundColor = bProps.backColor I'd think so. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
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=25873.
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=25873
[PATCH] abandoning code-generated Property.Maker
--- Additional Comments From [EMAIL PROTECTED] 2004-01-20 02:03 ---
Finn,
You have a change that doesn't appear relevant to this bug in
InlineStackingLayoutManager.java:
Index: src/java/org/apache/fop/layoutmgr/InlineStackingLayoutManager.java
===
@@ -292,6 +292,10 @@
// Reset state variables
clearPrevIPD(); // Clear stored prev content dimensions
}
+// I don't have a clue if this is right.
+if (childLC == null) {
+childLC = new LayoutContext(lc);
+}
// We only do this loop more than once if a childLM returns
// a null BreakPoss, meaning it has nothing (more) to layout.
Should we skip this change?
Thanks,
Glen
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
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=25873. 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=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 02:05 --- Created an attachment (id=10016) current status of patch (down to about 4900 lines from 6200).
DO NOT REPLY [Bug 6997] - [PATCH] Row-spanned row data breaks over a page within a column
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=6997. 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=6997 [PATCH] Row-spanned row data breaks over a page within a column [EMAIL PROTECTED] changed: What|Removed |Added Summary|Row-spanned row data breaks |[PATCH] Row-spanned row data |over a page within a column |breaks over a page within a ||column
Re: cvs commit: xml-fop/src/documentation/content/xdocs team.xml
[EMAIL PROTECTED] wrote: gmazza 2004/01/19 15:56:50 Modified:src/documentation/content/xdocs team.xml Log: Updated team page--moved Finn, Andreas, Chris and Peter to active status; set Victor and Keiron to inactive status, removed former contributor section in favor of going back to giving credit within source files. I'm sorry that I didn't contribute to the discussion on this, but I think that Mark Lillywhite deserves an honourable mention on the web site. He saved Fop for many users by introducing page-sequence formatting. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
