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.
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
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,
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
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
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
[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
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
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.
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/
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
--- 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
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
--- 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 {}
14 matches
Mail list logo