Compiling HEAD

2004-01-23 Thread Peter B. West 
Is HEAD supposed to be compiling?  I'm getting errors starting at 
datatypes/ColorType.java.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

Alt-design: framework for marker handling

2004-01-23 Thread Peter B. West 
Recent commits to alt-design have laid the groundwork for handling of 
fo:marker within fo:static-content.

...xml.SyncedXmlEventsBuffer now extends 
...datastructs.SyncedCircularBuffer and implements 
...xml.XmlEventSource.  A new class, ...xml.XmlEventsArrayBuffer, also 
implements XmlEventSource.

...xml.XmlEventReader, which has been extracted from 
...xml.SyncedXmlEventsBuffer, requires an XmlEventSource argument to its 
constructor, and provides a general pull-parsing mechanism based (for 
now) on an XmlEventSource, and later, probably, an XmlEventSourceStack.

...fo.flow.FoMarker and ...fo.flow.FoStaticContent both use a new method 
in XmlEventReader to flush their contents into an XmlEventArrayBuffer, 
for later reading during the construction of static regions.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

Re: Unnesting properties and makers.

2004-01-23 Thread Peter B. West 
Finn Bock wrote:

I have not yet removed the properties.xsl file from CVS. I guess it 
should be removed since it isn't used anymore.


[J.Pietschmann]

I think you could leave the file there for now. 


Ok.

It should be
sufficient to  inactivate the related task in the buildfile
(for example putting it in an XML comment).


Too late for that, but I'll reactive the lines as comments tomorrow.

Does anyone know why we wrap the datatypes instances in a property 
instance?


No.

Actually we should strive to use a proper parse tree for
property expressions:
1. Create a few classes for the symbols in the property
  expression grammar (section 5.9 of the spec). I think we need
 as terminals
 - AbsoluteNumeric
 - RelativeNumeric
 - Color (the #N thingy)
 - String (aka Literal)
 - NCName (everything else, basically, including enum tokens and
  inherit)
 and for the nonterminals
 - PropertyFunction
 - Some classes for the operators
2. Write a proper parser (maybe using ANTLR, at least for bootstrap)
 which produces a proper parse tree.
With my naive understanding of parsing as a two-stage process (lexemes 
- higher level constructs) I have been curious about earlier comments 
of yours about multi-stage parsing.  Can ANTLR do this sort of thing?

3. Add methods to the objects for resolving relative numeric values
 (percentages, em) and for evaluation.
4. Perhaps add constant folding to the parser.


Interesting. What issues do we have in property parsing that is solved 
by this? I'm only aware of arithmetic on relative numerics which doesn't 
work.
Given the amount of hacking I had to do to parse everything that could 
legally be thrown at me, I am very surprised that these are the only 
issues in HEAD parsing.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

Re: Compiling HEAD

2004-01-23 Thread Finn Bock 
[Peter B. West]

Is HEAD supposed to be compiling? 
Yes. I can compile it just fine from a fresh checkout.

I'm getting errors starting at datatypes/ColorType.java.
Which errors? Have you tried to do a ant clean first?

regards,
finn

Re: Getting rid of JIMI

2004-01-23 Thread Jeremias Maerki 
The ASF does see a problem. Until the FSF has clarified the relationship
between linking and Java's import concept the ASF's policy is not to
allow usage of LGPL packages. There are certain exceptions. For example,
if you have a JAI-compatible image codec under the LPGL you could use it
because FOP would directly link only with the JAI API, not with the
codec that's made available through JAI.

See also:
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

I think it's no problem if you modify your copy of FOP to use one of the
LGPL packages. The ASF simply cannot publish code that uses these
packages at the moment.

A possible work-around is to establish a better plug-in concept for our
image lib adapters in HEAD (not 0.20.5) so interested parties can create
plug-ins outside of the ASF to use LGPL libraries.

On 23.01.2004 00:19:28 Dalibor Topic wrote:
 While I understand that GPL2 and ASL 1.1 are not compatible, I don't see 
 a problem with LGPL 2.1 and ASL 1.1. Could you elaborate?


Jeremias Maerki

Re: @author tags in source files (Was re:cvs commit....)

2004-01-23 Thread Jeremias Maerki 

On 21.01.2004 15:34:15 Glen Mazza wrote:
 --- Peter B. West [EMAIL PROTECTED] wrote:
  It seems to me that a major motivation for writing
  OSS is precisely the 
  recognition.  When alt-design is completed, I will
  probably have written 
  the bulk of it, as well as designing it, and I have
  no intention of 
  removing my @author tags.   Why should they be
  removed in favour of a 
  mailing-list address?
  
 
 Of course they shouldn't.

Clearly, my English is worse than I thought. I thought I said that
credits, after removeing them from the code, go on our website along
with a description what a contributor has done for the project. A
concentrated hall of fame will allow much better visibility of the
contributions to the project. If you leave author tags in the code you
have to explicitly search for them or by chance stumble upon them.

I have absolutely no intention to lessen anyone's contribution to this
project. On the contrary, with my proposal I intended improve the
visibility of any contribution.

There's another point. Within the ASF a group of people is legally
concerned about the attributions in code as they could be exploited by
lawyers. It's an unlikely event but the cencerns are there. The ASF
simply wants to protect every contributor from lawsuits. Sometimes that
means that certain habits need to be avoided.

 In my work, I always try to
 recognize those people taking FOP to the
 dance--something, IMHO, that Jeremias needs to be
 better focused on--

Please explain what I've done wrong. I know I forgot to add the
Submitted By comment in a CVS commit message once or twice but I
always added that comment into the changes files.

 and put them on a pedestal, making
 sure that they're being properly honored.  You are
 certainly one of them and your credits should not be
 removed.
 
 I also disagree on having the team page be watered
 down to that of a phone book where anyone on demand
 gets listed on it.

By on demand I don't mean that anyone simply can request to be put
there. I simply try to include the case where we forget someone. Please
don't interpret any bad intents into my proposal.


Jeremias Maerki

cvs commit: xml-fop/src/java/org/apache/fop/fo FoRoot.java

2004-01-23 Thread pbwest 
pbwest  2004/01/23 04:47:58

  Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FoRoot.java
  Log:
  Remove pageSequenceMasters HashMap.
  Add LayoutMasterSet to FoPageSequence constructor.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.8   +9 -17 xml-fop/src/java/org/apache/fop/fo/Attic/FoRoot.java
  
  Index: FoRoot.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Attic/FoRoot.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  --- FoRoot.java   20 Jan 2004 05:45:55 -  1.1.2.7
  +++ FoRoot.java   23 Jan 2004 12:47:58 -  1.1.2.8
  @@ -1,6 +1,4 @@
   /*
  - * $Id$
  - * 
* 
*   The Apache Software License, Version 1.1
* 
  @@ -48,15 +46,12 @@
* James Tauber [EMAIL PROTECTED]. For more  information on the Apache 
* Software Foundation, please see http://www.apache.org/.
*  
  - *
  - * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
  - * @version $Revision$ $Name$
  + * $Id$
*/
   
   package org.apache.fop.fo;
   
   import java.util.Arrays;
  -import java.util.HashMap;
   import java.util.NoSuchElementException;
   
   import org.apache.fop.apps.FOPException;
  @@ -73,10 +68,12 @@
   /**
* ttFoRoot/tt is the class which processes the fo:root start element
* XML event.
  - * p
* The building of all of the fo tree, and the forwarding of FO tree events
* on to further stages of processing, will all take place within the
* ttbuildFoTree()/tt method of this class instance.
  + * 
  + * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
  + * @version $Revision$ $Name$
*/
   
   public class FoRoot extends FONode {
  @@ -111,12 +108,6 @@
   [PropNames.MEDIA_USAGE] = 0;
   }
   
  -/** 
  - * The HashMap of PageSequenceMaster objects produced from the
  - * layout-master-set.
  - */
  -private HashMap pageSequenceMasters;
  -
   /** Offset of declarations child node. */
   private int declarations = -1;
   
  @@ -174,7 +165,6 @@
   FoLayoutMasterSet layoutMasters =
   new FoLayoutMasterSet(getFOTree(), this, ev);
   // Clean up the fo:layout-master-set event
  -pageSequenceMasters = layoutMasters.getPageSequenceMasters();
   ev = xmlevents.getEndElement(XmlEventReader.DISCARD_EV, ev);
   namespaces.relinquishEvent(ev);
   layoutMasters.deleteSubTree();
  @@ -199,14 +189,16 @@
   if (ev == null)
   throw new FOPException(No page-sequence found.);
   firstPageSeq = numChildren();
  -new FoPageSequence(getFOTree(), this, (FoXmlEvent)ev);
  +new FoPageSequence(
  +getFOTree(), this, (FoXmlEvent)ev, layoutMasters);
   ev = xmlevents.getEndElement(XmlEventReader.DISCARD_EV, ev);
   namespaces.relinquishEvent(ev);
   while ((ev = xmlevents.expectStartElement
   (FObjectNames.PAGE_SEQUENCE, XmlEvent.DISCARD_W_SPACE))
  != null) {
   // Loop over remaining fo:page-sequences
  -new FoPageSequence(getFOTree(), this, (FoXmlEvent)ev);
  +new FoPageSequence(
  +getFOTree(), this, (FoXmlEvent)ev, layoutMasters);
   ev = xmlevents.getEndElement(XmlEventReader.DISCARD_EV, ev);
   namespaces.relinquishEvent(ev);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop/src/java/org/apache/fop/fo/flow FoPageSequence.java

2004-01-23 Thread pbwest 
pbwest  2004/01/23 04:52:23

  Modified:src/java/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoPageSequence.java
  Log:
  Added LayoutMasterSet to constructor.
  Changed name of the index of the fo:flow child to flowChild.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.8   +11 -9 
xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoPageSequence.java
  
  Index: FoPageSequence.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoPageSequence.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  --- FoPageSequence.java   21 Jan 2004 07:03:23 -  1.1.2.7
  +++ FoPageSequence.java   23 Jan 2004 12:52:23 -  1.1.2.8
  @@ -1,6 +1,4 @@
   /*
  - * $Id$
  - * 
* 
*   The Apache Software License, Version 1.1
* 
  @@ -48,8 +46,7 @@
* James Tauber [EMAIL PROTECTED]. For more  information on the Apache 
* Software Foundation, please see http://www.apache.org/.
*  
  - *
  - * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
  + * $Id$
*/
   
   package org.apache.fop.fo.flow;
  @@ -66,12 +63,15 @@
   import org.apache.fop.fo.FObjectNames;
   import org.apache.fop.fo.PropNames;
   import org.apache.fop.fo.expr.PropertyException;
  +import org.apache.fop.fo.pagination.FoLayoutMasterSet;
   import org.apache.fop.xml.FoXmlEvent;
   import org.apache.fop.xml.XmlEvent;
   import org.apache.fop.xml.XmlEventReader;
   
   /**
* Implements the fo:simple-page-master flow object
  + * @author a href=mailto:[EMAIL PROTECTED]Peter B. West/a
  + * @version $Revision$ $Name$
*/
   public class FoPageSequence extends FONode {
   
  @@ -128,16 +128,18 @@
   private int title = -1;
   /** Child index of first fo:static-content child. */
   private int firstStaticContent = -1;
  -/** Child index of first fo:flow child. */
  -private int firstFlow = -1;
  +/** Child index of fo:flow child. */
  +private int flowChild = -1;
   
   /**
* @param foTree the FO tree being built
* @param parent the parent FONode of this node
* @param event the ttXmlEvent/tt that triggered the creation of
* this node
  + * @param layoutMasters the layout master set
*/
  -public FoPageSequence(FOTree foTree, FONode parent, FoXmlEvent event)
  +public FoPageSequence(FOTree foTree, FONode parent, FoXmlEvent event,
  +FoLayoutMasterSet layoutMasters)
   throws TreeException, FOPException
   {
   super(foTree, FObjectNames.PAGE_SEQUENCE, parent, event,
  @@ -175,7 +177,7 @@
   (FObjectNames.FLOW, XmlEvent.DISCARD_W_SPACE);
   if (ev == null)
   throw new FOPException(No flow found.);
  -firstFlow = numChildren();
  +flowChild = numChildren();
   new FoFlow(getFOTree(), this, (FoXmlEvent)ev);
   ev = xmlevents.getEndElement(XmlEventReader.DISCARD_EV, ev);
   namespaces.relinquishEvent(ev);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unnesting properties and makers.

2004-01-23 Thread Finn Bock 

Does anyone know why we wrap the datatypes instances
in a property 
instance? I think we could avoid the property
instance by having the 
datatypes extends an AbstractProperty class which
implement a Property 
interface:
[Glen Mazza]

Could you explain why we have the datatypes instances
to begin with--what they're for?  I'm not sure what
their precise purpose is.
The datatypes are the slightly more complex property values. The 
property classes wraps the datatype in order to give the datatypes a 
common interface.

This list show the concrete Property subclasses and the datatypes that 
each of them wraps.

CharacterPropertychar
ColorTypePropertyColorType (*)
CondLengthProperty   CondLength (*)
EnumProperty int
KeepProperty Keep (*)
LengthPairProperty   LengthPair (*)
LengthProperty   Length,AutoLength,FixedLength,PercentLength (*)
LengthRangeProperty  LengthRange (*)
ListProperty Vector
NCNameProperty   String
NumberProperty   Number
NumericProperty  Numeric (*)
SpacePropertySpace
StringProperty   String
ToBeImplementedProperty
Some of the concrete property subclasses wraps standard java types such 
as int, char, String, Number and Vector and for these properties we 
still need a wrapper. But some of them, marked with (*), wraps a 
datatype which is under our own control and for those properties, the 
datatype class could also function as the property wrapper.

Offhand, it's doesn't seem natural to go without
Property objects--they are kept in the PropertyList
and indexed by the property ID in that list. 
That would still be the case. Everything stored in the PropertyList 
implements the Property interface. In the list below of the new property 
classes, all the typeType classes implements Property and are stored 
in PropertyList.

CharacterType   char
ColorTypeType   it-self
CondLengthType  it-self
EnumTypeint
KeepTypeit-self
LengthPairType  it-self
LengthType, AutoLengthType, FixedLengthType, PercentLengthType
it-self
LengthRangeType it-self
ListTypeVector
NCNameType  String
NumberType  Number
NumericType it-self
SpaceType   it-self
StringType  String
ToBeImplementedType
Each of the typeType classes also implements the gettype methods 
from Property so the layout must do exactly the same as it does now to 
extract the right value:

   propertyList.get(PR_INLINE_PROGRESSION_DIMENSION).
 getLengthRange().getOptimum().getLength();
For the classes which are both property and datatype, the gettype 
method becomes:

public type gettype() {
this this;
}
Furthermore, those are the objects requested by
layout.  What would be your alternative storage
technique otherwise--I believe, we do (frequently?)
have more than one datatype per property, correct?
I remember two cases, but I can only find one at the moment: In 
Title.setup():

prop = this.propertyList.get(PR_BASELINE_SHIFT);
if (prop instanceof LengthProperty) {
Length bShift = prop.getLength();
} else if (prop instanceof EnumProperty) {
int bShift = prop.getEnum();
}
This would stay the same, except LengthProperty would be called 
LengthType and EnumProperty would be called EnumType. Except that the 
code above should IMHO use if (prop.getLength() != null) to test for a 
length type instead of using instanceof.

I'm not sure what I propose as the naming convention for the new 
combined property/value, but Alt-Design calls them typeType so I used 
that in the list above.

regards,
finn

cvs commit: xml-fop build.xml

2004-01-23 Thread jeremias 
jeremias2004/01/23 07:07:29

  Modified:.build.xml
  Log:
  Fixed a bug where I got a NoClassDefFoundError when I'm using a 
build-local.properties where I set optional.lib.dir to an absolute Windows path. These 
absolute paths weren't removed somehow resulting in NoClassDefFound errors due to a 
illegal Class-Path entry in fop.jar's manifest.
  
  Revision  ChangesPath
  1.102 +1 -0  xml-fop/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-fop/build.xml,v
  retrieving revision 1.101
  retrieving revision 1.102
  diff -u -r1.101 -r1.102
  --- build.xml 22 Jan 2004 22:40:51 -  1.101
  +++ build.xml 23 Jan 2004 15:07:29 -  1.102
  @@ -471,6 +471,7 @@
   pathconvert property=manifest-classpath dirsep=/ pathsep=  
refid=libs-run-classpath
 map from=${basedir}${file.separator}lib${file.separator} to=/
 map from=${basedir}${file.separator}build${file.separator}fop.jar to=/
  +  map from=${optional.lib.dir}${file.separator} to=/
   /pathconvert
   
   jar jarfile=${build.dir}/${name}.jar basedir=${build.dest} 
includes=org/**,hyph/**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting rid of JIMI

2004-01-23 Thread Dalibor Topic 
Hi Jeremias,

thanks for the quick response.

Jeremias Maerki wrote:
The ASF does see a problem. Until the FSF has clarified the relationship
between linking and Java's import concept the ASF's policy is not to
allow usage of LGPL packages. There are certain exceptions. For example,
if you have a JAI-compatible image codec under the LPGL you could use it
because FOP would directly link only with the JAI API, not with the
codec that's made available through JAI.
See also:
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
Thanks a lot for the link! That was precisely the sort of information I 
was looking for.

A possible work-around is to establish a better plug-in concept for our
image lib adapters in HEAD (not 0.20.5) so interested parties can create
plug-ins outside of the ASF to use LGPL libraries.
I'm not very well aware of the differences between all the different 
image io APIs, so please excuse me if my next question is a typical 
newbie question. If, for example, we had javax.imageio support working 
for PNG images in GNU Classpath (and Kaffe), would/could FOP 
automatically use that, or would it still need to use JIMI?

The reasoning behind this being that PNG image support seems to be part 
of JDK 1.4 anyway, so it will be implemented in free runtimes eventually 
as well.

cheers,
dalibor topic

Re: Getting rid of JIMI

2004-01-23 Thread Jeremias Maerki 
No apologies required!

Image IO (javax.imageio) support is not there, yet, I'm afraid. But if
you created an implementation for Image IO then your idea would work.
Shouldn't be very hard. Check the org.apache.fop.image package. You
wouldn't need to use JIMI. Think of JIMI, JAI and ImageIO as equals.
They all provide an API to access bitmap images.


On 23.01.2004 16:08:55 Dalibor Topic wrote:
  A possible work-around is to establish a better plug-in concept for our
  image lib adapters in HEAD (not 0.20.5) so interested parties can create
  plug-ins outside of the ASF to use LGPL libraries.
 
 I'm not very well aware of the differences between all the different 
 image io APIs, so please excuse me if my next question is a typical 
 newbie question. If, for example, we had javax.imageio support working 
 for PNG images in GNU Classpath (and Kaffe), would/could FOP 
 automatically use that, or would it still need to use JIMI?
 
 The reasoning behind this being that PNG image support seems to be part 
 of JDK 1.4 anyway, so it will be implemented in free runtimes eventually 
 as well.


Jeremias Maerki

cvs commit: xml-fop/src/java/org/apache/fop/fo BorderWidthPropertyMaker.java BoxPropShorthandParser.java CompoundPropertyMaker.java GenericShorthandParser.java IndentPropertyMaker.java LineHeightPropertyMaker.java

2004-01-23 Thread bckfnn 
bckfnn  2004/01/23 13:39:59

  Modified:src/java/org/apache/fop/fo BorderWidthPropertyMaker.java
BoxPropShorthandParser.java
CompoundPropertyMaker.java
GenericShorthandParser.java
IndentPropertyMaker.java
LineHeightPropertyMaker.java
  Log:
  Fix javadoc warnings.
  
  Revision  ChangesPath
  1.2   +2 -2  xml-fop/src/java/org/apache/fop/fo/BorderWidthPropertyMaker.java
  
  Index: BorderWidthPropertyMaker.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/fo/BorderWidthPropertyMaker.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BorderWidthPropertyMaker.java 22 Jan 2004 09:06:05 -  1.1
  +++ BorderWidthPropertyMaker.java 23 Jan 2004 21:39:59 -  1.2
  @@ -79,7 +79,7 @@
   /**
* Check the value of the style property and return a length of 0 when
* the style is NONE.
  - * @see org.apacge.fo.Property.Maker.get(int, PropertyList, boolean, boolean)
  + * @see org.apache.fo.Property.Maker#get(int, PropertyList, boolean, boolean)
*/
  
   public Property get(int subpropId, PropertyList propertyList,
  
  
  
  1.7   +2 -2  xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java
  
  Index: BoxPropShorthandParser.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- BoxPropShorthandParser.java   22 Jan 2004 09:06:05 -  1.6
  +++ BoxPropShorthandParser.java   23 Jan 2004 21:39:59 -  1.7
  @@ -65,8 +65,8 @@
* Stores 1 to 4 values of same type.
* Set the given property based on the number of values set.
* Example: padding, border-width, border-color, border-style, margin
  - * @see org.apache.fop.fo.GenericShorthandParser#convertValueForProperty(String,
  - * Property.Maker, PropertyList)
  + * @see org.apache.fop.fo.GenericShorthandParser#convertValueForProperty(
  + * int, ListProperty, Property.Maker, PropertyList)
*/
   protected Property convertValueForProperty(int propId,
  ListProperty listProperty,
  
  
  
  1.2   +3 -3  xml-fop/src/java/org/apache/fop/fo/CompoundPropertyMaker.java
  
  Index: CompoundPropertyMaker.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/CompoundPropertyMaker.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CompoundPropertyMaker.java22 Jan 2004 09:06:05 -  1.1
  +++ CompoundPropertyMaker.java23 Jan 2004 21:39:59 -  1.2
  @@ -83,7 +83,7 @@
   }
   
   /**
  - * @see org.apache.fop.fo.Property#useGeneric(Property.Maker)
  + * @see org.apache.fop.fo.Property.Maker#useGeneric(Property.Maker)
*/
   public void useGeneric(Property.Maker generic) {
   super.useGeneric(generic);
  @@ -295,4 +295,4 @@
   }
   return p;
   }
  -}
  \ No newline at end of file
  +}
  
  
  
  1.6   +1 -2  xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java
  
  Index: GenericShorthandParser.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- GenericShorthandParser.java   22 Jan 2004 09:06:05 -  1.5
  +++ GenericShorthandParser.java   23 Jan 2004 21:39:59 -  1.6
  @@ -55,8 +55,7 @@
   public class GenericShorthandParser implements ShorthandParser {
   
   /**
  - * Constructor. The listprop to operate on must b set with setList().
  - * @see #setList(ListProperty) 
  + * Constructor. 
*/
   public GenericShorthandParser() {
   }
  
  
  
  1.2   +2 -2  xml-fop/src/java/org/apache/fop/fo/IndentPropertyMaker.java
  
  Index: IndentPropertyMaker.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/IndentPropertyMaker.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- IndentPropertyMaker.java  22 Jan 2004 09:06:05 -  1.1
  +++ IndentPropertyMaker.java  23 Jan 2004 21:39:59 -  1.2
  @@ -96,7 +96,7 @@
   
   /**
* Calculate the corresponding value for start-indent and end-indent.  
  - * @see CorrespondingPropertyMaker.compute(PropertyList)
  + * @see CorrespondingPropertyMaker#compute(PropertyList)
*/
   public Property