Re: [Cocoon Users] Re: .XML to .PDF OK, but what whit .DOC?

[Lu...@merck.de]

Dear Colleagues,
I would like hereby to provide you with an update of my previous posting of
August 18th  on the matter of generating RTF from XML.

The part of the mentioning posting that I would like to update consists in
the following sentence
"The first approach is to embed the XML2RTF bean from IBM with FOP."

Infact, I have evaluated the XML2RTF bean from IBM and identified the
following reasons for which it is likely not an appropriate choice:

   no source code is available
   licensing conditions are not compatible with the licensing conditions of
   the FOP / Apache project
   design

Of the 3 above observations, I would like hereby to focus on the last one
(which is the one which interests me the most since is the one for which
I am more familiar with ), namely the design of such bean. The mentioned
IBM bean (named RTF2XML and downloadable from
http://alphaworks.ibm.com/ab.nsf/bean/RTF2XML ) generates XML compliant
with a very simple DTD, given an input RTF.
The formal specification of the output of the RTF2XML Bean is given by the following DTD:

<!DOCTYPE Document [
<!ELEMENT Document(Group ) >
<!ELEMENT Group ( Group | Control | Data)* >
<!ELEMENT Control (#PCDATA)>
<!ATTLIST Control id CDATA #REQUIRED>
<!ELEMENT Data (#PCDATA) >
]>

As well  the reverse process (namely given an XML, generate RTF  ) requires the input XML to be compliant wit the above DTD.
If at first approach this could sound great since one would simply need to write an XSL to do the XML->XML conversion and
then "pipe" it in the bean , in reality is not so great. Infact, unfortunately one has to supply the bean with the specific RTF code
that needs to be applied . For example here is a snapshot from the example available ...

<Document>
 <Group>
  <Control id="\rtf1"/>
  <Control id="\ansi"/>
 <Control id="\ansicpg1252"/>
 <Control id="\uc1 "/>
 <Control id="\deff0"/>
 <Control id="\deflang1033"/>
 <Control id="\deflangfe1033"/>
 <Group><Control id="\fonttbl"/>
 <Group><Control id="\f0"/>
 <Control id="\froman"/>
<Control id="\fcharset0"/>
<Control id="\fprq2"/>
<Group><Control id="\*"/><Control id="\panose "/><Data>02020603050405020304</Data></Group>
<Data>Times New Roman;</Data></Group>
<Group><Control id="\f3"/><Control id="\froman"/><Control id="\fcharset2"/><Control id="\fprq2"/><Group><Control id="
\*"/><Control id="\panose "/><Data>05050102010706020507</Data></Group>
<Data>Symbol;</Data></Group>

You will notice that the "Control" element contains in its mandatory id attribute the specific rtf code to be applied to the group.

IMHO it is therefore lacking support for a more "conceptual" representation of that information and namely XSL FO.

Therefore, I have started with the coding of rtf and brl extensions in fop. I am using the pdf source code as basic material for the
generation of the RTFRenderer and BRLRenderer since little documentation is available on the matter. Specifically, all what is
documented is hereafter reported:

     http://xml.apache.org/fop/architecture.html

                    Rendering
      This is a separate process. The render() method in Driver is invoked
                 (say, by CommandLine) with the laid-out AreaTree and a
                 PrintWriter as arguments. This actually calls the render() method in a
                 specific implementation of the Renderer interface, typically
                 PDFRenderer or AWTRenderer.

                 At the highest level PDFRenderer, for example, begins by rendering
                 each Page. The render() method in Page (as is the case for other
                 areas), invokes a particular method in the renderer of choice, e.g.
                 renderPage(). NOTE: this system is bypassed for Page, incidentally.

                 Rendering will not be discussed further in this document, as most of
                 our current effort must concentrate on layout. Section 4.12 in the XSL
                 WD discusses some issues applicable to rendering.  (http://www.w3.org/TR/xsl/slice4.html#rendmodel)

Regards
Luca

Re: [Cocoon Users] Re: .XML to .PDF OK, but what whit .DOC?

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 10:36 AM 8/21/00 +0200, Luca.Toldo@merck.de wrote:
>Therefore, I have started with the coding of rtf and brl extensions in
fop. I am using the pdf source code as basic material for the
>generation of the RTFRenderer and BRLRenderer since little documentation
is available on the matter. Specifically, all what is
>documented is hereafter reported:
>
>     http://xml.apache.org/fop/architecture.html
>
>                    Rendering
>      This is a separate process. The render() method in Driver is invoked
>                 (say, by CommandLine) with the laid-out AreaTree and a
>                 PrintWriter as arguments. This actually calls the
render() method in a
>                 specific implementation of the Renderer interface, typically
>                 PDFRenderer or AWTRenderer.
>
>                 At the highest level PDFRenderer, for example, begins by
rendering
>                 each Page. The render() method in Page (as is the case
for other
>                 areas), invokes a particular method in the renderer of
choice, e.g.
>                 renderPage(). NOTE: this system is bypassed for Page,
incidentally.
>
>                 Rendering will not be discussed further in this document,
as most of
>                 our current effort must concentrate on layout. Section
4.12 in the XSL
>                 WD discusses some issues applicable to rendering.
(http://www.w3.org/TR/xsl/slice4.html#rendmodel)
>
>Regards
>Luca

Hi, Luca

This is excellent, and I for one will be very interested in seeing what you 
write.

The existing code is the best reference. However, if you have any questions 
don't hesitate to ask - we have a bunch of folks on the list who will be 
able to answer.

Arved Sandstrom

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"