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. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 cross-link in a clear way. Advance warning: I didn't follow possible discussions on the iText list regarding this issue. 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 of the Apache license. This is a strong opinoin. Remember that the Apache license is a *license*, not the community. Apache values the community, and the license is there to help the community. Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically speaking it still is. ? This boils down to a question: what is FOP? From http://xml.apache.org/fop/: FOP is the world's first print formatter driven by XSL formatting objects and the world's first *output independent* formatter. Currently FOP is not totally output indipendent, in the sense that it doesn't even output without going through a FOP renderer. The goals of the Apache XML FOP Project are to deliver an XSL FO-PDF formatter that is compliant to at least the Basic conformance level described in the W3C Recommendation from 15 October 2001, and that complies with the 11 March 1999 Portable Document Format Specification (Version 1.3) from Adobe Systems. FOP is currently two things: -formatter -renderer Nobody has ever thought to ditch the current FOP renderers. It would be illogical. The proposal is to focus on the formatting part, that is somethind that no other project does AFAIK, and make the rendering accessible to other projects, like iText, jFor and POI. Fop renderers would be just another possibility, and now there are no alternatives I see for PCL, for example. This way different working groups could focus indipendently on different parts. Separation of concerns can help keep working groups more focused and productive. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could tell whether there are enough people interested in keeping Apache-licensed PDF output alive. Basically, this is the idea :-) I remember that iText has already proposed to be put in the FOP codebase, thus gaining Apache license. But several reasons advise us to be cautious and defer it for now. It's not codebases that would merge, but communities, and we have to avoid stalling while in the process. If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far. IMO, it's the opposite. This can give FOP another opportunity, not make it go back. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. . . . Yes, but IMHO resolving (in the sense of resolving FO object properties like I think is meant by FOP) is part of the core functionality. I'm talking about computing presentation attributes for child elements based on their parent's attributes. . . . This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) . . That's me by the way ;-) (but I haven't done much lately) -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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. Jeremias mentioned LogEnabled is replacing Loggable, is there any concensus about moving Driver over to the new interface, making it implement both, or just leaving it as-is for now? I'd suggest moving it over, if not, then implementing both. Michael, I've got a day off tomorrow, so I could help, too. No way at the moment I can allocate time during work. The projects kill me. I'd do the following: - Remove logkit.jar as it's not really need when we're finished. - Add avalon-framework.jar (We probably have to use a CVS snapshot because the current version 4.1.2 doesn't contain the ConsoleLogger, yet. CVS of framework is very stable.) - Replace all occurences of org.apache.log.Logger with org.apache.avalon.framework.logger.Logger. - Use org.apache.avalon.framework.logger.ConsoleLogger (prints to System.out) as default logger. - There's a choice whether we want to use the LogEnabled interface or not (Forget Loggable). I mean after a quick look at the main branch I've seen a number of occurences where Keiron made setLogger/getLogger methods. These are candidates for implementing LogEnabled, because it defines just that. Where applicable we can extend AbstractLogEnabled which provides implementations for LogEnabled along with methods for getting child loggers etc. I'm for using LogEnabled wherever possible because it will help us later adopt the other contract interfaces from Avalon (which enables us the make use of ComponentManager (or its successor)). I can help you with implementing or documenting, whatever you want. I'll reserve my time tomorrow. Unfortunately I can't help a lot during the next 8 hours because I'm going to visit a customer. I'm here for another hour or so. I hope this helps. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. Right. And flush it ASAP, as FOP already tries to do now to some degree. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. 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 interface. To make a renderer use by FOP in this way, you just need to say:We give you this xml area tree that conforms to this schema via SAX. Render it. No knowledge of FOP internals is needed. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. Can't agree more :-) For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. 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? Thank you. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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. . . . For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. . . . How hard would it be to render the FOTree in XSL-FO (based on SAX events) with all possible attributes resolved? Speaking specifically about the jfor RTF converter, this would allow it to be used as a FOP renderer without needing as much code changes as an API-based integration. Might be a little slower but much more flexible. This would allow the parser and property resolver (is that the right term?) components of FOP to be reused by jfor and future structure-based renderers. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 find by searching the list archive probably ;-) is used here for yet-to-be renderers that don't do any layout by themselves. If you're generating RTF or MIF formats, for example, you usually don't need to know on which page a given FO element will go, you leave this to the word processor or desktop publishing program that will use the generated document. So these renderers will be plugged in right after the parsing and property resolution stages, before the layout stage. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 projects.. ;)
I'm 100% confident I can sort this myself - it's exacly the same work
involved as the previous patch I posted, but if you're on hand to answer
any further questions that may arise, that would be useful.
WRT the last point, I'll make Driver implement LogEnabled and drop
Loggable. Given that (according to the javadocs on the Avalon web site)
LogEnabled exposes enableLogging(), not setLogger(), and does not
provide an analog for getLogger(), I'd suggest leaving any classes which
implement {get|set}Loggable() alone for now.
Sound okay?
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
smime.p7s
Description: S/MIME Cryptographic Signature
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 going to great lengths to describe how it all works so others will have the knowledge to help out. Many others are helping with ideas and requirements. Not much code is getting done because people are busy and the issues are complex (many of the side issues are being dealt with) The maintenance branch is being updated for bugs etc. I am hoping people will get to a point where they feel ready to jump in. So what needs to be done: Finish the implementation of the line layout do the page layout then do all fo's handle other issues then hopefully we will be ready for a developers release (version number yet to be decided) On 2002.03.14 08:49 Nicola Ken Barozzi wrote: Although I'm subscribed to this mailing list for quite some time now, I didn't really understand the status of the works that are going on to get to FOP2 or whatever you are going to call it. AFAIK, changing codebase requires a notice of this, a branch in CVS (no vote is necessary), and a final VOTE if the codebase is to switch. This is how Tomcat, Xalan, Xerces and many other projects did it, and how the priject guidelines advise. (http://xml.apache.org/source.html) What's the current status? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 on OS projects.. ;)
Sleep well!
I'm 100% confident I can sort this myself - it's exacly the same work
involved as the previous patch I posted, but if you're on hand to answer
any further questions that may arise, that would be useful.
WRT the last point, I'll make Driver implement LogEnabled and drop
Loggable. Given that (according to the javadocs on the Avalon web site)
LogEnabled exposes enableLogging(), not setLogger(), and does not
provide an analog for getLogger(), I'd suggest leaving any classes which
implement {get|set}Loggable() alone for now.
Sound okay?
Right, enableLogger() replaces setLogger(). And right, there's no
getLogger() on LogEnabled. I'm so used to having getLogger() provided by
AbstractLogEnabled (!) that I didn't remember. LogEnabled just defines a
contract on how to set the logger, not how to retrieve one. I'd extend
Driver from AbstractLogEnabled and overwrite getLogger() as done in the
current version (maintbranch). You just have to replace the LogKit setup
code in getLogger() by the ConsoleLogger.
Sounds okay. We can do these changes later if necessary.
Cheers,
Jeremias Märki
mailto:[EMAIL PROTECTED]
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
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 Reading sAdvI25b.TTF... Number of glyphs in font: 119 Unicode cmap table not present java.util.NoSuchElementException: Vector Enumeration at java.util.Vector$1.nextElement(Unknown Source) at org.apache.fop.fonts.TTFFile.createCMaps(TTFFile.java:398) at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:387) at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:181) at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:143) and when I tried for another true type java org.apache.fop.fonts.apps.TTFReader sAdvI25b.TTF sadvc39e.ttf sadvc39e.xml Number of glyphs in font: 119 java.io.EOFException: Reached EOF, file size=37560 offset=100592 at org.apache.fop.fonts.FontFileReader.seek_set(FontFileReader.java:78) at org.apache.fop.fonts.TTFFile.readCMAP(TTFFile.java:217) at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:386) at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:181) at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:143) can anybody tell me whether true type font with windows encoding support by FOP or not . if yes then how to embed it thanks in advance. Regards Rikhil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 active development is happening. Ok. Makes sense since the community has common views. So where are we: I am going to great lengths to describe how it all works so others will have the knowledge to help out. I've seen it and it's very very well done. My sincere compliments :-) Many others are helping with ideas and requirements. Not much code is getting done because people are busy and the issues are complex (many of the side issues are being dealt with) The maintenance branch is being updated for bugs etc. Ok. I am hoping people will get to a point where they feel ready to jump in. So what needs to be done: Finish the implementation of the line layout do the page layout then do all fo's handle other issues then hopefully we will be ready for a developers release (version number yet to be decided) Ok, nice. This seems more like evolution than revolution, am I right? Are there any projects underway to change the processing model? How about the new property resolving proposal. Sorry if I keep asking, but I got a bit confused reading some mails on the list. Thank you :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 of the Apache license. This is a strong opinoin. Remember that the Apache license is a *license*, not the community. Apache values the community, and the license is there to help the community. Yes, I agree to all of this (including the strong opinion). Still, I think you underrate the importance of the license. In marketing terms: what is it that makes Apache and GNU a brand, while SourceFourge is not widely seen as a brand. I think it's the license. If I take something from the Apache projects, I know - because of the Apache license - that I can do most everything with it as long as I mention the origin in an appropriate way. This makes its very simple to use Apache projects in commercial projects in medium-size and large companies. Basically it boils down to this: If I want to use open-source components in a customer project, I can use Apache-licensed stuff with no problems. MPL, LGPL and GPL licensed components give me so many headaches when used in commercial customer projects that I no longer even try to use them (with the exception of internal-use-only projects). I just want to design and implement software, not fuss with legal departments, you know... 8-) Warning: Strong opinion follows The Apache project just would not be the same if it adopted the MPL, LGPL or GPL. Also, a number of contributors would quit in that case. If this is true, the Apache license is still a *license* but not *only a license*. In a sense, the license defines what persons the community consists of. FULL STOP Philosopical issues aside, if the integration/collaboration is planned as you say, then most points of my original mail become moot. Remember, my mail started with an uppercase IF. The discussion here on fop-dev showed that it was NOT clear that PDF via iText would only be an option, not a replacement. And one more thing - I recite your citation: The goals of the Apache XML FOP Project are to deliver an XSL FO-PDF formatter that is compliant to at least the Basic conformance level described in the W3C Recommendation from 15 October 2001, and that complies with the 11 March 1999 Portable Document Format Specification (Version 1.3) from Adobe Systems. From this, it's clear that as soon as FOP no longer outputs PDF by itself, but using a non-Apache-licensed component, then it not longer fulfills the original goal. This may be good: it makes a lot of sense to separate formatter and renderer if the abstraction layer is done well (this won't be an easy task, I'm pretty sure of that). 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. There is a real reason why there are different types of licenses. And as for this: This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. 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-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
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 FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. 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. Apache is very clear in the licencing terms. *GPL libraries cannot be distributed by Apache. So this rules them out. The iText developer are maing it possible now to redistribute the jar with the MPL license only. AFAIK, MPL is compatible with APL. Which means that the MPL -jar- can be used in *every* condition in which APL -code- or -jars- are used. Who cannot use MPL jars in APL code? Maybe I'm wrong, but I cannot come up with an example. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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-EngineeringBahnhofstr. 3, 71063 Sindelfingen, GermanyEmail: [EMAIL PROTECTED]Phone: +49-7031-463458Mobile: +49-173-3016917 My company, for instance, would have to stop usingFOP; 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... Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 change the processing model? I'm not sure exactly what you mean but there are probably no projects as such. Peter is looking at alternatives. How about the new property resolving proposal. No active development that I am aware of. Maybe Peter can elaborate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 using Apache license software? And did you study it with this scrutiny? If you are using the Apache license and are confortable with it, then there is no problem. If Apache can distribute it with APL code, you can do the same. It's simple as that. Apache admits only compatible licenses in the CVS for this reason; some weeks ago there has been a check in the CVS to check this, and you can be sure that there is zero tolerance on this issue, it is applied very strictly. Look at the descriptions on the main apache site and on Jakarta; there are very important pages IMO that explain as clearly as possible the position Apache has on this point. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 development is happening. Ok. Makes sense since the community has common views. I suppose that depends on how you define community. So where are we: I am going to great lengths to describe how it all works so others will have the knowledge to help out. I've seen it and it's very very well done. My sincere compliments :-) Yes, that was a good idea. Many others are helping with ideas and requirements. Not much code is getting done because people are busy and the issues are complex (many of the side issues are being dealt with) The maintenance branch is being updated for bugs etc. I am hoping people will get to a point where they feel ready to jump in. So what needs to be done: Finish the implementation of the line layout do the page layout then do all fo's handle other issues then hopefully we will be ready for a developers release (version number yet to be decided) Ok, nice. This seems more like evolution than revolution, am I right? Are there any projects underway to change the processing model? How about the new property resolving proposal. Sorry if I keep asking, but I got a bit confused reading some mails on the list. I made an attempt to explain this recently. Maybe Keiron can try. Keiron? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. Hear, hear. We must have a place to do the layout and to store the page information. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. Agree strongly. At various times the notion of flattening the area tree has been wrestled with in these pages. At some point the tree model of pages loses all relevance. Trees are very useful to describe the structure of the stuff being squirted onto the page. At the end of the day, though, the stuff is rendered as a series of marks on a flat surface, and, to the renderer of last resort, all of the data structures that generated the marks are irrelevant. I am utterly ignorant of any particular page description languages, so imagine such a language that provides for the drawing of certain sorts of marks on the page at certain co-ordinates. That, essentially, is the output of the area tree. If you want to express that page definition language in xml, go right ahead. Xml output would indeed be loosely coupled. It's a data stream. SAX events are about as loosely coupled as tree roots. It's an API, after all, and an API which is inimical to pipelining processes. However, if you want to be able to feed the area tree into various renderers, you have to use some sort of PDL to transcribe the area tree, and the description is linear set of random access instructions, whether expressed in an xml file or an API. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. Yes. For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. My own approach is an API-based pipeline. As you say, these three, FO Tree - Layout (Tree?) - Area Tree, are the tightly coupled core issues. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 within the layout process, and the particulars of that are the cause of much wailing and gnashing of teeth. Peter Bertrand Delacretaz wrote: 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 interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 events, I really meant that for structure renderers. What I envision (in the context of RTF rendering through jfor) is the possibility of using the FOP front-end only to resolve XSL-FO properties, like an XSL-FO preprocessor if you want. That's for this preprocessor-to-StructureRenderer interface that I think using XML makes sense, for loose coupling of the StructureRenderers which would then not necessarily be part of the FOP code base. If we agree that XML is good for this, I think generating this XML through SAX events allows the preprocessor component to be efficiently integrated in Cocoon (for example) later on, without having to serialize and reparse the XML. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 added too. There are more issues to be explained, like the 1pt grid lines show differently and such. There are also serious omissions in other parts. Now that i have broadband access from home, i could take some serious shots at keeping the FAQ in a good shape if somebody supplied me with instructions for writing and publishing the material (DTD, additional conventions, whatever). More explicitely, i'm offering assistance in FAQ maintenance. There should be a decision whether i should assist alex and the external FAQ or provide for the FAQ at xml.apache.org/fop/faq Hopefully this will help everyone. After a short glance at recent traffic it seems to be a vain endeavour. There ought to be a law that the more inferior a solution is, the faster it spreads. :( Regards J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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. :( If you fix the height of the columns, however, you could easily tell where on the next page the columns would be. Another idea might be to use the area tree XML- you could parse it into a second XSL:FO to create the horizontal pages across and run it through FOP again. [EMAIL PROTECTED] wrote: I need to be able to print a table under a landscape type setup but, I would like the report flow to print all the columns and then all rows. Another way to say it is I may have more columns that will fit on a page so I want the page breaking to first break and complete all the columns for the row and then I guess go back to start the next row. Anyone have a solution for this? TIA, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7131] New: - soft hyphen #xAD; not a valid character?!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7131. 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=7131 soft hyphen #xAD; not a valid character?! Summary: soft hyphen #xAD; not a valid character?! Product: Fop Version: 0.15 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi! I am using FOP to generate my PDF from XML and XSL files. Reading through the unicode charts, the character #xAD; should appear properly using encoding ISO- 8859-1. I am using this encoding, but the character is unknown to FOP. Meaning, I get the standard # when I use this #xAD; character. I really need this character to appear properly as the soft hyphen because we have users in Hong Kong and Taiwan that are using our program and they cannot display the traditional chinese properly without this character. This greatly affects the business of Yahoo!. Please help me to find the reason for this character not displaying. Thanks, Amy Weiss Technical Yahoo! Media Delivery Solutions Yahoo! Inc. Phone: 408.349.6232 ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°¤º° DO YOU YAHOO!? ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°¤º° - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7131] - soft hyphen #xAD; not a valid character?!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7131. 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=7131 soft hyphen #xAD; not a valid character?! [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High Version|0.15|all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7131] - soft hyphen #xAD; not a valid character?!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7131. 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=7131 soft hyphen #xAD; not a valid character?! [EMAIL PROTECTED] changed: What|Removed |Added Version|all |0.17 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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, small footprint FO Processor over at SourceForge, and I copy all of my design discussions to him. He has just committed another set of perl modules to his prototype. Why not put it here, in FOP. Hey, xml.apache is not only Java. Has this been tried? -End of Original Message- I've had the urge to try a SAX-based approach that uses C/C++ for quite a while. The main motivation behind C/C++ is so that SWIG can be used and therefore open the door at one fell swoop for Perl, Python, Tcl, Ruby etc etc. The main motivation behind SAX is to radically reduce memory consumption. I've only really gotten started on a prototype after the New Year. Prior to that I had too much other stuff going on - job switching (one employer going bust, working on a contract, and now fulltime again with a new employer), personal affairs (nothing bad, just that real life intrudes from time to time :-)), and quite frankly, a certain amount of FOP burnout - I was fed up with the codebase and needed to take a break. In the interim Keiron and Karen have really stepped up to the plate. They are doing great stuff. As it stands you can only have so many people doing what they are doing - 2 is about the limit - so I, like others, am waiting for the right moment to get involved in the redesign coding again. You may have noted that I volunteered to look at image support for the redesign and I am devoting time to that this weekend, so I haven't forsaken FOP in the least. Why is xslfo-proc (the Sourceforge project) not in Apache XML? Because the tide has turned for people wishing to make donations of unsupported codebases. A SAX-based, non-Java XSL formatter is basically an entirely different project - the rule of thumb these days is that you incubate the project somewhere else, like Sourceforge, develop a user and developer community, and then and only then do you look at bringing it into the Apache fold. And I completely agree with this. 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 at best. It would (possibly) divert resources from FOP rather than independently develop its own. That's not just my opinion; there have been discussions about alternate implementations before and I think there is a consensus that we don't diffuse the FOP effort at this time. But there is also no rule that any of us XSL enthusiasts cannot pursue parallel experiments, and that is what xslfo-proc is for me. I hope that answers a few questions. Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7140. 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=7140 page-position attribute set to last on conditional-page-master-refernce does not work Summary: page-position attribute set to last on conditional- page-master-refernce does not work Product: Fop Version: 0.20.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I try to use the page-seqence-master called sequence1 as follows the resulting output does not contain a master1 layout as a final page: fo:layout-master-set fo:simple-page-master page-width=8.5in page-height=11in master-name=master1 fo:region-body/ /fo:simple-page-master fo:simple-page-master page-width=8.5in page-height=1in master-name=number fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=sequence1 fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=master1 page-position=last/ fo:conditional-page-master-reference master-reference=master1 page-position=first/ fo:conditional-page-master-reference master-reference=master2 page-position=rest/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 is obviously going to be HEAD, the other I assumed was MAIN, but I'm not so sure now.. Anyway, a preliminary, but fully functional patch against the fop-0_20_3 branch can be found here: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. I just need to port it to the two other branches, and deal with both MessageHandler and ToBeImplementedProperty, then it is ready to land. I'll fix these things up sometime in the next few days.. Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
