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=26055.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=26055.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=26096.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=26096.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sorry for the long post... Just trying to put a few ideas together.
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
Pardon me for repeating what might be obvious,
Well, it wasn't to me, so... thanks in advance
but I'll like to take
a look at what information we want to store at each
There was an inquiry by Xerces-J people on the XML PMC yesterday asking
for the compatibility of IBM's ICU package with the ASF license.
It looks like this package could be interesting for our project, too:
http://oss.software.ibm.com/icu/
Jeremias Maerki
Simon Pepping wrote:
Do you need to break the line is as many separate text areas as there
are word spaces ( + 1 )?
Well, the line may be parsed while rendering, which means you don't have
to create area objects, roughly:
StringTokenizer tok=new StringTokenizer(...);
while( tok.hasMoreTokens )
OK--this may also be overkill then. Thank you for the
analysis.
Glen
--- Finn Bock [EMAIL PROTECTED] wrote:
[Glen Mazza]
This sounds like it could be an excellent idea--a
PropertyRepository (extending, of course, a
DelmelleRepository (tm) ;) ) could be a very
useful
tool for FO Tree
gmazza 2004/01/13 15:28:31
Modified:src/java/org/apache/fop/fo PropertyList.java
Log:
static boolean array inheritableProperty[] added, to reduce processing costs
of lookups to see if a property is inheritable. Work based on Finn Bock's patch.
Revision ChangesPath
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
OK--this may also be overkill then. Thank you for the
analysis.
It will prove useful, I am sure --provided we want to uphold the intention
to be able to process any size of document (from sources that may not be as
gmazza 2004/01/13 16:00:39
Modified:src/java/org/apache/fop/fo FObj.java
src/java/org/apache/fop/fo/flow TableRow.java
src/java/org/apache/fop/fo/pagination
ConditionalPageMasterReference.java Flow.java
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=25480.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Let's not get too certain of anything right now with
respect to implementation--but you probably have a
point--a huge and very repetitively formatted document
(say, the Chicago phone book, perhaps) would have
comparatively fewer properties with a higher
cardinality for each.
Glen
--- Andreas L.
On Tue, 2004-01-13 at 20:49, Glen Mazza wrote:
Let's not get too certain of anything right now with
respect to implementation--but you probably have a
point--a huge and very repetitively formatted document
(say, the Chicago phone book, perhaps) would have
comparatively fewer properties with a
Andreas L. Delmelle wrote:
Sorry for the long post... Just trying to put a few ideas together.
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet
15 matches
Mail list logo
