DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-19 10:30 --- Simon, concernig names, unnecessary if, etc. , I agree with you. It seems to me that your change concerning hyphenation exceptions works, otherwise the hyphenation points would appear in the wrong place because of the punctuation marks. The strange pdf generated is due, IMO, to a couple of problems: -1- In the last test case the text is (quite oddly) divided among 3 TextLM **[...]** (philanthrop ic). Specifying the property linefeed-treatment=ignore, the text is all in a TLM. Removing from the test file the linefeed after (philanthropic)., the text is still split in two parts: *** *** (philanthropic). So, it seems there is an irksome bug affecting text splitting. -2- The last line in a justified paragraph is sometimes justified too (bug 28314). The phantom linefeed is by default treated as a space, and so it is adjusted. Anyway, I was pleased to notice that, although shattered, the word is correctly collected and hyphenated. Regards Luca
DO NOT REPLY [Bug 28237] - [PATCH] Use the commons logging LogFactory also in Fop.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28237. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28237 [PATCH] Use the commons logging LogFactory also in Fop.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-19 11:30 --- Glen, One more... 3) setLevel() has been part of the Log4J API since before Logger was born; i.e. when Logger was Category. What Sun is up to is summed up neatly in the java.util.logging description: http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/package-summary.html#package_description The Log4J documentation also mentions the critical importance of logging for debugging, quoting Kernighan and Pike on the superiority of judicious logging over interactive debuggers. (Yes!) I discovered the limitations because I started the process of converting the recently introduced 1.4 logging in alt-design to use commons-logging. At some stage I will probably subclass commons-logging and apply that, so that at least the logging invocations will look the same. Thanks, Glen, for taking the trouble to look up the details of the usage of commons-logging. Unfortunately, Craig doesn't address the issue. Currently, commons-logging *forces* us to use the kind of work-around he describes. But that work-around is only necessary because of the absence of setLevel(). Not including it is an ideological decision which cripples the logging. In the absence of commons-logging, users of 1.4, Log4J and Lumberjack can all setLevel dynamically. Craig might have decided that that is a Very Bad Thing, and that we must be protected from ourselves. But the four points have no bearing on whether to provide setLevel(); they are all about getting the native logger, which users are forced to do by the refusal to include setLevel in the interface. If it were included, there would be no need to get the native logger. The real workaround is to modify the interface and the implementations. All any of us have to do is understand the arguments. If they persuade us, it doesn't matter how many or how few have adopted it. Likewise if they fail to persuade.
DO NOT REPLY [Bug 28314] - [PATCH] Alignment of the last line in a justified block
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28314. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28314 [PATCH] Alignment of the last line in a justified block [EMAIL PROTECTED] changed: What|Removed |Added Summary|Alignment of the last line |[PATCH] Alignment of the |in a justified block|last line in a justified ||block --- Additional Comments From [EMAIL PROTECTED] 2004-04-19 13:31 --- Hi Luca, I'm not certain that your first solution of changing Block.handleWhiteSpace() to ignore spaces in last TextLM text is bullet proof. I havent done any testing, so it may be okay. Certainly for ordinary Blocks it may be fine, but for other FOs, which inherit from Block, this may not be acceptable. For example, table-cells, with auto-layout feature on, spaces at the end might be relevant. I'm not rejecting your solution, but I would like to explore your second idea a bit further. Another reason why it may not be good to change the logic in Block.handleWhiteSpace() is that it currently follows the description for whitespace handling in the spec fairly closely and putting other conditions in, will detract from this.
Jean-Christian Bucelle/NCE/AMADEUS is out of the office.
I will be out of the office starting 16/04/2004 and will not return until 26/04/2004. I will respond to your message when I return.
cvs commit: xml-fop/src/java/org/apache/fop/area CoordTransformer.java
pbwest 2004/04/19 08:22:42 Modified:src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design CoordTransformer.java Log: Minor doc changes Revision ChangesPath No revision No revision 1.1.2.2 +2 -6 xml-fop/src/java/org/apache/fop/area/Attic/CoordTransformer.java Index: CoordTransformer.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/CoordTransformer.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- CoordTransformer.java 24 Feb 2004 07:54:00 - 1.1.2.1 +++ CoordTransformer.java 19 Apr 2004 15:22:42 - 1.1.2.2 @@ -254,13 +254,9 @@ } /** + * Construct a coordinate transformation matrix. * @param absRefOrient * @param writingMode - * @param absVPrect - * @return - */ -/** - * Construct a coordinate transformation matrix. * @param absVPrect absolute viewpoint rectangle * @param relBPDim the relative block progression dimension * @param relIPDim the relative inline progression dimension - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo FONode.java
pbwest 2004/04/19 08:24:51
Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FONode.java
Log:
Modified a logging call level
Revision ChangesPath
No revision
No revision
1.2.2.18 +5 -2 xml-fop/src/java/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
retrieving revision 1.2.2.17
retrieving revision 1.2.2.18
diff -u -r1.2.2.17 -r1.2.2.18
--- FONode.java 16 Apr 2004 05:17:00 - 1.2.2.17
+++ FONode.java 19 Apr 2004 15:24:51 - 1.2.2.18
@@ -21,6 +21,7 @@
import java.util.BitSet;
import java.util.HashMap;
import java.util.Iterator;
+import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.fop.apps.FOPException;
@@ -241,14 +242,16 @@
int property;
int prop = foKeys[propx].intValue();
if ( ! attrBitSet.get(prop)) {
-log.info(Ignoring
+if (log.isLoggable(Level.FINE)) {
+log.fine(Ignoring
+ PropNames.getPropertyName(prop)
+ on
+ FObjectNames.getFOName(type)
+ for attribute set
+ FOPropertySets.getAttrSetName(stateFlags)
+ .);
-continue;
+continue;
+}
}
String attrValue = foAttributes.getFoAttrValue(prop);
try {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo/properties Property.java
pbwest 2004/04/19 08:34:29
Modified:src/java/org/apache/fop/fo/properties Tag:
FOP_0-20-0_Alt-Design Property.java
Log:
Moved borderEdge and private processEdgeValue and processEdgeList methods to
BorderAbsoluteShorthand
Revision ChangesPath
No revision
No revision
1.1.2.10 +7 -176xml-fop/src/java/org/apache/fop/fo/properties/Property.java
Index: Property.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Property.java,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -u -r1.1.2.9 -r1.1.2.10
--- Property.java 25 Feb 2004 23:09:09 - 1.1.2.9
+++ Property.java 19 Apr 2004 15:34:29 - 1.1.2.10
@@ -26,7 +26,6 @@
import org.apache.fop.apps.Fop;
import org.apache.fop.datatypes.Auto;
-import org.apache.fop.datatypes.ColorType;
import org.apache.fop.datatypes.CountryType;
import org.apache.fop.datatypes.EnumType;
import org.apache.fop.datatypes.LanguageType;
@@ -459,10 +458,9 @@
// TODO: validate here
return pv;
case PropertyValue.LIST:
-System.out.println(value);
throw new PropertyException
(PropertyValueList passed to Property.refineParsing for
-+ propName);
++ propName + \n + value.toString());
default:
if ( ! nested) {
if ((dataTypes COMPOUND) != 0)
@@ -531,8 +529,7 @@
* @throws PropertyException if ilist/i contains more than
* one element or if the contained element is not a list.
*/
-protected PropertyValueList spaceSeparatedList
-(PropertyValueList list)
+protected PropertyValueList spaceSeparatedList (PropertyValueList list)
throws PropertyException
{
if (list.size() != 1)
@@ -653,8 +650,7 @@
{
int initialValueType =
PropertyConsts.pconsts.getInitialValueType(property);
-//System.out.println(In Property getInitialValue property
-//+ property);
+logger.fine(In Property getInitialValue property + property);
if ((initialValueType Property.USE_GET_IT_FUNCTION) != 0)
throw new PropertyException
(Property.getInitialValue() called for property with
@@ -669,6 +665,7 @@
case NONE_IT:
return new None(property);
case AURAL_IT:
+// TODO Arrange to ignore and log PropertyNotImplemented
throw new PropertyNotImplementedException
(Aural properties not implemented:
+ PropNames.getPropertyName(property));
@@ -677,172 +674,6 @@
(Unexpected initial value type + initialValueType
+ for + PropNames.getPropertyName(property));
}
-}
-
-/**
- * 'value' is a PropertyValueList or an individual PropertyValue.
- * If 'value' is a PropertyValueList, it must contain a single
- * PropertyValueList, which in turn contains the individual elements.
- *
- * 'value' can contain a parsed Inherit value,
- * parsed FromParent value, parsed FromNearestSpecified value,
- * or, in any order;
- * border-width
- * a parsed NCName value containing a standard border width
- * or a Numeric length value (including a percentage)
- * border-style
- * a parsed NCName value containing a standard border style
- * border-color
- * a parsed ColorType value, or an NCName containing one of
- * the standard colors
- *
- * pThe value(s) provided, if valid, are converted into a list
- * containing the expansion of the shorthand. The elements may
- * be in any order. A minimum of one value will be present.
- *
- * a border-EDGE-color ColorType or inheritance value
- * a border-EDGE-style EnumType or inheritance value
- * a border-EDGE-width MappedNumeric or inheritance value
- *
- * N.B. this is the order of elements defined in
- * ShorthandPropSets.borderRightExpansion
- */
-protected PropertyValue borderEdge
-(int propindex, FONode foNode, PropertyValue value,
-int styleProp, int colorProp, int widthProp)
-throws PropertyException
-{
-return borderEdge(propindex, foNode, value, styleProp,
-colorProp, widthProp, NOT_NESTED);
-}
-
-protected PropertyValue borderEdge
-(int propindex, FONode foNode, PropertyValue value, int styleProp,
cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BorderLeft.java BorderBottom.java BorderRight.java BorderTop.java
pbwest 2004/04/19 08:37:24
Modified:src/java/org/apache/fop/fo/properties Tag:
FOP_0-20-0_Alt-Design BorderLeft.java
BorderBottom.java BorderRight.java BorderTop.java
Log:
Made subclass of BorderAbsolute shorthands
Revision ChangesPath
No revision
No revision
1.1.2.4 +15 -13
xml-fop/src/java/org/apache/fop/fo/properties/Attic/BorderLeft.java
Index: BorderLeft.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Attic/BorderLeft.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- BorderLeft.java 19 Feb 2004 03:11:40 - 1.1.2.3
+++ BorderLeft.java 19 Apr 2004 15:37:23 - 1.1.2.4
@@ -25,7 +25,7 @@
import org.apache.fop.fo.PropNames;
import org.apache.fop.fo.expr.PropertyException;
-public class BorderLeft extends Property {
+public class BorderLeft extends BorderAbsoluteShorthand {
public static final int dataTypes = SHORTHAND;
public int getDataTypes() {
@@ -57,18 +57,20 @@
* pThe value(s) provided, if valid, are converted into a list
* containing the expansion of the shorthand. The elements may
* be in any order. A minimum of one value will be present.
+ * ul
+ * lia border-EDGE-color codeColorType/code or inheritance value/li
+ * lia border-EDGE-style codeEnumType/code or inheritance value/li
+ * lia border-EDGE-width codeMappedNumeric/code or inheritance
+ * value/li
+ * /ul
+ * pN.B. this is the order of elements defined in
+ * codeShorthandPropSets.borderRightExpansion/code
*
- * a border-EDGE-color ColorType or inheritance value
- * a border-EDGE-style EnumType or inheritance value
- * a border-EDGE-width MappedNumeric or inheritance value
- *
- * N.B. this is the order of elements defined in
- * ShorthandPropSets.borderRightExpansion
- *
- * @param propindex - the ttint/tt property index.
- * @param foNode - the ttFONode/tt being built
- * @param value ttPropertyValue/tt returned by the parser
- * @return ttPropertyValue/tt the verified value
+ * @param propindex index of the property
+ * @param foNode on which this property value is expressed
+ * @param value of the property expression parsed in the previous stages
+ * of property expression evaluation
+ * @return the refined and expanded value
*/
public PropertyValue refineParsing
(int propindex, FONode foNode, PropertyValue value)
1.1.2.4 +15 -13
xml-fop/src/java/org/apache/fop/fo/properties/Attic/BorderBottom.java
Index: BorderBottom.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/Attic/BorderBottom.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- BorderBottom.java 19 Feb 2004 03:11:40 - 1.1.2.3
+++ BorderBottom.java 19 Apr 2004 15:37:23 - 1.1.2.4
@@ -25,7 +25,7 @@
import org.apache.fop.fo.PropNames;
import org.apache.fop.fo.expr.PropertyException;
-public class BorderBottom extends Property {
+public class BorderBottom extends BorderAbsoluteShorthand {
public static final int dataTypes = SHORTHAND;
public int getDataTypes() {
@@ -57,18 +57,20 @@
* pThe value(s) provided, if valid, are converted into a list
* containing the expansion of the shorthand. The elements may
* be in any order. A minimum of one value will be present.
+ * ul
+ * lia border-EDGE-color codeColorType/code or inheritance value/li
+ * lia border-EDGE-style codeEnumType/code or inheritance value/li
+ * lia border-EDGE-width codeMappedNumeric/code or inheritance
+ * value/li
+ * /ul
+ * pN.B. this is the order of elements defined in
+ * codeShorthandPropSets.borderRightExpansion/code
*
- * a border-EDGE-color ColorType or inheritance value
- * a border-EDGE-style EnumType or inheritance value
- * a border-EDGE-width MappedNumeric or inheritance value
- *
- * N.B. this is the order of elements defined in
- * ShorthandPropSets.borderRightExpansion
- *
- * @param propindex - the ttint/tt proeprty index.
- * @param foNode - the ttFONode/tt being built
- * @param value ttPropertyValue/tt returned by the parser
- * @return ttPropertyValue/tt the verified value
+ * @param propindex index of the property
+ * @param foNode on which this property value is expressed
+ * @param value of the property expression parsed in the
Re: [Bug 27901] - [PATCH] TextCharIterator.remove() does not work properly
J.Pietschmann wrote: Hmmm...not that big a deal to me, but I would be inclined to keep the whitespace removal out of the LayoutManagers, because it is fo:block specific I don't quite understand this argument. Handling space-before is also fo:block specific. Where should this logic be put, then? If you replace whitespace handling with replacing every occurrence of the letter 'A' with 'B', a similar idea, you can see what I'm getting at--the fo:block should be able to clean itself up (if there is such a property defined for the fo mandating that cleanup) prior to presenting itself to layout, so layout needn't be concerned with the whitespace handling. The earlier this is done, preferably in flow.Block, the less work (and fewer instantiations) for FOText object and TextLayoutManager. It is fo:block specific in the sense that not all fo:blocks mandate it. The analogy with space-before is imperfect because (1) it is really only usable as a trait, because it interacts with other Area objects; (2) unlike whitespace handling, all fo:blocks have this value, even if 0 it must at least be queried by layout; and (3) fo:blocks can resolve into multiple Area.Blocks (because they could go past one page), only the first of which needs to worry about space-before. Furthermore, this division of fo:blocks into possibly multiple Area.blocks is decided by Layout. So handling space-before is not really fo:block specific, it is actually Area.block-specific. Note that whitespace handling includes removing spaces around line breaks which are introduced during the layout process. IIRC flow.Block is parsed into multiple FOText items, each of which get fed into the TextLayoutManager. I'm not certain that line breaks are actually being created during layout; rather, during parsing, I suspect the BPD is just incremented and the next line is rendered. Glen
