DO NOT REPLY [Bug 20943] - number-rows-spanned render spanned cell background.
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=20943. 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=20943 number-rows-spanned render spanned cell background. [EMAIL PROTECTED] changed: What|Removed |Added Component|pdf renderer|general OS/Version|Windows NT/2K |All Platform|PC |All Version|0.20.5 |all --- Additional Comments From [EMAIL PROTECTED] 2004-01-18 07:50 --- As I've been occupying myself with row- and column-span in HEAD lately (1.0dev), just want to add the following: The added example fo-file specifies background-colors on the row. If I interpret the spec correctly the background being overpainted is actually compliant. A spanned cell *can* have a different background in each of the table-grid-units it occupies. Defining BGC on the row is one way of contributing in this effect. WRT the content and the borders, this is of course a different matter... (Borders -are- working, they're just overpainted) I guess it has something to do with the sequential processing of the table-rows, where, in case of RowSpan, a number of rows should be processed as a unity. I doubt that the issue will be fixed in 0.20.5, but it will certainly be addressed in 1.0dev. Thanks for bringing this back to our attention!
Re: Servlet Examples in HEAD v.s. 0.20.5
John Austin wrote: (is Content-length: required for any reason other than placating Acrobat and that rich hermit who lives outside Redmond WA ?) Not really a FOP topic but anyway. Setting content-length is considered good style, because it allows browsers give feedback to the users how far the download proceeded. This is especially useful for larger files on slow connections. Of course, there is a tradeoff for dynamically generated content: there wont be any feedback at all until the content is ready, and if this is longer than the download time itself (now that everybody has broadband :-) ), the user is still dissatisfied. Well, the IEx architecture bug saves us from pondering the philosophical background. 2) Cache Templates objects for faster Transformations when XSLT files are to be re-used. The 'Java and XSLT' O'Reilly book has some interesting suggestions in this area. The problem is to detect style sheet reuse without context information. 3) Using URL's for the fo= and xml=,xsl= parameters so we can use network resources as well as local files. +1000. Doh, revert to +0. I'd like to do this, unfortunately, this is not without drawbacks: - People have to learn what an URI is. This seems to be much harder than expected, especially for file:-URLs. - People will still insist to keep xml=foo.xml. This is still an URL (actually: a relative URL reference, which has to be resolved). We have to think hard what the base URL is in this case. J.Pietschmann
Re: Servlet Examples in HEAD v.s. 0.20.5
On Sun, 2004-01-18 at 08:49, J.Pietschmann wrote: John Austin wrote: (is Content-length: required for any reason other than placating Acrobat and that rich hermit who lives outside Redmond WA ?) Not really a FOP topic but anyway. Setting content-length is considered good style, because it allows browsers give feedback to the users how far the download proceeded. This is especially useful for larger files on slow connections. Of course, there is a tradeoff for dynamically generated content: there wont be any feedback at all until the content is ready, and if this is longer than the download time itself (now that everybody has broadband :-) ), the user is still dissatisfied. Well, the IEx architecture bug saves us from pondering the philosophical background. Mentioned because it is in the extant codebase even though it isn't necessary. I deduce it is related to Acrobat because of cryptic comments in the documentation. 2) Cache Templates objects for faster Transformations when XSLT files are to be re-used. The 'Java and XSLT' O'Reilly book has some interesting suggestions in this area. The problem is to detect style sheet reuse without context information. I think the only prob is how to purge from the cache. Re-use detected if names are URL's. Still faces the problem of detecting changes to stylesheets. Discussed a bit in Burke's book. 3) Using URL's for the fo= and xml=,xsl= parameters so we can use network resources as well as local files. +1000. Doh, revert to +0. I'd like to do this, unfortunately, this is not without drawbacks: - People have to learn what an URI is. This seems to be much harder than expected, especially for file:-URLs. - People will still insist to keep xml=foo.xml. This is still an URL (actually: a relative URL reference, which has to be resolved). We have to think hard what the base URL is in this case. What if default xml=fred.xml is mapped to xml=file://./fred.xml where the servlet's 'working dir' is defined relative to servlet context. The we can ship some of our test xml/xsl files in that location and people have something to start with. J.Pietschmann -- John Austin [EMAIL PROTECTED]
Bug report for Fop [2004/01/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|Row-spanned row data breaks over a page within a c| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly | |
Comments on new property maker implementation
Finn, I've looked at your changes--I like them, and I'm thankful to have someone on our team to be able to redesign the properties as you have. Getting rid of the 250 autogenerated or so classes will be a welcome improvement. Comments right now: 1.) Unlike what I was saying earlier, I don't think we should move from Property.Maker to a new PropertyMaker class after all, your design looks fine. I've noticed most subclasses of Property.Maker are within subclasses of Properties themselves (e.g., LengthProperty, LengthProperty.Maker, etc.) so it looks like a neat, clean design. 2.) The new FOPropertyMapping.java class appears (1) autogenerated, and (2) to be an XSLT masterpiece at that as well. If it is indeed in good shape, I'd like you to submit it to Bugzilla as the new fo-property-mapping.xsl, replacing the old one of that name in src/codegen. (We won't apply it however, until we no longer need the current autogenerated fo-property-mapping.xsl, i.e., until all the old properties have been tossed out.) This way if we have to make wide-ranging changes to FOPropertyMapping, we'll have a XSLT source file we can conveniently work with. (Note that putting it in codegen does *not* mean that it will be automatically autogenerated anymore--it won't, just as constants.xsl no longer is--we'll pull it out of the main Ant build target at that time and keep it the separate, manual xsltToJava target in our build file[1]. [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/build.xml?rev=1.97view=auto ) Comments on FOPropertyMapping: I like removing all these autogenerated classes, but I think we can still keep some processing at compile-time for more of a performance gain, as follows: 3) I think the runtime construction of the generic properties (genericColor, genericCondBorderWidth, etc.) may not be necessary. We can still have those xslt-generated into classes (6-8 classes total), but this time we check them into FOP (again, keeping the xsl available for manual re-generation when needed). But most of the generic classes are so small (your initialization of GenericCondPadding is only 4 lines of code), that going back to creating concrete classes would be noticeably beneficial either, so I'm not recommending this change. One thing that *does* stick out, however, is the 100 or so addKeyword() calls for genericColor (the largest of the generic properties): genericColor.addKeyword(antiquewhite, #faebd7); genericColor.addKeyword(aqua, #00); genericColor.addKeyword(aquamarine, #7fffd4); . I'd like us to have a static array of these values--i.e., something done compile-time, that genericColor can just reference, so we don't have to do this keyword initialization. 4) I'd also like us to, rather than call setInherited() and setDefault() for each of the properties during initialization, for the Property/Property.Maker classes to just reference that information from two (new) static arrays, added to Constants.java. We can also get rid of these two setter methods as well (ideally there shouldn't be setters for these attributes anyway--they should remain inherent to the Property.) This change will allow us to take advantage of the fact that we are now on int-constants. getDefault(PR_WHATEVER), for example, is just Constants.DefaultArray[PR_WHATEVER]. 5) Similar to (b) above, several of the makers also have a useGeneric() initialization requirement: m = new CondLengthProperty.Maker(PR_PADDING_END); m.useGeneric(genericCondPadding); For those Makers that require it, I'd like the constructor to be expanded to this: m = new CondLengthProperty.Maker(PR_PADDING_END, genericCondPadding); Again, getting rid of the useGeneric() function. This is for more speed, encapsulation, and also shrinking FOPropertyMapping class a bit. Sorry for the long post. I'll probably have other comments in other areas, but this is all I've studied for now. Thoughts? Thanks, Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: [PATCH] abandoning code-generated Property.Maker
Team, I moved the 64 or so property value interfaces from separate autogenerated files to Constants.java yesterday. The work is not perfect--there are still a few linkages to (autogenerated) generic enumerations (I will fix these after we apply Finn's latest properties patch), a couple of interfaces conflicted name-wise with already existing classes (I just commented those interfaces out--we can forgo those). Also, for classes not implementing Constants, a Constants.InterfaceName.PropertyValue name ends up needing to be used--but for these, we can also easily revert to Constants.PropertyValue. These interfaces are just meant to be a developer convenience, not something required. One (minor) thing I would like to fix though, is that the interfaces are not appearing in alphabetical order in Constants.java (Java [1], XSLT source [2]) (in the XSLT, under the Enumeration Interfaces comment: // Enumeration Interfaces xsl:apply-templates select=document(propfile)//property[not(@type='generic')] / ) [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/Constants.java?rev=1.4view=auto [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/codegen/constants.xsl?rev=1.2view=auto I am not an XSLT guru--offhand, does anyone know of a simple way to get the interfaces to appear alphabetically? It's not that big a deal, but there might be something very obvious I've missed, a simple change to get them in alpha order. Thanks, Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Comments on new property maker implementation
[Glen Mazza]
I've looked at your changes--I like them, and I'm
thankful to have someone on our team to be able to
redesign the properties as you have. Getting rid of
the 250 autogenerated or so classes will be a welcome
improvement.
But the biggest improvement is IMHO the easy ability to create special
maker subclasses to handle the corner cases. Take a look at
IndentPropertyMaker for the calculation of start and end-indent and at
BorderWidthPropertyMaker for the special handling of border-width when
border-style is NONE.
Comments right now:
1.) Unlike what I was saying earlier, I don't think
we should move from Property.Maker to a new
PropertyMaker class after all, your design looks fine.
I've noticed most subclasses of Property.Maker are
within subclasses of Properties themselves (e.g.,
LengthProperty, LengthProperty.Maker, etc.) so it
looks like a neat, clean design.
2.) The new FOPropertyMapping.java class appears (1)
autogenerated, and (2) to be an XSLT masterpiece at
that as well. If it is indeed in good shape, I'd like
you to submit it to Bugzilla as the new
fo-property-mapping.xsl, replacing the old one of that
name in src/codegen.
Initially my new FOPropertyMapping was generated by XSLT but that is now
a long time ago and I have made lots of manual changes since then. The
XSLT script only handled the most common property information and was
just a hack to get me started. The output isn't a complete java file, it
doesn't link the subproperties to the base properties and it doesn't
deal with the classname of any of the complex properties.
(We won't apply it however,
until we no longer need the current autogenerated
fo-property-mapping.xsl, i.e., until all the old
properties have been tossed out.)
This way if we have to make wide-ranging changes to
FOPropertyMapping, we'll have a XSLT source file we
can conveniently work with. (Note that putting it in
codegen does *not* mean that it will be automatically
autogenerated anymore--it won't, just as constants.xsl
no longer is--we'll pull it out of the main Ant build
target at that time and keep it the separate, manual
xsltToJava target in our build file[1].
[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/build.xml?rev=1.97view=auto
)
Comments on FOPropertyMapping:
I like removing all these autogenerated classes, but I
think we can still keep some processing at
compile-time for more of a performance gain, as
follows:
3) I think the runtime construction of the generic
properties (genericColor, genericCondBorderWidth,
etc.) may not be necessary. We can still have those
xslt-generated into classes (6-8 classes total), but
this time we check them into FOP (again, keeping the
xsl available for manual re-generation when needed).
But most of the generic classes are so small (your
initialization of GenericCondPadding is only 4 lines
of code), that going back to creating concrete classes
would be noticeably beneficial either, so I'm not
recommending this change.
The generic properties are just templates that carries default data
values to be used later on, so I don't fully see how we could xslt-
generate them as anything other than containers of default values. Your
last statement is a bit difficult to parse so I'm not sure what exactly
you are recommending.
One thing that *does* stick out, however, is the 100
or so addKeyword() calls for genericColor (the largest
of the generic properties):
genericColor.addKeyword(antiquewhite, #faebd7);
genericColor.addKeyword(aqua, #00);
genericColor.addKeyword(aquamarine, #7fffd4);
.
I'd like us to have a static array of these
values--i.e., something done compile-time, that
genericColor can just reference, so we don't have to
do this keyword initialization.
I probably need an example of what you thinking are here. Right now in
HEAD all the color keywords are stored in a HashMap created in
GenericColor so the keywords initialization is already done. Putting the
keywords in static array would require us to somehow search the array
and I don't see how that will be much faster.
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
6 bipush 101
8 iastore
9 dup
10 iconst_1
11 bipush 102
13 iastore
14 dup
15 iconst_2
16 bipush 103
18 iastore
...
and so on for each index. (In case you don't know bytecode by heart,
iconst and bipush both push a constant on the stack and iastore pops 3
items from the stack; an index, a value and an array and assign the
value to the index in the array).
4) I'd also like us to, rather than call
setInherited() and setDefault() for each of the
properties during initialization, for the
Property/Property.Maker classes to just reference that
information from two (new) static arrays, added to
Constants.java. We
cvs commit: xml-fop/src/java/org/apache/fop/render/rtf TableAttributesConverter.java TextAttributesConverter.java
pherweg 2004/01/18 13:21:41
Modified:src/java/org/apache/fop/render/rtf
TableAttributesConverter.java
TextAttributesConverter.java
Log:
replaced string constants with int constants
Revision ChangesPath
1.8 +10 -10
xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java
Index: TableAttributesConverter.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TableAttributesConverter.java 5 Jan 2004 00:44:59 - 1.7
+++ TableAttributesConverter.java 18 Jan 2004 21:21:41 - 1.8
@@ -229,25 +229,25 @@
isBorderPresent=true;
*/
}
-ep = (EnumProperty)props.get(border-top-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_TOP_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.CELL_BORDER_TOP, \\
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-bottom-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_BOTTOM_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.CELL_BORDER_BOTTOM, \\
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-left-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_LEFT_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.CELL_BORDER_LEFT, \\
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-right-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_RIGHT_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.CELL_BORDER_RIGHT, \\
+ convertAttributetoRtf(ep.getEnum()));
@@ -272,7 +272,7 @@
// Column spanning :
-NumberProperty n = (NumberProperty)props.get(number-columns-spanned);
+NumberProperty n =
(NumberProperty)props.get(Constants.PR_NUMBER_COLUMNS_SPANNED);
if (n != null n.getNumber().intValue() 1) {
attrib.set(ITableAttributes.COLUMN_SPAN, n.getNumber().intValue());
}
@@ -371,7 +371,7 @@
isBorderPresent=true;
*/
}
-ep = (EnumProperty)props.get(border-top-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_TOP_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.ROW_BORDER_TOP, \\
+ convertAttributetoRtf(ep.getEnum()));
@@ -379,7 +379,7 @@
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-bottom-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_BOTTOM_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.ROW_BORDER_BOTTOM,\\
+ convertAttributetoRtf(ep.getEnum()));
@@ -387,7 +387,7 @@
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-left-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_LEFT_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.ROW_BORDER_LEFT, \\
+ convertAttributetoRtf(ep.getEnum()));
@@ -395,7 +395,7 @@
+ convertAttributetoRtf(ep.getEnum()));
isBorderPresent = true;
}
-ep = (EnumProperty)props.get(border-right-style);
+ep = (EnumProperty)props.get(Constants.PR_BORDER_RIGHT_STYLE);
if (ep != null ep.getEnum() != Constants.NONE) {
attrib.set(ITableAttributes.ROW_BORDER_RIGHT,\\
+ convertAttributetoRtf(ep.getEnum()));
1.8 +4 -4
xml-fop/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java
Index: TextAttributesConverter.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/render/rtf/TextAttributesConverter.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TextAttributesConverter.java 29 Dec
Re: Comments on new property maker implementation
Glen Mazza wrote: One thing that *does* stick out, however, is the 100 or so addKeyword() calls for genericColor ... I'd like us to have a static array of these values--i.e., something done compile-time, that genericColor can just reference, so we don't have to do this keyword initialization. Look up perfect hash code and the associated generators on the internet, like gperf, a C++ implementation used by gcc and a veriety of other compilers to provide a data structure for mapping strings to something else in an efficient way. Mind you, this would also benefit mapping to FO and property names to their associated classes or code numbers. J.Pietschmann
Re: [PATCH] abandoning code-generated Property.Maker
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
Re: Comments on new property maker implementation
Finn Bock wrote: You should perhaps also be aware that the values in a static array gets assigned to the array one element at a time. So 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). It would make sense, however, to properly initialitze initial size values for the various hashmaps currently used. J.Pietschmann
Re: Comments on new property maker implementation
--- Finn Bock [EMAIL PROTECTED] wrote:
But the biggest improvement is IMHO the easy ability
to create special
maker subclasses to handle the corner cases. Take a
look at
IndentPropertyMaker for the calculation of start and
end-indent and at
BorderWidthPropertyMaker for the special handling of
border-width when
border-style is NONE.
Well, I'm not there yet, but I'll be able to
appreciate it in due time.
Initially my new FOPropertyMapping was generated by
XSLT but that is now
a long time ago and I have made lots of manual
changes since then.
OK, no problem, we'll modify the Java source from now
on.
The generic properties are just templates that
carries default data
values to be used later on, so I don't fully see how
we could xslt-
generate them as anything other than containers of
default values. Your
last statement is a bit difficult to parse so I'm
not sure what exactly
you are recommending.
Umm, never mind. What I was trying to say is that the
generic templates (GenericKeep, GenericSpace, etc., of
the present code) were all autogenerated. *If* you
thought it still useful to keep it as such, it's OK
with me (i.e., going down from 250 autogenerated to
about 8 is still a very nice improvement.) But you no
longer see a need for it, which is absolutely fine
with me.
One thing that *does* stick out, however, is the
100
or so addKeyword() calls for genericColor (the
largest
of the generic properties):
genericColor.addKeyword(antiquewhite,
#faebd7);
genericColor.addKeyword(aqua, #00);
genericColor.addKeyword(aquamarine,
#7fffd4);
.
I'd like us to have a static array of these
values--i.e., something done compile-time, that
genericColor can just reference, so we don't have
to
do this keyword initialization.
I probably need an example of what you thinking are
here. Right now in
HEAD all the color keywords are stored in a HashMap
created in
GenericColor so the keywords initialization is
already done.
OK--I see, thanks for the enlightenment here. Never
mind again, I was wrong on this point.
Putting the
keywords in static array would require us to somehow
search the array
and I don't see how that will be much faster.
Yes, wasn't thinking of that.
4) I'd also like us to, rather than call
setInherited() and setDefault() for each of the
properties during initialization, for the
Property/Property.Maker classes to just reference
that
information from two (new) static arrays, added to
Constants.java. We can also get rid of these two
setter methods as well (ideally there shouldn't be
setters for these attributes anyway--they should
remain inherent to the Property.)
This change will allow us to take advantage of the
fact that we are now on int-constants.
getDefault(PR_WHATEVER), for example, is just
Constants.DefaultArray[PR_WHATEVER].
I think 'Default' is a bad example, noone ever tries
to get the default
value except for the property maker itself, but your
argument holds for
isInherited().
No--I don't think you've gotten my point here. I
don't care about the consumers of that
information--even if it is just Property.Maker. But I
don't see the reason to run-time initialize a
PropertyMaker with inherited and default values,
because I can add the whole array in the Constants
interface, or even in Property.Maker directly.
static Boolean inheritedArray[] =
{
false // 0
true// PR_PROP_1
true// PR_PROP_2
false // PR_PROP_3
true// ...
Once you initialize a Property.Maker with its
PR_XX constant, *it* (the Maker) can always obtain
these values by accessing inheritedArray[PR_XX] or
defaultArray[PR_XX]. No reason to initialize via
setInherited(true) or setDefault(5). Do you see
what I'm trying to say?
Still, I disagree. If one want to know is a property
is inherited, the
proper way to get the information should be to call
propertyMapping[PR_WHATEVER].isInherited().
OK--we can place these two arrays in a location where
only the Property.Makers can get to it. (Maybe a
protected static array in Property.Maker?) Thoughts
here?
Again, getting rid of the useGeneric() function.
This
is for more speed, encapsulation, and also
shrinking
FOPropertyMapping class a bit.
A very good idea. +1.
I can probably make the modifications to this--looks
simple.
Thanks,
Glen
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Comments on new property maker implementation
Finn Bock wrote:
I probably need an example of what you thinking are here. Right now in
HEAD all the color keywords are stored in a HashMap created in
GenericColor so the keywords initialization is already done. Putting the
keywords in static array would require us to somehow search the array
and I don't see how that will be much faster.
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
6 bipush 101
8 iastore
9 dup
10 iconst_1
11 bipush 102
13 iastore
14 dup
15 iconst_2
16 bipush 103
18 iastore
...
and so on for each index. (In case you don't know bytecode by heart,
iconst and bipush both push a constant on the stack and iastore pops 3
items from the stack; an index, a value and an array and assign the
value to the index in the array).
Finn,
I can't imagine there is anyone here who doesn't know bytecode by heart.
(Except maybe me.)
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Comments on new property maker implementation
--- Peter B. West [EMAIL PROTECTED] wrote:
[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
Hmmm...Are you saying that declaring a static array
isn't much (any?) faster than manually creating one?
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.) Isn't that how C works, at least?
Sigh...I guess I *didn't* know bytecode by heart after
all! ;-)
Glen
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
