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? The practical reason for this is that I will need to create some "editable", at least "printable" and "permanently storable" documents like orders or requests for quotes. One possible way would be to make forms completely editable on screen, i.e. within Seaside, and then use a tool like CSS2XSLFO (see http://sourceforge.net/projects/css2xslfo ) which makes use of (X)HTML input, CSS-based layout info and an external XSL processor like apache's FOP to produce a PDF file. The advantages are that editing happens completely within the application, hence the "printed" document is internally available. Another approach would be to generate an ODF-based file, which the user can download and edit with OOo (which would be a great way to wean clients from their perceived MS dependency). An "advantage" here is that I don't have to put as much work into the application (the less code, the better) and that the user can modify the docs in whatever yet unthought of way he wants. What do you think? Regards, Stefan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
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 ---- good: + high-quality TeX output bad: - HTML -> TeX is not loss-free, so it's hard to control the appearance of the output ---- Report -> FOP -> PDF ---- good: + it actually generates PDF bad: - 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. ---- Report -> PDF ---- good: + can control every bit of the generated PDF bad: - need to control every bit of the generated PDF. - converting HTML -> PDF is as easy as writing a HTML renderer *cough* ---- Graph -> SXD ---- good: + graph can be translated into a document more or less loss-free. bad: - 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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Stefan Schmiedl
> The practical reason for this is that I will need to create some
> "editable", at least "printable" and "permanently storable" documents > like orders or requests for quotes. I'm happy generating LaTeX and processing it with pdflatex. It is simple (at least compared to odf), fast, free, and a lot better looking than fo based approaches. Stephan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Holger Kleinsorgen-3
Hi Holger,
love the domain name :-) On Fri, 11 Apr 2008 12:24:30 +0200 Holger Kleinsorgen <[hidden email]> 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 > ---- > good: > + high-quality TeX output and reasonably fast to convert on a current server, too. > > bad: > - 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 > ---- > good: > + it actually generates PDF > > bad: > - 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 > ---- > > good: > + can control every bit of the generated PDF > > bad: > - 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 > ---- > > good: > + graph can be translated into a document more or less loss-free. > > bad: > - 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. Thanks, s. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Stephan Eggermont-3
Hi Stephan,
On Fri, 11 Apr 2008 13:25:09 +0200 [hidden email] wrote: > > The practical reason for this is that I will need to create some > > "editable", at least "printable" and "permanently storable" documents > > like orders or requests for quotes. > > I'm happy generating LaTeX and processing it with pdflatex. > It is simple (at least compared to odf), fast, free, and a lot > better looking than fo based approaches. I agree with the advantages you mention. One of the reasons I came up with the css2xslfo transformator is that it should result in a pretty good WYSIWYG effect, as it would make use of the style information I use on the site already. Whereas with LaTeX I'd have to recreate something similar looking first. I admit to not knowing much about the internals, possibilities and limitations of creating ODF files "manually", but I hope that ODF being XML based would allow me to leverage much of what is already available. And it would be really nice to produce an editable document by calling "renderContentOn: odf" instead of "renderContentOn: html", wouldn't it? Thanks, s. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Stefan Schmiedl
Stefan Schmiedl schrieb:
>> ---- >> Report -> PDF >> ---- >> >> good: >> + can control every bit of the generated PDF >> >> bad: >> - 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. "Report" is just an example, generally speaking I meant the direct creation of PDF without an intermediate document. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Stefan Schmiedl
There are excellent programs out there that convert HTML+CSS to PDF, specifically PDFreactor which we have been using to generate downloadable documents using the same rendering code with slightly tweaked stylesheets for print media. I seem to recall posting small snippets to get you started on the list recently. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Holger Kleinsorgen-3
On Fri, 11 Apr 2008 15:07:15 +0200
Holger Kleinsorgen <[hidden email]> wrote: > "Report" is just an example, generally speaking I meant the direct > creation of PDF without an intermediate document. yeah ... back when I was young, daring and still had hair on the front half of the top of my head, I managed to write a "hello world" PDF file in vi. Never again :-) s. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
On Fri, 11 Apr 2008 06:44:44 -0700
"Boris Popov" <[hidden email]> wrote: > There are excellent programs out there that convert HTML+CSS to PDF, specifically PDFreactor which we have been using to generate downloadable documents using the same rendering code with slightly tweaked stylesheets for print media. I seem to recall posting small snippets to get you started on the list recently. Found it ... March 14, in "Printing - via rendering to static HTML file and prince CSS?". From the (vague) description on the website, I'd expect PDFreactor to work similarly to CSS2XSLFO, so it seems to be a viable solution to create "printable" documents. However, now that I thought of it, the idea of producing an editable document looks mighty attractive. I hope that I manage to wait for my customer to come up with this idea himself :-) s. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Stefan Schmiedl
That largely depends on what documents you produce. If its invoices and statements, they shouldn't be editable. If its something else, maybe. We do the former, so html to pdf works great. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |