DO NOT REPLY [Bug 26055] - Some GIF imaes do not appear
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26055 Some GIF imaes do not appear --- Additional Comments From [EMAIL PROTECTED] 2004-01-13 09:41 --- I am unable to change the version of fop as it is a customers system. I have tried opening and re-saving the images in MSOffice Photo Editor (and other application) with no change. The images are larger and have more colors than the ones which work. However if I convert the images to *.bmp they appear correctly.
DO NOT REPLY [Bug 26055] - Some GIF imaes do not appear
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26055 Some GIF imaes do not appear --- Additional Comments From [EMAIL PROTECTED] 2004-01-13 09:46 --- Created an attachment (id=9927) This one doesnt work
DO NOT REPLY [Bug 26096] New: - subproperty=inherit does not find inherited value.
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.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26096
subproperty=inherit does not find inherited value.
Summary: subproperty=inherit does not find inherited value.
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
My recently applied patch 25810 which add support for inherit values doesn't
work for subproperties.
This is because the subproperty maker doesn't know which base maker it is
attached to. So for keep-with-next.within-line=inherit the propId for
the 'within-line' maker is CP_WITHIN_LINE and the getFromParent(propId) can't
find the specified parent value.
Unfortunately the subprop makers for the within-* subprops are created as
static instances in GenericKeep so they can't easily have the base propId or'ed
in.
The issue can the solved with a hack like this to Property.java:
@@ -193,6 +194,8 @@
Maker spMaker = getSubpropMaker(subpropId);
if (spMaker != null) {
+spMaker.propId =
+(spMaker.propId Constants.COMPOUND_MASK) | this.propId;
Property p = spMaker.make(propertyList, value, fo);
if (p != null) {
return setSubprop(baseProp, subpropId, p);
but changing the static singleton makers like that every time they are about to
get used, is too ugly to even consider wink.
DO NOT REPLY [Bug 26096] - subproperty=inherit does not find inherited value.
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26096 subproperty=inherit does not find inherited value. --- Additional Comments From [EMAIL PROTECTED] 2004-01-13 14:44 --- Created an attachment (id=9933) A testcase .fo
RE: [Bug 25480] - Experimental performance improvements.
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 FObj. If you look at the big picture, I think this could as well be none ( a null vector ) for FObj's with nothing but inherited props. Their property accessor should be able to perform the logic 'if absent in this FObj's prop specs, get the specified/computed value (or the property, in case the value is still unresolved) for the correct FObj', instead of having to redirect the call to the immediate parent's Propertylist, which may or may not have to do the same, who knows... the parser probably did at some point, but it forgot, so did we and now it's got us frantically climbing up the FOTree --like monkeys :) I can come up with 3 different strategies: 1) Only store the specified properties. That is what HEAD does now. ? Is this meant ironically? :) IIC, if not optimized or normalized in some way, overconstraint would lead to a drastically high object instantiation rate, not? Besides that, the spec *does* enforce verbosity in some quite trivial and widely used constructs... like, sigh/, tables From: Peter B. West [mailto:[EMAIL PROTECTED] snip / 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 of specified properties. When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away. Yum... so a Collection of Objects is traded for a handful of --what? (Would this be the propertyValue singletons you mention?) What happens with 'unresolvable' Props at that point (for the cases you mention below)? Do they get thrown away, or placed in a sort of Property stack for later accessing? If so, how exactly do you indicate in the FObj (or FONode) that the property in question still has to be resolved? So that, when Layout asks for this property, it is signaled that some computations still need to be made? (Pardon me if these questions mean I haven't read your docs thoroughly enough; I did read some of them, but it seems I still miss a bit of technical background to fully understand it.) This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed. Yes... cases I was overlooking --not so plain inheritance as the FObj's for static-content appear only once or twice every page-sequence, but their inherited properties and values vary, depending on the further processing of the tree. Still, I'm wondering whether you really need to re-parse them (as you indicated)... Couldn't you just, say, keep the Property alive and alter its value when needed? (If this would save you any re-initializing, I mean) The re-parsing idea seems very interesting to be able to say after a threesome of pages have been processed: collapse the branches of the FOTree that have already been layed out to the level below the current fo:flow (or fo:block; in any case some logical point of reference). If downstream, it turns out that their layout needs to be modified again (what are the odds? any way of predicting this?), one could trigger a re-parse from the subtree in question onwards. (This would, I think, save us some memory) Perhaps the same approach can be taken WRT tables: collapse all finished rows, so their cells are released. When their layed-out state turns out to be insufficient, start processing again from the row in question onwards, *with* the knowledge of what lies ahead this time... From: Glen Mazza [mailto:[EMAIL PROTECTED] --- Andreas L. Delmelle [EMAIL PROTECTED] What I'm very concerned about, for example, are cases like tables, where it would be quite awkward to have the TableCell FObj's reference their own copy of a Property instance To put it more precisely, the individual Properties of an FObj are currently stored in the PropertyList of that FOBj. snip / This sounds like it could be an excellent idea--a PropertyRepository ( ... ) could be a very useful tool for FO Tree Building. Prior to creating any Property instance for any FO's array, we send the specs of the needed property to the PropertyRepository, and it gives us either (1) a brand-new property instance, or (2) a reference to an already-created one. Aha! So this approach could also be used to recycle some of the HashMap and BitSet that get thrown away in alt-design, correct?
Intersting link for i18n freaks
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
Re: Justification in HEAD
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 ) {
String word = tok.nextToken();
renderText(x,y,word);
x+=width(word);
x+=adjustedSpaceWidth;
}
There is a tradeoff between avoiding recomputing the word width and
carrying it around for probably some significant time.
J.Pietschmann
Re: [Bug 25480] - Experimental performance improvements.
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 Building. Prior to creating any Property instance for any FO's array, we send the specs of the needed property to the PropertyRepository, and it gives us either (1) a brand-new property instance, or (2) a reference to an already-created one. So, indeed, only one instance of that font-size = 12pt would need to be created. The amount to be saved will of course depend on the input, but for DocBook: The Definite Guide, the amount is quite small. So small that I didn't bothered to do it when I made the performance patch. Here is a break down on the string values that are parsed into properties. It is the output from sort | uniq -c | sort so in the first column is the number of times that a value occurs. http://bckfnn-modules.sf.net/property-value-breakdown.txt The properties that starts with a '.' are the default values for subproperties and they can all be reduced to one occurrence if the default value for subproperties was cached. 'start-ident' and 'line-height=1.2em' both depend on other properties and therefore can't be (easily) cached. regards, finn __ 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 PropertyList.java
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
1.25 +10 -7 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.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- PropertyList.java 9 Jan 2004 03:05:55 - 1.24
+++ PropertyList.java 13 Jan 2004 23:28:31 - 1.25
@@ -69,6 +69,7 @@
// writing-mode values
private byte[] wmtable = null;
private int writingMode;
+private static boolean[] inheritableProperty;
// absolute directions and dimensions
/** constant for direction left */
@@ -678,14 +679,16 @@
* @return isInherited value from the requested Property.Maker
*/
private boolean isInherited(int propId) {
-boolean b = true;
-
-Property.Maker propertyMaker = findMaker(propId);
-if (propertyMaker != null) {
-b = propertyMaker.isInherited();
+if (inheritableProperty == null) {
+inheritableProperty = new boolean[Constants.PROPERTY_COUNT + 1];
+Property.Maker maker = null;
+for (int prop = 1; prop = Constants.PROPERTY_COUNT; prop++) {
+maker = findMaker(prop);
+inheritableProperty[prop] = (maker != null maker.isInherited());
+}
}
-
-return b;
+
+return inheritableProperty[propId];
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 25480] - Experimental performance improvements.
-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 exemplary as DocBook :/)... and eventually redo part of the process with significantly less effort. Over out (for the time being :) ) Cheers, Andreas
cvs commit: xml-fop/src/java/org/apache/fop/render/mif MIFHandler.java
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
PageMasterReference.java RegionBody.java
RepeatablePageMasterAlternatives.java
RepeatablePageMasterReference.java
src/java/org/apache/fop/render/mif MIFHandler.java
Log:
More String-Int conversions (ones I've missed previously.) Appears I've finally
converted all of them. From Finn Bock's patch.
Revision ChangesPath
1.31 +2 -3 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.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- FObj.java 28 Dec 2003 16:13:10 - 1.30
+++ FObj.java 14 Jan 2004 00:00:37 - 1.31
@@ -258,8 +258,7 @@
* @param name - the name of the desired property to obtain
* @return the property
*/
-public Property getProperty(String name) {
-int propId = FOPropertyMapping.getPropertyId(name);
+public Property getProperty(int propId) {
return (propertyList.get(propId));
}
@@ -330,7 +329,7 @@
protected void setWritingMode() {
FObj p = findNearestAncestorGeneratingRAs(true, true);
this.propertyList.setWritingMode(
- p.getProperty(writing-mode).getEnum());
+ p.getProperty(PR_WRITING_MODE).getEnum());
}
/**
1.12 +4 -5 xml-fop/src/java/org/apache/fop/fo/flow/TableRow.java
Index: TableRow.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/TableRow.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- TableRow.java 31 Dec 2003 01:41:46 - 1.11
+++ TableRow.java 14 Jan 2004 00:00:37 - 1.12
@@ -133,17 +133,16 @@
this.backgroundColor =
this.propertyList.get(PR_BACKGROUND_COLOR).getColorType();
-this.keepTogether = getKeepValue(keep-together.within-column);
-this.keepWithNext = getKeepValue(keep-with-next.within-column);
+this.keepTogether = getKeepValue(PR_KEEP_TOGETHER | CP_WITHIN_COLUMN);
+this.keepWithNext = getKeepValue(PR_KEEP_WITH_NEXT | CP_WITHIN_COLUMN);
this.keepWithPrevious =
-getKeepValue(keep-with-previous.within-column);
+getKeepValue(PR_KEEP_WITH_PREVIOUS | CP_WITHIN_COLUMN);
this.minHeight = this.propertyList.get(PR_HEIGHT).getLength().getValue();
setup = true;
}
-private KeepValue getKeepValue(String sPropName) {
-int propId = FOPropertyMapping.getPropertyId(sPropName);
+private KeepValue getKeepValue(int propId) {
Property p = this.propertyList.get(propId);
Number n = p.getNumber();
if (n != null) {
1.6 +2 -2
xml-fop/src/java/org/apache/fop/fo/pagination/ConditionalPageMasterReference.java
Index: ConditionalPageMasterReference.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/ConditionalPageMasterReference.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ConditionalPageMasterReference.java 28 Dec 2003 17:10:17 - 1.5
+++ ConditionalPageMasterReference.java 14 Jan 2004 00:00:37 - 1.6
@@ -92,8 +92,8 @@
*/
public void handleAttrs(Attributes attlist) throws FOPException {
super.handleAttrs(attlist);
-if (getProperty(master-reference) != null) {
-setMasterName(getProperty(master-reference).getString());
+if (getProperty(PR_MASTER_REFERENCE) != null) {
+setMasterName(getProperty(PR_MASTER_REFERENCE).getString());
}
validateParent(parent);
1.7 +2 -2 xml-fop/src/java/org/apache/fop/fo/pagination/Flow.java
Index: Flow.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/pagination/Flow.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Flow.java 16 Sep 2003 05:21:06 - 1.6
+++ Flow.java 14 Jan 2004 00:00:37 - 1.7
@@ -122,7 +122,7 @@
}
}
*/
-setFlowName(getProperty(flow-name).getString());
+setFlowName(getProperty(PR_FLOW_NAME).getString());
// Now done in addChild of
DO NOT REPLY [Bug 25480] - [PATCH] Experimental performance improvements.
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 [PATCH] Experimental performance improvements. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-14 00:05 --- OK, Finn, I just added in the inherit[] (inheritableProperties[]) array in PropertyList. Also, converted what appears to be the last of the properties (I read through the whole patch again to confirm.) We decided earlier for the time being to leave out the FO element conversions due to lack of use, so I will mark this patch as Fixed. If you see me missing anything, or would otherwise still like to keep it open, go ahead and do so. Thanks! Glen
RE: [Bug 25480] - Experimental performance improvements.
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. Delmelle [EMAIL PROTECTED] wrote: -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 exemplary as DocBook :/) ... and eventually redo part of the process with significantly less effort. Over out (for the time being :) ) Cheers, Andreas __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
RE: [Bug 25480] - Experimental performance improvements.
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 higher cardinality for each. SOLVED! Yes! Something to cheer up a morbidly downcast Packers fan two days after the fall of the mighty number '4'. I used DocBook for the frequency table because I was familiar with formatting it as PDF with FOP. I suspect that properties have similar distributions in general because XSL-FO are always generated with programs and (ransom notes notwithstanding) adhere to general styles. Really repetitive documents would be only slightly more skewed than general text documents. (Say 90-10 rather than 80-20). Someone told me where to get the style sheets for the XSL-FO specification (RenderX) and I wanted to generate the XSL-FO file for it, as a more appropriate 'challenge' for the project. -- John Austin [EMAIL PROTECTED]
Re: [Bug 25480] - Experimental performance improvements.
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 of specified properties. When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away. Yum... so a Collection of Objects is traded for a handful of --what? (Would this be the propertyValue singletons you mention?) If I mentioned PropertyValue singletons, it was a slip of the fingers. I maintain Property singletons, which are exist solely to provide access to certain static information about individual properties. What happens with 'unresolvable' Props at that point (for the cases you mention below)? See the package org.apache.fop.datatypes.indirect, especially IndirectValue, which the others extend. IndirectValue itself extends AbstractPropertyValue. Unresolved values take their place alongside the resolved properties. Do they get thrown away, or placed in a sort of Property stack for later accessing? If so, how exactly do you indicate in the FObj (or FONode) that the property in question still has to be resolved? So that, when Layout asks for this property, it is signaled that some computations still need to be made? (Pardon me if these questions mean I haven't read your docs thoroughly enough; I did read some of them, but it seems I still miss a bit of technical background to fully understand it.) The docs are far from adequate. This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed. Yes... cases I was overlooking --not so plain inheritance as the FObj's for static-content appear only once or twice every page-sequence, but their inherited properties and values vary, depending on the further processing of the tree. Still, I'm wondering whether you really need to re-parse them (as you indicated)... Couldn't you just, say, keep the Property alive and alter its value when needed? (If this would save you any re-initializing, I mean) The re-parsing idea seems very interesting to be able to say after a threesome of pages have been processed: collapse the branches of the FOTree that have already been layed out to the level below the current fo:flow (or fo:block; in any case some logical point of reference). If downstream, it turns out that their layout needs to be modified again (what are the odds? any way of predicting this?), one could trigger a re-parse from the subtree in question onwards. (This would, I think, save us some memory) The re-parse may not be strictly necessary, but it is a workable first cut. Generally, static-content and markers will not be large subtrees, so re-parsing them ought not to have a major impact. This can be experimented with once the layout is working. The beauty of the approach is that it simplifies the logic, without (I hope) costing too much in performance. In terms of the re-layout, re-parsing is not required (Re, re, re your boat...) IndirectValues will need to be re-evaluated in the new context, but the process of re-layout is not markedly different from the normal layout process. Any particular lineage descendant from an fo:flow must be able to adapt to a new environment. Because the page is a logical unit different from the flow, some line of descent from the fo:flow will be unresolved when any particular page, which is being laid out from that flow, fills up. The incomplete lineage must somehow be associated with the new page, whose region-body dimensions may be different. The layout must then proceed from the point at which the previous page filled. There are similarities here with backtracking. Backtracking layout involves backtracking to a particular lineage in a particular state (even it that is the beginning of an fo:flow.) Perhaps the same approach can be taken WRT tables: collapse all finished rows, so their cells are released. When their layed-out state turns out to be insufficient, start processing again from the row in question onwards, *with* the knowledge of what lies ahead this time... Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
