Re: PDF Transcoder patch

--- 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, ther

Re: Unnesting properties and makers.

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

cvs commit: xml-fop NOTICE.txt

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

Re: Unnesting properties and makers.

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

Re: Comments on the changes to the property subsystem

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

Re: Getting rid of JIMI

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 1

Re: Changing policy on minimum JDK requirements for HEAD

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

Re: Unnesting properties and makers.

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 sepa

Re: Changing policy on minimum JDK requirements for HEAD

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

Re: Comments on the changes to the property subsystem

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

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

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_bu

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

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

Re: Unnesting properties and makers.

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

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

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_bu

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

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_bu

Comments on the changes to the property subsystem

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 FOProperty

Re: PDF Transcoder patch

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 inste

Re: Changing policy on minimum JDK requirements for HEAD

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

Re: Changing policy on minimum JDK requirements for HEAD

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: h

Re: Getting rid of JIMI

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 befo

Re: PDF Transcoder patch

(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

Re: Getting rid of JIMI

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

Re: PageViewport question

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

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 normaliza

Bug report for Fop [2004/01/25]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

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

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

PageViewport question

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.

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

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

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/

RE: Unnesting properties and makers.

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

Re: Getting rid of JIMI

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 (A

Changing policy on minimum JDK requirements for HEAD

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

RE: Unnesting properties and makers.

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

FO Tree needing knowledge of Area Tree

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 Re

RE: Getting rid of JIMI

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 th

Re: Unnesting properties and makers.

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 preced