Re: XSL-FO in C++
Avula, Raj wrote: > Hi, > I am looking for XSL Formatting Objects implementation in C++. > Are there any Open or Commercial implementations in C++? > Your help is greatly appreciated. This is a mailing list for people working on the source code of FOP, a Java implementation of XSL:FO. You may want to check www.xmlsoftware.com or www.w3.org. There you will find lists of free and commercial implementations of XSL:FO renderers. Hope this helps, Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Fax: +49-7031-463460 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO, embedded fonts
Aha! How about reading some good documentation at http://xml.apache.org/cocoon2/userdocs/serializers/pdf-serializer.html On Mon, 12 Nov 2001 13:27:09 +0100 Matthias Fischer wrote: > Thanks for the really quick answer. > I was inprecise in my formulation: I want to render PDF with embedded fonts > using Cocoon 2, not with the FOP engine as a standalone. Therefore, I think > I have to proceed in some different way. > > I'm sure there is an answer even to that... > > Best regards, > > Matthias > > > Dott. Matthias Fischer > abc.Mediaservice GmbH > > Nebelhornstraße 8 > 86807 Buchloe > Tel. (08241) 9686-38 > Fax (08241) 9686-26 > http://www.abc-media.de > e-mail: [EMAIL PROTECTED] > > ein Unternehmen der abc.Mediengruppe > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +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: XSl-FO question
You wrote: > I don't know, Max, I interpret "role" more narrowly than that. The spec > indicates that "role" is meant to assist alternate renderers. I agree, although I think that it is the simplest solution to this problem. Of course the best way would be, as suggested, to have metadata in the file, using a different namespace (possibly RDF). If you're looking for typed values (like date in the original question) maybe you want schema support in XSLT. Support for schema simple types is on the requirement list for XSLT 2.0. > Here we are talking about identifying XML elements so that an XSLT > transformation can do some work on them; so this all should happen prior to > formatting and ought not be handled by using XSL-FO. IMO. The role attribute is in the FO file prior to formatting, so you can write an XSLT transformation that will process the FO file(s). Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSl-FO question
I don't know, Max, I interpret "role" more narrowly than that. The spec indicates that "role" is meant to assist alternate renderers. Here we are talking about identifying XML elements so that an XSLT transformation can do some work on them; so this all should happen prior to formatting and ought not be handled by using XSL-FO. IMO. In effect it is immaterial to the question as to whether it is an fo:block that contains a date field or it is an igglfix:blah. Regards, Arved Sandstrom P.S. Please hold your questions concerning the "igglfix" namespace and the powerful IGGLFIX 1.0 vocabulary. :-) At 10:44 AM 10/24/01 +0200, Max Froumentin wrote: > >The "role" attribute is supposed to be used to add semantics to >formatting objects. Either it can contain a simple string (prboably >"date" in your case), or a QName from your own namespace. > >[1] http://www.w3.org/TR/xsl/slice7.html#role > >Max. > > >You wrote: > >> During the concatenation process, I need to find all the dates throughout >> the different reports and update them to the current date. Is there an easy >> way to mark a as containing a date string? >> >> I tried using the id="date" attribute, but you can't use that multiple times >> per document. But I need something similiar to distinguish parts of the >> document that are related. Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSl-FO question
Arved, Thanks for the info. I'll use it to fix my problem. Thanks, Scott - Original Message - From: "Arved Sandstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 23, 2001 5:32 PM Subject: RE: XSl-FO question > FOP is not permitted to consider it an error, and in fact really should not > even warn about it. See Section 2.2 in the specification: an element from > the XSL namespace (e.g. fo:block) may have an attribute from a non-XSL > namespace, provided that the namespace prefix maps to a non-null URI. The > processor may act on such an attribute provided that it doesn't affect > behaviour otherwise mandated by the spec, and a processor must ignore such > an attribute if it doesn't know what to do with it. > > Regards, > Arved Sandstrom > > At 12:34 PM 10/23/01 -0400, you wrote: > > That's a good idea, my only concern is that at some point in the future > >FOP might consider it an error and not a warning. Should I be concerned > >about this? Scott-Original Message- > >From: Giannetti, Fabio[mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, October 23,2001 11:54 AM > >To: '[EMAIL PROTECTED]' > >Subject: RE:XSl-FO question > > > > HiScott, you can generate your own namespace with a field that > > tells you if that block is containing a data, then when FOP will process > >thedocument it will ignore this property .. giving you some Warnings, > >but thefile will be rendered fine. Soyou can define a new > >namespace like: xmlns:foo=http://foo"; then you can definethis > >attributes in your blocks that contains the data <> andmodify only > >them. Hopethis helps, Fabio-Original Message- > >From: Scott Moore [mailto:[EMAIL PROTECTED]] > >Sent: 23 October 2001 16:12 > >To: Fop-Dev (E-mail) > >Subject: XSl-FO question > > > > > I need to save the XSL-FO files for later "concatenation" > >with other generated reports.<> as containing a date > >string? distinguish parts of the document that are > >related. Thanks for any help! Scott > > > > > Fairly Senior Software Type > e-plicity (http://www.e-plicity.com) > Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSl-FO question
The "role" attribute is supposed to be used to add semantics to formatting objects. Either it can contain a simple string (prboably "date" in your case), or a QName from your own namespace. [1] http://www.w3.org/TR/xsl/slice7.html#role Max. You wrote: > During the concatenation process, I need to find all the dates throughout > the different reports and update them to the current date. Is there an easy > way to mark a as containing a date string? > > I tried using the id="date" attribute, but you can't use that multiple times > per document. But I need something similiar to distinguish parts of the > document that are related. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSl-FO question
FOP is not permitted to consider it an error, and in fact really should not even warn about it. See Section 2.2 in the specification: an element from the XSL namespace (e.g. fo:block) may have an attribute from a non-XSL namespace, provided that the namespace prefix maps to a non-null URI. The processor may act on such an attribute provided that it doesn't affect behaviour otherwise mandated by the spec, and a processor must ignore such an attribute if it doesn't know what to do with it. Regards, Arved Sandstrom At 12:34 PM 10/23/01 -0400, you wrote: > That's a good idea, my only concern is that at some point in the future >FOP might consider it an error and not a warning. Should I be concerned >about this? Scott-Original Message- >From: Giannetti, Fabio[mailto:[EMAIL PROTECTED]] >Sent: Tuesday, October 23,2001 11:54 AM >To: '[EMAIL PROTECTED]' >Subject: RE:XSl-FO question > > HiScott, you can generate your own namespace with a field that > tells you if that block is containing a data, then when FOP will process >thedocument it will ignore this property .. giving you some Warnings, >but thefile will be rendered fine. Soyou can define a new >namespace like: xmlns:foo=http://foo"; then you can definethis >attributes in your blocks that contains the data <> andmodify only >them. Hopethis helps, Fabio-Original Message- >From: Scott Moore [mailto:[EMAIL PROTECTED]] >Sent: 23 October 2001 16:12 >To: Fop-Dev (E-mail) >Subject: XSl-FO question > > > I need to save the XSL-FO files for later "concatenation" >with other generated reports.<> as containing a date >string? distinguish parts of the document that are >related. Thanks for any help! Scott > > Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSl-FO question
That would work per document, but part of the problem is that I use a reuseable XSLT template to write the common footer block/page. Without using recursion, I can't update the value of a variable in XSLT to keep track of the number of dates currently written to the FO. For the reports I create, recursion would be impossible or nearly impossible to write and certainly more complicated than it's worth. Scott -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 11:35 AM To: [EMAIL PROTECTED] Subject: Re: XSl-FO question On Tuesday 23 October 2001 17:12, Scott Moore wrote: > I tried using the id="date" attribute, but you can't use that multiple > times per document. But I need something similiar to distinguish parts of > the document that are related. You could use id="date-01", "date-02" etc. The value has to be unique in the document, so maybe the common "date-" prefix would help -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSl-FO question
That's a good idea, my only concern is that at some point in the future FOP might consider it an error and not a warning. Should I be concerned about this? Scott -Original Message-From: Giannetti, Fabio [mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 23, 2001 11:54 AMTo: '[EMAIL PROTECTED]'Subject: RE: XSl-FO question Hi Scott, you can generate your own namespace with a field that tells you if that block is containing a data, then when FOP will process the document it will ignore this property .. giving you some Warnings, but the file will be rendered fine. So you can define a new namespace like: xmlns:foo=http://foo" then you can define this attributes in your blocks that contains the data and modify only them. Hope this helps, Fabio -Original Message-From: Scott Moore [mailto:[EMAIL PROTECTED]]Sent: 23 October 2001 16:12To: Fop-Dev (E-mail)Subject: XSl-FO question This question isn't really about FOP, but FO. I'm writing a reporting system that will transform XML using XSLT into XSL-FO, then use FOP->PDF. I need to save the XSL-FO files for later "concatenation" with other generated reports. During the concatenation process, I need to find all the dates throughout the different reports and update them to the current date. Is there an easy way to mark a as containing a date string? I tried using the id="date" attribute, but you can't use that multiple times per document. But I need something similiar to distinguish parts of the document that are related. Thanks for any help! Scott
RE: XSl-FO question
Hi Scott, you can generate your own namespace with a field that tells you if that block is containing a data, then when FOP will process the document it will ignore this property .. giving you some Warnings, but the file will be rendered fine. So you can define a new namespace like: xmlns:foo=http://foo" then you can define this attributes in your blocks that contains the data and modify only them. Hope this helps, Fabio -Original Message-From: Scott Moore [mailto:[EMAIL PROTECTED]]Sent: 23 October 2001 16:12To: Fop-Dev (E-mail)Subject: XSl-FO question This question isn't really about FOP, but FO. I'm writing a reporting system that will transform XML using XSLT into XSL-FO, then use FOP->PDF. I need to save the XSL-FO files for later "concatenation" with other generated reports. During the concatenation process, I need to find all the dates throughout the different reports and update them to the current date. Is there an easy way to mark a as containing a date string? I tried using the id="date" attribute, but you can't use that multiple times per document. But I need something similiar to distinguish parts of the document that are related. Thanks for any help! Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSl-FO question
On Tuesday 23 October 2001 17:12, Scott Moore wrote: > I tried using the id="date" attribute, but you can't use that multiple > times per document. But I need something similiar to distinguish parts of > the document that are related. You could use id="date-01", "date-02" etc. The value has to be unique in the document, so maybe the common "date-" prefix would help -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL FO
Marianne: It would appear from you email that you are subscribed. Welcome. Regards, Jeff Langdon -Original Message- From: Marianne Engesvik [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 10, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: XSL FO Subscribe I would like to join a group working with/learning XSL FO Adaptive Media ASA Marianne Engesvik XML/XSLT trainee/programmer Mobile: 928 19 572 Private: 22 17 38 66 Work: 22 82 32 25 Mailto: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
I developed a servlet app using font earlier this year for my company. The fo documents are fairly simple, and I did have some problems, but overall it seems stable and is working well. Hats off to all those who put so much time into Fop! JT -Original Message- From: Christopher Farley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 07, 2001 7:26 AM To: [EMAIL PROTECTED] Subject: Re: XSL-FO Engine comparisons I've been using FOP in production for many months. The catch is that I don't use it 'live'; I use it to build static PDF documents from XML documentation. I have not personally found FOP to be very crashy with my input docs, but I would still probably be nervous about using it live in a servlet application... -- Christopher Farley www.northernbrewer.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
I've been using FOP in production for many months. The catch is that I don't use it 'live'; I use it to build static PDF documents from XML documentation. I have not personally found FOP to be very crashy with my input docs, but I would still probably be nervous about using it live in a servlet application... -- Christopher Farley www.northernbrewer.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
At 10:28 PM +0100 7/31/01, Sebastian Rahtz wrote: >Elliotte Rusty Harold writes: > > The downside to this otherwise excellent engine is that it's Windows > > only and based on Windows graphics primitives rather than PostScript or > > PDF. It displays on the screen very nicely, and prints nicely too. > > However, it does not produce a PDF document that I can send to my editor > > or a typesetter. >Cant you print PS to file and Distill it? > I suppose I could, but only if somebody knows of an open source tool for distilling files. After the Skylarov fiasco, I'll be damned if I'm going to give Adobe one more penny. Hmm, after a little hunting around with Google it looks like GhostScript might actually do that. I'll have to give it a try. -- +---++---+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +---++---+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +--+-+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +--+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
> Hmm, after a little hunting around with Google it looks like > GhostScript might actually do that. I'll have to give it a try. Yes, I do it this way, I print into virtual postscript printer and convert resulting .ps to .pdf via ghostview (File/Convert) Martin -- Martin Krumpolec <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
I have used GhostScript for awhile. And it works great for that purpose. Steve Rybin. -Original Message- From: Elliotte Rusty Harold [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 7:19 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: XSL-FO Engine comparisons At 10:28 PM +0100 7/31/01, Sebastian Rahtz wrote: >Elliotte Rusty Harold writes: > > The downside to this otherwise excellent engine is that it's Windows > > only and based on Windows graphics primitives rather than PostScript or > > PDF. It displays on the screen very nicely, and prints nicely too. > > However, it does not produce a PDF document that I can send to my editor > > or a typesetter. >Cant you print PS to file and Distill it? > I suppose I could, but only if somebody knows of an open source tool for distilling files. After the Skylarov fiasco, I'll be damned if I'm going to give Adobe one more penny. Hmm, after a little hunting around with Google it looks like GhostScript might actually do that. I'll have to give it a try. -- +---++---+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +---++---+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +--+-+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +--+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
2 more cents... I am using FOP in production. We have a major problem with performance, but have a working app with bad performance beats no app. Generating 200 page reports uses GBs of memory and 3 to 10 minutes of a single CPU on a quad 500 PIII. Our document is a single table. The header has SVG column headings; the column headings are rotated 90 degrees. Profiling the VM indicates significant time spent in the graphics toolkit. Short reports, less then 10 pages work great and the users are very happy with them. I haven't tried to fix it recently, but we did have a problem with rows of the table breaking across pages. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
At 7:19 PM +0200 7/31/01, Petr Andrs wrote: >I think there is other reason for formatters beeing not production redy >as well. This reason is that XSL FO is only in CR state of its first >version. I think 1.1 or 2.0 XSL FO Recomendation will be far better. > I don't think that's it. I haven't found any cases where XSL FO was insufficiently expressive for my needs (essentially laying out a computer book). There've been a couple of cases where Docbook was insufficiently expressive, but there are workarounds for that. The problems I encountered were all in implementation, not in the language. A new version of XSLFO wouldn't really help me any. -- +---++---+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +---++---+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +--+-+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +--+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
Title: RE: XSL-FO Engine comparisons Hi, Though I'd add in my 2c to the debate ;) I've just started evaluating FOP for production use in our company. We have some code documentation in XML format and can use XSLT to create FO, then PDFs and/or HTML - very useful. I had downloaded FOP 0.19, and was becoming quite frustrated with some issues. To be fair: all the basic stuff worked with no problems. But I was trying to recreate our technical documentation cover page and headers/footers, with little success. For I start I needed a page border, which I have still not discovered how to do; then I needed tables with cells spanning rows, which I found to be broken. The list of other little niggles goes on. So I decided to get the latest CVS version, and try with that. I'm *extremely* impressed :) I haven't tried the page border again, but most of the issues that I was fighting with seem to have been resolved. FOP seems quite capable of reliably producing attractive layout, which is pretty much as much as you can demand from a program of its nature. I think a disclaimer or warning is very prudent, albeit becoming less justified. Regards, Twylite -Original Message- I'm personally very pleased that FOP gets used. I'd be less interested in working on the thing if it wasn't. Unfortunately we have to issue some blunt disclaimers occasionally, along the lines of DO NOT USE FOP FOR PRODUCTION; if you know what you're doing you can interpret that how you want. :-)
Re: XSL-FO Engine comparisons
On Wednesday 01 August 2001 09:19, Alistair Hopkins wrote: > I'm also using it in production to generate simple but nice printable > invoices from a website. As a precaution, only company staff can access > the invoice download at the moment, but I'm going to throw it open to the > punters soon as there have been 0 problems over the last 6 months. > > -Original Message- > From: Alex McLintock [mailto:[EMAIL PROTECTED]] > --- Darren Munt <[EMAIL PROTECTED]> wrote: > > > > But you're right - nobody should be using the processor in production. > > Not yet. When we think it's ready we'll say so. > > I've been using FOP in production for over six months, nearer twelve. > > This is only possibly however because we have a small set of required > pages. We were able to test the fo templates prior to going live and the > features we need > work fine. > > So using FOP in production is no different from any other open source > project: > > Test it to see whether it does what you want. Agreed, to all. See my earlier reply to Darren. You guys are doing things right...for a variety of reasons (cost of ownership, ease of use, etc) you've all made an informed decision to use FOP. I think you all know that it doesn't do nearly everything and it doesn't do everything correctly, but there is a subset of stuff that FOP already handles OK. I'm personally very pleased that FOP gets used. I'd be less interested in working on the thing if it wasn't. Unfortunately we have to issue some blunt disclaimers occasionally, along the lines of DO NOT USE FOP FOR PRODUCTION; if you know what you're doing you can interpret that how you want. :-) Unfortunately what happens is that despite all the disclaimers we get compared to production-ready stuff. As a result, despite every statement that FOP is under development, people get the impression that FOP is ready for use. I think we are exactly where we should expect to be given resources involved with this project. By the time FOP is ready I estimate that 2 calendar years will have elapsed. On average I'll bet that we haven't even come close to the equivalent of one (1) FT resource, current circumstances excepted. Writing an XSL formatter is a big deal, and if I was estimating such a project from scratch I'd give it 2 person-years of _effort_ easy (maybe more). So it's no surprise that we are where we are. Regards, Arved Sandstrom -- Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Halifax, Nova Scotia Wireless * B2B * J2EE * XML - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
On Wednesday 01 August 2001 01:08, Darren Munt wrote: > > But you're right - nobody should be using the processor in production. > > Not yet. When we think it's ready we'll say so. > > I know we do so at our risk, but we have been using v0.18 FOP in a > production situation (albeit a low-load, non-critical one) for a week now. > Apart from a minor performance problem (discussed previously), and a couple > of quirks that we had to work around in the xml:fo, it suits our needs very > nicely in that: > > 1. The output renders nicely > 2. The file size is smaller than we achieved using a commercial product > (not one mentioned anywhere here) > 3. The users are very happy with the output > 4. It didn't cost us the equivalent of 2 months salary to buy a license > > I have FOP running in a Windows 2000, IIS, Visual Basic environment using > MSXML to do the XSLT processing. I'm certainly looking forward to future > versions, but we are extremely pleased with the results to date. To be honest I (and I would assume the other developers) are pleased that there are early adopters. We are not so much trying to discourage production use as we are trying to discourage _uninformed_ production use. In order to do that, though, what is necessary are frequent and blunt warnings. :-) The points you mention are pretty persuasive, too. As you say, if you know what FOP doesn't do, or doesn't do quite right, then there are workarounds. Regards, Arved Sandstrom -- Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Halifax, Nova Scotia Wireless * B2B * J2EE * XML - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
I'm also using it in production to generate simple but nice printable invoices from a website. As a precaution, only company staff can access the invoice download at the moment, but I'm going to throw it open to the punters soon as there have been 0 problems over the last 6 months. -Original Message- From: Alex McLintock [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 01, 2001 10:11 AM To: [EMAIL PROTECTED] Subject: RE: XSL-FO Engine comparisons --- Darren Munt <[EMAIL PROTECTED]> wrote: > > But you're right - nobody should be using the processor in production. Not > yet. When we think it's ready we'll say so. I've been using FOP in production for over six months, nearer twelve. This is only possibly however because we have a small set of required pages. We were able to test the fo templates prior to going live and the features we need work fine. So using FOP in production is no different from any other open source project: Test it to see whether it does what you want. Alex = Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ DR WHO COMPETITION: http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104 Get Your XML T-Shirt at http://www.inversity.co.uk/ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
--- Darren Munt <[EMAIL PROTECTED]> wrote: > > But you're right - nobody should be using the processor in production. Not > yet. When we think it's ready we'll say so. I've been using FOP in production for over six months, nearer twelve. This is only possibly however because we have a small set of required pages. We were able to test the fo templates prior to going live and the features we need work fine. So using FOP in production is no different from any other open source project: Test it to see whether it does what you want. Alex = Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ DR WHO COMPETITION: http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104 Get Your XML T-Shirt at http://www.inversity.co.uk/ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
Peter B. West writes: > > Sebastian Rahtz wrote: > > Sebastina > Your better half? all my halves are equally good sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
Sebastian Rahtz wrote: > Elliotte Rusty Harold writes: . > Sebastina Your better half? Peter -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XSL-FO Engine comparisons
> But you're right - nobody should be using the processor in production. Not > yet. When we think it's ready we'll say so. I know we do so at our risk, but we have been using v0.18 FOP in a production situation (albeit a low-load, non-critical one) for a week now. Apart from a minor performance problem (discussed previously), and a couple of quirks that we had to work around in the xml:fo, it suits our needs very nicely in that: 1. The output renders nicely 2. The file size is smaller than we achieved using a commercial product (not one mentioned anywhere here) 3. The users are very happy with the output 4. It didn't cost us the equivalent of 2 months salary to buy a license I have FOP running in a Windows 2000, IIS, Visual Basic environment using MSXML to do the XSLT processing. I'm certainly looking forward to future versions, but we are extremely pleased with the results to date. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
Elliotte Rusty Harold writes: > that end, I've been putting the various XSL-FO engines on the market > through their paces. interesting, thanks for that > PassiveTeX ... > quirky instance where the first bullet point in a list was not indented > quite right, but this didn't seem to occur in other bulleted lists. its an interaction with running heads, I think > The downside to PassiveTeX is that it depends on a "decent modern TeX > setup"; and TeX is invariably a nightmare. heresy! TeX is a very very simple program to set up. far far easier than anything involving Python, Perl and Java (in descending order of horror). and it never segfaults > consider myself lucky to have been able to get PassiveTeX running; and > it still fails one time out of every two. This is probably due to TeX's > unusual multipass architecture. unusual? "simplistic", perhaps. > You sometimes have to run TeX a second > time to get the links and cross-references right. In my case, the first > pass succeeds but the second pass invariably fails. Thus I never get > proper cross-references to page numbers in the table of contents and > elsewhere. I'd much appreciate a test file showing the problem, please. I do not have this problem (having just finished a conference proceeedings using FO and PassiveTeX, I am prety confident) (antenna house) > The downside to this otherwise excellent engine is that it's Windows > only and based on Windows graphics primitives rather than PostScript or > PDF. It displays on the screen very nicely, and prints nicely too. > However, it does not produce a PDF document that I can send to my editor > or a typesetter. Cant you print PS to file and Distill it? > finished product. Ñone of them can replace TeX or QuarkXPress. You might > be able to publish a simple book with these, but you'd have to design > your book and style sheet so that you avoided the bugs and unimplemented > features of the processor. how true... Sebastina
Re: XSL-FO Engine comparisons
At 09:24 AM 7/31/01 -0400, Elliotte Rusty Harold wrote: [SNIP] >So far, I've experimented with four different XSL-FO processors: the >Apache XML Project's FOP, Sebastian Rahtz's PassiveTeX, the Antenna >House XSL Formatter 1.1E, and RenderX's XEP. Two are implemented in >Java, one in native Windows code, and one in TeX. FOP and PassiveTeX are >open source. Antenna House and XEP are payware. Here are my experiences >with each: > >FOP > >FOP was the first XSL-FO engine and is certainly the most popular. It's >open source and far easier to install than PassiveTeX, the other open >source alternative. However, of the ones I was able to actually test it >produced by far the worst output. It had the most annoying formatting >troubles. For example, it ate all the blank lines in my source code >examples and put extra indentation at the front of the first line of >each example. I've noticed that probably more than half of the bug >reports on the Docbook-APPS mailing list about the Docbook XSL-FO >stylesheets can actually be attributed to bugs in FOP. FOP is improving >rapidly -- one major bug I noted in footnote handling was fixed in the >last couple of weeks while I was performing my tests -- but it's clearly >not even an alpha quality release yet. A lot of work needs to be done >before FOP can be recommended for more than experimentation. [SNIP] No arguments from me, in the main. You've basically established that there is a reasonably strong correlation between effort expended and progress. :-) The 2 commercial efforts probably put in more person-hours per day than FOP gets in a week, and of course PassiveTeX gets even less attention than FOP. FOP developers and committers have never suggested that the processor is anything other than a work in progress. My best guess is that if we have a production release by the end of the year then we'll be doing well. Alpha is a long ways away. My experience with DocBook FO stylesheets and all of the formatters suggest that even though your statement about bugs on the Docbook-APPS mailing list is most likely true, that there are sizeable chunks of DocBook FO that do not layout properly in _any_ formatter. Statistically, if the huge majority of people that process DocBook FO are using FOP, then it stands to reason that they are turning up lots of bugs and that almost all are from FOP. Says very little about FOP relative to other processors. And how many _unique_ defects are being reported? But you're right - nobody should be using the processor in production. Not yet. When we think it's ready we'll say so. >Bottom line: none of the formatters are yet suitable for producing a >finished product. Ñone of them can replace TeX or QuarkXPress. You might >be able to publish a simple book with these, but you'd have to design >your book and style sheet so that you avoided the bugs and unimplemented >features of the processor. Antenna House probably produces the most >polished output, and I'd use it if all I wanted to do was print out a >document from my laser printer. However, since I need PDF files I can >send to my editors and download to a typesetter, my choice for the time >being is PassiveTeX. Antenna House is good, but as you say it's Windows only...serious drawback. RenderX XEP, IMHO, is the best all-round FO processor available right now. I certainly have had no problems in using it, either. Useful review, in any case. If you happen to post it elsewhere, do us a favour - specifically note that we (FOP) do not recommend FOP for general production, that it is under development, and that it's not even close to alpha. All points you made yourself. Thanks. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
Elliotte, > However, it simply did not work for me at all. However good the XEP > engine may be at converting XSL-FO documents to PDF, its horrible user > interface and incomprehensible installation procedure eliminated it from > my consideration. Installation package of XEP 2.5 evaluation version consists of two files: readme.txt and Setup.class. You run Setup.class and follow the prompts; I wonder if this is not intuitive. (A further step would be using InstallShield; but this is hard to achieve for a Java application :-)). Anyhow, in case of installation problems, you can direct your questions to RenderX support ([EMAIL PROTECTED]). I realize that our poor command-line utility is far from being a model of user-friendliness. There are reasons for this: XEP is sold exclusively for server applications, and we care more about efficiency than about ease of use. Still there are many downloads from our site, and we get enough feedback from people who manage to get our tool running. This makes me think it's not really impossible. If you ever decide to retry XEP, I would be glad to assist you. > Bottom line: none of the formatters are yet suitable for producing > a finished product. I dare not say that XEP is good enough to suit your needs :-). But (IMVHO) it's difficult to make statements about maturity level of an application if you have never run it. Best regards, Nikolai Grigoriev RenderX - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
Hi, I am now working on reporting tool which outputs reports into XSL FO, so I have some experinece with tools described here. Althoug we are using only quite simple formatting I would like to say something to this topic as well. On 31 Jul 2001, at 9:24 Elliotte Rusty Harold wrote about XSL-FO Engine comparisons : > FOP > > FOP was the first XSL-FO engine and is certainly the most popular. It's > open source and far easier to install than PassiveTeX, the other open > source alternative. However, of the ones I was able to actually test it > produced by far the worst output. It had the most annoying formatting > troubles. For example, it ate all the blank lines in my source code I have to agree that FOP is worst I have used, but is improving rapidly. In version 0.17, which was recent in the time I started to follow developement it was practicaly unusable due to lack of international support. Now I am quite satisfied, in basics FOP fullfills our needs although some workarounds are still needed. > examples and put extra indentation at the front of the first line of > each example. I've noticed that probably more than half of the bug > reports on the Docbook-APPS mailing list about the Docbook XSL-FO > stylesheets can actually be attributed to bugs in FOP. FOP is improving > rapidly -- one major bug I noted in footnote handling was fixed in the > last couple of weeks while I was performing my tests -- but it's clearly > not even an alpha quality release yet. A lot of work needs to be done > before FOP can be recommended for more than experimentation. > > XEP > > I was unable to get XEP to run. It was totally non-functional, and did > not produce any output. I know some other people have gotten it to run > -- the PDF version of the XSL specification was produced with XEP. > However, it simply did not work for me at all. However good the XEP > engine may be at converting XSL-FO documents to PDF, its horrible user > interface and incomprehensible installation procedure eliminated it from > my consideration. I am using evaluation version of XEP with success. It is far better than FOP. It has strange behavior on repeating table headers and it doesn't support collapsing border model on tables. Instalation i quite easy, version 2.50 has even installer which configures BAT file for you. There is one issue - JAXP MUST NOT be installed as JAVA extension - In that case XEP fails with Class not found exception. > PassiveTeX As I had some experience with TeX that suggested that TeX is I nightmare I even didn't try It. :-)) > Antenna House XSL Formatter > > The Antenna House XSL Formatter produced very attractive output, on a > par with that generated by PassiveTeX and much better than FOP's. I > noticed no major flaws or cosmetic bugs. Antenna House also claims > they're the only formatter able to handle mixed writing-modes such as > "tb-rl" for Chinese/Japanese/Korean, though I didn't test that. I have to agree that Antenna is best I have seen > Most importantly, Antenna House had by far the easiest installation and > the nicest user interface of all the formatters tested. More work is > still needed, but at least I could conceive of giving this formatter to > a non-programmer end-user. The others all have effectively non-existent > user interfaces, and horrible installation procedures. The Antenna house I think that lack of user interface is not bug but feature, FOP and XEP are renderers intended for usage in application servers and servlets. Software that will provide environment for creating and rendering FO documnets via services like FOP and XEP must be created. Problems with instalation and similar things are common feature of really portable and OS independent Java software. > formatter was the only one of the four that took me less than an hour > from download to first use. > > The downside to this otherwise excellent engine is that it's Windows > only and based on Windows graphics primitives rather than PostScript or > PDF. It displays on the screen very nicely, and prints nicely too. > However, it does not produce a PDF document that I can send to my editor > or a typesetter. > > Bottom line: none of the formatters are yet suitable for producing a > finished product. Ňone of them can replace TeX or QuarkXPress. You might I think there is other reason for formatters beeing not production redy as well. This reason is that XSL FO is only in CR state of its first version. I think 1.1 or 2.0 XSL FO Recomendation will be far better. > be able to publish a simple book with these, but you'd have to design > your book and style sheet so that you avoided the bugs and unimplemented > features of the processor. Antenna House probably produces the most > polished output, and I'd use it if all I wanted to do was print out a > document from my laser printer. However, since I need PDF files I can > send to my editors and download to a typesetter, my choice for the time > being is PassiveTeX. -- > pa
Re: XSL-FO Engine comparisons
>I've been spending a lot of time lately with Docbook and XSL-FO as part >of the ongoing development of my next book, Processing XML with Java. To >that end, I've been putting the various XSL-FO engines on the market >through their paces. I'm trying to find one that will actually let me >produce the complete, finished book from my Docbook source code and Norm >Walsh's XSLT-to-XSL-FO stylesheet. I thought I'd share my experiences >here. It's not FO-based, but I've been experimenting with ReportMill, which was originally for use with WebObjects but is not (more or less) accessible via Java. It looks pretty promising but I don't think it's geared toward long structured documents. -- Steve Lane Vice President Chris Moyer Consulting, Inc. 833 West Chicago Ave Suite 203 (312) 433-2421 http://www.fmpro.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
