Re: PDF Transcoder patch

[Glen Mazza]

--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
> 
> Well I think it is probably bad ignore the
> things it is setup to log.  Does the logging
> stuff have a sort of default 'err' Console logger?
> You could have it use that if the one passed in is
> 'null'.
> 

We don't have that yet--also, there are too many
public methods into the images package where this
would need to be trapped (i.e., a default logger
created), so I'll keep the code as-is right now.

I tried to do a complete switch from FOUserAgent to
logger in the images package, was not able to (there
are still other cases the FOUserAgent is actually
being used.)

Thanks,
Glen


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Unnesting properties and makers.

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [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.
> 

Thanks for taking the time to explain this.  My
comprehension has increased quite a bit.

> 
> 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.
> 

I now understand what you're saying, and like the
simplification you're suggesting.  The current naming
however, is probably preferable--the word "Property" 
figures quite highly in the spec!  Do you have a
problem remaining with it?

For those (*)'ed datatypes, can't we get rid of the
datatype instead by rolling that datatype into the
equivalently named Property?  In turn, have *those*
Properties extend AbstractProperty as you suggest. 
Actually, I guess I'm just saying the same thing
you're suggesting, except to use "--Property" instead
of "--Type" for everything.

> > 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. 

But only a few of them would extend AbstractProperty,
correct--or would you plan on having all do so?

> 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.
> 

Well, instanceof is slower I believe, but better
self-commenting.  If you switch to this type of
conditional for speed, just add a short comment of its
purpose--here, to determine if we are working with an
EnumProperty or a LengthProperty.

(Another option, BTW, if you think it will cut down on
buggy programming, is to have the classes implementing
this Property interface supply unsupported interface
methods a la Peter's Read-Only BitSet[1], i.e., throw
exceptions.  We can revisit this topic later if code
errors are becoming a problem.)

Thanks,
Glen

[1]
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/datastructs/Attic/ROBitSet.java?content-type=text%2Fplain&rev=1.1.2.2


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

cvs commit: xml-fop NOTICE.txt

[pbwest]

pbwest  2004/01/25 18:43:38

  Added:   .Tag: FOP_0-20-0_Alt-Design NOTICE.txt
  Log:
  Initial version of the NOTICE file for use with the Apache License 2.0.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.1.2.1   +7 -0  xml-fop/Attic/NOTICE.txt
  
  
  
  

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

Re: Unnesting properties and makers.

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> 
> 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:
> 
> public interface Property {
>  public Length getLength();
>  public Space getSpace();
>  ...
> }
> 

Finn, just so I understand more here--what is the set
of methods that this interface would have?  (You don't
have to give me a full enumeration if it's huge--but
let me know you determine them.)  How many of them are
there--10 of them or 20 or 30 or ???

Thanks,
Glen


> public class AbstractProperty {
>  public Length getLength() {
>  return null;
>  }
> 
>  public Space getSpace() {
>  return null;
>  }
> 
>  ...
> }
> 
> public class Length extends AbstractProperty {
>  // Rest of datatypes.Length class.
>  ...
> 
>  public Length getLength() {
>  return this;
>  }
> }
> 



__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Comments on the changes to the property subsystem

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
> 
> Yes, but I would like to take the question a bit
> further and ask where 
> such information should be cached? Storing it in
> static variables caches 
> it in the classloader which makes it difficult to
> control the release of 
> the memory.
> 

Hmmm...where would this matter?  Single-use command
line would still be fine (instantly release after
running.)  As for servlet use, indeed it wouldn't be
released after every run of a document--but I don't
think you would want it released here.  This
information is needed for every run of a new document,
correct?

Also, while it is certainly a lot of data, overall its
memory usage may not be that big a deal.

Glen


> Perhaps it would be better to store the information
> in the Driver or 
> FOUserAgent, IOW to put the caching under user
> control.
> 
> If caching at the classloader level is the best way
> to do it, then it 
> makes perfect sense to do what you suggest.
> 
> regards,
> finn
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

[Glen Mazza]

Very classy response.  (You're getting good at knowing
how to handle me... ;-)

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Noted. I will make it a point in the proposal so the
> Batik people will
> be able to comment and we can develop mechnisms to
> ensure quality.
> 
> On 25.01.2004 18:42:20 Glen Mazza wrote:
> > The current (lowered) committer standards on the
> FOP
> > team definitely needs to be explained to the Batik
> > team before we get write access to their
> > project--something I'm still far from
> recommending. 
> > Jeremias, being perhaps the leading proponent of
> the
> > new committer standards, is probably in the best
> > position to explain this to Thomas--I still don't
> > understand it myself.
> 
> 
> Jeremias Maerki
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Changing policy on minimum JDK requirements for HEAD

[Glen Mazza]

I suspect we'll be OK with 1.4; and also the graphics
bugs I think Joerg was mentioning below with 1.3 makes
that latter probably not much of an option going into
2005.

Glen


--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > Here's the team's comments so far on this topic:
> > 
> > Chris:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107330434824865&w=2
> > 
> > Peter West:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107334589414161&w=2
> > 
> > Glen:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107334968118783&w=2
> > 
> > Web Maestro Clay and John Austin:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107336350330714&w=2
> > 
> > Chris 2:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107338058309642&w=2
> > 
> > Web Maestro Clay 2:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107339978229070&w=2
> > 
> > Joerg:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107341756423664&w=2
> > 
> > Peter West 2:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=107353819024636&w=2
> > 
> > Glen
> > 
> > 
> > --- Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> > 
> >>There was a thread recently which brought up that
> >>FOP HEAD currently
> >>doesn't compile under JDK 1.3. IMO this is an
> >>important point and a
> >>change of policy needs a community decision (vote)
> >>and a susequent
> >>documentation update. Since we should respect our
> >>customers a new
> >>opinion poll before the vote would be appropriate.
> >>
> >>Does anyone know of a good and up-to-date list of
> >>platforms and the JDK
> >>versions they support? I haven't found one. Sun's
> >>isn't ready, yet:
> >>http://java.sun.com/j2se/1.4.2/ports.html
> 
> Another point of interest is that 1.5 is available
> in beta releases. 
> 1.5 contains changes to the language, the only ones
> since 1.1, IIUC.  I 
> suspect that any vendor who takes Java seriously
> will port 1.5 as a 
> matter of urgency.  IBM e.g., has 1.3 and 1.4 for
> AIX and z/OS (what 
> level of 1.4 I am not sure.)  Linux/390 also has
> 1.4.
> 
> We're talking about a product (1.0) without a
> definite release date, but 
> unlikely before late 2004.  I hope to have a very
> limited functionality 
> available in alt-design by mid-year.  In any case, I
> expect that by the 
> time anyone is using alt-design in anger, 1.4 will
> not be a problem.
> 
> The 0.20 series is supported on 1.3, so an important
> question is: what 
> is the expected timeframe for availability of 1.4
> for those users who 
> are currently restricted to 1.3?  Vendors should be
> able to provide 
> their users with some indication of this.  We should
> at least ask the 
> question in any survey of users.  An ancillary
> question is: what is the 
> user's expected timeframe for migration?
> 
> Peter
> -- 
> Peter B. West
> 
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Unnesting properties and makers.

[Peter B. West]

J.Pietschmann wrote:
...
Well, one of the problems with the FO spec is that section 5.9
defines a grammar for property expressions, but this doesn't
give the whole picture for all XML attribute values in FO files.
There are also (mostly) whitespace separated lists for shorthands,
and the comma separated font family name list, where
a) whitespace is allowed around the commas and
b) quotes around the names may be omitted basically as long
 as there are no commas or whitespace in the name.
The latter means there may be unquoted sequences of characters
which has to be interpreted as a single token but are not NCNames.
It also means the in the "font" shorthand there may be whitespace
which is not a list element delimiter. I think this is valid:
 font="bold 12pt 'Times Roman' , serif"
and it should be parsed as
 font-weight="bold"
 font-size="12pt"
 font-family="'Times Roman' , serif"
then the font family can be split. This is easy for humans but can
be quite tricky to get right for computers, given that the shorthand
list has a bunch of optional elements. Specifically
 font="bold small-caps italic 12pt/14pt 'Times Roman' , A+B,serif"
should be valid too. At least, the font family is the last entry.
Note that suddenly a slash appears as delimiter between font size
and line height...
...

Alt-design takes a two-stage approach to parsing.  In the first stage 
the basic datatypes are detected.  Where there are nasty constructs hung 
over from CSS, as in 'font', the elements are collected into 
PropertyValueLists, in a manner dependent on whether the components were 
space or comma separated.  From the javadoc comment to the 'parse' 
method in ...fo.expr.PropertyParser

* Parse the property expression described in the instance variables.
*
* The PropertyValue returned by this function has the
* following characteristics:
* If the expression resolves to a single element that object is returned
* directly in an object which implements .
*
* If the expression cannot be resolved into a single object, the set
* to which it resolves is returned in a PropertyValueList object
* (which itself implements PropertyValue).
*
* The PropertyValueList contains objects whose corresponding
* elements in the original expression were separated by commas.
*
* Objects whose corresponding elements in the original expression
* were separated by spaces are composed into a sublist contained in
* another PropertyValueList.  If all of the elements in the
* expression were separated by spaces, the returned
* PropertyValueList will contain one element, a
* PropertyValueList containing objects representing each of
* the space-separated elements in the original expression.
*
* E.g., if a font-family property is assigned the string
* Palatino, New Century Schoolbook, serif, the returned value
* will look like this:
* 
* PropertyValueList(NCName('Palatino')
*   PropertyValueList(NCName('New')
* NCName('Century')
* NCName('Schoolbook') )
*   NCName('serif') )
* 
* If the property had been assigned the string
* Palatino, "New Century Schoolbook", serif, the returned value
* would look like this:
* 
* PropertyValueList(NCName('Palatino')
*   NCName('New Century Schoolbook')
*   NCName('serif') )
* 
* If a background-position property is assigned the string
* top center, the returned value will look like this:
* 
* PropertyValueList(PropertyValueList(NCName('top')
* NCName('center') ) )
* 
In the second stage (refineParsing) the lists are analysed in their 
context (e.g. 'font') and the appropriate final values are developed.

The maintenance branch tried to unify all cases into a single
framework, which quite predictably resulted in a complex and
somewhat messy code. It's also less efficient than it could be:
format="01" is (or would be) indeed parsed as expression, while
an optimized parser can take advantage of the lack of any string
operations and look for quoted strings and function calls only,
returning the trimmed XML attribute value otherwise.
This sounds promising.

Peter
--
Peter B. West 

Re: Changing policy on minimum JDK requirements for HEAD

[Peter B. West]

Glen Mazza wrote:
Here's the team's comments so far on this topic:

Chris:
http://marc.theaimsgroup.com/?l=fop-dev&m=107330434824865&w=2
Peter West:
http://marc.theaimsgroup.com/?l=fop-dev&m=107334589414161&w=2
Glen:
http://marc.theaimsgroup.com/?l=fop-dev&m=107334968118783&w=2
Web Maestro Clay and John Austin:
http://marc.theaimsgroup.com/?l=fop-dev&m=107336350330714&w=2
Chris 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107338058309642&w=2
Web Maestro Clay 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107339978229070&w=2
Joerg:
http://marc.theaimsgroup.com/?l=fop-dev&m=107341756423664&w=2
Peter West 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107353819024636&w=2
Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

There was a thread recently which brought up that
FOP HEAD currently
doesn't compile under JDK 1.3. IMO this is an
important point and a
change of policy needs a community decision (vote)
and a susequent
documentation update. Since we should respect our
customers a new
opinion poll before the vote would be appropriate.
Does anyone know of a good and up-to-date list of
platforms and the JDK
versions they support? I haven't found one. Sun's
isn't ready, yet:
http://java.sun.com/j2se/1.4.2/ports.html
Another point of interest is that 1.5 is available in beta releases. 
1.5 contains changes to the language, the only ones since 1.1, IIUC.  I 
suspect that any vendor who takes Java seriously will port 1.5 as a 
matter of urgency.  IBM e.g., has 1.3 and 1.4 for AIX and z/OS (what 
level of 1.4 I am not sure.)  Linux/390 also has 1.4.

We're talking about a product (1.0) without a definite release date, but 
unlikely before late 2004.  I hope to have a very limited functionality 
available in alt-design by mid-year.  In any case, I expect that by the 
time anyone is using alt-design in anger, 1.4 will not be a problem.

The 0.20 series is supported on 1.3, so an important question is: what 
is the expected timeframe for availability of 1.4 for those users who 
are currently restricted to 1.3?  Vendors should be able to provide 
their users with some indication of this.  We should at least ask the 
question in any survey of users.  An ancillary question is: what is the 
user's expected timeframe for migration?

Peter
--
Peter B. West 

Re: Comments on the changes to the property subsystem

[Finn Bock]

[Simon Pepping]

I have just catched up with the massive changes to the property
system. Allow me to share a few observations:
Thanks for your comments. How do you otherwise think it compares to the 
previous generated property makers?

1. If I see correctly, PropertySets is not yet used. 
Correct. Its intended use is when we, at some point in the future, want 
to store more than just the specified properties in the FObjs.

   PropertyList is
   still a HashMap keyed on property name. Is this waiting for
   some other changes to be made?
Yes. Either PropertyList should have a Property[] array indexed directly 
by the propId or the HashMap should be keyed by an Integer object with 
the same value as the propId:

   super.get(integerArray[propId]);

where integerArray is initialized as:

   integerArray[1] = new Integer(1);
   integerArray[2] = new Integer(2);
   ...
Which of these it will be depends on how much information we decide to 
store in the Fobj.

2. In FOPropertyMapping the word 'generic' is used in two different
   senses: in s_generics and getGenericMappings() on the one hand,
   and in genericBoolean etc., createGenerics() and useGeneric() on
   the other hand. This may be confusing. One might e.g. be tempted to
   think that s_generics contains the objects genericXxx only, which
   is not the case.
You are absolutely correct. I've took the names from the code which 
existed at the time. I'm also terrible at naming things so other 
suggestions will be welcome. I suggest that we rename s_generics and 
getGenericMappings to s_fomapping and getFoMappings because they deal 
with the properties from the xsl:fo spec.

3. getGenericMappings rebuilds s_generics every time it is called. In
   the current code it seems to be called only once, by FObj when the
   class is loaded. Would it not be better if getGenericMappings
   itself would ensure that the array is built only once?
Yes, but I would like to take the question a bit further and ask where 
such information should be cached? Storing it in static variables caches 
it in the classloader which makes it difficult to control the release of 
the memory.

Perhaps it would be better to store the information in the Driver or 
FOUserAgent, IOW to put the caching under user control.

If caching at the classloader level is the best way to do it, then it 
makes perfect sense to do what you suggest.

regards,
finn

DO NOT REPLY [Bug 26423] - [PATCH] Two small corrections to Property and FOPropertyMapping

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=26423

[PATCH] Two small corrections to Property and FOPropertyMapping

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-25 22:35 ---
Applied,
Thanks.

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

[bckfnn]

bckfnn  2004/01/25 14:34:50

  Modified:src/java/org/apache/fop/fo FOPropertyMapping.java
Property.java
  Log:
  Fix missing shorthands.
  
  PR: 26423
  Submitted by: Simon Pepping
  
  Revision  ChangesPath
  1.3   +2 -2  xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java
  
  Index: FOPropertyMapping.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- FOPropertyMapping.java22 Jan 2004 09:06:05 -  1.2
  +++ FOPropertyMapping.java25 Jan 2004 22:34:49 -  1.3
  @@ -412,9 +412,9 @@
*/
   public static Property.Maker[] getGenericMappings() {
   FOPropertyMapping gp = new FOPropertyMapping();
  -gp.createGenerics();
   // Create the shorthand first, they are referenced by the real properties. 
   gp.createShorthandProperties();
  +gp.createGenerics();
   gp.createAccessibilityProperties();
   gp.createAbsolutePositionProperties();
   gp.createAuralProperties();
  
  
  
  1.18  +1 -1  xml-fop/src/java/org/apache/fop/fo/Property.java
  
  Index: Property.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Property.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- Property.java 22 Jan 2004 09:06:05 -  1.17
  +++ Property.java 25 Jan 2004 22:34:49 -  1.18
  @@ -117,7 +117,7 @@
   inherited = generic.inherited;
   defaultValue = generic.defaultValue;
   percentBase = generic.percentBase;
  -if (shorthands != null) {
  +if (generic.shorthands != null) {
   shorthands = new Property.Maker[generic.shorthands.length];
   System.arraycopy(shorthands, 0, generic.shorthands, 0, 
shorthands.length);
   }
  
  
  

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

Re: Unnesting properties and makers.

[Peter B. West]

J.Pietschmann wrote:
Peter B. West wrote:
 > 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?
I'm not quite sure whether you mean by "parsing as a two-stage
process" the same as I do. In language specs, the formal description
is usually divided into a grammar level representing a Chomsky
level 2 context free grammar and a lexical level, described by simple
regular expressions (Chomsy level 0 IIRC). This is done both for
keeping the spec readable and for efficient implementation
...

This is basically what I meant - I see (and have experienced in FOP) the
difficulty of trying to parse "multiple" grammars out of a single stream
of lexical objects.
 > 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.
Well, one of the problems with the FO spec is that section 5.9
defines a grammar for property expressions, but this doesn't
give the whole picture for all XML attribute values in FO files.
There are also (mostly) whitespace separated lists for shorthands,
and the comma separated font family name list, where
a) whitespace is allowed around the commas and
b) quotes around the names may be omitted basically as long
 as there are no commas or whitespace in the name.
The latter means there may be unquoted sequences of characters
which has to be interpreted as a single token but are not NCNames.
It also means the in the "font" shorthand there may be whitespace
which is not a list element delimiter. I think this is valid:
 font="bold 12pt 'Times Roman' , serif"
and it should be parsed as
 font-weight="bold"
 font-size="12pt"
 font-family="'Times Roman' , serif"
then the font family can be split. This is easy for humans but can
be quite tricky to get right for computers, given that the shorthand
list has a bunch of optional elements. Specifically
 font="bold small-caps italic 12pt/14pt 'Times Roman' , A+B,serif"
should be valid too. At least, the font family is the last entry.
Note that suddenly a slash appears as delimiter between font size
and line height...
This usage, AFAICT, is the reason that division is specified by the
token 'div'.  All a matter of CSS compatibility.
Another set of problems is token typing, the implicit type conversion
and the very implicit type specification for the properties. While
often harmless, it shows itself for the "format" property: the
spec says the expected type is a string, which means it should be
written as format="'01'". Of course, people tend to write
format="01". While the parsed number could be cast back into a
string, unfortunately the leading zero is lost. The errata
amended 5.9 specifically for this use case that in case of an
error the original string representation of the property value
expression should be used to recover. Which temps me to use
initial-page-number="auto+1".
This is one of the disgraces of the spec - this time for compatibility
with XSLT usage.  XSL-FO just cops it sweet whenever someone else's
problem (SEP) extrudes into the XSL namespace.
Another famous case is hyphenation-char="-", which is by no
means a valid property expression. Additionally the restriction
to a string of length 1 (a "char") isn't spelled out explicitly
anywhere.
Peter
--
Peter B. West 

DO NOT REPLY [Bug 26423] - [PATCH] Two small corrections to Property and FOPropertyMapping

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=26423

[PATCH] Two small corrections to Property and FOPropertyMapping





--- Additional Comments From [EMAIL PROTECTED]  2004-01-25 21:03 ---
Created an attachment (id=10084)
The patch as described

DO NOT REPLY [Bug 26423] New: - [PATCH] Two small corrections to Property and FOPropertyMapping

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=26423

[PATCH] Two small corrections to Property and FOPropertyMapping

   Summary: [PATCH] Two small corrections to Property and
FOPropertyMapping
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]

Comments on the changes to the property subsystem

[Simon Pepping]

Hi,

I have just catched up with the massive changes to the property
system. Allow me to share a few observations:

1. If I see correctly, PropertySets is not yet used. PropertyList is
   still a HashMap keyed on property name. Is this waiting for
   some other changes to be made?

2. In FOPropertyMapping the word 'generic' is used in two different
   senses: in s_generics and getGenericMappings() on the one hand,
   and in genericBoolean etc., createGenerics() and useGeneric() on
   the other hand. This may be confusing. One might e.g. be tempted to
   think that s_generics contains the objects genericXxx only, which
   is not the case.

3. getGenericMappings rebuilds s_generics every time it is called. In
   the current code it seems to be called only once, by FObj when the
   class is loaded. Would it not be better if getGenericMappings
   itself would ensure that the array is built only once?

Regards,
Simon Pepping

-- 
Simon Pepping
email: spepping AT leverkruid.nl
home page: http://www.leverkruid.nl

Re: PDF Transcoder patch

[Thomas DeWeese]

Glen Mazza wrote:

(Resending to FOP-DEV list...)

Please take a look at my most recent changes
today--comments welcome.  

In short, for the images package, as well as for
transcoder work, I don't care much about the UA
anymore.  I switched the signatures in question to
just request a logger instead, because that is the
only thing the image package's methods are doing with
FOUserAgent parameter anyway.  
  Ok, I knew that it only used it for logging, and
only for problems at that, otherwise I wouldn't have
tried passing in null.
(Your package creates a temporary ConsoleLogger instead 
of passing in NULL--but I think I should update the package 
to be able to handle a NULL parameter by not logging
anything at all.  Comments again welcome.)
   Well I think it is probably bad ignore the
things it is setup to log.  Does the logging
stuff have a sort of default 'err' Console logger?
You could have it use that if the one passed in is 'null'.
There's a few more trivial FOUserAgent->Logger
conversions needed in the images package, but I'm
awaiting more comments before proceeding.
We can discuss the other issue in your original email
after this one.
  Where the load call is made is probably less important,
part of it was that I didn't know what conventions (if any)
existed for calling it.  My preference is for these sorts of
things to take care of themselves - so the FopPDFImage
seemed ideal -it could call it before methods that were
likely to need the sort of information it loads.
Thanks,
Glen
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:

Glen Mazza wrote:


Applied, thanks!
   Thanks Glen, any comments on my comments?  In
particular how
to get the UA?

Hi all,

  I've attached a patch for the PDF Transcoder
that Batik uses.  





__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Changing policy on minimum JDK requirements for HEAD

[Dalibor Topic]

Hi Glen,

Glen Mazza wrote:
Here's the team's comments so far on this topic:
On a somewhat related side note, most of those features asked for by the 
 fop team from jdk 1.4 (logging, prefs, new util classes) exist in free 
runtimes (kaffe, gcj, sablevm, ...) already. The major blocker on 
running all of fop on free runtimes is the need to use non-distributable 
code like jimi for some features, and the state of java2d support on 
free runtimes (in the works, I plan to merge in agile2d into kaffe for a 
speedy opengl based java2d implementation, and there is work on a 
cairo/gtk+ based java2d implementation in GNU Classpath).

Given that the free runtimes are quite widely ported, to even rather 
obscure platforms (arm-acorn or superh-linux [1], anyone?), and are 
catching up quite quickly[2], I hope the issue of 'does a vendor support 
java 1.4 on some platform' is going to be moot in a year or two, since 
you may be able to simply use [3] gcj/gij/kaffe/sablevm on your platform 
of choice to satisfy your customer's needs.

cheers,
dalibor topic
[1] Kaffe has more than 50 platforms in CVS and a few more to be merged 
in ;)
[2] http://www.kaffe.org/~robilad/loc.png ;)
[3] Depending on developers actively maintaining these runtimes there, 
of course ;)

Re: Changing policy on minimum JDK requirements for HEAD

[Glen Mazza]

Here's the team's comments so far on this topic:

Chris:
http://marc.theaimsgroup.com/?l=fop-dev&m=107330434824865&w=2

Peter West:
http://marc.theaimsgroup.com/?l=fop-dev&m=107334589414161&w=2

Glen:
http://marc.theaimsgroup.com/?l=fop-dev&m=107334968118783&w=2

Web Maestro Clay and John Austin:
http://marc.theaimsgroup.com/?l=fop-dev&m=107336350330714&w=2

Chris 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107338058309642&w=2

Web Maestro Clay 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107339978229070&w=2

Joerg:
http://marc.theaimsgroup.com/?l=fop-dev&m=107341756423664&w=2

Peter West 2:
http://marc.theaimsgroup.com/?l=fop-dev&m=107353819024636&w=2

Glen


--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> There was a thread recently which brought up that
> FOP HEAD currently
> doesn't compile under JDK 1.3. IMO this is an
> important point and a
> change of policy needs a community decision (vote)
> and a susequent
> documentation update. Since we should respect our
> customers a new
> opinion poll before the vote would be appropriate.
> 
> Does anyone know of a good and up-to-date list of
> platforms and the JDK
> versions they support? I haven't found one. Sun's
> isn't ready, yet:
> http://java.sun.com/j2se/1.4.2/ports.html
> 
> Jeremias Maerki
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

[Jeremias Maerki]

Noted. I will make it a point in the proposal so the Batik people will
be able to comment and we can develop mechnisms to ensure quality.

On 25.01.2004 18:42:20 Glen Mazza wrote:
> The current (lowered) committer standards on the FOP
> team definitely needs to be explained to the Batik
> team before we get write access to their
> project--something I'm still far from recommending. 
> Jeremias, being perhaps the leading proponent of the
> new committer standards, is probably in the best
> position to explain this to Thomas--I still don't
> understand it myself.


Jeremias Maerki

Re: PDF Transcoder patch

[Glen Mazza]

(Resending to FOP-DEV list...)

Please take a look at my most recent changes
today--comments welcome.  

In short, for the images package, as well as for
transcoder work, I don't care much about the UA
anymore.  I switched the signatures in question to
just request a logger instead, because that is the
only thing the image package's methods are doing with
FOUserAgent parameter anyway.  (Your package creates a
temporary ConsoleLogger instead of passing in
NULL--but I think I should update the package to be
able to handle a NULL parameter by not logging
anything at all.  Comments again welcome.)

There's a few more trivial FOUserAgent->Logger
conversions needed in the images package, but I'm
awaiting more comments before proceeding.

We can discuss the other issue in your original email
after this one.

Thanks,
Glen


--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> 
> > Applied, thanks!
> 
> Thanks Glen, any comments on my comments?  In
> particular how
> to get the UA?
> 
> >>Hi all,
> >>
> >>I've attached a patch for the PDF Transcoder
> >>that Batik uses.  
> 
> 
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> I will probably have some time next month to write a
> proposal on how our
> two projects can move closer together to make the
> code sharing happen.
> 
> Jeremias Maerki
> 

Ummm...Jeremias, remember, your recent nominations for
FOP committers included those who don't even know Java
[1][2] and haven't submitted any code patches (and
barely any--*if* any--doc patches at that.)  Per you
and Joerg's new standards, to be a committer on the
FOP team, just being helpful on the mailing lists
suffices.[3]

The Batik team, like Xalan, Struts, HTTPD, and other
successful projects, however, still keeps programmatic
committer standards and pretty high ones at that. 
(Take a look at the solid backgrounds of the Batik
committers [4], for example.)  To protect their user
base and their excellent products, they don't
gratuitously (and dangerously) hand out write access
to people as tokens of appreciation.

If you and Joerg want to insist on committers who
haven't even learned CVS and Ant yet, then interfacing
with other teams is going to be problematic, if only
for the safety of their code.  I wish you had both
thought out the consequences beforehand (I certainly
didn't appreciate being made into the "mean one" on
this issue)--regardless, the Batik team should be
aware of this issue.

The current (lowered) committer standards on the FOP
team definitely needs to be explained to the Batik
team before we get write access to their
project--something I'm still far from recommending. 
Jeremias, being perhaps the leading proponent of the
new committer standards, is probably in the best
position to explain this to Thomas--I still don't
understand it myself.

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=106640132114490&w=2
[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=107262232610618&w=2
[3]
http://marc.theaimsgroup.com/?l=fop-dev&m=107271927618049&w=2
[4] http://xml.apache.org/batik/whoAreWe.html

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: PageViewport question

[J.Pietschmann]

Tibor Vyletel wrote:
I would like to ask, what's the reason why PageViewport class is not
descended from Area class.
Mainly because it's not an area. It makes a difference for example
for rendering into AWT windows and such.
J.Pietschmann

Re: Getting rid of JIMI

[J.Pietschmann]

Jeremias Maerki wrote:
I will probably have some time next month to write a proposal on how our
two projects can move closer together to make the code sharing happen.
Stuff that comes to mind immediately:
- fonts, metrics, character and word width
- various configuration stuff
- character normalization and line breaking (for SVG flow text)
- command line wrapper
- common area rendering
- embedded images, of course
- API concerns, as discussed: hooks for custom resolvers for fonts,
 images, URLs in general
J.Pietschmann

Bug report for Fop [2004/01/25]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font  |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in |
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly  |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables   |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body  |
| 3497|New|Maj|2001-09-07|id already exists error when using span="all" attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling="uniform" does not work on images...  |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored?  |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG   |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5047|Ass|Nor|2001-11-23|Dotted border style is not supported  |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values   |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|fi (fi ligature) produces a "sharp"? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render   |
| 6483|New|Nor|2002-02-15|Table, Loop, "footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect   |
| 6929|New|Nor|2002-03-06|Cells border hidden by cells background   |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7140|New|Enh|2002-03-15|page-position attribute set to "last" on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space   |
| 7487|New|Nor|2002-03-26|break-before="page" for table inserts empty page  |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block  |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images  |
| 8050|New|Nor|2002-04-13|Soft hyphen (­) is not handled properly   |
| 8321|New|Nor|2002-04-19|from-

cvs commit: xml-fop/src/java/org/apache/fop/svg PDFImageElementBridge.java

[gmazza]

gmazza  2004/01/25 06:40:14

  Modified:src/java/org/apache/fop/fo/flow ExternalGraphic.java
   src/java/org/apache/fop/image AbstractFopImage.java
BmpImage.java FopImage.java GifImage.java
JimiImage.java JpegImage.java
   src/java/org/apache/fop/render/awt AWTRenderer.java
   src/java/org/apache/fop/render/pdf PDFRenderer.java
   src/java/org/apache/fop/render/ps PSRenderer.java
   src/java/org/apache/fop/svg PDFImageElementBridge.java
  Log:
  Switching from passing the FOUserAgent for several of the image
  functions to its internal Avalon logger instead.  (Only object used within
  FOUserAgent parameter, plus this library is also used for the PDFTranscoder, plus
  FOUserAgent not always available from everywhere anymore.)  Holding off making
  a complete switch in this package (FOUserAgent still used in a few more
  places, albeit only its logger is being requested)
  until others comment.
  
  Revision  ChangesPath
  1.18  +1 -1  xml-fop/src/java/org/apache/fop/fo/flow/ExternalGraphic.java
  
  Index: ExternalGraphic.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/ExternalGraphic.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ExternalGraphic.java  17 Jan 2004 19:29:46 -  1.17
  +++ ExternalGraphic.java  25 Jan 2004 14:40:14 -  1.18
  @@ -158,7 +158,7 @@
   return;
   }
   // load dimensions
  -if (!fopimage.load(FopImage.DIMENSIONS, getUserAgent())) {
  +if (!fopimage.load(FopImage.DIMENSIONS, getUserAgent().getLogger())) {
   // error
   url = null;
   return;
  
  
  
  1.4   +8 -8  xml-fop/src/java/org/apache/fop/image/AbstractFopImage.java
  
  Index: AbstractFopImage.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/image/AbstractFopImage.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- AbstractFopImage.java 30 Aug 2003 17:59:53 -  1.3
  +++ AbstractFopImage.java 25 Jan 2004 14:40:14 -  1.4
  @@ -57,7 +57,7 @@
   import java.awt.Color;
   
   // FOP
  -import org.apache.fop.apps.FOUserAgent;
  +import org.apache.avalon.framework.logger.Logger;
   
   /**
* Base class to implement the FopImage interface.
  @@ -157,13 +157,13 @@
* @param ua the user agent for handling logging etc.
* @return true if the loading was successful
*/
  -public synchronized boolean load(int type, FOUserAgent ua) {
  +public synchronized boolean load(int type, Logger logger) {
   if ((loaded & type) != 0) {
   return true;
   }
   boolean success = true;
   if (((type & DIMENSIONS) != 0) && ((loaded & DIMENSIONS) == 0)) {
  -success = success && loadDimensions(ua);
  +success = success && loadDimensions(logger);
   
   if (!success) {
   return false;
  @@ -171,13 +171,13 @@
   loaded = loaded | DIMENSIONS;
   }
   if (((type & BITMAP) != 0) && ((loaded & BITMAP) == 0)) {
  -success = success && loadBitmap(ua);
  +success = success && loadBitmap(logger);
   if (success) {
   loaded = loaded | BITMAP;
   }
   }
   if (((type & ORIGINAL_DATA) != 0) && ((loaded & ORIGINAL_DATA) == 0)) {
  -success = success && loadOriginalData(ua);
  +success = success && loadOriginalData(logger);
   if (success) {
   loaded = loaded | ORIGINAL_DATA;
   }
  @@ -193,7 +193,7 @@
* @param ua the user agent
* @return true if the loading was successful
*/
  -protected boolean loadDimensions(FOUserAgent ua) {
  +protected boolean loadDimensions(Logger logger) {
   return false;
   }
   
  @@ -205,7 +205,7 @@
* @param ua the user agent
* @return true if the loading was successful
*/
  -protected boolean loadBitmap(FOUserAgent ua) {
  +protected boolean loadBitmap(Logger logger) {
   return false;
   }
   
  @@ -217,7 +217,7 @@
* @param ua the user agent
* @return true if the loading was successful
*/
  -protected boolean loadOriginalData(FOUserAgent ua) {
  +protected boolean loadOriginalData(Logger logger) {
   return false;
   }
   
  
  
  
  1.3   +10 -10xml-fop/src/java/org/apache/fop/image/BmpImage.java
  
  Index: BmpImage.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/image/BmpImage.java,v

PageViewport question

[Tibor Vyletel]

Hello,
 
I would like to ask, what's the reason why 
PageViewport class is not descended from Area class. It's a bit 
complicating factor in design of one my class which processes different kinds of 
Area objects.
 
Thanks in advance.
 
Tibor

RE: Unnesting properties and makers.

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]



> LayoutProps, for example, is already present, but seems to be
> underused at the moment.)
>
>

Speaking of which: what exactly is the purpose of having a
spaceBefore/spaceAfter in fop.traits.LayoutProps and another in
fop.fo.properties.CommonMarginBlock ? Got something to do with the
prop-to-trait mapping? Or is this just an unfortunate clashing of names?

> Cheers,
>
> Andreas
>
>
>
>

cvs commit: xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc RtfListStyleNumber.java

[bckfnn]

bckfnn  2004/01/25 05:59:33

  Modified:src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfListStyleNumber.java
  Log:
  Fix a 'javadoc' warning about missing @see target.
  
  Revision  ChangesPath
  1.4   +2 -2  
xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfListStyleNumber.java
  
  Index: RtfListStyleNumber.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfListStyleNumber.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RtfListStyleNumber.java   24 Jan 2004 22:24:14 -  1.3
  +++ RtfListStyleNumber.java   25 Jan 2004 13:59:33 -  1.4
  @@ -68,7 +68,7 @@
   /**
* Gets call before a RtfListItem has to be written.
* 
  - * @see org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListStyle#writeListPrefix()
  + * @see 
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListStyle#writeListPrefix(RtfListItem)
*/
   public void writeListPrefix(RtfListItem item)
   throws IOException {
  
  
  

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

RE: Unnesting properties and makers.

[Andreas L. Delmelle]

> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>

> Each of the Type classes also implements the get 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();
>

Hmmm... coming back to my recent question about the use of/access to the
background-color property: I somehow would feel much for further extending
the way the Common*Properties are handled. IIC, the calls like the above
should only happen in the background via the propMgr of the FObj, and not
become part of the public API.

As a concrete example, in Layout, I would rather see something like:

private AreaDimensionProps adimProps;
...
protected void initProperties(PropertyManager propMgr) {
adimProps = propMgr.getAreaDimensionProps();
...
}

...
Length ipd = aProps.ipd;
(maybe the latter can become more abstract
  PropertyValue ipd = aProps.ipd; )

Does this sound crazy? (FYI: the AreaDimensionProps class does not exist
yet... LayoutProps, for example, is already present, but seems to be
underused at the moment.)


Cheers,

Andreas

Re: Getting rid of JIMI

[Jeremias Maerki]

On 25.01.2004 12:46:08 Thomas DeWeese wrote:
> Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > Damn, you're right. I wonder why we haven't made use of this, yet. BTW,
> > is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF
> > renderer) or is this separately developed code (ASF origin)?
> 
> This was contributed by Sun and is I believe the code came
> from JAI (great group of guys).  There have been some bug
> fixes/improvements since then but it is basically that code.
> 
> > You know that there's a number of people who would actually be
> > interested in creating/having a BSD-style image (codec) library? 
> 
>Sure, but given imageio does it make sense to put a lot of
> effort into an independent codec library?  If I were going to
> create a codec library I would create one that plugged into
> image-io.

I agree that the codec library should plug into ImageIO, but this API
is only available since JDK 1.4. I'm sure that if there's enough
interest in supporting the image library under pre-1.4 JDKs there will
be contributions to make that happen. No need to lose too much time if
it's not needed at first.

> > I think that should be one of the packages that should be separated 
> > out, when FOP and Batik get closer together.
> 
> This probably makes sense.

I will probably have some time next month to write a proposal on how our
two projects can move closer together to make the code sharing happen.


Jeremias Maerki

Changing policy on minimum JDK requirements for HEAD

[Jeremias Maerki]

There was a thread recently which brought up that FOP HEAD currently
doesn't compile under JDK 1.3. IMO this is an important point and a
change of policy needs a community decision (vote) and a susequent
documentation update. Since we should respect our customers a new
opinion poll before the vote would be appropriate.

Does anyone know of a good and up-to-date list of platforms and the JDK
versions they support? I haven't found one. Sun's isn't ready, yet:
http://java.sun.com/j2se/1.4.2/ports.html

Jeremias Maerki

RE: Unnesting properties and makers.

[Andreas L. Delmelle]

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
>

> Ah well, I overlooked this

And it's easy to overlook. The spec-layout is quite misleading, putting this
XSL-addition in the place it is now... If you're reading diagonally, it
looks more like an insignificant note.


>
> Uh no, it's more ugly: line-height is actually meant to be
> a "compound" property, like space-before. I.e. it is possible
> to write
>  ...

Yup, suspected _something_ like this. I wanted to add the little phrasing:
'to make the party complete' ;)

> The precedence and conditionality are combination of the
> half-leading with space-before and space-after at the beginning
> and the end of the block, I think.
>

Sounds like the correct interpretation, only that it's expressed more
generally 'above the first ... or after the last ... placed in a reference
area' --comes down to the same thing, in this case.

> I see why they thought this is necessary, but this kind of spec
> makes it unnecessary hard to follow.
>

Hmmm.. I do agree that first making it look like line-height is a simple
property, and then adding a little extension to the definition, making it
exactly the opposite --that's definitely not the way to go. The definition
should be revised here, if you ask me...

Bottom-line is that line-height is supposed to be treated as a compound
property, for which the subfields are defaulted to values according to the
definition in the spec when it is used as a simple property.


Cheers,

Andreas

FO Tree needing knowledge of Area Tree

[Glen Mazza]

Some of the previous heated discussion on whether the
FO tree could be created without knowledge of the Area
Tree apparently has been answered by the XSL
specification, with Peter West's view being correct. 
Property resolution *does* in some areas rely on
knowledge of the Area Tree, and the XML Result Tree
--> FO Tree --> Area Tree does not always occur in a
sequential manner.

If this issue comes up again, Peter, next time just
point to the spec!

Glen

http://www.w3.org/TR/2001/REC-xsl-20011015/slice3.html#fo-jc-intro

Ch. 3 Spec:

"Central to this model of formatting is refinement.
This is a computational process which finalizes the
specification of properties based on the attribute
values in the XML result tree. Though the XML result
tree and the formatting object tree have very similar
structure, it is helpful to think of them as separate
conceptual entities. Refinement involves

-propagating the various inherited values of
properties (both implicitly and those with an
attribute value of "inherit"), 

-evaluating expressions in property value
specifications into actual values, which are then used
to determine the value of the properties,

-converting relative numerics to absolute numerics,

-constructing some composite properties from more than
one attribute

Some of these operations (particularly evaluating
expressions) depend on knowledge of the area tree.
Thus refinement is not necessarily a straightforward,
sequential procedure, but may involve look-ahead,
back-tracking, or control-splicing with other
processes in the formatter. Refinement is described
more fully in [5 Property Refinement / Resolution]."

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

RE: Getting rid of JIMI

[Thomas DeWeese]

Jeremias Maerki <[EMAIL PROTECTED]> wrote:

Damn, you're right. I wonder why we haven't made use of this, yet. BTW,
is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF
renderer) or is this separately developed code (ASF origin)?
   This was contributed by Sun and is I believe the code came
from JAI (great group of guys).  There have been some bug
fixes/improvements since then but it is basically that code.
You know that there's a number of people who would actually be
interested in creating/having a BSD-style image (codec) library? 
  Sure, but given imageio does it make sense to put a lot of
effort into an independent codec library?  If I were going to
create a codec library I would create one that plugged into
image-io.
I think that should be one of the packages that should be separated 
out, when FOP and Batik get closer together.
   This probably makes sense.


On 24.01.2004 12:21:48 Thomas DeWeese wrote:
It is certainly true that javax.imageio is the direction
to go in the future.
However, It is probably worth pointing out that you already
include a PNG encoder/decoder with the FOP distribution,
from Batik!
  org.apache.batik.ext.awt.image.codec.PNGImageEncoder
  org.apache.batik.ext.awt.image.codec.PNGImageDecoder
Let me know if you want/need more info (including pointers
to where FOP does the image loading would be helpful as well).

Re: Unnesting properties and makers.

[J.Pietschmann]

Andreas L. Delmelle wrote:
Does anybody know what "" means for line-height???
Know? I guess not. But judging from the spec...
Ah well, I overlooked this
"XSL adds the following value with the following meaning:

  Specifies the minimum, optimum, and maximum values, the conditionality and
precedence of the 'line-height' that is used in determining the
half-leading."
Perhaps this is just a way of saying that 'line-height' can be 'shorthanded'

line-height="min opt max cond prec"??
Uh no, it's more ugly: line-height is actually meant to be
a "compound" property, like space-before. I.e. it is possible
to write
 
I see why they thought this is necessary, but this kind of spec
makes it unnecessary hard to follow.
J.Pietschmann