AW: FO to RTF, Java Viewer: request for a systematic approach

["J.U. Anderegg" <ha...@bluewin.ch>]

Step 1: Specify what has to be done!

What are the requirements? What has to be supported? Which operating
environments? I'm afraid there is no common understanding, i.e. a fairly
precise specification in a few sentences, for these recent examples below.


Step 2: How can the specified requirements be implemented?

Look for and investigate candidate solutions!


Step 3: Which is the most reasonable candidate solution?

Evaluate candidate solutions and all their consequences! Select the most
appropriate one!


Step 4: Implementation

Contributors take over the job with a solid background.
_____________________________________________________________________

RTF

1. Requirements:
- generate revisable documents from XML data, preferably RTF?
- support images, graphics, indices, TOC's, tables, viewing/printing?


2 Candidate solutions

2.1 FOP

2.2 XSLT


3. Evaluation

3.1 FOP

This is the RTF text of a very simple RTF document:

{\rtf1\ansi\ansicpg1252\deff0\deflang1031{\fonttbl{\f0\fswiss\fcharset0
Arial;}}
\viewkind4\uc1\pard\f0\fs20 paragraph 1 and text\par
\par
paragraph 2 and text\par
\par
\par
}

The first line is some declarations (character set, font f0), followed by
next lines containing the document text.

What is FOP supposed to do? The structure is fundamentally different from
XSL:FO without any kind of declarations ("style sheets"). We do not see any
page coordinates, pagination controls.

3.2 XSLT

RTF text can be generated by XSLT. An infrastructure organisation of "XSLT
stylesheets" is needed to generate "RTF stylesheets".

_____________________________________________________________________

Java Viewer

1. Requirement
- Display XSL:FO documents in a Swing/AWT window? PDF?
- Support: view/print, images, graphics?


2 Candidate solutions

2.1 AWT Renderer

2.2 Acrobat Reader

2.3 Java PDF Viewer

2.4 Java SVG Viewer


3. Evaluation

3.1 AWT

What's wrong with the AWT renderer: are there just programming errors or
were system limitations hit?

3.2 Acrobat Reader

Acrobat Reader is THE full function PDF viewer. Is there a way to run
Acrobat Reader in a Java window: Mozilla, OLE by Java, ...?

3.3 Java PDF Viewer

Pretty hard to develop a full function viewer.

3.4 Java SVG Viewer

Is code available? If yes, image handling is to be solved.
_____________________________________________________________________


These examples are just meant to explane my request. Similar considerations
apply to FOP extensions. Only a systematic approach will allow efficent
development and evolution of FOP.

_____________________________________________________________________

Hansuli Anderegg



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FO to RTF, request for a systematic approach

[Keiron Liddle <ke...@aftexsw.com>]

On Mon, 2002-07-29 at 17:52, Bertrand Delacretaz wrote:
> I'd go for 2.2 as this avoids having to maintain two RTF document libraries 
> (jfor and FOP) during the transition. I think that's what Chris Scott is 
> working on, but I haven't seen his code or design yet, hence my request to 
> him for an early release.

That sounds like a good idea.
Release early and release often as they say.

> Hope this helps clarify things.
> -Bertrand



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FO to RTF, request for a systematic approach

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Hello Hansuli,

Here's my point of view regarding FO to RTF

> FO to RTF
>
> 1. Requirements:

Integrate the existing jfor code (www.jfor.org) into FOP so that FOP can 
become a better XSL-FO to RTF converter than jfor currently is.

> 2 Candidate solutions

2.1 move all jfor code in the FOP codebase and start from there

evaluation: as it will take some time for FOP to be better than jfor regarding 
RTF generation, this means maintaining two RTF libraries until FOP is ready 
and released. This is a serious waste of resources IMHO.

2.2 in a first step, use jfor in binary form and connect it to FOP using the 
StructureHandler concept

evaluation: first implementation (to generate a basic RTF document while 
ignoring most formatting) should be easy, using jfor's 
org.jfor.jfor.converter package as an example. Then, need to handle 
StructureHandler events in more detail. 

I'd go for 2.2 as this avoids having to maintain two RTF document libraries 
(jfor and FOP) during the transition. I think that's what Chris Scott is 
working on, but I haven't seen his code or design yet, hence my request to 
him for an early release.

Hope this helps clarify things.
-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org