Hello Zopistas With all the ZDP excitement and discussions related to nicely formated documents, I would like to do an early release of ZpdfDocument. It creates relatively nice formatted PDF output from structured text or HTML. You can download it from: http://www.zope.org/Members/gaaros/ZpdfDocument ZpdfDocument ZpdfDocument is Zope wrap around Zpdf (included in the distribution) providing a through the web interface and management of style parameters as properties, similar to a standard Zope DTML Document. Generated PDF documents are cached in volatile attributes. Zpdf Native python library for generating Portable Document Format (PDF) documents. Provided mainly in support of StruturedText and is therefore limited to text. However it provides a nice class interface to PDF document generation. The main structure in a PDF document is a Document which contains a number of elements defined in the elements.py module. The pages are collected in a hierarchical manner under a root object and can share common resources through shared dictionaries. The PDF language is, like postscript a general page description language, and provides no tools for higher level document formatting. The object model of this module was designed for simple applications and facilitates easy document formatting. Pavlos
Hi, I tried and found it very interesting. However I would like the following features: ability to store the generated PDF in the Zope database, support for more HTML tags. Do you thing it is difficult to implement? If it is not very difficult, as I am not a real good coder, I could try to do it. Thanks
I would like to do an early release of ZpdfDocument
****************************************************** Oscar Picasso picasso@videotron.ca ******************************************************
On Thu, 4 Nov 1999, Oscar Picasso wrote:
Hi,
I tried and found it very interesting. However I would like the following features: ability to store the generated PDF in the Zope database, support for more HTML tags.
Do you thing it is difficult to implement? If it is not very difficult, as I am not a real good coder, I could try to do it.
Storing the generated PDF in ZODB is a straight forward modification. However every change to either the style elements or the content will create a new PDF document and store it in the ZODB. Frequently modified ZpdfDocuments, especially if they are large will cause unneccessary increase of the ZODB. But assuming we add this as an option, where should the PDF doc be added? As a File subobject to the ZpdfDocument? What do you think? Additional tags can be easily added. The underlying pdflib.py is quite flexible. However if you are thinking about tables then it might be a bit more difficult because of the many parameters that define a table layout. Which tags did you have in mind? Pavlos
Storing the generated PDF in ZODB is a straight forward modification. However every change to either the style elements or the content will create a new PDF document and store it in the ZODB. Frequently modified ZpdfDocuments, especially if they are large will cause unneccessary increase of the ZODB. But assuming we add this as an option, where should the PDF doc be added? As a File subobject to the ZpdfDocument? What do you think?
No, I don't think the generated PDF should be stored in the Zpdf Document. It should be stored in a Folder, a class instance, every where it is useful to keep a copy of a this particular file. The idea behind that is to use Zpdf Documents as templates and fill some variable data via a form. Lets take and example. In the insurance field we could create a template for a contract. A person could provide all the necessary data: name, age, profession and check the options the client wants. Then using the Zpdf Document template and the data in the form, we could generate a particular contract for that person. I think we have to be able to retrieve that particular contract on a database. This is just an example, I think the potential of such a tool is huge.
Additional tags can be easily added. The underlying pdflib.py is quite flexible. However if you are thinking about tables then it might be a bit more difficult because of the many parameters that define a table layout. Which tags did you have in mind? I was thinking about more simple tags like <s> and <u>.
Another useful thing would be the abilty to include some arbitrary PDF code in the generated files. For example a logo that could be generated by an authoring application like Illustrator. As I said I do believe PDF+Zope has a huge potential. Printing industry and printed documentation is still a great market (maybe to much conservative). If there is a group working on this field I would be glad to participate. Taking into account that: - I'm not a professional programmer, but I could give some inputs and constructive criticism. - my english is not so good ;) ****************************************************** Oscar Picasso picasso@videotron.ca ******************************************************
On Thu, 4 Nov 1999, Oscar Picasso wrote:
No, I don't think the generated PDF should be stored in the Zpdf Document. It should be stored in a Folder, a class instance, every where it is useful to keep a copy of a this particular file.
Ok I see. One way is to provide a file-like interface to ZpdfDocument so you can add it wherever you want from dtml, like: <dtml-call "manage_addFile ....>
The idea behind that is to use Zpdf Documents as templates and fill some variable data via a form. Lets take and example. In the insurance field we could create a template for a contract. A person could provide all the necessary data: name, age, profession and check the options the client wants. Then using the Zpdf Document template and the data in the form, we could generate a particular contract for that person. I think we have to be able to retrieve that particular contract on a database. This is just an example, I think the potential of such a tool is huge.
Why not create the ZpdfDocument template above the clients folder (lets say we name it pdf) so each client has access to it through acquisition. Client specific data are stored as properties on the client 'object' ZClass, DTMLDocument etc and whenever someone accesses: .../client_name/contract/pdf he will get the pdf version of his contract. In this way you can change the contract (lets say you add a new logo) and every client will see the changes without needing to update every generated pdf document. It will be less efficient but I think is more 'Zopish' this way.
I was thinking about more simple tags like <s> and <u>.
Ok I will add them on my TODO list Pavlos
Pavlos Christoforou wrote:
Hello Zopistas
With all the ZDP excitement and discussions related to nicely formated documents, I would like to do an early release of ZpdfDocument. It creates relatively nice formatted PDF output from structured text or HTML. You can download it from: http://www.zope.org/Members/gaaros/ZpdfDocument
I have written an additional (non-html btw) tag <PAGE> that implements a page break. Is this the right approach ? Or should this be a (configurable) attribute of some headers or an attribute to HR or whatever. And - should I send patches to somewhere ? ------- Hannu
Hi Hannu - On Sat, 13 Nov 1999, Hannu Krosing wrote:
I have written an additional (non-html btw) tag <PAGE> that implements a page break.
Is this the right approach ?
My intention was not to implement yet another document generation language, but I understand that HTML is not enough for nicely formated docs. A pagebreak tag is essential for good formating.
Or should this be a (configurable) attribute of some headers or an attribute to HR or whatever.
And - should I send patches to somewhere ?
I am not sure. If the number of 'extra' attributes required for decent formating is not large then we can add them as extra tags (definetely pagebreak is one of them. Even TeX with its advanced layout algorithms still gets pagebreaks wrong occasionally. What do you think? I need to get some feedback and then I will add them in the next release. and yes *please* send your patches to me: pavlos@gaaros.com Pavlos
Pavlos Christoforou wrote:
Hi Hannu -
On Sat, 13 Nov 1999, Hannu Krosing wrote:
I have written an additional (non-html btw) tag <PAGE> that implements a page break.
Is this the right approach ?
My intention was not to implement yet another document generation language, but I understand that HTML is not enough for nicely formated docs. A pagebreak tag is essential for good formating.
Or should this be a (configurable) attribute of some headers or an attribute to HR or whatever.
I am not sure. If the number of 'extra' attributes required for decent formating is not large then we can add them as extra tags (definetely pagebreak is one of them. Even TeX with its advanced layout algorithms still gets pagebreaks wrong occasionally.
What I meant was adding something like an attribute page_break_before to either <Hn> or <P> or even making it a mandatory for some styles by specifying it on the properysheet - H1_page_break_before
What do you think? I need to get some feedback and then I will add them in the next release.
The _right_ (tm) approach would be to implement support for CSS2 (and test it on something really complex like MSWord2000 MS-XML-(X)HTML docs ;) The one that actually can be done in reasonable amount of time would be a minimal set of additional tags (maybe only <page>) an some attributes for some tags - page_break_before, page_break_after with their counterparts no_ page_break_xxx to override style defaults. And a possibility to set such style defaults. And maybe a few pages of explanations of how the thigs work and what one has to do to add stuff. The code seems quite well structured, but even after actually adding the <page> tag I'm not sure I did it the best way (or that I understand how it does what it does ;). I suspect most of my not fully understanding it comes from my lazyness in reading the PDF spec. I will also need to disable page headers and footers (my current need is printing exactly positioned addresses on postcards) and next I will add a feature to make them optional (unless this already exists ?)
and yes *please* send your patches to me:
Done. -------------- Hannu
Hannu Krosing wrote:
I have written an additional (non-html btw) tag <PAGE> that implements a page break.
Is this the right approach ?
Or should this be a (configurable) attribute of some headers or an attribute to HR or whatever.
I might suggest using the @page rule from css2- section 13 of the Recommendation. That way any standards-compliant content will work with this method. -- Ethan "mindlace" Fremen you cannot abdicate responsibility for your ideology.
Ethan Fremen wrote:
Hannu Krosing wrote:
I have written an additional (non-html btw) tag <PAGE> that implements a page break.
Is this the right approach ?
Or should this be a (configurable) attribute of some headers or an attribute to HR or whatever.
I might suggest using the @page rule from css2- section 13 of the Recommendation. That way any standards-compliant content will work with this method.
How would it look like in plain HTML ? AFAIK the ZpdfDocument is a very simple layer knowing only as much HTML as is needed for rendering StructuredText. Any pointers to the "Recommendation" ? ----------- Hannu
participants (4)
-
Ethan Fremen -
Hannu Krosing -
Oscar Picasso -
Pavlos Christoforou