Re: Using Avalon/Logkit

Jeremias Maerki wrote: > > I'd extend Driver from AbstractLogEnabled and overwrite getLogger() > as done in the current version (maintbranch). Cool, will do. Out of curiosity, what was the name of that branch? Keiron mentioned elsewhere that I'd probably want to patch both branches - one i

Re: development status

From: "Arved Sandstrom" <[EMAIL PROTECTED]> > You're 100% right - Apache XML is not just about Java. But programming > language is not the reason xslfo-proc is not a sideproject to FOP. It is all > about community. If this codebase was side-by-side with FOP right now it > would be a distraction a

DO NOT REPLY [Bug 7140] New: - page-position attribute set to "last" on conditional-page-master-refernce does not work

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

RE: development status

Comments below. -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: March 14, 2002 11:07 AM To: [EMAIL PROTECTED] Subject: Re: development status From: "Peter B. West" <[EMAIL PROTECTED]> [ SNIP ] > Arved is, as you know, engaged in a > C/C++ project for a fast,

DO NOT REPLY [Bug 7131] - soft hyphen ­ not a valid character?!

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 7131] - soft hyphen ­ not a valid character?!

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 7131] New: - soft hyphen ­ not a valid character?!

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

Re: A how-to question:

As far as I can tell, the best way to fit your columns would be to shrink the PDF, depending on how many columns wide your output is. I haven't determined any sort of way to get columns to render across a set of horizontally pages while rendering down vertical page breaks at the same time.

Re: Using Avalon/Logkit

On 14.03.2002 16:51:55 Joerg Pietschmann wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > But I think you have some fears because you know too little of Avalon. > > Well, thats nearly the core of the problem. Actually, in my case > JAXP is the ultimate cause. > > We started using XSLT in

Re: FAQ Answers please

Keiron Liddle <[EMAIL PROTECTED]> wrote: [rearranged] > > 2. Batik/SVG specific questions > > 2.1 SVG text rendered in bad quality, how to put SVG text as text into > > PDF > This isn't quite true... Well, it is asked in this form frequently enough. But you are right your explanation should be ad

Re: Using Avalon/Logkit

Jeremias Maerki <[EMAIL PROTECTED]> wrote: > But I think you have some fears because you know too little of Avalon. Well, thats nearly the core of the problem. Actually, in my case JAXP is the ultimate cause. We started using XSLT in a servlet using JAXP, which defines its own facilities for dea

FOP and iText

My only concern about using iText within FOP is the addition of yet another .jar file. We use FOP on the client side of a Java Web Start application in order to do document formatting and PS printing. I would hate like h_ll to have to add yet another jar file to the list of jar files the applica

Re: development status

From: "Peter B. West" <[EMAIL PROTECTED]> > There is very active development on FO Tree building, property > resolution and layout models. A lot of that development is desisn > speculation, such as the design notes I have been posting, and there is > also a fair bit of code, all of which resides

Re: development status

Keiron, You have pre-empted my last post on this topic. Keiron Liddle wrote: > On 2002.03.14 10:55 Nicola Ken Barozzi wrote: > >> Ok, nice. This seems more like evolution than revolution, am I right? > > > You could say that. > The code is forming a revolution, not the people. We needed to go b

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

Hi Peter, > Aside from my low opinion of SAX for process coupling, there should > be no need for communication back from the renderer. >. . . cool - I thought the Area Tree code needed to know about font metrics and the like, but if this communication is one-way all the better. Regarding SAX

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

Bertrand, Aside from my low opinion of SAX for process coupling, there should be no need for communication back from the renderer. The Area Tree should just give orders to the renderer. All of the layout decisions have been made by the time the Area Tree is constructed. The feedback is with

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

Keiron Liddle wrote: > On 2002.03.14 09:00 Nicola Ken Barozzi wrote: > >> What I would like to see, is that FOP stops discussing about the >> logging, >> resolving, pipelineing and stuff and starts to focus on the core >> functionality. >> IMHO, the best way to get this thing going *quick* is to

Re: development status

Nicola, Comments interspersed. Nicola Ken Barozzi wrote: >From: "Keiron Liddle" <[EMAIL PROTECTED]> > >>There was a notice of this a number of months ago. Admittedly we have it >>the other way around. Maintenance releases are made from a branch. So the >>main branch is where the active develop

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

From: Matthias Fischer > My company, for instance, would have to stop using FOP; > we would not even take the time to go into studying legal > aspects, because, as a medium-sized company, we > don't have the time and money and personnel to do this... I think you are exaggerating a bit. Are you u

Re: development status

On 2002.03.14 10:55 Nicola Ken Barozzi wrote: > Ok, nice. This seems more like evolution than revolution, am I right? You could say that. The code is forming a revolution, not the people. We needed to go back a bit and approach things from a different angle. > Are there any projects underway to

RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

If n persons are using FOP now and some of these can no longer use FOP because a part of FOP they need has a license they can't use, then I'd say this reduces FOPs usefulness for these "some" persons, despite being more useful to others. Arnd Beissner --Arnd Beißner IT-Engineer

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

From: [EMAIL PROTECTED] > Technically, it's very tempting to do what you propose. In fact, technically, > I'm all for it. Let's just be aware that the license problem is not only a > philosophical issue. Of course. I think we agree. And as for this: > > > This would reduce the usefulness of >

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

Nicola Ken Barozzi wrote: > > IF the integration FOP-iText is done in a way where PDF > > output via iText is not just an option but a replacement > > for the existing PDF output - or even for the other renderers, > > too, then I'd say this step contradicts the intention > > though not the letters

Re: development status

From: "Keiron Liddle" <[EMAIL PROTECTED]> > (as a guess I would say you haven't beed subscribed long enough :) ;-) > There was a notice of this a number of months ago. Admittedly we have it > the other way around. Maintenance releases are made from a branch. So the > main branch is where the ac

problem in embedding font

Hi all , I tried to embed barcode font of windows encoding (not identity-H etc. ) in PDF .For that I tried to generate XML using this command . java org.apache.fop.fonts.apps.TTFReader -ttcname "barcode" sAdvI25b.ttf sAdvI25b.xml TTF Reader v1.1.1

Re: Using Avalon/Logkit

Hey Michael > Jeremias Maerki wrote: > > > > I can help you with implementing or documenting, whatever you want. > > Thanks for the offer, and thanks for the pointers. It's too late for me > start this now, I'll do it at work tomorrow (about 16hrs away) - gotta > love getting paid to work o

development status

(as a guess I would say you haven't beed subscribed long enough :) There was a notice of this a number of months ago. Admittedly we have it the other way around. Maintenance releases are made from a branch. So the main branch is where the active development is happening. So where are we: I am

Re: Using Avalon/Logkit

Hey Jeremias, Jeremias Maerki wrote: > > I can help you with implementing or documenting, whatever you want. Thanks for the offer, and thanks for the pointers. It's too late for me start this now, I'll do it at work tomorrow (about 16hrs away) - gotta love getting paid to work on OS projec

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: >. . . > I think that a SAXrenderer could be the solution. SAX is based on > calling a method when a tag begin-content-end is reached. It can be > used to communicate the Area Tree to the renderer in a clean way, > whith a standard interfa

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: >. . . > Hmmm... AFAIK FO is about layout, not semantical structure. > Bold is just Bold, and not "emphasis" or "strong". > Maybe I don't get the point. Could you elaborate more please? >. . . The term "structure renderer" (as you could f

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

On Thursday 14 March 2002 09:19, Keiron Liddle wrote: >. . . > Firstly the Area Tree is unavoidable. We must have a place to do the > layout and to store the page information. >. . . Unavoidable for "Layout rendering", isn't it? I thought structure-based rendering wouldn't need the area tree. >.

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

From: "Keiron Liddle" <[EMAIL PROTECTED]> > On 2002.03.14 09:00 Nicola Ken Barozzi wrote: > > What I would like to see, is that FOP stops discussing about the logging, > > resolving, pipelineing and stuff and starts to focus on the core > > functionality. > > IMHO, the best way to get this thing

Re: Using Avalon/Logkit

> Keiron Liddle wrote: > > > > If you submit a patch for this it will be committed before you know it! > > Excellent! > > > No-one else has mentioned working on it so go ahead. It will probably > > need to be done on both branches but do whatever you want to. > > Right, I'll get onto it, then

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote: >. . . > > 1. FopParser parses and validates the input XSL-FO document > Not needed if using Cocoon as a pipeline. >. . . Right, but it's so easy that we might as well keep it for easier testing. >. . . > What I would like to see, is th

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)

From: [EMAIL PROTECTED] >Nicola Ken Barozzi wrote: >> Given the licences, nobody is prohibited to cross-collaborate. iText >> developers can send patches to FOP and viceversa, and be [VOTE]d as usual >> when the time is right. >> FOP can distribute iText jar as it's MPL, and both projects would c

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-

On 2002.03.14 09:00 Nicola Ken Barozzi wrote: > What I would like to see, is that FOP stops discussing about the logging, > resolving, pipelineing and stuff and starts to focus on the core > functionality. > IMHO, the best way to get this thing going *quick* is to use Cocoon as a > pipeline. Cocoo