s at xss.de
Fri Apr 11 12:39:45 UTC 2008
love the domain name :-)
On Fri, 11 Apr 2008 12:24:30 +0200
Holger Kleinsorgen <kleinsor at smallish.org> wrote:
> Stefan Schmiedl wrote:
> > Greetings,
> > since there's been some ideas on generating SVG from within a Seaside
> > application, I start wondering about creating another XML-based
> > document format: Open Document Format, nee ODF, which is what
> > OpenOffice.org is using as its native file format.
> > Has anybody done anything in this direction?
> not personally, but where I work we've tried various approaches for
> creating printable documents.
> HTML -> TeX -> PDF
> + high-quality TeX output
and reasonably fast to convert on a current server, too.
> - HTML -> TeX is not loss-free, so it's hard to control the appearance
> of the output
As Stephan suggested in another message, going straight to LaTeX from
the application data would be easier to control.
> Report -> FOP -> PDF
> + it actually generates PDF
> - haven't found a FOP processor that handles tables correctly
> (e.g. text within cells crosses the cell boundaries).
> Maby this has changed in the meantime.
> - generally, not loss-free
> - Apache FOP requires JRE. Other FOP processors in C are way behind
> Apache FOP in terms of quality.
The specific target I have currently in mind is already running
Open-Xchange, so a JRE is available.
> Report -> PDF
> + can control every bit of the generated PDF
> - need to control every bit of the generated PDF.
> - converting HTML -> PDF is as easy as writing a HTML renderer *cough*
I'm not quite sure what you mean by "Report" here.
> Graph -> SXD
> + graph can be translated into a document more or less loss-free.
> - user needs OpenOffice. might be ok in a intranet environment,
> difficult in environments where people cannot or don't want to install
> OpenOffice or an ODF converter/plugin for their favorite tool.
The big advantage of the ODF target is that you have something that
the user can adjust to his tastes. "This is a very unfortunate
linebreak", "Can you get this text right aligned for position 1, but not
for 2 and 3", "Can't you make the font smaller so that the total does
not end up alone on the second page".
If I produce something that's editable, stuff like that is not my
problem, as it can (and will) be fixed by the user on an adhoc basis.
If I encapsulate all the way from Seaside to PDF, I will have to provide
solutions for these borderline cases sooner or later.
This will need some more mulling over before acting, I think.
More information about the seaside