Re: Document automation with ODF (was Re: Request: Can "proposed committers" introduce themselves?)

[Dave Fisher <da...@comcast.net>]

>> Of course we had been using ODFDOM but the issue is how do you get ODF
>> transformed accordingly to other formats such as RTF, AFP or PDF and
>> make those formats look consistent with what you would get if doing
>> the transformation natively during design time in OO or Symphony.
>> 
>> 
> 
> I think your observation is correct.  The ODF Toolkit does not currently 
> have a good way of generating print or print equivalent output from an ODF 
> document.  The Toolkit had no layout or rendering support.
> 
> But I wonder if this is something that Apache FOP could help solve?
> 
> The styling vocabulary of ODF is loosely borrowed from XSL Formatting 
> Objects (XSL:FO).   It may be possible to generate XSL:FO from ODF much 
> more easily than converting from ODF to PDF or Postscript directly.  But 
> once we have the XSL:FO intermediary, then the pipeline could continue 
> with Apache FOP to target formats ranging from PDF to raster images.
> 
> Does that sound plausible?  Someone needs to do the layout and rendering. 
> But I hate to see that code written more than once.  The ODF->XSL:FO 
> conversion would be a great toolkit enhancement.  Has POI done this with 
> the Microsoft formats?

POI is more about reading, writing and calculating than it is about rendering. Users come to the list with questions about it, usually to HTML, and we help. In POI Excel is much better covered. Lately Word has finally been getting some attention.

Yegor and I have experimented outside the POI project with PPT2PS (and PDF) conversion so that we can make use of slides in our postscript workflow. We have been using some EPS generated by OOo for this, but likely due to the font embedding issues that Robert referenced earlier these EPS have the text rendered as shapes which is awful looking because font anti-aliasing is gone ... big fat lowercase "l" etc for Arial of all things.

One trouble with the FOP approach is that layout and rendering of tricky features is pushed even farther away from OOo. Not knowing the details, but knowing rendering and layout, there must certainly be code to do it in OOo. I would want to follow that - it is what the ODF toolkit ought to use from the core.  Maybe the trouble with that approach is that the rendering there is too tied in with GUI considerations?

IIRC - FOP like POI can suffer from the need to have the whole DOM in memory. If you have ever built a 6000 page PDF ...

We have thought of using PDFBox...

I think until we figure out where the rendering and layout should come from, the ODF Toolkit should be included as part of the Apache OOo podling. If the community decides it needs separate incubation that's fine. 

Exploring these trade-offs scientifically is what's needed - in the podling.

I need to stop reading these emails and start reading the OOo site and looking at code.

Now back to work...

Best Regards,
Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org