Re: FOP source code ambigous
in other words I didn't find a file containing : package org.apache.fop.fo.properties I don't know the exact details, but the source code for org.apache.fop.fo.properties is generated from XML and (I think) XSL files during the build. You can find the exact mechanism by studying the build.xml file used by ant during the build process. -- -- 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: Conversion RTF to FO
I 'd like to convert a .RTF file to .FO file. Is there a program doing it ? There are a few programs called rtf2xml on the web (see http://www.google.com/search?q=rtf2xml), but I didn't test any of them yet. It might be your first step: convert RTF to XML, then use XSL to generate XSL:FO. You could also use upCast (commercial product, http://www.infinity-loop.de/) for the RTF-to-XML conversion step, it does a job of making sense out of RTF. -- -- 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]
RTF backend status (was: where is fop.jar?)
What happened to the rtf backend which Mr Bertarnd submitted? Actually I didn't submit the RTF backend yet, only made it available as a hacked version of fop on our own CVS server (:pserver:[EMAIL PROTECTED]:/usr/local/cvsroot, password is anoncvs, module name is xml-fop, cvsweb at http://codeconsult.dsvr.co.uk/cgi-bin/cvsweb.cgi). It's not there yet RTF-wise, and I realized this week that the code has major flaws which would need too much messy code to be added for it to be usable. So I don't feel good about submitting this version which I hope to replace with very different (better :-) code in a short while. I'm currently working on redesign it, but as for others it's not a full-time job, so I can't really give a release date. My plan now is to redesign, get the basics working with the new structure and then submit it for inclusion in fop. -- -- 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]
(jfor) how to define XSL-FO extensions a la fox:outline
In the jfor project (XSL-FO to RTF converter) we'd like to define extensions to XSL-FO for RTF-specific constructs (RTF styles in this case). Could someone from the FOP team check that the proposal below is ok with FOP? Ideally, our jfor: extensions should be completely ignored by FOP, while our output stays as much FOP-like as possible when jfor: extensions are not used. jfor stylesheets extension proposal (example/excerpts): fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:jfor=http://www.jfor.org/xmlns/2001/stylesheet; !-- this generates an RTF stylesheet -- jfor:stylesheet jfor:style name=sourceCode font-size=10pt font-family=Courier/ !-- more RTF styles here -- /jfor:stylesheet fo:flow fo:block jfor-class=sourceCode in RTF, this block will have the sourceCode style. /fo:block /fo:flow Shouldn't the jfor-class attribute also be made part of the jfor namespace? like fo:block jfor:jfor-class=sourceCode Thanks for having a look at this! -- -- 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: Performance and java 1.1
So the question is: can we drop java 1.1 support and use better data structures? +1 for this: -even switching to a 1.2 JVM (+hotspot) without code changes often brings big performance improvements compared to 1.1, so IMHO forcing users to 1.2 is a good thing for FOP in general -the perspective of 60% performance improvements is certainly enticing... -- 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: Will there be a RTF renderer?
On Monday 24 September 2001 12:18, Beer, Christian wrote: Will there be a RTF renderer in the near future? We (my company, I'm not speaking for the FOP team) have been working on an RTF renderer earlier this year, and later scrapped it for a standalone implementation known as jfor that is released under the MPL license. So currently AFAIK there is no RTF renderer for FOP, but jfor will allow you to convert XSL-FO documents to RTF. You can find more info at www.jfor.org. -- -- 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: [vote] Merging JFor with FOP (jfor speed/presentation)
On Thursday 18 October 2001 23:06, Art Welch wrote: snip My concerns are that if jfor excels at speed at the expense of presentation. 1. Are jfor users going to be happy with jfor integrated with FOP which seems to favor presentation over speed? 2. Would FOP users be happy with the RTF generated if it loses presentation information? snip Thanks for putting this up - the thing with RTF is that there is a fairly strong similarity between XSL-FO and RTF constructs, that does not need any layout work in the FO-RTF transformation (we had a good discussion about this earlier this year on this list). The layout is done later by the wordprocessor when the RTF file is opened. Hence jfor being called an XSL-FO to RTF *converter* and not *formatter*. jfor does a fairly simple mapping of XSL-FO elements to RTF constructs, hence the speed and small code size. So, technically I think the initial merging might see jfor sharing only some infrastructure with FOP (command-line and Cocoon invocation mechanisms, configuration, logging, parser, etc.), with a -rtf option that would more or less switch between jfor and FOP for processing of the XSL-FO elements. This is of course going to be discussed with the FOP community, I'm only thinking outloud here. As Stefano rightly mentioned in the private discussion that lead to this merging proposal, such a side-by-side merging would already be a big advantage for *users* of FOP who would get RTF output for free, without needing separate downloads and configuration. Not to mention increased visibility for both projects. Later on, we will have to refactor the jfor code to use more of the the FOP codebase where it makes sense. This might lead to new interfaces between FOP and its renderers (post-processors?), where a renderer could be plugged in at an earlier stage of the FOP formatting chain, not necessarily after the layout stage. So, IMHO jfor would not be a FOP renderer per se initially, but might become one later in the integration process. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Merging jfor into FOP - what's the plan?
On Friday 23 November 2001 20:13, Art Welch wrote: . . . Would it be possible to have one RTFRenderer and then have an option use either the full FOP layout or bypass the FOP layout for quick RTF?. . . I don't know about using the full FOP layout - last time I tried (beginning of this year) it looked hard - my understanding is that the Renderers receive graphical area events from FOP, whereas jfor works more at the document elements level. But I don't know much about what's currently going on about the layout mechanism - maybe it would be easier now. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Merging jfor into FOP - what's the plan?
Hi Keiron, If there is not going to be a FOP release in the next few weeks, I agree that a minimal integration does not make sense. Currently the jfor conversion is driven directly from SAX events, so the first thing that comes to mind is driving it from the FO tree. You're right that, contrary to print renderers, the RTF one will need to know about the structure of the original document. Does the FO tree handle things like attribute inheritance (i.e. a block inherits the font definition from an ancestor block), or is this handled while doing the layout? Such inheritance is currently missing in jfor. To summarize: -jfor needs to know about the original document structure: speaks for option (A), plugging jfor right after the FO tree stage if I understand well. -BUT jfor could probably benefit from some operations done at the layout stage (attributes inheritance, others?) : speaks for option (B), extending the renderer interface to let the renderers know (cleanly) about the original document structure. If you can give me some pointers about where to look at in the code to evaluate (A) and (B), I'll have a look. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Merging jfor into FOP - what's the plan?
Hi Arved, What are your recommendations for someone to come up to speed with RTF? I'd recommend to stay away from it unless you really have to ;-) Seriously, to someone accustomed to clear and well-defined specs, RTF is somewhat messy, what it is really is a documented internal format, not a spec that has been agreed upon by a carefully-selected comittee. The RTF spec that we use in jfor is (mostly) V1.5 from Microsoft, who since moved on to 1.6 (at least), but apparently 1.5 is the most widely supported spec. A google search shows it at http://www.dubois.ws/software/RTF, it might be harder to find at Microsoft as it's not the latest. The rtflib package of jfor (available at www.jfor.org) encapsulates our knowledge of RTF and is fairly simple and understandable, but it is still too much element-oriented. One important thing to realize (happened too late here) is that RTF is more flow-based or stack-based than element-based: not everything that is opened has to be closed, it's more like a flow with embedded attribute changes. As I understand it, RTF is presented to a user-agent which does a fair amount of layout; higher-level structures are still present in the RTF. Right - but there are both structure and presentations codes, so an RTF document could be both. Jfor has a strong bend towards structure, as usually the user goal is to get an editable RTF document, where as much of the original document structure must be preserved for convenience. Precise appearance usually comes second, as applying a new wordprocessor style sheet can change a lot of it. RTF is both a presentation and a structure format, along with a moving target due to the spec being expanded and rewritten with nearly every new version of winword. There are a many grey areas in the spec, meaning the only possible test is opening the generated RTF in the desired wordprocessors (and often watching it crash...). snip This is not so different from MIF Agreed. We are working with MIF for another project, and didn't choose FOP for that because of lack of precise control over the MIF output. I tend to see these formats as: -PDF for finished high-quality output (presentation language), layout 100% done by FOP -MIF for semi-finished high-quality output (typography language), layout done by Framemaker according to MIF instructions. -RTF for editable structure + presentation output (wordprocessing language), layout done by wordprocessor. So I fully agree that MIF and RTF renderers share a lot in common - they must be able to get as much information as possible about the original document structure, and in my view do not need any layout computations. In a sense with RTF and MIF (and HTML for anyone who really desperately wants to see FO-HTML) we are talking about translators as opposed to formatters and renderers... yes - that's why I called jfor a converter instead of formatter Without knowing too much about FOP internals, I think a processing chain along these lines might help: parsing if needed - SAX events - FO attributes processing (validation, inheritance) - StructureRenderer StructureRenderer is EITHER Layout + PrintRenderer OR StructureProcessor (RTF, MIF, etc.) What we need to find out is how much the existing FOP and these structure renderers have in common. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Servlet called twice
On Tuesday 09 October 2001 10:52, Kuehnberger wrote: my servlet is still called twice when the output is pdf, Are you using Internet Explorer as a client? If yes, this is a known problem: IE often does additional requests for non-HTML files. AFAIK this is hard, if not impossible, to solve on the server side. -- -- 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: Fop speed improvements
On Thursday 11 October 2001 20:05, Scott Moore wrote: I generated a 100 page PDF in about 20 seconds Would you mind sharing the XSL-FO of this document? We are currently studying how far optimizing FO code (just on one example document that we know is less than optimal) makes a difference, and I'd be interested in comparing your FO constructs. -- -- 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: Making a native win32 binary out of FOP
On Wednesday 10 October 2001 10:19, Thomas Kæregaard wrote: I would like to distribute FOP with my application, but I don't want to force people to install 5,4 MB worth of JRE. Most likely you *will* have to distribute the JRE (unless you find a compatible java-to-exe compiler?). You might not need to *install* the JRE, though. Recent experiments here have shown that merely *copying* an installed JRE directory to another system works, as long as you're careful with PATH and the like to make sure that the desired version of the JRE is started. I don't know if this is official but it works fine. Starting java classes from an EXE is possible using JNI (the java native interface), this is done for example by the javaserv utility, see http://www.kcmultimedia.com/javaserv. -- -- 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: [ANN] XSLfast: Authoring tool for XSL-FO
On Friday 12 October 2001 23:14, Stephan Albers wrote: after a long development period, we have finaly released the very first version of XSLfast for public review and test. Interesting, thanks for the info! How is XSLfast licensed? Open Source? Commercial? -- -- 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: Merging jfor into FOP - what's the plan?
On Thursday 29 November 2001 12:44, Keiron Liddle wrote: So are things like static areas, markers, page numbers etc. possible with rtf or are these type of things simply not possible. Keiron, as far as I know, RTF does support the following (but jfor currently not for most of these things) - In parentheses, my understanding of these concepts, to make sure we're on the same wavelength: static areas - yes (headers and footers) markers - yes (references like see page N) page numbers - yes (dynamic auto-numbering) But things like page numbers must be left to RTF to compute, FOP will need to include an *RTF code* to let the RTF reader compute page numbers, not compute them by itself. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Maintanance release (was: FOP conformance)
On Monday 03 December 2001 12:19, Christian Geisert wrote: What about jfor ? I think it would be a good idea to add it with user-level integration as proposed by Betrand. Depends on schedule - I'm very busy for the next two weeks, it would be hard for me to find time to do the code moving and integration, - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: whats FOP
On Friday 07 December 2001 12:55, Suhail Rashid wrote: What does FOP stand for ; Formatting Objects Processor - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
On Wednesday 12 December 2001 12:24, Lukas Pietsch wrote: What's still slow is the preceding docbook-to-.fo conversion. One thing I've seen is document referring to a DTD using an http:// URL. This is ok, but usually the parser will go out to the Internet to fetch the DTD, which can slow down the process noticeably. I'd suggest checking your documents or remove any DOCTYPE declarations to see if it makes a difference. -- -- 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: FOP performance on Win98/JRE 1.3.1
On Wednesday 12 December 2001 14:42, Cyril Rognon wrote: before making any modification to your docbook stylesheet, I suggest you simply use some XML parser feature to deactivate the DTD validation and DTD loading. Yes, of course to actually solve the problem (assuming DTD fetching *is* the problem), I agree. But for a quick test, trying to find out if DTD fetching is the problem, I'd rather take out the DOCTYPE from a test document - quicker and I wouldn't have to mess with configuration settings. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Basic aspects (big fat list vs. live test documents)
On Thursday 13 December 2001 15:35, Matthias Fischer wrote: . . . My whish to Santa Clause this year: A big fat list containing all major graphic formats and the FO/FOP-related aspects that concern them. . . . I'm skeptical: to me big fat list means big maintenance work and usually out-of-sync list. I'd rather have many small, focused, self-documented, numbered XSL-FO example files that show what works and what doesn't in FOP (note that I haven't looked at our test files for a while - maybe it's there already?). Maybe a live FOP system where users can post a ZIP containing XSL:FO + graphics files and get back the PDF? (got to tell Santa Claus about this one ;-) Such examples could be donated by users after they find that a particular feature works or not, with a standard mail header ([TESTDOC] ?) that would help committers sort out these files. Any thoughts? -- -- 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: Basic aspects (big fat list vs. live test documents)
On Friday 14 December 2001 10:05, Matthias Fischer wrote: However, you won't escape big maintenance so easily: Right - maintaining such a test suite is not light work. The advantage over pure documentation, however, is that both users and developers directly benefit from having strong test documents. So I think it would be easier to get the FOP community to work on building such a test suite (or organize/document existing tests) than finding someone to write and maintain documentation. -- -- 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: Basic aspects (big fat list vs. live test documents)
On Monday 17 December 2001 09:07, Matthias Fischer wrote: What are _your_ plans with regard to the material offered by W3C/Carmelo? As mentioned by Keiron (see http://xml.apache.org/fop/testing.html), the current FOP tests are based on automatically comparing the ouput of two FOP revisions. This is needed to make sure new releases don't break existing features, but IMHO doesn't make it easy for end users to find out exactly how FOP interprets specific features. Again, I think what would help end-users a lot (and also have good tutorial value) would be small self-describing XSL-FO documents where one can check the results by reading the PDF, along with an official list of which samples work and which don't. Nice and well, but I don't think anyone on the FOP team currently has time to fully set this up (but I'd be happy to be proven wrong!). There are quite a lot of FOP samples already (http://xml.apache.org/fop/examples.html), some more useful than others, so maybe it's just a case of sorting through the samples, classifying them and making them easily accessible, ideally using a live Internet-accessible FOP setup. In the meantime, I'd encourage users that find a bug or problem to send to this list the smallest possible XSL-FO document that demonstrates the problem. We could start collecting these in the hope of setting up a user-friendly demo/test suite when someone finds time to do it. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Basic aspects (big fat list vs. live test documents)
On Tuesday 18 December 2001 09:59, Matthias Fischer wrote: Right now, I have a pice of code I would contribute. It would be useful, if there were an alternative e-mail address to that of the list, to collect the submitted code segments. ok, right now we don't have an alternative address available. I suggest that you post your code to the list, inline (not as an attachment) with [TESTDOC] in the subject line (I hope I'm not breaking an existing convention here). We can then find it easily in the mailing list archives. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Properties documentation
On Saturday 29 December 2001 02:57, Peter B. West wrote: . . .let me know if there is some easy way to get full conformance with the Apache XML norm, or if there are severe problems viewing these pages with modern browsers. Hi Peter, FYI, with Konqueror (modern yes, 100% finished maybe not), the PNG images (like in PropertyConsts.html) aren't displayed, but right-clicking them allow them to be opened in the image viewer. Maybe a mime-type problem? The pages look fine with IE5. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project (jfor integration)
(cc to [EMAIL PROTECTED] - fyi) On Friday 25 January 2002 00:12, [EMAIL PROTECTED] wrote: . . . I see some notes about the inclusion of jfor (RTF output) into the FOP project. I think that would be really cool, and speaks very well of the effort put in thus far. Anyone care to comment on when that may make it into a release? I'm progressing very slowly for the integration of jfor, been talking (mostly with Keiron) about design issues. Proper jfor integration requires new interfaces to FOP, which is being partially redesigned at the same time, so it is a bit hard if we want to get it right. On the other hands, resources are scarce - I'm currently busy with other projects, and no one is currently actively working on jfor (although I understand it is in active use out there). So I cannot really commit to a timeframe for the jfor integration - if someone needs it quickly and is able to commit resources, I'd be more than happy to help (coaching etc.). -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project (testing)
On Friday 25 January 2002 00:12, [EMAIL PROTECTED] wrote: . . . I am involved with the approval process for bringing new technology into our company. We have several development groups who have seen the FOP engine and would like to include it their applications. . . . One of our primary tenets is no beta software should be included in production applications. . . . Depending on the costs your company would incur if going for a commercial solution, wouldn't it be cheaper to contribute some resources to the FOP project for testing? There have been some testing efforts in the past year, but IMHO having someone come from the outside and design or complete conformance + stability tests would be a great contribution to the project. As Arved indicated, although FOP has known limitations it is fairly usable for a lot of applications today. Being able to measure this usability would be great! -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
refocusing fop-dev and fop-user?
I see a lot of posts going to fop-dev that really belong to the fop-user mailing list. Should we do something about it (I'd like to)? If yes how best to do it - polite please ask there messages, having the list moderated for a while, ? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: refocusing fop-dev and fop-user?
On Friday 25 January 2002 10:26, Jens von Pilgrim wrote: . . . On http://xml.apache.org/mail.html is only the fop-dev listed - is there also a user list? This is probably the cause - AFAIK fop-user is alive and kicking, just not listed in the proper places. Can anyone clarify the situation and/or make sure fop-user is listed in the right places? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: keep-with-next?
(by the way your message was crossposted to fop-user, please avoid this as it makes it very hard to follow discussions) On Wednesday 30 January 2002 20:21, David Wood wrote: I am a Java coder and know my way around the standard. I volunteer to try to fix this, if someone who is more familiar with FOP's internals can tell me where to look... I cannot help you much, but here's at least a reply to your offer ;-) AFAIK getting keep-with... stuff to work requires serious redesign, which is currently going on (Keiron and Karen?), but apparently fairly slowly. Keiron would probably be the one to answer you, but in his last message (Jan.14th I think) he indicated that he'd be away for some time. I have no idea when he will be back, maybe someone knows more? -- -- 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: Seeking Comments on Status of Project
On Tuesday 05 February 2002 23:25, Peter B. West wrote: . . . I think that most people need some encouragement to take the plunge in murky waters. I agree, make sense with the various offers for help that came up in the last few weeks. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project
On Thursday 07 February 2002 03:57, Arved Sandstrom wrote: . . . If you do some code and want to see it added to the main or maintenance branches, then the onus is on one or more committers to explain why it's a bad idea, but there must be a good reason. . . . To make sure there is no confusion about this, could someone clarify (once more I guess) what exactly the main and maintenance branches are, and how to get the source code for both of them? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On Thursday 07 February 2002 12:15, Keiron Liddle wrote: . . . Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. Right - let me try to reformulate what we need to be able to create an RTF document. If this is already covered by the current layout manager interface, then it's fine. We need: - start and end of document yes - start and end of page sequence yes (mapped to an RTF document section) - resolved properties yes - static areas yes, for RTF they should at best come right after the start of the page sequence - add info after end of block level object: block, table, list etc. yes, for RTF we need both start and end events for most such constructs: table cells, list items, etc. So I think what you suggest maps well with the requirements of an RTF render (or other structure-based renderers). Where should I look in the current code to start playing with this? layoutmgr package? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: StructureEvents concept
On Friday 08 February 2002 01:58, Peter B. West wrote: Bernard, (That's Bertrand by the way ;-) What sort of structure does rtf exhibit? Is it a page-based structure, or is it divided, like xslfo, into page definitions and flows? This is a critical difference as far as the design goes. From what you say below, it seems to rely on a flow-based model. In the sense of not being mapped to printed pages directly (unless hard page-breaks are used), RTF is flow-based, not page-based. An RTF document is broken out in sections which are very similar to page-sequences in concept. The pagination is done by the RTF reader (usually a word processor) when it renders the document to screen or print. Constructs like tables, lists etc. are flow-based but need to be closed, kind of like the nested elements of an XML document. I think RTF maps well to XSL-FO documents in terms of structure. What has been hard in our past efforts to write an RTF renderer was that FOP didn't provide end events (or we didn't find out how it did) for tables, lists and other elements, for which the RTF render needs to generate element-closing codes. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML Parsing [2] (RTF document header)
On Monday 11 February 2002 10:19, Keiron Liddle wrote: . . . At the end of a page sequence we know that all pages in the page sequence can be rendered without being effected by any further XML. Note that this won't be the case with RTF: AFAIK an RTF document has to contain a document header with font tables, tables of list formats etc. This header has to come at the beginning of the document but most of the information (notably information about list formats) it contains won't be available until much later in the document. This is a problem if we want to generate RTF on the fly, and we don't have a solution for this in jfor yet, we just keep the RTF document in memory until it is complete. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tool to create XSL:FO without stylesheet from Java?
On Friday 15 February 2002 15:47, Roland wrote: does anyone have a good tool to create an XSL:FO file without the use of a stylesheet? You might want to look at jdom (www.jdom.org), a very nice DOM manipulation library for java. Saxon (http://users.iclway.co.uk/mhkay/saxon) is also a good choice for this. And if you do a search on google with jdom saxon xml you'll find a few more such libraries. The reason I want to do this is because I think XSLT is very complicated. IMHO XSLT is worth learning - the combination of XSLT with java is killer for working with XML. -- -- 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: Integrating Tree into FO tree handling
On Sunday 17 February 2002 06:07, Peter B. West wrote: . . . FOTree maintains the property stacks with the initial value, current value and history of the properties being defined on elements of the FO Tree. It also implements Runnable, and its run() method is the source of the FoTreeBuilder thread. On construction, it is given a SyncedCircularBuffer by means of which it receives event notification from the parser. . . . Would this SyncedCircularBuffer help in propagating the events downstream from FoTreeBuilder to StructureRenderers? Or is is already implemented so in some experimental branch of the code? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: remove html-docs dir?
On Monday 18 February 2002 10:54, Keiron Liddle wrote: Can I remove everything under docs/html-docs. +1 because it will force the builds to have up to date information -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
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 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). 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. 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. How does this sound? -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote: . . . 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. . . . Right, but it's so easy that we might as well keep it for easier testing. . . . What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. . . . Yes, but IMHO resolving (in the sense of resolving FO object properties like I think is meant by FOP) is part of the core functionality. I'm talking about computing presentation attributes for child elements based on their parent's attributes. . . . This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) . . That's me by the way ;-) (but I haven't done much lately) -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:19, Keiron Liddle wrote: . . . Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. . . . Unavoidable for Layout rendering, isn't it? I thought structure-based rendering wouldn't need the area tree. . . . For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. . . . How hard would it be to render the FOTree in XSL-FO (based on SAX events) with all possible attributes resolved? Speaking specifically about the jfor RTF converter, this would allow it to be used as a FOP renderer without needing as much code changes as an API-based integration. Might be a little slower but much more flexible. This would allow the parser and property resolver (is that the right term?) components of FOP to be reused by jfor and future structure-based renderers. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . Hmmm... AFAIK FO is about layout, not semantical structure. Bold is just Bold, and not emphasis or strong. Maybe I don't get the point. Could you elaborate more please? . . . The term structure renderer (as you could find by searching the list archive probably ;-) is used here for yet-to-be renderers that don't do any layout by themselves. If you're generating RTF or MIF formats, for example, you usually don't need to know on which page a given FO element will go, you leave this to the word processor or desktop publishing program that will use the generated document. So these renderers will be plugged in right after the parsing and property resolution stages, before the layout stage. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . I think that a SAXrenderer could be the solution. SAX is based on calling a method when a tag begin-content-end is reached. It can be used to communicate the Area Tree to the renderer in a clean way, whith a standard interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Hi Peter, Aside from my low opinion of SAX for process coupling, there should be no need for communication back from the renderer. . . . cool - I thought the Area Tree code needed to know about font metrics and the like, but if this communication is one-way all the better. Regarding SAX events, I really meant that for structure renderers. What I envision (in the context of RTF rendering through jfor) is the possibility of using the FOP front-end only to resolve XSL-FO properties, like an XSL-FO preprocessor if you want. That's for this preprocessor-to-StructureRenderer interface that I think using XML makes sense, for loose coupling of the StructureRenderers which would then not necessarily be part of the FOP code base. If we agree that XML is good for this, I think generating this XML through SAX events allows the preprocessor component to be efficiently integrated in Cocoon (for example) later on, without having to serialize and reparse the XML. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
On Saturday 16 March 2002 14:52, Peter B. West wrote: . . . The last stage of the FOP process translates one page description (the area tree) into another (the input to the target renderer.) ok So why would anyone want to interpose another translation step into this tightly coupled arrangement? Who knows? . . . For page-based renderers where FOP has to compute the layout (like for PDF output), I don't see a need for another translation step either. IMHO asking who knows is usually a sign that a feature is not needed *at this stage of development*... OTOH, for structure-based renderers like RTF and MIF, I think the only parts of FOP that are reusable are the first two stages: parsing and property resolution (apart from infrastructure like logging, config, etc. which might come from Avalon in the future?). Last week we had a talk about using XML to communicate between FOP pipeline components, but for me this currently would only make sense between the property resolver and structure renderers components. The deal is being able to reuse FOP's property resolution (p.res) in different contexts. I think the following usage scenarios could greatly benefit from reusing FOP's front-end (parser + p.res). In the following I call pr.fo an XSL-FO document where all properties (fonts, sizes, etc.) are explicitely written, for example when inherited from parents: a) XSL-FO to RTF conversion: FOP parser - FOP p.res - pr.fo - jfor converter b) XSL-FO to MIF conversion FOP parser - FOP p.res - pr.fo - yet-to-write XML-to-MIF converter c) automated testing of first FOP stages FOP parser - FOP p.res - pr.fo - XML testing tool Keeping in mind that RTF and MIF are formats where the page layout is left to the client software to compute (word processor or FrameMaker), keeping these converters independent of FOP instead of integrating them has several advantages: b) Helps keep FOP focused on its main task: generating great PDF from XSL-FO documents c) If FOP is ever rewritten in another language for performance, these converters, being much less compute-intensive, can stay in java and keep the same interface to the FOP components that they use d) assuming I want to write a MIF converter, basing it on XSL-FO input instead of on a FOP API allows me to easily include MIF-specific constructs for applications where XSL-FO conformance is not needed but precise control of the generated MIF is (often a requirement for MIF when producing half-finished documents that are typographically reviewed before printing). In conclusion, I think an interface based on XML documents (possibly this pr.fo discussed above) is the best choice to use between the FOP property resolution stage and the structure renderers like RTF and MIF renderers. OTOH I agree that using XML between the layout and rendering stages doesn't make sense at this stage of FOP development. Due to many other commitments, I don't have time right now (sorry, I know you're getting used to hear this) to implement this pr.fo interface, but if we agree on its usefulness I'll put this high on my list and hopefully give it a shot in the next few weeks... -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
On Monday 18 March 2002 13:37, Peter B. West wrote: . . . Bertrand Delacretaz wrote: In conclusion, I think an interface based on XML documents (possibly this pr.fo discussed above) is the best choice to use between the FOP property resolution stage and the structure renderers like RTF and MIF renderers. The big problem is in defining the p.res step. How far do you need to go with this? If you require all of the relative lengths resolved, e.g., you'll have to wait until the layout is done. The properties are only finalised as the area tree is being constructed. It's one of the things that makes this all so frustrating. ok I see. I'll try to play with this for RTF rendering based on jfor, to get a feel for how hard/useful this is. In case of jfor, what is needed is mostly property inheritance, for which AFAIK rules are well defined in FOP. I guess relative lengths will probably stay relative in the RTF code, but I'll have to play with it to be positive about this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Area tree - renderer (pr.fo for structure renderers)
Hi Peter, On Monday 18 March 2002 22:06, Peter B. West wrote: . . . There's another gotcha - markers. The properties in markers are resolved relative to the retrieve-marker invocation point. . . . Thanks - I'll keep this in mind when I get to play with this stuff.. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Vote] New committers: Peter West, Joerg Pietschmann?
On Thursday 11 April 2002 12:16, you wrote: I propose that we offer Peter West and Joerg Pietschmann to become committers. +1 for both! (Although officially a committer I have done nothing concrete yet, so I hope my vote counts ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Lest we forget
This probably helps: http://www.anzacday.org.au/ -Bertrand 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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Lest we forget (please use REPLY!)
On Friday 26 April 2002 08:09, Bertrand Delacretaz wrote: This probably helps: http://www.anzacday.org.au/ sorry for the noise - I didn't see that the question had long been answered. PLEASE everybody use reply-to when replying to mailing lists messages. With the right mail client, it allows discussions threads to stay together. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
On Wednesday 01 May 2002 18:19, Peter B. West wrote: Does the near-silence on this one signify consent? I don't know enough about this to give meaningful advice, so in my case yes, silence means consent. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
Hi Keiron, . . . We should be able to set common objects like the logging and config on the structure handler itself. But the context idea could be useful for other objects that it may need to access. . . . ok, It wasn't clear for me either what would go into the context object, but it is certainly better that passing the FO object directly. . . . I'm not sure about the best way to do things like the table columns. It would be simpler if it could do a start table after it has all the table columns rather than needing to get each table column individually through method calls. . . . Would this scenario be easy to implement? startTable startRow (maybe after all FOs for the row have been parsed) startCell (maybe after all FOs for the cell have been parsed) start/end stuff for cell contents endCell more start/endCell endRow more start/endRow endTable or do you mean just one startTable with row/columns contained in the FO? I'd prefer many event calls, as the StructureHandler wouldn't need to know as much about FOs in this case. Conceptually (and this might be useful for concrete stuff like testing too), I think the StructureHandler needs to be able to rebuild the XSL-FO structure with as little code as possible. Maybe (if easier to implement or to avoid slowing down PDF rendering) this event generation can be done by an intermediate component that decodes the FOs and generates detailed events? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure Handlers - RTF Renderer
Hi Peter, Sorry for taking so long, week's been hectic around here. . . . I think you will still have attribute resolution problems. Remember that some attributes are only going to be resolved during the layout. I understand that some attributes cannot be resolved at the parsing stage, and as Keiron mentioned, there will need to be a way to transfer them with all the relevant information. The implications for RTF are not that clear for me though (mostly because jfor is currently sooo weak about attributes, AND I never worked on a print-type renderer) - I think I need to be able to play with actual code to better understand the issues. AFAIK Keiron is working on a first shot StructureHandler which should help me jump in. . . . It seems to me that the general solution would involve the definition of a structure api, taking account of the layout dependencies. . . . I agree, but again the whole picture is not clear enough in my mind yet to be able to specifiy these dependencies. I suggest that we wait for Keiron's skeleton code, on which we build a rough RTF converter which will help us (me at least ;-) understand the issues on concrete examples. We should then be able to define a set of XSL-FO documents that show different use-cases for attribute resolution. . . . You may already have documented the structure transformations needed for FO-RTF. If so, it would be a very good idea to include them in the NEW DESIGN documentation. . . . Unfortunately not - what jfor currently does is 1-to-1 mapping of basic attributes like font sizes, bold, italic, etc. so there's not much to be said. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2
On Monday 10 June 2002 17:06, Christian Geisert wrote: . . . 1) Declare that Fop needs JDK1.3 Could cause confusion with Cocoon users - Cocoon requires JDK1.2. 2) Remove truetype font support from AWT viewer +0 3) Compile Fop with JDK1.3 (which will be done anyway) and state in the release notes that compiling with JDK1.2 and using truetype fonts in the AWT viewer does not work. +1 If I understand correctly, a version compiled with 1.3 would run ok on 1.2 except for these truetype fonts? Then fine. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2 (using ant copy tasks to select implementations)
On Tuesday 11 June 2002 08:22, Jeremias Maerki wrote: . . . 2. Try to build up the support for version dependant code for the next release. . . . Note that this is fairly easy to do using filtering in ant copy tasks and package names containing identifiers. For example: package A contains interfaces, abstract classes and factories as needed package A.jdk12 contains 1.2 implementations package A.jdk13 contains 1.3 implementations The ant copy task (copying source files to an intermediate directory before compiling) can then filter source files based on package names, in order to select and compile the right classes. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2 (using ant copy tasks to select implementations)
On Tuesday 11 June 2002 14:43, Rhett Aultman wrote: . . . Rather than relying on Ant, I'd say a runtime detection of VM demographics (version, vendor, etc) would be in order, which could then allow a classloader to select the correct classes to instantiate. . . . I like your idea a lot - hopefully it won't be too complicated to implement, but there might be cases where you actually have classes that do not compile on some VM version. If that's the case, multiple JDKs might be needed to compile FOP completely, and we must make sure that single-VM compilation remains possible. So we might need to combine both approaches in the end. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: For once Good news and a thank you
Hi Jochen, Would it be thinkable for you to share examples of your XSL-FO documents, as good examples of what works well in FOP? The question of which constructs to use to get good performance come often, so I think it would be a worthwile addition to the project. If needed, I can send you a piece of java code that obfuscates the text of XML files by replacing all words with others from a list, so that the confidentiality of your data would be preserved. Please let us know what you think! -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
StringWarper - obfuscates XML files (was: For once Good news and a thank you)
On Thursday 13 June 2002 14:51, Ralph LaChance wrote: ooo, I could use that ! You'll find it at http://codeconsult.ch/download/string-warper/string-warper-2002-06-13.zip There's a build.xml for ant, target test runs a self-test. Actually I should have said a piece of java hacking. You'll see that it's dead simple, doesn't even use a proper parser. Which means it might *destroy* some XML files depending on the constructs used. Please let me know if you make it better (wellthatsnothard)! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence short or long
On Wednesday 26 June 2002 22:42, Jeremias Maerki wrote: . . . We have the short form but it seems like we have to switch (back?) to the long form. . . . I agree, Stefano's message [1] in the thread you mention makes it clear, . . .the ASF board, to avoid confusion, wants everybody to stick with the full license until the new license is out. . . -Bertrand [1] http://marc.theaimsgroup.com/?l=avalon-devm=102511331724304w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO to RTF
On Friday 26 July 2002 20:05, J.U. Anderegg wrote: . . . RTF is the format of yesterday: better generate MicroSoft Office XML or Open Office XML. Depends on what you're aiming for. RTF is a terrible format, yes, but at least it allows documents to be opened by a fair number of wordprocessors. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: FO to RTF
Hi Peter, I tentatively suggested using XSLT to generate RTF a little while ago, but I had no idea whether it was feasible. The main question would seem to be: is RTF a text-only format or a binary format? Can anyone answer that one for us? AFAIK, everything in RTF can be expressed with text-only characters, and it would certainly be possible to convert XSL-FO to RTF using XSLT. Our choice to use java for the jfor converter was based on better availability of programming and debugging tools. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO to RTF (new jfor license)
Hello, On Friday 26 July 2002 10:20, Mulet, Jordi wrote: . . . We have started to experiment with jfor (FO-RTF) and we don't know the best path to follow and if there are plans to integrate jfor in FOP as a RTF renderer. . . . Note that the jfor license was recently changed to allow it to an ASF-compatible one, see www.jfor.org for more info. This allows jfor to be distributed with ASF projects. This means that the RTF library part of jfor can be used in binary form as a back-end for FOP (StructureHandler) to generate RTF, without having to maintain two RTF libraries (which would be the case if the jfor RTF code was moved to the FOP codebase). I think this will ease the transition from jfor to FOP for RTF generation, until FOP 1.x is released. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott, On Wednesday 09 October 2002 16:20, Sauyet, Scott (OTS-HAR) wrote: Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Where to start for an RTF renderer (was: New Developer Suggestion)
Hi Scott, On Wednesday 09 October 2002 17:15, Sauyet, Scott (OTS-HAR) wrote: . . . So is integrating other renderers something that the group would eventually like to do? . . . Yes, we've been talking about structure-based renderers (like RTF and MIF) vs. layout-based ones (PDF being the focal point) for some time. The following messages might shed some light on this: http://marc.theaimsgroup.com/?l=fop-devm=102742684000426w=2 http://marc.theaimsgroup.com/?l=fop-devm=102795797014083w=2 . . . As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? . . . As Jeremias said, you're the one who decides what you'd like to work on. I'm personally biased towards the RTF renderer because that's the part I know best, so here are some starting points if you're interested in studying this in more detail and hopefully jumping in. You won't need much RTF knowledge to start with as the jfor RTF library will generate it for you, and no PDF knowledge at all since this RTF renderer will bypass the layout and PDF generation stages completely. Starting points: 1) org/apache/fop/apps/StructureHandler is the base class that receives structure events from the FO tree while the input XSL-FO is being parsed. The main class of the RTF renderer will inherit from this class to transform the events into an RTF document. 2) Package org/apache/fop/mif is an example of how to build a structure-based renderer similar to what the RTF renderer (org/apache/fop/rtf) will be. 3) jfor (www.jfor.org) is currently a separate project that converts XSL-FO to RTF directly, but could take advantage of FOP's much better handling of XSL-FO properties, hence the plan of replacing jfor by a FOP RTF renderer. 4) My suggestion is to first use the RTF library from jfor in binary form, by including jfor's jar in the FOP distribution, to create the RTF document from the StructureHandler events. The current jfor code does a similar thing where the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive the jfor RTF library. Later, when FOP becomes better than jfor at generating RTF, we can move the jfor RTF library code into the FOP codebase. I'd like this to happen in a second stage to avoid having to maintain two RTF libraries while both projects coexist. Hope this helps - feel free to ask any additional questions! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Where to start for an RTF renderer (was: New Developer Sugges tion)
Hi Scott, . . .anyone who wants to do it will not offend me by going ahead and doing it without me. . . . We haven't had too many volunteers lately in this area, so this shouldn't be a problem. Just make sure to send your patches early, without waiting for your enhancements to be finished. This will help coordinating your work with that of other developers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fopping 1-12 to Jan-Dec
On Monday 28 October 2002 11:18, Guy D'haenens wrote: WHAT'S THIS? I DIDN'T WRITE THIS MESSAGE! I think the from: address is such that it is being rewritten by some part of your mail system before delivery, it happened here too. If you look at http://marc.theaimsgroup.com/?l=fop-devm=103579950332696w=2 you'll see that the from: address is different of what you got. Don't feed the trolls... -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[FYI] jfor integration jumpstarted...
I have added jfor-0.7.1.jar and its license to the lib subdirectory, and created a first version of an RTFHandler that outputs (very rough) RTF documents using the existing jfor RTF library [1]. build.sh examples now generates RTF documents, assuming the following is set in build-local.properties in the directory that contains build.xml: # output format for ant examples build.property.examples.mime.type = rtf I probably won't work on this over the weekend (I'll be building the music room instead ;-), so if anyone wants to have a shot at improving it, go for it! Examples of how to use the jfor RTF library can be found in the org.jfor.jfor.converter package of jfor, see www.jfor.org. -Bertrand [1] as already discussed here, this is done so as to avoid having to maintain two RTF libraries until FOP is better than jfor at generating RTF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about fop 2)
On Saturday 02 November 2002 10:35, Victor Mote wrote: . . .I would also recommend that, in the above case, we actually put the code into two different projects. . . . +1, I like the idea. How about moving the new code (HEAD) to a separate (xml-fop2) CVS project to clarify things, and maybe name the new version fop 2 instead of 1.0x? Although the current version is 0.20.x, it *is* used in production at a number of sites, so going directly to version 2.x for a mostly new codebase makes sense IMHO. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches
On Friday 01 November 2002 16:51, Keiron Liddle wrote: . . .Maybe the simplest is to move the old layout to the trunk, get that working and put the new layout in a branch. But it needs to be agreed upon. . . . It would be great if the layout engine could be factored out as a component with a clean interface, so as to be able to switch between current engine, not perfect but usable, and new engine, not finished but testable. I have a feeling that working on the layout engine requires fairly specialized skills, whereas other parts of the code are more general in nature (logging, Driver, config, Avalonizing, etc.). IMHO the layout engine is the most risky component of FOP, so a good candidate for a component with a thin interface. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 23:53, Peter B. West wrote: . . .I don't know the mechanism for handling line-end differences on entry into a CVS repository on a unix box. . . . AFAIK as long as the binary file flag is not set, CVS takes care of line endings by itself when a file is checked out (http://www.loria.fr/~molli/cvs/doc/cvs_9.html#SEC76), converting them to what's appropriate for the platform. Funny things can happen if people checkout files on a unix box and edit them from a windows box, but most windows editors handle this correctly. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 17:02, Jeremias Maerki wrote: . . .Does anyone have a good idea how to... 2. enforce correct line endings? Using the commitinfo administrative file, scripts can be configured in CVS to run when a file is committed, at which point you could detect the problem. I'm not sure if it's worth the effort though. When such a problem is found, you could also study file revisions to find out who created the problem and tell people to fix their environment. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 12:31, Keiron Liddle wrote: . . . What sort of jfor extensions are there, what do they do? We have jfor:style to define RTF styles (similar to CSS classes in concept) on the generated RTF elements. A concept that does not exist in XSL-FO as it doesn't make sense when generating printable documents. And also jfor:cmd to set options for the jfor processor, currently used for special tricks/hacks for keep-with stuff. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest is coming?
On Wednesday 06 November 2002 10:03, Keiron Liddle wrote: . . . Lots more to do but I think it is a good start. Great job indeed! I've also been looking at Forrest more closely recently, already very usable and looks even more promising. Need to brighten up or change the logo. Maybe we should have a competition. Good idea, make sure you announce it on fop-users too if you decide to do it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: feature request queue
On Wednesday 06 November 2002 14:58, Oleg Tkachenko wrote: . . . Patch queue looks very good, and what about introducing one more queue for feature requests? . . . I think these can be identified by the severity=enhancement field of bugzilla issues, isn't that sufficient? Maybe this must be documented on http://xml.apache.org/fop/bugs.html, adding a comment make sure to set severity=enhancement if you're entering a feature request? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP developer's style guide? (Was: interface instead of implementation)
On Wednesday 06 November 2002 16:31, Rhett Aultman wrote: . . . Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. . . . How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP developer's style guide? (Was: interface instead of implementation)
Wow, that's a quick vote... I have setup the page at http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide with a most basic style guide skeleton. I have to run now, but feel free to work on it. Make sure you keep copies of what you write, I cannot guarantee backups on this server yet. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
On Thursday 07 November 2002 09:23, Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! +1 - welcome! -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, Cocoon, FOP, mentoring/teaching/coding. blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another Bugzilla URL
On Thursday 07 November 2002 10:09, Victor Mote wrote: . . . BTW, I haven't found any doc on the mozilla site to help in building these URLs. If anyone knows of some, I would be grateful. . . . I don't think there's any other way than studying what the bugzilla query form sends when you submit it, maybe trying to remove parameters that have no effect to keep the URLs short. Bugzilla allows queries to be saved (per-user at least), you might be able to create a named query with the appropriate parameters and call it from a URL by giving only the query name (but I didn't try it). This would prevent those URLs from being too long, which might cause them to be broken by old browsers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Friday 15 November 2002 09:30, Keiron Liddle wrote: . . .(does anyone even know what I am talking about) Not much on my side as the whole layout thing is still a mystery to me (because I have no experience in computing layouts and never took the time to study this part the code in detail). Anyway I'll try to put my 2 cents in... From your description, I get a feeling that a separate BreaksManager class might be needed, i.e. it might be better making this break stuff modular instead of making the layout managers more complex. I told you...just 2 cents ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [OT] Apache committers meeting in german-speaking area
On Friday 15 November 2002 10:02, Jeremias Maerki wrote: . . .There was the idea to organize a meeting among Apache committers next year in the german-speaking part of the world . . . I might be interested too, depending on where and when. I am subscribed to party@. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
On Wednesday 20 November 2002 10:23, Keiron Liddle wrote: Plenty of eagerness shown already and I am sure he will do lots more for the project. Yes, agreed, here's my +1 -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
On Wednesday 20 November 2002 15:15, Jeremias Maerki wrote: . . .I've finally finished the first draft for our style guide... Thanks! I voted -1 on most TBD stuff, braces and spaces are not really important IMHO and I think it's good that the style guide stays as small as possible. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alt-Design status: XML handling
Great work Peter!
It makes a lot of sense to use higher-level than SAX events, and thanks for
explaining this so clearly.
If you allow me a suggestion regarding the structure of the code: maybe using
some table-driven stuff instead of the many if statements in
FoSimplePageMaster would be more readable?
Something like:
class EventHandler
{
EventHandler(String regionName,boolean discardSpace,boolean required)
...
}
/** table of event handlers that must be applied, in order */
EventHandler [] handlers = {
new EventHandler(FObjectNames.REGION_BODY,true,true),
new EventHandler(FObjectNames.REGION_BEFORE,true,false)
};
...then, in FoSimplePageMaster(...) loop over handlers and let them process
the events.
I don't know if this applies in general but it might be clearer to read and
less risky to modify.
-Bertrand
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer (votes from non-commiters)
On Wednesday 20 November 2002 20:11, Rhett Aultman wrote: I thought everyone was allowed to use a vote to express their opinion. If I've gravely mistaken this, then I'll stop voting. I *think* it is so, that everyone is welcome to express their opinion. But as a mostly inactive committer I'm not the one to decide. Indicating this when voting helps, something like: VOTE: should FOP be rewritten in Forth? -1 (from a non-committer) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:16, Jeremias Maerki wrote: . . . The MUST part is very small and establishes some hard rules. I'll try to do the final layout in XML in a way that takes this into consideration. ok, cool! . . . By the way, due to common desire I added a few lines on exception handling and a few other items that I found were agreed upon in recent discussion. I added note 4 to propose a different/additional way of saying that exceptions are important. I'd put this stuff about exceptions as a subsection in the MUSTS, this so much more important than brace placement ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote: . . . final String myString = (String)myListIterator.next(); . . . How do you think, is this final specifier only a style oriented or it have some performance benefit also? I don't know about performance, but I use it all the time anyway as it makes intentions clearer and can save the day by preventing someone from messing up with the variable value. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Servlet, contrib stuff and tutorial
On Wednesday 27 November 2002 09:36, Keiron Liddle wrote: On Tue, 2002-11-26 at 13:53, Jeremias Maerki wrote: . . . Problems that need to be addressed: - All Java sources need to be checked easily before a release (do they compile, do they work?). Could ant call help out here? No extra build.sh or build.bat. . . . The ant ant task can easily call an external build.xml. The cvs task allows sources to be checked out (but AFAIK requires command-line CVS to be installed on Windows systems). -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Sunday 01 December 2002 22:26, Oleg Tkachenko wrote: . . . J.Pietschmann wrote: I think we should leverage final more often in FOP. At http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide we've got +2 vs -2 on this point, so taking into acount your opinion it's +3 vs -2 now. I think the +2 vs -2 that you mention refer to declaring variables in the inner scope, not precisely to using final or not. This thing about final is really minor IMHO, I think it's a good practice and should be mentioned as such, but I wouldn't make any checks on it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Happy Holidays
Happy Holidays team - I've been very quiet lately but this is *definitely* a good crowd, I wish I could spend more time here! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP wiki pages moved
As there is now an official Apache wiki [1], I moved the pages that were on my server to http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectPages Please do any further work on them there. They still need some cleanup after moving, I'll do it in January unless someone finds time to do it before. -Bertrand [1] as announced on community@ - thanks Andy Oliver! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
JforIntegrationInFop - background and guidelines
Hi FOP team, Due to popular demand (well, two people anyway), I have written this at the Wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?JforIntegrationInFop It explains my (hopefully our) motivations for integrating jfor into FOP, and how we could proceed on this. I'll be off for skiing (assuming snow comes) for a few days, so even quieter than usual. -- Bertrand Delacretaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, Cocoon, FOP, mentoring/teaching/coding. blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Integration of Peter's work
Peter B. West wrote: . . . What will be interesting here is the possibility of defining a set of structure events for integration with the structure renderers like RTF, and I hope we can have some fruitful discussions with Bertrand on this. Looks promising, let me know where to look when the time is right. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Conversion from src/org.. to src/java/org..
Le Vendredi, 7 mars 2003, à 17:39 Europe/Zurich, Jeremias Maerki a écrit : ...My main motivations for the move as such: - Easier handling of FOP in IDEs - Best practices confirmance - Finish what we (I) started +0.5, the IDE thing might be useful. As an option, we can also agree to do the same in the maintenance branch, -0, I don't see a need here. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Nomination of Glen Mazza as committer
Le Lundi, 16 juin 2003, à 02:12 Europe/Zurich, Victor Mote a écrit : ...However, I think it is appropriate to nominate Glen Mazza for committer status +1, welcome! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Hi Victor, If you're going to work on the RTFHandler I'd be happy to commit the relevant jfor sources (the RTF library I assume) to the FOP codebase with appropriate package name changes. As Jeremias mentions, it might be better if I do it myself so that the legal stuff is clear. I should be able to do it between today and tomorrow. The idea of using jfor in binary form at first was to avoid having to maintain two RTF libraries - but if you're going for it, then the time might be right to actually move the code here. .. Some of the source files contain non-ASCII characters (see main/JForVersionInfo.java, line 67, for example), but are encoded as ASCII (instead of UTF-8), so the IDE was choking... Are .java files meant to be encoded in UTF-8? I didn't know that. ...dropping in the Apache license (looks like no problem), no problem indeed and some style issues Do you mean code writing style like brace positions and stuff, or deeper code structure issues? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
Hi Victor, I have committed the classes from the jfor RTF library under org.apache.fop.rtf.rtflib. They don't compile out of the box, so I disabled their compilation in build.xml for now, didn't have time to look further. The next step would be to get them to compile, have the RTFHandler use them and remove jfor.jar from the lib directory. You will probably find dependencies to other parts of jfor, let me know if you need more classes (but hopefully most of those dependencies are not needed). ...I don't want to mislead anyone into thinking I'm making a big commitment here -- it will probably be a little here and a little there... fine - we'll see what happens! ...Java source is Unicode, and I don't think the encoding would matter, but UTF-8 makes the most sense as most of the source is ASCII. And it could be that most tools don't care, but I know that JBuilder does... yes, idea for example uses a configurable file encoding. ...if there is some doc on the RTF libs, there is none ATM. ...t seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much. Feel free to ask if you have questions. There is also the testdocs package some parts of the RTF library. Does it make sense in the long run for the jfor libs to be a separate project? It seems like it should have wider appeal than just for FOP, although FOP is probably a good home for it for now. I think FOP is a good start. It would be easy to create a separate rtflib.jar if needed. By creating another project we would lose the FOP community, it is certainly better at this point to strengthen it by adding new features to FOP. What's sorely missing IMHO is a way to validate the generated RTF other than by crashing word processors. If you hear about an RTF validator or an RTF parser grammar it would be a welcome improvement. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
Le Dimanche, 22 juin 2003, à 21:15 Europe/Zurich, Arnd Beißner a écrit : ...Before we're getting too philosophical, let me say that we're now talking two different issues: 1. Is it possible to develop a conforming XSL:FO implementation that produces RTF or MIF or similar ouput? Probably not, XSL-FO is clearly meant for page output and RTF and MIF (unless abused in strange ways) are document formats, not page formats. 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP) There are definitely two groups, and I agree with you that All of the stuff needed for FO-RTF or FO-MIF conversion is pretty straightforward stuff The whole point of the StructureHandler interface is to be able to reuse FOP's frontend for structure-based renderers. The impact of StructureHandler on the standard FOP output formats (PDF mostly) is minor, but it allows the FOP pipeline to branch cleanly, after the parsing and attributes resolution, to generate either structure-based or page-based formats. Besides sharing code, the advantage in RTF and similar output formats being developed as part of FOP is the community: one project with more audience instead of several, each with a smaller audience. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 10:35 Europe/Zurich, J.U. Anderegg a écrit : ... How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles. Another way would be to recognize sets of attribute values in the input XSL-FO and map them to RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. If you import XML in the newest versions of FrameMaker for example, you have to define a kind of style map which recognizes specific constructions in the XML and assigns styles to them. This might also be an option, use a second input file that tells FOP which (MIF or RTF) styles to assign when certain patterns are recognized in the input. ...Is it difficult to transform tables and lists? Not too much, but when we developed jfor we targeted it at RTF 1.5 which as no support for nested tables, so we had to fake them using joined cells (as older versions of Word did). Other than that, the tables and lists structures of XSL-FO map nicely to RTF. Possible problems are relative dimensions, for example it might be hard in RTF to say that a table must take 60% of the page height. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 12:08 Europe/Zurich, J.U. Anderegg a écrit : Bertrand Delacretaz wrote: ...In jfor we defined an extension to XSL-FO (the jfor-style attribute) to control RTF styles (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. What I called extension applies to XSL-FO, or rather to the input documents handled by jfor, which use the jfor-style attribute in addition to standard XSL-FO. You're right that this is not a FOP extension. This can be implemented cleanly with namespaces, so as not to pollute the XSL-FO input, something like fo:block font-size=12pt style:name=someRtfStyle Meaning that the style names are decorations to the input document. ...(2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries Sounds reasonable, but I don't know enough about the current properties code to comment on this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
