WAComponent to PDF

Hello,

I would like to render WAComponents as PDF documents.
I took at look at Artefact, but it is an important work to render again
the data as PDF with Artefact, not to mention I feel it is a duplicated
work. Moreover, I have quite long documents spanning over several pages,
some of my tables are complex with some columns spanning over 2 or 3
columns and I have about 50 different documents to turn as PDF file.

Now I am think about rendering these components on dedicated pages, then
using wkhtmltopdf.
What I would do is get these components rendered at dedicated urls, then
call wkhtmltopdf with these urls as arguments.
Practically how will you do that? How to forge an URL for a page
rendering the component with a dedicated decoration for PDF conversion
(dedicated css, header, footer)?
My initial though is REST. Is it the right direction? Or are there other
options?

Thanks for tips, enlightenment or thought on the matter.

Hilaire

--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I recently stumbled upon this: http://www.cloudformatter.com/css2pdf
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Hilaire,

It has been a while since I used wkhtmltopdf to create PDF files from HTML
pages but I liked the way it worked when I did it.  I used a WARenderer
builder (actually it was WARenderCanvas builder at the time but things have
changed and I think WARenderer builder should work but haven't tried it) to
create the page as a full document HTML string and save it as a file.  

I would then execute wkhtmltopdf, pointing it to the file, to create the
PDF file.  I could then do what I wanted to with the PDF file, like let the
use download it.

I'm pretty sure wkhtmltopdf was able to do all the CSS stuff from URLs in
the generated HTML file.

I can look up more details if you need them.

Lou


On Thu, 22 Oct 2015 15:56:28 +0200, Hilaire <[hidden email]> wrote:
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi,

We have been producing PDF documents for quite a while now with this
approach. We like the approach of using seaside because we write the
code once (to see it in the browser) and then trust that the look in
the PDF is good. We render html and write it to a file; then call a
program on the command line and read the resultant PDF back or email
it as an attachment.

We reference the CSS URL in the html header. This is quite important
because we want the tool to render the PDF correctly with the CSS. We
have a single CSS url (file) per site and use this same one for PDF.

We've used prince (www.princexml.com) for many years now and it has
been reliable. We also used chart director to generate charts / graphs
by producing an image which we reference in the html file and produce
a PDF with. We've now moved graphs and things to HighCharts, which
uses a lot of JavaScript to render the graphs. Many tools have
problems with executing JS and producing correct PDF. So we are in the
process of moving to wxhtmltopdf. We found that it uses the CSS
properly and that it works well with HighCharts.

Below is a method that may help. Our stuff is not that nicely
packaged. We also have diverse documents and several span a number of
pages, depending on data and various things. We had to do a bit of
work to handle widows & orphans, which we did in Seaside

 (WAHtmlCanvas builder fullDocument: true)
rootBlock: [ :root |
root context visitor: (WARenderingGuide client: root context visitor).
root title: 'Form'.
root meta contentType: (WAMimeType textHtml charset: 'utf-8').
root stylesheet url: self stylesheetFileFullPath.
self addAdditionalBookmarksForRowsToRootIfNecessary: root ];
yourself


HTH
Let me know if you need more.
Otto



On Thu, Oct 22, 2015 at 3:56 PM, Hilaire <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This probably has more of what you're after:

http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF


If you're not on linux there is a was to access wkhtmltopdf via OSProcess in there as well I think.  If not I can send you what I'm doing.  Which is basically rendering the component to a file, having wkhtmltopdf do the conversion, and serving the pdf as a download in a tab that opens after some polling code posts a link to the PDF.  

HilaireFernandes wrote

Hello,

I would like to render WAComponents as PDF documents.
I took at look at Artefact, but it is an important work to render again
the data as PDF with Artefact, not to mention I feel it is a duplicated
work. Moreover, I have quite long documents spanning over several pages,
some of my tables are complex with some columns spanning over 2 or 3
columns and I have about 50 different documents to turn as PDF file.

Now I am think about rendering these components on dedicated pages, then
using wkhtmltopdf.
What I would do is get these components rendered at dedicated urls, then
call wkhtmltopdf with these urls as arguments.
Practically how will you do that? How to forge an URL for a page
rendering the component with a dedicated decoration for PDF conversion
(dedicated css, header, footer)?
My initial though is REST. Is it the right direction? Or are there other
options?

Thanks for tips, enlightenment or thought on the matter.

Hilaire

--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Hilaire,

It has been a while since I used wkhtmltopdf to create PDF files from HTML
pages but I liked the way it worked when I did it.  I used a WARenderer
builder (actually it was WARenderCanvas builder at the time but things have
changed and I think WARenderer builder should work but haven't tried it) to
create the page as a full document HTML string and save it as a file.  

I would then execute wkhtmltopdf, pointing it to the file, to create the
PDF file.  I could then do what I wanted to with the PDF file, like let the
use download it.

I'm pretty sure wkhtmltopdf was able to do all the CSS stuff from URLs in
the generated HTML file.

I can look up more details if you need them.

Lou


On Thu, 22 Oct 2015 15:56:28 +0200, Hilaire <[hidden email]> wrote:
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 22/10/15 15:56, Hilaire wrote:
> I would like to render WAComponents as PDF documents.
> I took at look at Artefact, but it is an important work to render again
> the data as PDF with Artefact, not to mention I feel it is a duplicated
> work. Moreover, I have quite long documents spanning over several pages,
> some of my tables are complex with some columns spanning over 2 or 3
> columns and I have about 50 different documents to turn as PDF file.

What are you trying to achieve and how complex are the pages? The output
quality of html to pdf solutions has always been a bit disappointing to
me, but I'm used to Framemaker/LaTeX. Line breaking, kerning, micro
typography are all worse. But that might not be relevant for your
documents. You could add a canvas subclass that generates what you need
(LaTeX, rtf, etc) instead, or make an iText based webservice. iText
offers better paragraph support than Artefact currently. Extending
Artefact would of course be very welcome, but I understand the
reluctance to spend that much time.

Stephan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Le 22/10/2015 15:56, Hilaire a écrit :
> Thanks for tips, enlightenment or thought on the matter.

Thanks to all of you for your tips.

Hilaire

--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Le 22/10/2015 18:38, Otto Behrens a écrit :
Hi Otto,

As the generated html file is read locally I get issue with the css path.

It renders the path to the style file as /files/MyFileLibrary/style.css
but it should look like http://myHost/pathToCss/style.css when you want
to read the html file locally.

The absolute path to style.css is purely constructed by Seaside, adding
the host part does not make a valid url:
http://myHost/files/MyFileLibrary/style.css is not valid.

How did you manage it? Are you serving your static files with Apache? I
am not there yet and would like to find a pure Seaside solution. Is
there a way to have a valid url, to a resource, with the http part in?
So far I did not find it, but Seaside is so big.

Thanks

Hilaire


--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yes, we serve a static file (with nginx). You should be able to create
a static URL to your seaside css as well, so I don't see why you'd
have a problem. You cannot specify a relative URL in your HTML output
as this will then probably be interpreted as relative to the file you
wrote on disk. Unless you write the css out to a file in that relative
path.

We use the full url eg. "root stylesheet url:
'http://myHost/resources/style.css'", where this is the site's css
path. Alternatively, try just a relative path like "root stylesheet
url: 'style.css'" and write the css file next to the html one. I don't
know why seaside would make the url absolute when you write it out.

We took all our CSS out of Seaside and put it on disk. We use less and
what not to "compile" it and get the web server to produce it. Mainly
because 1. Seaside is too heavyweight to serve (dynamically created)
CSS up as well as the HTML and 2. The tools are a but scrappy to deal
with CSS properly (but would be nice if we had a Seaside-like library
that helps with CSS).

On Tue, Oct 27, 2015 at 7:43 PM, Hilaire <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Le 27/10/2015 20:25, Otto Behrens a écrit :
> Yes, we serve a static file (with nginx). You should be able to create
> a static URL to your seaside css as well, so I don't see why you'd
> have a problem. You cannot specify a relative URL in your HTML output
> as this will then probably be interpreted as relative to the file you
> wrote on disk. Unless you write the css out to a file in that relative
> path.
Got it. From the file library config web tool, I have to set up server
hostname and server port to get a valid url as
http://localhost:8080/files/FileLibrary/style.css

Now I wonder how you can set up the hostname and port programmatically?

Thanks

Hilaire

--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Hliaire,

wkhtmltopdf has the --footer-url and --header-url options if you don't want to create a complete document and instead just want to render a component.  

Then you can save the component to a HTML file and have wkhtmltopdf prepend the header and append the footer to your content before doing the conversion.  

Since the header/footer likely change infrequently vs the content it may be an easier way to go.


Hope this helps,

Paul

HilaireFernandes wrote

Le 22/10/2015 18:38, Otto Behrens a écrit :
>  (WAHtmlCanvas builder fullDocument: true)
> rootBlock: [ :root |
> root context visitor: (WARenderingGuide client: root context visitor).
> root title: 'Form'.
> root meta contentType: (WAMimeType textHtml charset: 'utf-8').
> root stylesheet url: self stylesheetFileFullPath.
> self addAdditionalBookmarksForRowsToRootIfNecessary: root ];
> yourself
>
>
> HTH
> Let me know if you need more.

Hi Otto,

As the generated html file is read locally I get issue with the css path.

It renders the path to the style file as /files/MyFileLibrary/style.css
but it should look like http://myHost/pathToCss/style.css when you want
to read the html file locally.

The absolute path to style.css is purely constructed by Seaside, adding
the host part does not make a valid url:
http://myHost/files/MyFileLibrary/style.css is not valid.

How did you manage it? Are you serving your static files with Apache? I
am not there yet and would like to find a pure Seaside solution. Is
there a way to have a valid url, to a resource, with the http part in?
So far I did not find it, but Seaside is so big.

Thanks

Hilaire


--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

The options are described here:

http://wkhtmltopdf.org/usage/wkhtmltopdf.txt

Paul DeBruicker wrote

Hi Hliaire,

wkhtmltopdf has the --footer-url and --header-url options if you don't want to create a complete document and instead just want to render a component.  

Then you can save the component to a HTML file and have wkhtmltopdf prepend the header and append the footer to your content before doing the conversion.  

Since the header/footer likely change infrequently vs the content it may be an easier way to go.


Hope this helps,

Paul

HilaireFernandes wrote

Le 22/10/2015 18:38, Otto Behrens a écrit :
>  (WAHtmlCanvas builder fullDocument: true)
> rootBlock: [ :root |
> root context visitor: (WARenderingGuide client: root context visitor).
> root title: 'Form'.
> root meta contentType: (WAMimeType textHtml charset: 'utf-8').
> root stylesheet url: self stylesheetFileFullPath.
> self addAdditionalBookmarksForRowsToRootIfNecessary: root ];
> yourself
>
>
> HTH
> Let me know if you need more.

Hi Otto,

As the generated html file is read locally I get issue with the css path.

It renders the path to the style file as /files/MyFileLibrary/style.css
but it should look like http://myHost/pathToCss/style.css when you want
to read the html file locally.

The absolute path to style.css is purely constructed by Seaside, adding
the host part does not make a valid url:
http://myHost/files/MyFileLibrary/style.css is not valid.

How did you manage it? Are you serving your static files with Apache? I
am not there yet and would like to find a pure Seaside solution. Is
there a way to have a valid url, to a resource, with the http part in?
So far I did not find it, but Seaside is so big.

Thanks

Hilaire


--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Otto Behrens wrote:
>We took all our CSS out of Seaside and put it on disk. We use less and
>what not to "compile" it and get the web server to produce it. Mainly
>because 1. Seaside is too heavyweight to serve (dynamically created)
>CSS up as well as the HTML and 2. The tools are a but scrappy to deal
>with CSS properly (but would be nice if we had a Seaside-like library
>that helps with CSS).

Did you check:  http://gcotelli.github.io/RenoirSt
for Pharo?

Bye
T.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Le 23/10/2015 16:52, Stephan Eggermont a écrit :
Documents contain long texts, tables, with various colours and font
schemes. Some come with graphics, but I can pass on that for now.

Now, I realize there are too many documents to code it as Seaside
components.

I have been looking at Mustache and it will be part of the equation;
documents should be Mustache template edited by a non technician person,
so it is easier to update when needed. Editing does not need to be
on-line, an html editor could be ok.
I am wondering if some of you ever used Mustache template edited by non
tech person? What tools did you used?

Of course Mustache could generate anything else than html. LaTeX?
Docbook? It is also then a matter of an appropriate editor for non tech
person, as well cpu consumption to generate the final PDF, and
eventually html for on line viewing.


Thanks

Hilaire


--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside