[svgplan] Status and future?
I'm using now the plan stuff to visualize some planning data for myself, and here are a couple of fixes (patch seems overkill): - in Main there is no need to do a System.exit, that makes it impossible to reuse the class as a utility - the font-family in PlanRenderer should be sans-serif instead of sans-serif so that the SVG can render in the Adobe plugin I'm starting to patch some stuff, and I was wondering if anyone has ideas wether there are some commits pending on it, and what is the forseeable future for this. -- 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: Integration of Peter's work
Peter B. West wrote: Jeremias Maerki wrote: On 01.02.2003 00:16:30 Peter B. West wrote: Should we reserve a directory on the web site for storing diagrams which find their way into the Wiki? +0. The other possibility is to put it in the public_html folder of your cvs.apache.org account. Even though I don't have any appropriate tools for such at the moment, I should like the diagrams to be editable to the same extent as the text. I don't comprehend design discussions without diagrams. In order to do this, we need somewhere accessible, not necessarily on the web-site, to drop these things. Can they be fitted within the Wiki structure? What about putting in the CVS svg files (Openoffice does them IIRC) and have Forrest publish them as PNG on the website? You could reference them from the forrestbot.cocoondev.org space and have them updated every hour or so. Just another option. -- 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]
Licensing confusion (was Re: Distributing jimi.jar)
- forwarding to incubator and licensing lists - - note: licensing is not open to all - Jeremias Maerki wrote: Did you know that the Cocoon guys have jimi.jar in their CVS? I wonder if that's correct and if yes, I think we should do it, too. Reading the licence I get the impression that redistribution of the jar is possible but not without restrictions. IANAL so who can we ask if distributing this jar is ok? I get the impression that things like that will be an everlasting problem. There should be a central source of information on licencing at Apache. A place where the gathered legal knowledge can be hammered in stone and be reused by other projects. Even the fact that we didn't include jimi.jar and Cocoon did gives me an uneasy feeling that the licence-sweep held at the XML project last year wasn't done 100% right. I'd like to escalate that topic again. What I think would be in the best interest of the Apache Foundation would be a central source of information where all projects and subprojects can get information on licencing. The following things would be very helpful: - Licence guidelines - A document describing the relationship of the APL to other licences. (what's compatible, what's not and why) - A list of approved products to be redistributable by Apache What are your thoughts? -- 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]
[FYI] Gump run timing out
Just FYI... your Gump runs seem to be timing out: http://nagoya.apache.org/~rubys/gump/xml-fop.html dist-bin: [echo] Building the binary distribution files (zip,tar) [mkdir] Created dir: /tmp/gump/xml-fop/dist-bin/Fop-1.0dev [copy] Copying 148 files to /tmp/gump/xml-fop/dist-bin/Fop-1.0dev [mkdir] Created dir: /tmp/gump/xml-fop/dist-bin/Fop-1.0dev/build [copy] Copying 1 file to /tmp/gump/xml-fop/dist-bin/Fop-1.0dev/build [zip] Building zip: /tmp/gump/xml-fop/Fop-1.0dev-bin.zip /home/rubys/bin/timeout: timed out java: died with signal 4 -- 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: Why use XML configuration files?
Roland wrote: Hello, I noticed that the apache project uses mostly XML files for configuration. Personally I prefer using .properties files because then I don't have the overhead of parsing the file each time. So what's the advantage of using XML files? They are hierarchical, can easily be transformed and published via XSLT and in some build systems used with xpath queries. Thanks for any answers... -- 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: website
Keiron Liddle wrote: On Mon, 2002-12-02 at 21:37, Victor Mote wrote: [...] 2. The new Compliance document is now visible at http://xml.apache.org/fop/compliance.html. It refers to color-coding which, by passing through Forrest, we don't have yet. I'll work on either removing the color-coding reference or getting the color-coding to work. colour coding would good I think, maybe you could make a dtd enhancement suggestion. Color coding is easily possible with chaperon, that is part of Cocoon and also Forrest (for our ongoing wiki-like editing development). Send us a RFE about it with suggestions on the DTD changes and it'll help the process, thanks :-) -- 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: Alt-Design status: XML handling
Peter B. West wrote: [...] STATUS: The XML pull buffering has been working for some considerable time. I have simply been extending the get/expect methods on top of the simpler methods as I have found a requirement for them in building the FO tree. In cases where the DTD is well known and well structured, XML pull is much easier to use than SAX. For example, one can write a XSL styleshees with templates or with many for-each. SAX is similar to tomplates, XML pull is similar to for-each. Having worked so much with SAX stuff, I can say that in many cases SAX is effectively a PITA, as DOM is for some, and as XML pull is too for some. If the code proves to be easier to understand and write, it will be easier to fix and maintain, so this option should IMHO taken in strong consideration. My 2c -- 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: [VOTE] Victor as committer
Venkata Rao Nadella wrote: Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html -- 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: forrest DTDs
copying this to forrest-dev for feeback. Thanks :-) Victor Mote wrote: Keiron Liddle wrote: I wouldn't recommend putting the dtd's in our cvs, one version is better. In principle I agree. I think the best solution is for Forrest to make them available in a small download. The are some pages describing the dtd but I presume you mean for editing. I think it would be useful to make them downloadable separately just for editing. Yes, I was referring to editing. I think the process is something like: - put your own catalog in resources/schema/catalog - it will then verify with that catalog - cocoon will use that catalog when copied across to webapps Unfortunately it does work like that. To get the verification to work I need to add just the local public ID, so it uses the forrest one to verify forrest ID's and the local one for the local ID. Then when it is copied across cocoon can only find the ID for the fop dtd and the others are missing. If I put all the forrest+fop ID's in the catalog then it cannot verify as it cannot find the forrest dtd's relative to the catalog. So something is a bit broken. I am not familiar with cocoon, so I am a bit lost. However, the catalog concept is just for local use -- in other words for a specific editor/parser. Since Christian has shown us how to find the DTDs on the Web, we should probably add the URL in the declaration -- then people with always-on web access can see that one. The catalog is really just for standalone boxes without access to the URL version, to map the public ID to a local file. After I downloaded Forrest last night, I was able to add an entry in XML-Spy to see my local copy of the DTD. Without that mapping, and since the files don't have the URL, right now an editor will complain that it can't find the DTD in the current directory. Victor Mote r additional commands, email: [EMAIL PROTECTED] -- 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: forrest is coming?
Oleg Tkachenko wrote: Hello there! I see forrest at the web site and it looks terrific! Well done, my congratulations. Congratulations! :-) -- 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: mirroring, web pages, and disk space
Greg Stein wrote: I believe Brian also asked the XML folks to lighten up their web pages, since the combination size of pages/images are expensive compared to the other Apache sites. In Forrest we already have made a Forrest version of the XML website http://xml.apache.org/forrest/xml-site/index.html We can push it to the front quite quickly, what do others think? As for the projects... Cocoon will be doable soon, FOP is almost ready IIUC, and Xindice is already working on it. Which all means I guess that we'll have to speed up the transition of the sites. So, to organize this a bit, who is in charge of managing the docs of other xml projects please let us (Forrest devs) know what the current situation is, or on [EMAIL PROTECTED] or directly on our list. The docs format is not that far away from the original xml.apache format, and the docs build process doesn't need anymore to be in the ant buildfile, as forrest is now a tool that can be used from a single installation as Ant. We will actively help you with the transition to Forrest docs in the smallest time possible. -- 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: [PDF Viewer] Utility request
Ralph LaChance wrote: At 12:46 PM 7/25/02, you wrote: After seeing the OutOfMemoryError, the AWT renderer is causing, why don't thinking of providing a PDF viewer in the FOP itself. I think, this will be useful so much. I don't think people couldn't have ever thought about it, but is it diffucult to do so? I feel, FOP is very much useful with the PDF viewer. What do others say? Seems to me it might be a lot simpler to fix the awt viewer... Also, oddly enough doing a viewer against pdf is rather tricky - Adobe put an un-supported java-bean on their web site, but it is buggy and hasn't been updated in 2 or so years. The only commercial pkg (a toolset; some assembly required) I know of probably would pose a licensing challenge (understatement) Anyone contacted Adobe to see if they wanna opensource it? -- 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]
[Morphos] Java data morphing package - second stab
Ok, here is the second stab at it :-)
I'm still crossposting now to other projects that have shown interest.
I have gotten many suggestions privately, so this will contain them +
clarifications, and a concrete example.
This discussion properly resides on the Jakarta Commons mailing list.
To subscribe, send an empty mail to [EMAIL PROTECTED]
From: Nicola Ken Barozzi [EMAIL PROTECTED]
What is Morphos?
-
Morphos will be a Java Api and implementation for transforming data, in
any
form it may be: xml, streams, objects.
It focuses on the API and framework, and demands implementation to other
projects-modules wherever possible.
Why Morphos?
-
Morphos starts from a need around a community of developers, with an
initial
charter committed in Jakarta Commons Sandbox.
[...]
What does it do?
-
Morphos should simply do:
data -- morphos --- data
Data can be:
- stream
- events
- objects
I don't see other basic generic data types, since files and such can
become streams and viceversa without any format or form conversion.
I want a *very* simple api, with no duplicated methods.
IE having get(Stream) and get(File) is not necessary IMO, since they do
the
same thing.
The main API must be very simple. We can always add helper classes.
[...]
Ok, but in Concrete?
--
Here is the proposed API, all in package org.apache.commons.morphos:
/**
* The interface that is implemented by classes that morph.
* It uses two params and not a return value to make it usable with
* event based Objects (contenthandlers).
* Parameters are key pairs, used to configure the Morpher.
* Events in the Morpher are notified by registering a listener.
*/
public interface Morpher {
void morph(Object input, Object output) throws MorphException.
IOException;
void addParameter(String paramName, String paramValue);
String getParameter(String paramName);
void remove Parameter(String paramName);
String[] getParameterNames();
String[] getParameterValues();
void addNotificationListener(NotificationListener nl);
void removeNotificationListener(NotificationListener nl);
void clearNotificationListeners();
}
/**
* The interface that is implemented by classes that morph.
* It uses two params and not a return value to make it usable with
* event based Objects (contenthandlers).
* Events in the Morpher are notified by registering a listener.
* [new] parameters are managed with beans get/set methods
**none* are mandatory
*/
public interface Morpher {
void morph(Object input, Object output) throws MorphException.
IOException;
void addNotificationListener(NotificationListener nl);
void removeNotificationListener(NotificationListener nl);
void clearNotificationListeners();
}
[Clarification]
Why not
Object morph(Object input) throws MorphException, IOException;
?
Because if the output object is a SAX handler, the morphing doesn't take
place, and this is not evident.
Any other pros-cons?
[Clarification 2]
Why use Object as input and output?
Why not use different types?
Genericity.
See the below comments after the Factory/Manager.
/**
* A Morpher made out of a sequence of morphers.
*/
public interface MorpherPipeline extends Morpher {
void addStage(Morpher nextMorpher);
}
This remains.
/**
* The Factory for Morphers.
* There is a getDefaultFactory method for easy use.
* Used in frameworks it's better not to use it and rely on
* services that give the proper MorpherFactory.
*/
public abstract MorpherFactory {
Morpher getMorpher(DataType inputType, DataType outputType);
Morpher getMorpher(name);
Morpher getPreparedMorpher(DataType inputType, DataType outputType);
Morpher getPreparedMorpher(name);
static MorpherFactory getDefaultFactory();
}
/**
* The Morphers' manager.
* There is a getDefaultFactory method for easy use.
* Used in frameworks it's better not to use it and rely on
* services that give the proper MorpherFactory.
*/
public interface MorpherManager {
Morpher getMorpher(DataType inputType, DataType outputType);
Morpher getMorpher(name);
Morpher getPreparedMorpher(DataType inputType, DataType outputType);
Morpher getPreparedMorpher(name);
}
I've removed the static method, and made it an interface.
It will be the MorpherManager implementation that can use this pattern.
Why not *Factory?
Because it does more than just create them.
[Clarification 2]
Why is a Manager needed?
Because (see clarification 1) any Morpher instance is supposed to be an
implementation that is guaranteed to work with a determined kind of Objects
(a subset); this enforcement is done by the Manager.
/**
* Describes what the format of the data is.
* It consists of a mimetype (format) and a dataForm
[Morphos] Java data morphing package
*CROSSPOST * PROPOSAL OF PARTICIPATION *
Welcome to the first public discussion about project Morphos.
This message is being posted to many lists because it has the aim of solving
a common need.
The discussion will continue, for those interested, on the jakarta commons
mailing list.
To subscribe, send an empty mail to
[EMAIL PROTECTED]
What is Morphos?
-
Morphos will be a Java Api and implementation for transforming data, in any
form it may be: xml, streams, objects.
It focuses on the API and framework, and demands implementation to other
projects-modules wherever possible.
Why Morphos?
-
Morphos starts from a need around a community of developers, with an initial
charter committed in Jakarta Commons Sandbox.
Before anything got committed, it has slightly evolved from being tied
initially to XML.
Here is the old charter
(http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/morphos/PROPOSAL.txt?
rev=HEADcontent-type=text/vnd.viewcvs-markup).
This mail illustrates the latest status of the private discussions, and a is
the start of the public one.
Currently there are many projects that need or would benefit from a generic
transformation API:
- Jakarta POI -
OLE-XML transformations
- Cocoon -
using a single api and a contrib section for the
loads of components it now hosts in the core
- FOP -
redesigning the main interface for FO-PDF,MIF,...etc
- Krysalis Wings -
transforming chart XML format to SVG or image formats
Other projects that can be wrapped round this api are numerous:
- Batik (image transcoders)
- Xerces-Xalan
- Avalon Excalibur Converter
- Commons Digester
- Jakarta-commons-sandbox Jelly
- etc...
A componentization of the transformation process can help reuse and minimize
code duplication.
What does it do?
-
Morphos should simply do:
data -- morphos --- data
Data can be:
- stream
- events
- objects
I don't see other basic generic data types, since files and such can
become streams and viceversa without any format or form conversion.
I want a *very* simple api, with no duplicated methods.
IE having get(Stream) and get(File) is not necessary IMO, since they do the
same thing.
The main API must be very simple. We can always add helper classes.
I took look at these APIs:
- Jaxp
- Batik Transcoder
Jaxp:
Baised towards xml (more in package names than in fact). Already has a bad
track on version using (the infamious endorsed dir and param). Uses static
method for getting the transformer.
Batik Transcoder:
Good API but it's source can contain a Reader, InputStream, Contenthandler,
etc, so it's tied to these.
No support for pipelining of transcodes.
Ok, but in Concrete?
--
Here is the proposed API, all in package org.apache.commons.morphos:
/**
* The interface that is implemented by classes that morph.
* It uses two params and not a return value to make it usable with
* event based Objects (contenthandlers).
* Parameters are key pairs, used to configure the Morpher.
* Events in the Morpher are notified by registering a listener.
*/
public interface Morpher {
void morph(Object input, Object output) throws MorphException.
IOException;
void addParameter(String paramName, String paramValue);
String getParameter(String paramName);
void remove Parameter(String paramName);
String[] getParameterNames();
String[] getParameterValues();
void addNotificationListener(NotificationListener nl);
void removeNotificationListener(NotificationListener nl);
void clearNotificationListeners();
}
/**
* A Morpher made out of a sequence of morphers.
*/
public interface MorpherPipeline extends Morpher {
void addStage(Morpher nextMorpher);
}
/**
* The Factory for Morphers.
* There is a getDefaultFactory method for easy use.
* Used in frameworks it's better not to use it and rely on
* services that give the proper MorpherFactory.
*/
public abstract MorpherFactory {
Morpher getMorpher(DataType inputType, DataType outputType);
Morpher getMorpher(name);
Morpher getPreparedMorpher(DataType inputType, DataType outputType);
Morpher getPreparedMorpher(name);
static MorpherFactory getDefaultFactory();
}
/**
* Describes what the format of the data is.
* It consists of a mimetype (format) and a dataForm (representation).
* For example a gif image file and a jped image file have a different
mimetype but same dataform (file).
* An SVG file and an SVG DOM in memory have same mimetype but different
dataform.
*/
public interface DataType {
void setMimeType(String mimetype);
void setDataForm(String format);
String getMimeType();
String getDataForm();
}
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains
Re: [REDESIGN] configuration
Sorry if I'm not replying inline, but with some mails Outlook Express seems to be unable to properly add s . :-( (If anyone knows a workaround, please let me know) Anyway, your description is correct, and very well done. One of the main points in avalon is the IoC (inversion of control), where the Container pushes things to the Components. Static accessors are bad in this regard, as they make the Component ask something to a class that is not even a container. This usually brings to the problems FOP has had with config until now. In a server environment especially, good role hierarchy and containment is paramount, and Avalon helps to enforce and use it. One thing though: Logging is a bit different than other things... it's not really a component, but an aspect. This means that we would need another programming language to use it correctly from a framework POV... In practice, I have seen that the best thing is making the big blocks get a Logger from the parent, and have the smaller classes get it from a static method that permits the usage of a key, that in the case of important classes can be set from the outside. As for helping, I will be happy to do so. Unfortunately I have not had time till now to give an active hand, but now I can find some time. The good news is that Forrest is running (http://xml.apache.org/forrest/) and that we are starting to convert the xml.apache projects to use the new DTD. Since you have showed interest, FOP will be one of the first projects to have the site automatically published by Forrest :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 5:18 PM Subject: Re: [REDESIGN] configuration Here are some ideas about how we could do the configuration for FOP. Comments are welcome. Use this class and various supporting classs (already in avalon framework jar): org.apache.avalon.framework.configuration.Configuration From a brief look at how this works it should be quite easy to use. We just need to decide on an appropriate xml structure. I have attached an example. It is. I'm using this stuff every day. This can be used either with an xml file on the command line or through embedding, eg. cocoon could pass a fop configuration class. If the classes are not configured then default values are used. Configurable classes: I'd like to elaborate because I'm not sure that everyone is familiar with Avalon's concepts: These classes will implement the Configurable interface from Avalon. Following the concept of IoC (those who are not familiar with this term, please look up Avalon docs) the configuration is set by the container (ex. Cocoon or our command-line wrapper) on the child (Driver, Renderer etc.). - Driver Passes configuration to user agent if not already set and to renderers. Right. Driver will probably still remain our top-level component, serving as a black-box of the whole FOP-process. - All renderers (ie. Renderer, StructureHandler implements) This is so that the renderer can get its own specific information. The PDFRenderer could have font setup, stream filters etc. Correct. That's something I'm burning to do for a long time. PSRenderer will get very configurable eventually. - Configurable FOUserAgent (have default FOUserAgent that can be used/extended without config) To make it possible to setup all the various options like dpi. I'm still at a lack of knowledge on these new things. :-( But it sounds reasonable. I think a lot of thinking when using Avalon goes into which classes are components (they get a logger, configuration etc. and provide some sort of service) and which are merely data-holding classes like an InlineArea. Correct me if I'm wrong: UserAgents are those classes that do the heavy work that was formerly distributed in many different classes directly on classes that change into simple data-holding classes at the moment. -- The logkit Logger can be configured using this but it is not appropriate. If FOP is run from the command line then it should do what it already does and when embedding it would setup its own logger. Logging is also something that is set on the child by its container. The command-line wrapper sets a simple ConsoleLogger on the Driver by using the LogEnabled interface. Other containers like Cocoon will configure their Logging somewhere else and set the desired Logger using LogEnabled on Driver, which in turn passes some child logger of the given one to its children. The image cache and other cache are similar. These can be set with a static method and through the driver respectively. I'd like to avoid the static stuff, if possible. There's the concept of a ComponentManager (or after
Re: [REDESIGN] configuration
From: Jeremias Maerki [EMAIL PROTECTED] In a server environment especially, good role hierarchy and containment is paramount, and Avalon helps to enforce and use it. One thing though: Logging is a bit different than other things... it's not really a component, but an aspect. This means that we would need another programming language to use it correctly from a framework POV... In practice, I have seen that the best thing is making the big blocks get a Logger from the parent, and have the smaller classes get it from a static method that permits the usage of a key, that in the case of important classes can be set from the outside. That surprises me a little. I tend to extend from AbstractLogEnabled even for small classes if I need a Logger. But you're probably right that this reduces memory usage especially if you have a lot of small objects like we have in FOP. The fact that you are surprised is a good sign, because it means that you come from a purist view of IoC, which is always the best place to start from. I had your same vision till I tried implementing logging in Jakarta POI... a nightmare! Hundreds of classes, that were used as the object model, and it soon became not only slow but impractical. If I forgot to set a logger for a child class, the whole thing would crash with a NPE. I've come to the conclusion that smaller classes that are not really components are better of with a static system, since they use logging only during debugging. In this case JDK1.4 style logging is the best, since it can be removed compile-time. This becomes not correct with bigger Components, where Logging is part of the usage too, like server Components that log accesses for example. In this case Avalon Logging framework has indeed no true rivals :-) -- 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: Lest we forget
From: Bertrand Delacretaz [EMAIL PROTECTED] This probably helps: http://www.anzacday.org.au/ -Bertrand In Italy we had Liberation Day. 25AprilAnniversary of the Revolution in Portugal 25AprilAnzac Day in Australia 25AprilAnzac Day in Cook Islands 25AprilAnzac Day in New Zealand 25AprilAnzac Day in Tonga 25AprilAnzac Day in Western Samoa 25AprilLiberation Day in Italy 25AprilLiberation Day in Portugal 25AprilNational Flag Day in Swaziland 25AprilSinai Liberation Day in Egypt Funny how Gallipoli is also an Italian town. This is a small world indeed... On Friday 26 April 2002 00:38, Martin Stricker wrote: Peter B. West wrote: Age shall not weary them, nor the years contemn. At the going down of the sun, and in the morning, We shall remember them. Lest we forget. Anzac Day 25th April 2002 Could you please explain this e-mail? -- 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: License Issue Inquiry
I'm moving this to [EMAIL PROTECTED] because I think it's of interest to all. If not, please excuse me. From: Charles Marcus [EMAIL PROTECTED] Greetings, I hope this is the proper place for this question to be submitted. If not, please direct me to where I need to go. I am taking it upon myself to submit a query regarding the Apache Software License that FOP is licensed under. There is some big interest currently in the OOo (OpenOffice.org) community with respect to finding a cross-platform, uniform and integrated method for providing PDF document creation, and FOP looks like it could be the answer. The only question is, can OOo use it? OOo requires that anything integrated into its source code be made available to them under the terms of the LGPL license. What would be required in order to allow a version of FOP to be licensed/sub-licensed/dual-licensed under the LGPL? The Apache license makes the code usable in any way, as long as you give proper credit and don't blame Apache for problems. AFAIK, the problem lies in the *GPL license, which is more restrictive; my personal suggestion is to check the LGPL license and ask the authors of that license. IIRC GNU states that Apache and *GNU licenses are incompatible for them, but don't take my word for it. Apache AFAIK releases code only under the Apache license. I am not subscribed to the list so would appreciate any replies to be cc'd directly to me at: [EMAIL PROTECTED] Thanks! Charles Marcus -- 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: [DOCUMENTATION] design/alt.design new files [2 of 2]
From: Peter B. West [EMAIL PROTECTED] Attached are new files for the xml-fop/docs/design/alt.design directory. Gee, this is cool! :-) catching up on tons of mail -- 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
From: Keiron Liddle [EMAIL PROTECTED] On 2002.03.19 14:45 Nicola Ken Barozzi wrote: I would consider the possibility (configurable) of having FOP make just sensible assumptions to continue processing and sacrifice some things it should do later. That sounds very vague. So what will you do if someone has a table of contents as the second page. Will you pass across a whole lot of to be resolved things for the page numbers to the renderer, so the renderer needs to do the resolving from some further information. Will the renderer go until it reaches a to be resolved thing then need to do some awkward processing of all the following pages. I would output a ? instead of the real pages. While this is not generally acceptable, in reports, for example, these references are usually not needed. High memory consumption is *the*killer*, and it's a burden that is not needed in these cases. It all sounds like an extra level of complexity that we really don't need. Rather than helping us it will simply make things more difficult. Good point. I will keep this in mind. - embedded xml will need to be parsed twice and saxified Why twice? May need to read it to get the width and height and do some pre-processing with a DOM. It can be equally done by a sub-pipeline with SAX. But I understand that Batik is still DOM based :-( ATM, I don't have a clear list of all the things that need to be held back before resolution. Is there a list somewhere? It would be of great help for me. Since propertiy resolution is basically inherited AFAIK, it seems that what you specify is in fact what really breaks the nice SAX stuff. Page references. Yes. Internal links. May be. In HTML it's not needed since I can write an internal link (#myref) before specifying it. Retrieve Markers? IMHO yes, since you can make a forward reference with it. Extensions. Let's bypass extensions for now. So we absolutely need to stop output and cache events if there is a forward reference. If we find it at the end, all the pages must remain in memory, and now I see that this can make FOP behave no better than it does now. There are three possibilities I see: 1. Start storing the SAX events as soon as a forward reference is caught, and flush them after the resolved reference. 2. Ignore the forward references (speed property); if someone doesn't use any of the above features, there is no difference in output anyway. 3. Do the FOP processing in 2 steps. 1- Process all the stuff without the references writing to disk 2- resolve them by rereading the file This resolves memory issues but not speed. I would go for 1 and 2. If we store the SAX events before firing them, they are smaller than DOM and can be saved to a Store that can also be a disk in case of low memory. This is how Cocoon caches pages, and this is how we could cache SAX fragments that are there just to wait for a forward reference. We can also give a clear indication to users to how to optimize pages: no forward references = much less memory = higher speed. Anyway, these forward references are a pain in the ass :-/ -- 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
From: Keiron Liddle [EMAIL PROTECTED] On 2002.03.19 16:47 Nicola Ken Barozzi wrote: So we absolutely need to stop output and cache events if there is a forward reference. If we find it at the end, all the pages must remain in memory, and now I see that this can make FOP behave no better than it does now. Thats not true. We can do better and the current development is developing towards a way that will do better. The key is that there is a definite API between the Area Tree and the Renderers. This means that we can prepare a page and later render its contents. All following pages can be rendered if they are finished. The forward reference resolution can be done in the area tree with the help of the layout managers and then the completed page can be rendered (depends if the renderer supports out of order which pdf does). If the memory gets low then a page can be stored to disk and retrieved when forward references are resolved. Ah, so it's done with pages. But with some renderers pages could not be defined (as the spec allows), like in HTML rendering. Anyway, I didn't come up with this possibility, since I don't usually deal with them, but it's a really neat solution to the problem, but still useless if every page has forward references. Without needing to handle this on two sides of the fence it is more straight forward and flexible. Two sides of the fence? Never thought so. Ok, so I see that there is agreement on the fact that using SAX events as intermediate steps of the FOP processing pipeline is not the best solution ATM. I will focus now on implementing Avalon stuff in FOP, starting from Configuration (non static) and URI resolving (for images). Thank you all for the wonderful feedback on my Random Thoughts :-) -- 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
From: Matthias Fischer [EMAIL PROTECTED] In other terms: IMO, the legal dispositions of an open source software shouldn't be more complex than those of their commercial competitors. You're right. In fact, the ASF is less complex. The ASF distributes software that can be 100% sure to be usable as the APL license says, which basically is do what you want but give us credit and don't blame us. The libraries are usable in the format they are distributed in as if they were APL, since this is what compatible means. If you have other questions regarding the license, or want to make these suggestions to the ASF, you are welcome. Taken from http://jakarta.apache.org/site/contact.html : The Jakarta Project is an effort of the Apache Software Foundation. The address for general ASF correspondence and licensing questions is: [EMAIL PROTECTED] You can find more contact information for the Apache Software Foundation on the contact page of the main Apache site. -- 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]
Going in the _Forrest_ (was Re: FAQ Answers please)
From: Joerg Pietschmann [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: There is a new project in Apache called Forrest, that is redesigning the whole xml.apache.org site to become useful as a Sourceforge on steroids. We are at the beginning, and it would be cool if you join us there! Well, there are already GNUforge and PostNuke I hope you havn't fall prey to the NIH syndrome. I hope too. But *GNU stuff is off limits for Apache, as you know. We have reviewed other projects, but they don't even come close to what we envision. If you have APL compatible projects that can help us, please let us know ([EMAIL PROTECTED]). Currently, there is a mailing list, forrest-dev and a CVS module xml.forrest Would it still be possible to use established mechanisms as long as forrest is not put into production? Of course. Forrest will be an *option*, not an obligation. It is *our* goal to do the work for you, not viceversa. BTW, if you want, in the meantime I can make a patch to your build to use Cocoon and the new slim xml.apache.org style that is in current Cocoon cvs. It has the same LF of the current one but doesn't make use of batik, and site is much slimmer. The libs would be an additional 1.4 Mb, comprising the Avalon framework and Excalibur jars that you will need anyways. The Cocoon jar itself is less than 1Mb. It would be nice if you could give a short note about the current state and how the forrest project will influence the publication of FOP docs in the future (to keep it on topic for this list :-). :-) Forrest will make the FOP site pubblication a _piece of cake_, and we are working with GUMP to integrate the two processes. Basically, all you will need is to register up for forrest docs generation, and that's it. Forrest will trigger regularly on GUMP and: -get the xdocs from your CVS -get the results from the gump build -generate xml javadocs -massage everything with new slimfast stylesheets -deploy the site -mail nags to the mailing lists like: - pending patches - pending bugs - please suggest ;-) This is the first phase. Subsequent releases will grow based on demand and the Forrest project scope in the README. -- 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
From: Peter B. West [EMAIL PROTECTED] Nicola Ken Barozzi wrote: Don't get me wrong, maybe I don't understand something, but still I'm very puzzled. Nicola, Your criticism here distresses me somewhat. How is anyone without commit access able to branch the code? I have been active on this list for twelve months or more, so your not knowing of my effort reflects the fact that you have recently joined. Sorry, I didn't know. I still think that it's strange that the redesign effort is done outside of FOP CVS, but now it's clear to me that you didn't have another possibility. It's some month's I've been on this list, and my longer experience on other lists made me wonder about the current status of FOP. I thank you for taking your time to explain. Since I would like to give a hand if possible, could you please give me insight on how you've redesigned the framework, or some reference to available material? It would be great. 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: FAQ Answers please
From: alex [EMAIL PROTECTED] Hello Joerg, Firstly lets set up a mailing list for discussing Apache FAQs. I think it would be a Good Thing. AFAIK there is no official XML schema or DTD for FAQs, but we can come up with one. There is something called xdocs which is what most Apache documentation is written in. I am not sure if it is suitable for FAQs. If we agree on a FAQ Schema I am happy to convert my data into that format so that it can be incorporated into the CVS tree. HOWEVER do we want the FAQ in the CVS tree? It means that it is a lot harder to add new answers. I am thinking of mimicking the old Java based Jyve program in simple perl so that people can use this URL http://www.owal.co.uk/cgi-bin/fopfaq.cgi to add material to (my) FAQ as well as read it. There is a new project in Apache called Forrest, that is redesigning the whole xml.apache.org site to become useful as a Sourceforge on steroids. We are at the beginning, and it would be cool if you join us there! Currently, there is a mailing list, forrest-dev and a CVS module xml.forrest Hope you join us! :-) -- 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
.
*/
void setOutputStream(OutputStream out) throws IOException;
/**
* Get the mime-type of the output of this codeComponent/code.
*/
String getMimeType();
/**
* Test if the component wants to set the content length
*/
boolean shouldSetContentLength();
}
public interface XMLConsumer extends ContentHandler, LexicalHandler {
}
public interface XMLPipe extends XMLConsumer, XMLProducer {}
public interface XMLProducer {
/**
* Set the codeXMLConsumer/code that will receive XML data.
*/
void setConsumer(XMLConsumer consumer);
}
As you can see, it's pretty straightforward.
Cocoon also makes all Avalon markers available: if you mark it as Poolable,
it gets pooled, LogEnabled, it gets logging, Configurable, it gets a
Configuration, and so on.
When this is in place, all the infrastructure is there, and we can
concentrate on the real FOP code.
Ok, fire at will, I have an asbestos suit on ;-)
--
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)
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-
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: 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 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)
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: merging two libraries
From: [EMAIL PROTECTED] Keiron Liddle writes: That sounds like a good suggestion. To start with I think we should consider only this: FOP behaves exactly the same but instead of having its own pdf generation code then iText is used as a library to generate pdf. So the questions are: - is the license useable I did a little search and I found people saying that MPL is compatible with the Apache license and others saying it isn't. My main concern is that I don't want a license that allows my employer to prevent me from distributing the code I write at my work for free. I don't know if the Apache License is strict enough to ensure me that. The Apache licen(c|s)e makes the code available for any use as long as due credit is given. No reference is given to availability of the source code of the modifications. If you modify Apache licen(c|s)e code, you can keep the modifications for yourself, as long as you give due credit. If the code is to ask to become an Apache project, the source code *must* be Apache licen(c|s)e 1.1. If not, it can be still used by FOP as a jar if the licen(c|s)e permits its distribution with Apache software-code. - is the api sufficient for FOP to use I don't know, but we can always fill the gaps. :-) -- 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]
[PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
Given what has been said on the mailing lists of FOP and iText, and given the current scope of the two projects, I feel reasonably sure that this could be a proposal accepted by bot communities. - FOP uses iText as a PDF generation library - This could have greater benefits than a merger and keep intact the strenghts that these two projects have (remember AOL+Time Warner? is the result we want?). iText could continue to be an excellent PDF (and RTF AFAIK) generation package with a good java API. FOP could concentrate on FO2AreaTree and use iText as the last step. 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. AFAIK iText is already able to produce PDF using an XML file. If FOP could make a transformation step from FO to this format, we could get this up running in a short time. And IText can also output to html, which is not bad at all. What do you think? Shall we pull this off? -- 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)
From: Peter B. West [EMAIL PROTECTED] Nicola, I think there are a few issues to be considered here. Essentially, what is FOP? Good point. There may be a number of requirements of an XSL-FO processor. The basic one is, Show me this on a page or screen. Any kind of renderer, using any approach whatsoever, will achieve this, more or less. The so-called structure renderers, like the rtf and mif renderers, do this with a useful side-effect; the file they produce can be not only viewed, but edited. It seems to me that what you are proposing is to use iText as a basic structure renderer, mapping the fo structures into iText-compatible structures. As a start, yes. With all of the structure renderers, however, you are at the mercy of the individual layout engines. Anyone who has tried to produce a complex document using two versions of MS-Word will have an acute understanding of what it means to be at the mercy of someone else's renderer. I think the POI team (http://jakarta.apache.org/poi/) would have something to say about this, but it would not be appreciation for the MS file formats ;-) The spec itself defines a layout engine in the production of the area tree from the fo tree. Admittedly, there are a number of grey areas in layout, especially when constraints conflict, in which the final decision is up to the User Agent. Effectively, it's up to the implementation. The area tree, though, defines the position of every mark on every page. It inherently holds out the prospect of producing identical layouts from every renderer downstream of the area tree. This implies AFAIK that the creation of the area tree is the crucial point, the pivotal scope of FOP. I was initially skeptical about this, because of the dependency of the layout on the font characteristics. It was pointed out to me, though, that as long as a renderer honoured the metrics of the design font then, even if individual glyphs were considerably different, the *layout* would still be identical down ot the position of individual glyphs on a page. It seems to me that that is what a full implementation of the spec implies, and that such a search for consistency in the position of marks on page or screen is one of the most desirable features of the spec. What may not be achievable across different implementations, we may still seek to achieve within a single implementation. Yes. With that in mind, we can probably conclude that a true structure renderer cannot achieve this cross-renderer consistency. And this is taken in account for in the spec as you know, which defines many tags as optional and hints on how to downgrade gracefully. That would also be true of iText, used in such a way. If however, the interface to iText were defined such that the position and size of al marks to be put on the page could be rigorously determined, it could meet the requirement. I, for one, would like to see such a precise and relatively low-level pdf library. In the proposal, the hint to active collaboration is there to achieve this synergy. Itext can give FOP a boost in rendering, and the FOP community can give iText greater precision in rendering. The iText community has shown IMO sincere quest for an active collaboration, and even donation of the code to FOP. As both communities pointed out correctly, just merging two project usually doesn't make a bigger project, but a bigger mess. So it seems that this thing can start :-) There is no need for a VOTE, since plain discussion and sharing of views is free, of course. 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? -- 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-
From: Bertrand Delacretaz [EMAIL PROTECTED] On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). 3b After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. This is the proposal I made, and I think it stands even stronger now. If FOP is pipeline driven, any renderer can be quite easily plugged in. AFAIK, the pipeline architecture is one of the major design differences that in some way has been agreed on. 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. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. I agree. This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) And POI. At POI, we are going to do a Word .doc format writer. It could fit easily in this picture. -- 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: [iText-questions] Re: merging two libraries
From: New, Cecil (GEAE) [EMAIL PROTECTED] My suggestion was *not* to merge the two! iText is a Java API with a document creation focus. In this day and age, XSL:FO can be viewed as just another document type - in the same way that more proprietary or older formats are (that is, PDF, RTF, etc.). Sorry if it's a bit off-topic, but this issue is similar to the one we just managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon (http://xml.apache.org/cocoon/). POI is a project that makes it possible to read-write common office file formats in Java. Cocoon is an XML processing framework-server. The POI team donated a Cocoon component that uses POI and outputs XML, but on the Cocoon side, committers saw too much POI code in it. Basically we understood that a project to read-write a file format should have a solid Java API. Other projects can use it to produce other results. Merging is not the best solution, both for developers and users. From this experience, I would humbly suggest that, after getting the licencing stuff straight, FOP could be refactored to use iText as a PDF generation step. In this way communities can focus on a smaller part of the project with greater efficiency, and the two products may have a much wider applicability than a single merged one. Since iText has a strong community behind it, since it would like to integrate code with FOP, thus coming to Apache, and since FOP could use part of it proficiently, I would like to see iText make a proposal at Jakarta for the creation of a project. All details for this are under http://jakarta.apache.org/site/newproject.html . What do you think? -- 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: [iText-questions] Re: merging two libraries
From: alex [EMAIL PROTECTED] At 14:27 12/03/02, Keiron Liddle wrote: FOP behaves exactly the same but instead of having its own pdf generation code then iText is used as a library to generate pdf. I agree that if anything iText could be considered as a plugin for PDF generation and FOP as an XSL:FO processor which could use iText to generate the end result. I think however it would require a significant software change which I am not qualified to estimate. Those more familiar with the FOP source code can evaluate that. So the questions are: - is the license useable - is the api sufficient for FOP to use A look at Sourceforge tells us that the licenCes (bloody Americans can't spell English words) are License: GNU Lesser General Public License (LGPL), Mozilla Public License 1.1 If Bruno is still the copyright holder then he can presumably simply add an Apache-style licence. I don't feel comfortable using the LGPL for this and don't know about the Mozilla license. Any *GPL licenced stuff cannot go in Apache CVS. If the code goes in the Apache CVS, it must have Apache licen(c|s)e. -- 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: java.util.HashMap to com.sun.java.util.collections.HashMap
From: David B. Bitton [EMAIL PROTECTED] Has it come up where anyone has attempted to use FOP w/ JDK 1.1. The is no HashMap class. Sun has made available the collections classes for use in 1.1. This requires changing every import of java.util.HashMap to com.sun.java.util.collections.HashMap. I plan on doing this on my copy of the codebase, because I am rolling FOP up into a COM DLL for use from an ASP page, and J++ (the only way to build a COM DLL, as far as I know) uses 1.1. You can use also the java-plugin (IIRC) to make java objects used as OCXs. There is also a project on IBM alphaworks, and one on Sun javasoft to make EJBs used in such a way. Maybe these can help. -- 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: [SUGGESTION] Java GUI for FOP
From: Michiel Verhoef [EMAIL PROTECTED] AFAIK The fop version included in Cocoon is not the most recent one. But of course it is possible to replace the one supplied with Cocoon yourself. Current CVS version uses fop-0.20.3rc.jar . -- 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: Using Avalon/Logkit
From: Joerg Pietschmann [EMAIL PROTECTED]
Jeremias Maerki [EMAIL PROTECTED] wrote:
Ok, I think that can be done, even when using Avalon in FOP. You propose
(I think) that we could provide an Avalon-Wrapper around FOP,
Thanks for the help.
Some comments on the concerns: I'm forced to use JDK 1.3 with JAXP1.1 and
proprietary extensions for logging and configuration management (and other
stuff i'll ignore now).
I have to use the proprietary API to retrieve configurable options and
want to feed them to a FOP instance. It's not easy for me to deploy a
config
file, nor do i want to. My purposes would be served best if there were a
processor class which took all configuration options as a Properties
bundle
or through some generic interface like Transformer does. An avalon
component
class encapsulating the simple processor class (or derived, for possible
performance gains) could use this interface to pass options read from a
config file, command line options or whatever.
Avalon can really help you here.
If FOP is completely Avalonized, you can plug in you own implementations of
logging or configuration Management without changing the core FOP code.
Avalon gives you these services using interfaces; this way any
implementation can be used.
but it
could also be the other way around. I'm sure that Avalon will not stand
in the way if we provide a simple interface similar to what you
proposed.
Well, adding is easier than subtracting. Apart from the interface, i
don't want to have FOP looking around for files (URIs are ok, if i could
supply code to resolve them).
Can somebody explain to me what could be gained if the processor
was an avalon component by default (other than easy integration into
the avalon framework, of course)?
It automatically gets the possibility of using all Avalon services.
Instead of explaining all possibilities, let me show you an example of the
Avalon way.
Let's say that you write your class:
public class MyClass {
public MyClass{}
}
Now you want it to get created and managed by Avalon.
So you define it in a config file (or programmatically)and change it to:
public class MyClass implements Component{
public MyClass{}
}
This way, when Avalon starts, it creates you class.
Now you want it to get some configuration.
public class MyClass implements Component, Configurable{
public MyClass{}
public void configure(Configuration conf)
{
//use conf here
}
}
The Configuration it gets is gotten from *any* class that uses that
interface; Avalon will supply it to you.
Now you know that your configuration can change, so you write:
public class MyClass implements Component, Configurable, Reconfigurable{
public MyClass{}
public void configure(Configuration conf)
{
//use conf here
}
public void reconfigure(Configuration conf)
{
//use conf here
}
}
now you want to add some init code:
public class MyClass implements Component, Configurable, Reconfigurable,
Initializable{
public MyClass{}
public void configure(Configuration conf)
{
//use conf here
}
public void reconfigure(Configuration conf)
{
//use conf here
}
public void initialize()
{
//initialization code
}
}
now you want to add some lifecycle code:
public class MyClass implements Component, Configurable, Reconfigurable,
Initializable, Startable{
public MyClass{}
public void configure(Configuration conf)
{
//use conf here
}
public void reconfigure(Configuration conf)
{
//use conf here
}
public void initialize()
{
//initialization code
}
public void start()
{
//start code
}
public void stop()
{
//stop code
}
}
now you want to logging:
public class MyClass implements Component, Configurable, Reconfigurable,
Initializable, Startable, Loggable{
public MyClass{}
public void configure(Configuration conf)
{
//use conf here
}
public void reconfigure(Configuration conf)
{
//use conf here
}
public void initialize()
{
//initialization code
}
public void start()
{
//start code
}
public void stop()
{
//stop code
}
public void getLogger(Logger logger)
{
//get logger here
}
}
And so on.
Avalon is the glue that ties all together.
If you implement Composable, you get a ComponentManager that gives you other
Avalon components managed in the same way.
There are Avalon components for URI resolving, caching, storage, xslt, etc.
All these components are accessed by an interface, so you can out any
concrete impl behind.
In fact, Composable has:
public Component lookup(String role);
Whatever you get must be cast to an interface.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains
Re: Using Avalon/Logkit
From: Joerg Pietschmann [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: I've used Avalon framework in many projects, and IMHO it's not heavyweight. Ok, scratch the heavyweight. In order to clarify issues: I have to use FOP in an environment which already provides logging, configuration management and life cycle management. What is it? I don't want to look into another log file. I don't want to write more config files. ? (There is also the fact that said environment goes to great length to make augmenting already provided functionality as complicated as possible). Avalon? I disagree. I've used it in a 10 months project. It saved me weeks of work. And the architecture came out really clean. I have already customized ErrorListeners, URIResolvers and such and i want to reuse the functionality in the most straightforward way possible. Using Avalon *is* reusing functionality. I don't want to write more customizations just for the Apache logkit. In particular, i don't want to learn how to write such customizations. Customizations? I don't get you here. I don't want to prevent anyone from providing a FOP embedding using logkit and avalon. Ok. Anyway, logging is a minor issue. If Avalon were logging, it would be just logkit. I *want* however access to a core which doesn't rely on yet another toolkit for common functionality Wait a second. If you need configuration, you *need* it. So you need to write code to do it. So, what's the difference between importing Avalon code or writing it yourself? What do you gain in writing it from scratch? and fits as seemlessy as possible into a run time environment roughly equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1). Sorry but I don't get you here. What is your measure of seamless? I don't want this discussion to get into -just- logging, because IMO it's not the point. FOP (correct me if I'm wrong) is about transforming a fo tree in an area tree, and then render this in many ways. It's not about logging, configuration, lifecycle management, URI resolving, etc. But it needs them. Avalon provides them, very well IMHO, and it's tried and tested code. Why not use it? My opinion is that using Avalon, FOP can concentrate on its core tasks, the FO-AT-Render phases. I would even dare go one step further. FOP has basically two phases: FO2AT and AT2Rendering. In Cocoon2, the first is a Transformation phase, the second a Serialization phase. My crazy idea is that the new SAX driven FOP can be built on Cocoon as a Transformer and a Serializer. All utility stuff is taken care of by Cocoon. In this way we can concentrate on the *real* features of FOP. When it works, we can then make it run in a more lightweight environment built on Avalon. For this, I seriously volunteer. -- 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: Using Avalon/Logkit Was: Re: [Understanding] Images [4]
From: Joerg Pietschmann [EMAIL PROTECTED]
Jeremias Maerki [EMAIL PROTECTED] wrote:
By the way: What's the current agreement whether to use Avalon or not? I
mean, we're already using LogKit (which is cool).
No, it's not cool unless done properly. I don't think users
who want only pure FO processing should be forced to use
another heavyweigth framework and logkit.
I've used Avalon framework in many projects, and IMHO it's not heavyweight.
Logkit is *very* light and fast, and I would humbly suggest to take a look
at the framework/logging classes that shields logging from implementation.
In this way any logger can be plugged in without changing code.
I rather imagine something like the following layered
architecture:
1. FOP core. Processes XML, either as SAX event stream by
supplying a content handler or by utilising the interface
javax.xml.transform.Source, into a renderer specific result
(probably a java.io.OutputStream, could even apply to a voice
renderer :-)
Do not rely on any hardcoded external files. Get configuration
via a java.util.Properties object or other explicit methods.
In my experience, using the avalon framework Configuration adds a *lot* of
flexibility and is very easy to use. Now it also has writing capability.
Using XML, it has a hierarchy.
Use a FOP owned interface like javax.transform.ErrorListener for
reporting errors and such, or perhaps even reuse ErrorListener
(somewhat odd, though).
In error reporting there are wo levels: user and developer.
The user gets notified by ErrorListener, the developer by logging. The user
could also want to put a logger as errorListener. Anyway avalon frameworl
logging shields from the logging implementation.
Use a javax.transform.URIResolver or a similar FOP owned
interface for resolving URIs (external graphics source, user
font file...).
There is already a tried and tested Avalon Component for this.
2. Intermediate layer with a class combining a transformer and
a FO processor instance (optional)
3. Class for embedding into the framework. Provides implementations
for the URIResolver and the ErrorListener, the latter redirecting
to the logging toolkit. May read external, user writable configuration
files. Uses framework for passing options and other parametrisations
from the outside (command line, servlet request, applet parameter...)
There is already a CLI util class in Avalon.
It may be an idea to use the factory pattern like javax.transform:
abstract classe FOProcessorFactory {
// get a new factory. factory may cache default properties for
// processors, fonts,...
static FOProcessorFactory newInstance();
// create a new processor. a FOProcessor instance is only good
// for one run, like a Transformer
abstract FOProcessor newFOProcessor();
abstract FOProcessor newFOProcessor(Renderer enumeration);
There are ComponentManagers in Avalon, that handle lifecycle automatically.
// inherited to generated processors
abstract void setErrorListener(ErrorListener);
// inherited to generated processors. use also for example for
// loading default fonts while creating a new processor instance
abstract void setURIResolver(URIResolver);
// set attributes, like font file URIs or even compiled font
// classes
abstract void setAttribute(String name, Object value)
// perhaps a few shortcuts for transformations
abstract void setTransformation(Source xsl);
abstract void setTransformation(Templates);
// various get methods omitted :-)
}
abstract class FOProcessor {
abstract void setRenderer(Renderer enumeration);
abstract void render(Source,OutputStream);
abstract void setErrorListener(ErrorListener);
abstract void setURIResolver(URIResolver);
abstract void setAttribute(String name, Object value)
// shortcuts
abstract void setTransformation(Source xsl);
abstract void setTransformation(Templates);
// extra shortcut (makes no sense for the factory)
abstract void setTransformation(Transformer);
}
This is basically a definition of an interface of a FOProcessor, the main
avalon-style Component for FOP.
Using Excalibur ComponentManager, you just need to add a reference in the
xml configuration and it gets automatically setup, configured, and managed.
If a transformation is set, the Source in render() is the original
XML piped through the transformation. I'm not sure whether get/set/
clearParameter for the transformation should be added to FOProcessor,
fortunately, no output properties are necessary.
If it implements the Parametrizable interface of Avalon, the Parameters get
set automatically by Excalibur.
Same with Configurable.
IMHO, Avalon *really* helps in making a clean class structure and
Componentization.
I am finding it a bit difficult in getting the grasp of FOP specific stuff,
but understand something of Avalon, so I'm very willing to help in this
regard.
Cheers!
Ken
--
Nicola Ken Barozzi
Re: AWT Window
- Original Message - From: IvanLatysh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 2:53 PM Subject: AWT Window Hello, Alistair! You wrote to [EMAIL PROTECTED] on Thu, 21 Feb 2002 09:26:32 -: AH Now that a few more people are interested in this: AH I think that it would be more useful if the basic AWT API returned a AH JPanel rather than a JFrame. ... From my practice the best way to make this flexible is just give JPanel without any controls. Just a report. And implement into this pane methods to switch pages, zoom, import And, If I need preview window I will do preview by myself with my buttons and my style. I think this is right way to do it. Better still... give the JPanel like you propose and Actions that (if needed) can be easily put in a toolbar. -- 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: AWT Window
From: Alistair Hopkins [EMAIL PROTECTED]
So how about this as the public interface:
package org.apache.fop.apps;
public class AwtManager
{
public AwtManager(InputSource fo)
public AwtManager(InputSource xsl. InputSource xml)
//these are separated so the work of showing the preview can go on a
background thread
public Component getPreviewPanel()
public Component showPreview()
//possible also to set the saved file type in the save method
public void save(Component fileChooserParent)
-0
public void save(File f)
+-0
public Action getSaveAction()
save(OutputStream out)
public void print()
public Action getPrintAction()
public void zoom(String zoomFactor)
public JCombo getZoomCombo()
public void goToPage(int n)
...etc...
//a short hand for lazy people
public JToolBar getToolbar()
}
Action[] getActions()
--
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: Any real-life business use ?
- Original Message - From: Patrick Andries [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 14, 2002 1:03 PM Subject: Re: Any real-life business use ? Alex Mc Lintock wrote that, due to a bug in IE, he had to save the whole PDF file on disk. I think I have seen this: is this when the PDF file is interpreted as text and displayed as gibberish in the main navigation window? Has this not been resolved in later versions of IE? Has the bug been reported to the MSIE team? I've been using FOP in Cocoon , and AFAIK, IE fails to understand that the file is a PDF if it doesn't have a .pdf extension. IE is not to clean when it comes to MIME type VS extensions. As a workaround you can also do IIRC document?hackattr=dummyvalue.pdf . IE knows of this, and AFAIK it's not resolved in IE5.5 . -- Nicola Ken Barozzi [EMAIL PROTECTED] These are the days of miracle and wonder... ...so don't cry baby, don't cry... Paul Simon smime.p7s Description: application/pkcs7-signature
Re: image protocal in Fop on unix
- Original Message - From: Keiron Liddle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 9:18 AM Subject: Re: image protocal in Fop on unix On 2002.01.02 21:23 Savino, Matt C wrote: This works for me: fo:external-graphic src=file:///usr/local/weblogic/config/isappdev/applications/RVWebApp1/WEB-I NF/lib/ClinTrialLogoGreenBig.gif / If you figure out how to use a relative path, PLEASE let me know. The example in docs/examples/fo/images.fo has relative urls for images (can't really have absolute urls for cvs and distributions!). The images are loaded properly. Of course if you are embedding fop then you will need to set the basedir via the config. This is really interesting 4 me. I would like to set it for the Cocoon FOP Serializer. How do you set the basedir programmatically? I'd be very grateful if you can indicate the relevant classes/parameters. Thank you in advance. Ken -- Nicola Ken Barozzi [EMAIL PROTECTED] These are the days of miracle and wonder... ...so don't cry baby, don't cry... Paul Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: image protocal in Fop on unix
- Original Message -
From: Keiron Liddle [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 03, 2002 3:17 PM
Subject: Re: image protocal in Fop on unix
This is really interesting 4 me.
I would like to set it for the Cocoon FOP Serializer.
How do you set the basedir programmatically?
I'd be very grateful if you can indicate the relevant
classes/parameters.
Coccon documentation on how to setup coccon:
http://xml.apache.org/cocoon/userdocs/serializers/pdf-serializer.html
FOP documentation on how to embed FOP:
http://xml.apache.org/fop/embedding.html
Thank you, but in the docs you indicated there is no reference to base-dir
parameters.
Is it possible to specify it in Options?
I've looked in the code and in AbstractFopImage I have:
this.m_imageReader =
ImageReaderFactory.Make(this.m_href.toExternalForm(),
this.m_href.openStream());
Then I looked in FopImageFactory and found:
// maybe relative
URL context_url = null;
String base = Configuration.getStringValue(baseDir);
if(base == null) {
throw new FopImageException(Error with image URL:
+ e.getMessage()
+ and no base directory is
specified);
}
try {
absoluteURL = new
URL(Configuration.getStringValue(baseDir)
+ absoluteURL.getFile());
} catch (MalformedURLException e_context) {
// pb context url
throw new FopImageException(Invalid Image URL - error on
relative URL :
+ e_context.getMessage());
}
In the code of the Ant task I found:
org.apache.fop.configuration.Configuration.put(baseDir,
task.getFofile().getParentFile().toURL().toExternalForm());
Configuration is static :-O
Should I use Configuration?
Ken
--
Nicola Ken Barozzi [EMAIL PROTECTED]
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
smime.p7s
Description: application/pkcs7-signature
Re: A simple question: Hot to close acrobat??????????????????
AFAIK, it remains in memory to be able to handle subsequent requests faster. AKAIK, there is no simple programmatic way to disable this. Nicola Ken Barozzi These are the days of miracle and wonder... ...so don't cry baby, don't cry [EMAIL PROTECTED] Paul Simon - Original Message - From: Raúl Carazo To: FOP Sent: Wednesday, December 12, 2001 12:04 PM Subject: A simple question: Hot to close acrobat?? It's not for this place, but... When I open a pdf-report on a IE I see it. OK. But when I close the IE, there is an acrobat.exe process still open... Any idea? thx
Re: need help
- Original Message - From: Keiron Liddle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 3:54 PM Subject: Re: need help While that is true there are certain things you need to realise. - there are serious layout issues that need to be addressed - performance and memory is very much tied up to how the whole system works, this makes it difficult to fix Are there any discussions on how to reorganize fop on a more scalable framework? Maybe going to SAX or other internal representations? Sorry for the questions, I'm not able to check the list arcives right now. - getting FOP to a stage where there is a clear development direction is difficult - none of this will happen by itself Right. It appears that more effort needs to be put towards communicating the issues involved and the way in which FOP can be improved. What are the plans for FOP. Are the releases giong to be so slowly incremental? I'm really in the need of enhancements on the performance side and I don't know where to start. I also needed something that could render fo dynamically but FOP is not made for this... How can I help regarding these issues? Nicola Ken Barozzi These are the days of miracle and wonder... ...so don't cry baby, don't cry [EMAIL PROTECTED] Paul Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
