Re: Unnecessary import of Constants

Sorry about that; I don't use Eclipse. I just fixed the Constants problem--but the TextAlignLastMaker will be more difficult--it appears to have been there for a long time, well before my recent changes. Glen --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > Eclipse is still complaining to me

Re: Recent tidying of alt.design

I checked the API, what you describe below is just as it states: http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html Its guidance on proper initial value and load factor sizing may be of help for you. Glen --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > Recent minor changes to alt.d

Re: Regression caused by the string->int conversion

Fixed. Thanks. Glen --- Finn Bock <[EMAIL PROTECTED]> wrote: __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

Re: PropertySets

It's probably not *yet* time to set 1.4 as the JDK to code against for 1.0, but it probably wouldn't be much of a disaster if we did so either. By the time 1.0 is release-ready, 90% will either be on 1.4 or will be upgrading to 1.4 along with the upgrade of FOP 0.20.x to 1.0. The remaining 10% ca

RE: Draft discussion of Federation proposal

lists with ours as well--and one giant ML just won't work. Searching the combined archive would also be a mess.) FOP and Batik support two distinct W3C specs, and as such should remain separate projects. Thanks, Glen Mazza Apache FOP Team __ Do you Yahoo

Re: Using Just the Font Metrics Stuff From FOP

--- Eliot Kimber <[EMAIL PROTECTED]> wrote: > Let me know if you need more from me on these > patches. > > Cheers, > > Eliot Yes, an explanation in Bugzilla on what the patches are for (I haven't been following the thread, and if it takes some weeks to be applied, no one will remember what they'

Re: Remember to update the copyright year

Yes, thanks--I just forgot to a few minutes ago though :( I'll leave a message on my monitor to reduce the chances of me forgetting. Glen --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > Jeremias Maerki wrote: > > Fellow committers > > > > We've got a new year. Please remember to update > the c

Re: [Bug 25480] - Experimental performance improvements.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > 1.) For the new PropertyList constructor (in the > patch), you appear to be > > duplicating the element ID argument, once as "el", > the other time > > as "elementId"--just to confirm, they are > referring to the same thing (and > > hence one of them

Re: Compile error in HEAD

--- Simon Pepping <[EMAIL PROTECTED]> wrote: > > The cause is that the import section is not > sufficient: > > package org.apache.fop.fo.properties; > > import org.apache.fop.fo.*; > import org.apache.fop.apps.FOPException; > > With these import statements the compiler applies > interface

Re: Compile error in HEAD

--- Glen Mazza <[EMAIL PROTECTED]> wrote: > > Yes, but the Eclipse warnings of "unneeded imports" > drives Peter West and a few others crazy. If the > above does not work, our only other solution would > be > a fully qualified import statement. > oops...I

RE: [Bug 25480] - Experimental performance improvements.

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > > > [Andreas L. Delmelle] > > > In this case, however, I think you > > > can't fully 'push' these onto the descendants, > as this would > > > lead to absurd storag

Re: [Bug 25480] - Experimental performance improvements.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > I.e., for all those references to the 'foo' > property > > instance for the children of an FO where that > value > > would be inherited, we don't have to create a new > > Property instance, just a reference to the > inherited > > instance. > > Right, th

RE: [Bug 25480] - Experimental performance improvements.

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > What I'm very concerned about, for example, are > cases like tables, where it > would be quite awkward to have the TableCell FObj's > reference their own copy > of a Property instance To put it more precisely, the individual Properties of an F

Re: [Bug 25480] - Experimental performance improvements.

OK--this may also be overkill then. Thank you for the analysis. Glen --- Finn Bock <[EMAIL PROTECTED]> wrote: > [Glen Mazza] > > > This sounds like it could be an excellent idea--a > > PropertyRepository (extending, of course, a > > DelmelleRepository (tm)

RE: [Bug 25480] - Experimental performance improvements.

;Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > > > OK--this may also be overkill then. Thank you for > the > > analysis. > > > > It will prove useful, I am

Re: [PATCH] abandoning code-generated Property.Maker

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > The patch does not unnest the Property.Maker class. > It doesn't matter > all that much to me, but if it is considered a good > idea it is easy to do. > Ooops...I think I had misread the code there. Actually, hold off on this then. > > Should the v

Comments on new property maker implementation

Finn, I've looked at your changes--I like them, and I'm thankful to have someone on our team to be able to redesign the properties as you have. Getting rid of the 250 autogenerated or so classes will be a welcome improvement. Comments right now: 1.) Unlike what I was saying earlier, I don't th

Re: [PATCH] abandoning code-generated Property.Maker

Team, I moved the 64 or so property value interfaces from separate autogenerated files to Constants.java yesterday. The work is not perfect--there are still a few linkages to (autogenerated) generic enumerations (I will fix these after we apply Finn's latest properties patch), a couple of inter

Re: Comments on new property maker implementation

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > But the biggest improvement is IMHO the easy ability > to create special > maker subclasses to handle the corner cases. Take a > look at > IndentPropertyMaker for the calculation of start and > end-indent and at > BorderWidthPropertyMaker for the spe

Re: Comments on new property maker implementation

--- "Peter B. West" <[EMAIL PROTECTED]> wrote: [Finn Bock] > > > > You should perhaps also be aware that the values > in a static array gets > > assigned to the array one element at a time. So > > > > static int[] a = { > 101,102,103,104,105,106,107,108 }; > > > > becomes in bytecodes: > >

Re: [PATCH] abandoning code-generated Property.Maker

Worked great--thanks! Glen --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > > > select="document(propfile)//property[not(@type='generic')]" > > /> ) > ... > > I am not an XSLT guru--offhand, d

RE: Properties question ( again? )

Please fix it whenever you get write access. Glen --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > > Shouldn't the latter be rewritten as : > > > > > > this.BackgroundColor = bProps.backColor > > > > I'd think so. > > > __ Do you Yahoo!? Yahoo! Ho

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

Indeed, last vote about 6-8 months ago was to deprecate the @author tags, and that rule is still on our web site. We'll need a revote to allow them. As a committer, I personally have never bothered with @author tags, but I do like how they show outside developer and corporate contributions to our

Re: Newbie committer questions.

Actually, yes and no, as I learned a ton--XSLT, Java, and FOP--from his coding. (Jeremias never taught me that much! ;) However, I am quite fatigued right now and need a few days off. Finn, would you mind taking over the rest of your last patch? The issues I found can be discussed and changed,

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

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

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > Hi, > > After updating from CVS, it is most likely necessary > to do an "ant > clean" to get rid of the old generated maker > classes, before building. > Great job--the build is now only 604 classes--1/3 removed! This simplification does make the prop

Re: Getting rid of JIMI

--- Dalibor Topic <[EMAIL PROTECTED]> wrote: > If that's not the case, would it be possible to use > the LGPLd code from > http://catcode.com/pngencoder/ and > http://www.sixlegs.com/software/png/ > for the job, and dropping the dependency on JIMI > completely? > No, (L)GPL and the Apache licen

Re: PDF Transcoder patch

Applied, thanks! Glen --- Thomas DeWeese <[EMAIL PROTECTED]> wrote: > 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/s

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: > > 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: PDF Transcoder patch

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

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

Re: Getting rid of JIMI

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

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

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: PDF Transcoder patch

so Thomas can just send "myImageBaseDir" to the same method for his transcoder work, without needing to bother with an FOUserAgent. Glen --- Chris Bowditch <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > > I tried to do a complete switch from FOUserAgent >

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > however, is probably preferable--the word > "Property" > > figures quite highly in the spec! Do you have a > > problem remaining with it? > > Not at all, it is just that I though it would be Good--we can stick with "Property" then. > > Indeed. Whic

Re: Updating licenses

--- "Peter B. West" <[EMAIL PROTECTED]> wrote: > When we get the OK, I'll use this to update the > licenses in alt-design, > and, if that works, I can also do the maint and HEAD > sources. > Sounds quite good. You've made *many* friends today... ;) Glen __ D

RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Simon Pepping > [mailto:[EMAIL PROTECTED] > > > > > All in all I think that this change simplifies the > code, and would be > > a good change. > > > > Allow me to make some notes: > > > > 1. Would it not

Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > I like it. How does this sound: > > - Unnest Property.Maker to PropertyMaker and put it > in fo.properties. > - Roll the datatypes classes into their property > class and move the >property class to fo.properties (but without > unnesting their Maker >

ExampleXML2PDF.java not working

I cannot get the ExampleXML2PDF.java example[1] to work with CVS HEAD. Jeremias, I believe you were going to fix something in the Driver class--something wrong with driver.getContentHandler(), correct? Is that where the problem is? I can look at it if you don't have the time right now. Thanks,

Re: ExampleXML2PDF.java not working

Thanks for the help. --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Fixed it...sort of. I've done what I've announced in > the thread below. > I'm not sure, however, if it will work in every > situation as there is > still an obscure little code section in render(). > > Anyway, ExampleXML2PDF p

RE: Just a small question...

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Nikolai Grigoriev [mailto:[EMAIL PROTECTED] > > > > If you look into XEP's main jar (e.g. > xep372_trial.jar), you can find > > the preprocessor stylesheet under > com/renderx/xep/pre/processor.xsl. > >

(FOP examples) XSLT question

Since this is FOP work-related, I guess I can be allowed to ask a very newbie XSLT question here: I just added a parameter to one of the XSL example files (eventually to show the use of a JAXP transformer.setParam() call) as follows: ... ... Version ... But it keeps outputting "Version 1" in

RE: Just a small question...

[Pardon me, Peter, for more shooting from the hip...] --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > --nor should FOP developers even > > be looking at its internals. Matter of simple > > integrity. > > I think this is a bit over the top. Suppose that > tomorrow, someone gets > fired a

RE: Just a small question...

I really appreciate your enthusiasm and am very happy, upon you finding something possibly of use to FOP on another ML, of your bringing it back to the team. We should just be careful in this particular case, however. (BTW, you may also wish to look at Xalan, Batik, and Cocoon for other ideas--*t

(Peter) Re: Just a small question...

Peter, Both of the remarks that Nikolai quoted [1] in leaving the list came from Andreas [2], not from me [3]. I was only stating the obvious in my warnings not to use their code. I don't appreciate you trying--for those who haven't been following the thread--to attribute Andreas' quotes to me.

Re: Contributions from competing products (was: Just a small question...)

--- Clay Leeds <[EMAIL PROTECTED]> wrote: > I would posit that the *issue* of how to deal with > PATCH contributions > should be discussed so that a plan/protocol can be > achieved. This needs > to occur at least at the "project" (FOP) level > (possibly ending with a > VOTE), but should really

Re: (Peter) Re: Just a small question...

No big deal--but I do wish to add that my phrasing that you were *intentionally* trying to attribute Andreas' quotes to me was wrong, and I do apologize for that. Anyway, let's get back to work... Glen --- "Peter B. West" <[EMAIL PROTECTED]> wrote: __ Do you Ya

Re: FOP components

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > - avalon and logging for the base library. > The avalon jar is indeed quite small (only 25K or so), but this dependency I'd like us to eventually get rid of in favor of what Xalan does with its messaging and i18n instead. (I suspect AH or RX don't

(test message)

Pardon me...just testing POP forwarding... Thanks, Glen

Re: FOP components

> Peter B. West wrote: > > If we go to 1.4, should we also use 1.4 logging (java.util.logging) and > > possibly also the preferences API (java.util.prefs) for > > configuration/user agent/user prefs? > > > > I don't know Avalon, so I don't know what other facilities from there we > > are using or c

Re: FOP components

+1 --- Chris Bowditch <[EMAIL PROTECTED]> wrote: > You would make FOP unavailable to 70% of the user > base. Take a look at > Sun's Xmlroff, it has a feature set comparable to > the maintainance > branch, its free, but FOP has a much bigger user > base. Why? because > xmlroff doesnt run on wind

Re: PMC representation change, still ot ack'ed

Sounds good. --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > I've just noticed that Joerg still hasn't been > formally voted in in the > XML PMC as a replacement for Peter. Since this was > more than 2 months > ago I wanted to check if this is still ok. I'll > start the vote in the > XML PMC on W

JAXP question

Team, I deprecated some of the methods in XSLTInputHandler to encourage use of JAXP. Any problems here--this was basically agreed to, but several months ago--I just never got to it. Also, big issue--I'm trying to implement command-line XSLT handling. Most of the code came from Xalan--quite sim

Re: cvs commit: fop.bat

--- Finn Bock <[EMAIL PROTECTED]> wrote: > Last time I had to work on cmdline args in windows, > the %* trick didn't > work on win9x: > That's a shame--the code is very simple. > Perhaps we should just copy the loop from ant and > hope that ant works on > win9x. > Good idea--done--thanks. G

Re: PMC representation

Ja, +1, bitte auf dem PMC bleiben. Danke. Glen --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > > Jeremias, > > I have no problem with your continuing. If we need > a formal vote, > > Jeremias to remain as one of our PMC > representatives: > > +1 > > Peter > -- > Peter B. West >

Re: XSLT-support related question

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > Hi all, > > Started having strange ideas on the possibility of a > scenario like > > 1 XML + 1 XSLT => n FOs => n PDFs > > XSLT processors support extension functions for the > output to multiple FOs, > but in what way could (or does) FOP

RE: JAXP question

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > AFAICT SAXTransformerFactory has its own > getTransformerHandler() method. > Maybe you can use this to set up a Handler, then > manipulate the related > Transformer ( setParams() ) through > TransformerHandler.getTransformer(). > After that,

RE: XSLT-support related question

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > The XSLT extension functions actually are meant to > redirect certain parts of > the transformation result to other files. Yes, our properties.xsl used to do that for the 250 or so autogenerated property class files. > In the case such a

Re: FOP report

Congratulations! Glen --- Christian Geisert <[EMAIL PROTECTED]> wrote: > > That would be me ;-) > I'm in temporary lurking mode as there are other > "things" with a higher > priority at the moment (happy daddy since two weeks! > [1]) > > -- > Christian > > [1] http://www.geisert.de/bilder/an

Re: JAXP question

> > -Original Message- > > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > > > --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> > > wrote: > > > > > > AFAICT SAXTransformerFactory has its own > > > getTransforme

Re: [xsl] creating multiple pdf-files from one xml

Andreas L. Delmelle wrote: Nightmares... Anyone to come and chase them away? Please...? ;) One thing to keep in mind, although I'm unsure of its relevance to this discussion, is we use Xalan only through JAXP--so if I'm not mistaken, the user is welcome to replace that with another JAXP-com

Re: [xsl] creating multiple pdf-files from one xml

Andreas L. Delmelle wrote: -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] So we not can assume the xml->xsl->fo processing was had via Xalan--and even if it were so, it also could have been done via its translets (compiled XSLT) feature. Aw, great! Yo

Re: [PATCH] Support for percentages and table-units

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > The layout dimension that is stored in the FO tree > is constantly updated > during discovery of BreakPoss'es and is never > reused, not even when a > block is split over a break where new values are > assigned. > I don't know enough to comment too m

Re: [PATCH] Support for percentages and table-units

--- Simon Pepping <[EMAIL PROTECTED]> wrote: > > In my view FOP consists of a number of subsystems > that are ordered > from upstream to downstream. The FO tree is the most > upstream system, > the area tree (or objects that are constructed by a > renderer) is the > most downstream system. Informa

Web Maestro vs. The Breadcrumb Problem

Clay, I'm *very* happy to see you working on fixing the pesky breadcrumb problem[1] on our website. I'm also seeing that you're bringing yourself up to speed with the usage of Forrest [2], something few (any?) of us have, outside of just being able to edit the XML documents. (This combinat

[VOTE] Remove Visitor Patterns from AbstractRenderer.java

Team, To simplify the Area Tree<-->Renderer interaction somewhat, making this section of the code easier to follow, I'd like to make two changes to the code: 1.) Remove the serveVisitor() methods in AbstractRenderer.java [1], and return to what we were using last year, that of having the Inli

Fwd: ASF Board Summary for February 18, 2004

Score (another) one for Jeremias... ;) --- Greg Stein <[EMAIL PROTECTED]> wrote: > > - author tags are officially discouraged. these > create difficulties in > establishing the proper ownership and the > protection of our > committers. there are other social issues > dealing with collab

PS & PCL: How do I test them?

Team, simple question: I use Adobe Acrobat to test PDF results. Are there any free/open-source viewers to test PCL and PS results -- on either Windows or Linux? I've never used PS & PCL before, so I don't know much about them. Thanks, Glen

Re: [VOTE] Remove Visitor Patterns from AbstractRenderer.java

2.) (This I'm less sure on) After reverting, I'd like to remove the "render" functions within the InlineArea objects in favor of direct function calls within AbstractRenderer: -1 Remember one of the three basic OO principles: use virtual methods instead of switch according to a class marker. T

RE: [VOTE] Remove Visitor Patterns from AbstractRenderer.java

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > Does any package other than the renderers really > *need* access to the > renderInlineXXX methods? No, they're now protected--furthermore, whether or not such renderInlineXXX methods even exist within a Renderer is now up to the renderer (th

Re: [VOTE] Remove Visitor Patterns from AbstractRenderer.java

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Question: in the maintenance branch, leader > expansion and > text justification is done just before a line is > rendered > in the LineArea.render() method. The reason for this > is > that it's only the renderer which knows when page > number > refer

Re: fop-cvs Digest 27 Feb 2004 18:53:01 -0000 Issue 868

Thanks! thanks! thanks! Glen --- [EMAIL PROTECTED] wrote: > 5209 by: jeremias.apache.org > > Applied Apache License Version 2.0 by following > the instructions at > http://www.apache.org/dev/apply-license.html. >

Re: [VOTE] Remove Visitor Patterns from AbstractRenderer.java

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > The problem is that text justification and leader > expansion > is a layout task, not a renderer task. Absolutely, much of the logic needs to be in the layout objects, which interface with the Renderer classes, indeed activate them. That's fine, no

Re: cvs commit: xml-fop/src/hyph cs.xml da.xml de.xml de_DR.xml el.xml en_GB.xml en_US.xml fr.xml nl.xml no.xml sk.xml tr.xml

Can you give us a link stating that? I know we can't distribute (L)GPL stuff, if that is the issue. Thanks, Glen --- Simon Pepping <[EMAIL PROTECTED]> wrote: > What are those legal problems? The Dutch file nl.xml > is based on the > hyphenation patterns created by the Dutch TeX user > group, and

[VOTE] Clay Leeds for Committer

Team, Waxing chutzpaic, I'd like us to try again to make Clay a committer on this project. You may recall his committership didn't pass last December (I can't remember who blocked it, it might have been Jeremias ;-), but especially with the loss of Victor, I think it's becoming increasingly evide

Re: [VOTE] Clay Leeds for Committer

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > Would you please enlighten me what the words below > mean? > > On 29.02.2004 22:10:42 Glen Mazza wrote: > > Waxing chutzpaic, > Well, that joke didn't work. ;) Long Answer: There's a certain amount of

Cocoon appears to be switching to 1.4

They're currently voting on the Cocoon side[1] to set 1.4 as the minimum JDK for their next 2.2 release. So far it looks good for approval. This would be good news for us, as it would remove one of the major risks (incompatibility with Cocoon) involved with adopting 1.4 on our side. Glen [1] ht

Re: Thanks Jeremias

HOORAY :) --- Chris Bowditch <[EMAIL PROTECTED]> wrote: > I would also like to thank Jeremias for sorting out > the licensing, not > the nicest of jobs, so three cheers for Jeremias, > hip hip :-) > > Chris > >

Re: fop-dev used to spread virus

Thanks, Manuel. We have about 430 people on FOP-DEV, last time we checked, so it would be hard to find the problem account. Still, sending to infrastructure... (well, I believe it's called infrastructure @ apache dot org, I'll be corrected soon otherwise... ) Glen --- Manuel Mall <[EMAIL PROTE

Re: namespace-prefixes

--- "Peter B. West" <[EMAIL PROTECTED]> wrote: > In HEAD, ///apps/FOFileHAndler.java contains the > following: > > factory.setFeature( > > "http://xml.org/sax/features/namespace-prefixes";, > true); > That is, I would turn allow the namespace-prefixes > feature to

Re: fop.xconf

I haven't looked at it--but this was before my time on the project, fop.xconf hasn't been altered since December 2002. It appears to be related to Avalonization of FOP. For the benefit of other relative newcomers, it is located here: http://cvs.apache.org/viewcvs.cgi/xml-fop/conf/fop.xconf And

RE: fop-dev used to spread virus

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > OTOH I seriously doubt there's enough reason to > assume that the culprit is > actually among the subscribers. On the contrary, I > have every bit of > confidence that every single one of these 430 is > smart enough to stop the > spread in th

Re: namespace-prefixes

--- Elliotte Rusty Harold <[EMAIL PROTECTED]> wrote: > What I ask on reading this code is why you're using > SAXParserFactory > at all? SAXParserFactory is a Sun class they > invented to fill a hole > in SAX 1.0. It's unnecessary in SAX 2.0. SAX2 apps > should use > XMLReaderFactory instead, whi

Re: [VOTE] Clay Leeds for Committer

Clay Leeds wrote: Perhaps I might even pick up a Java book and figure out how to add command line parameters to FOP (I'm hoping I won't have to figure out the issue that Glen and Andreas raised[1] in February, though...:-p). Sure, you'll have plenty of Java coding experience if you wish--there i

Re: FOP web site update

Nice job, Clay--I'm very happy with the "whole site" PDF in particular. Jeremias, would you please request write access for Clay now? Thanks, Glen Clay Leeds wrote: I thought you'd like to see a brief update on the FOP web site trials and tribulations. I've uploaded the web portion of the outpu

Re: CMYK- jpg

Unsubscribe here and subscribe to FOP-USER. Glen Naveen M V wrote: Hi All, I need to generate PDF files using XSL-FO transformation and embed CMYK -jpeg for printing. I am using fop-0.20.5. Can any body help. Regards/Naveen

temporarily inactive

Team, I'll be taking a few weeks off the project, there's some things I want to study and get out of the way right now. I'll be back to coding soon! Thanks, Glen

Re: InputHandler - re baseURL commits

(Hmmm...I'm supposed to be learning Cocoon right now, but am already suffering FOP-withdrawal. Apache's got me good... ;) [just removed the namespace-prefixes issue you were mentioning earlier, btw.] FOFileHandler.createParser() is just a simple static function that generates a parser. It can

Re: Web Start

Peter B. West schrieb: Fops, Does anyone have any detailed knowledge of Web Start? It occurred to me that it may be a way to resolve some of the licensing issues we (and other projects) are running into. Any educated thoughts on the matter? Peter I didn't know about Web Start--looks very in

[VOTE] Switch from Avalon to Commons-Logging

Team, The Cocoon project is starting to move away from Avalon. Their "building on stone" email thread today [1], deals with the need to build Cocoon on a solid framework they have control over, and not on the framework of another team that is apparently suffering from high turnover [2]). Cocoon

Re: DO NOT REPLY [Bug 27901] - TextCharIterator.remove() does not work properly

Ich bin confused--ist chz ([EMAIL PROTECTED])--Christian Geisert oder anderer Christian? The bugzilla entry lists chz as being "Christian Z", so I'm not sure whom I'm speaking with! Glen --- chz <[EMAIL PROTECTED]> wrote: > > The BreakIterator origins from the ICU project and > they state tha

Re: [VOTE] Switch from Avalon to Commons-Logging

Jeremias Maerki wrote: -0 (I don't feel I'm in a position to veto) for now as long as you're only talking about the logging aspect. FOP needs a few things more, as does Cocoon. Simply dropping Avalon doesn't help. If you look at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization you can

[VOTE] Simon Pepping for Committer

Team, I'd like us to go ahead and make Simon Pepping our newest FOP team member. He has provided steady ML help and numerous patch contributions for the past few months, and with the many layout patches that have been coming in recently, we could certainly use his continued help on our team. Cre

Re: DO NOT REPLY [Bug 28044] - Patch, Avalon Logging to Commons Logging Conversion.

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > I got home late today, so I didn't manage to finish > everything. I will > do that tomorrow morning. > > Todos: > - Figure out how best to configure the SimpleLog > when using static > loggers in command line apps. I'll let you start the cogitatio

Re: DO NOT REPLY [Bug 28044] - Patch, Avalon Logging to Commons Logging Conversion.

--- Glen Mazza <[EMAIL PROTECTED]> wrote: > > --- Jeremias Maerki <[EMAIL PROTECTED]> > wrote: > > I got home late today, so I didn't manage to > finish > > everything. I will > > do that tomorrow morning. > > > > Todos: > > - Fig

  1   2   3   4   5   6   7   >