[Components] PDF generation - design document
Hi,
After we discussed the requirements during the last two weeks with no
major changes, I wrote a design document for the PDF generation. Please
ensure to find your usecases covered in the attached design document
[1].
Comments on the current design and aspects of the implementation are now
also welcome.
Kind regards,
Kore
[1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquarters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
k...@ez.no | eZ systems | ez.no
==
Design document for PDF generation
==
:Author: kn
This is design document for the PDF generation in the eZ Components document
component. PDF documents should be created from Docbook documents, which can
be generated from each markup available in the document component.
The requirements which should be designed in this document are specified in
the pdf_requirements.txt document.
Layout directives
=
The PDF document will be created from the Docbook document object. It will
already contain basic formatting rules for meaningful default document layout.
Additional rules may be passed to the document in various ways.
Generally a CSS like approach will be used to encode layout information. This
allows both, the easily readable addressing of nodes in an XML tree, like
already known from CSS, and humanly readable formatting options.
A limited subset of CSS will be used for now for addressing elements inside the
Docbook XML tree. The grammar for those rules will be::
Address ::= Element ( Rule )*
Rule::= ''? Element
Element ::= ElementName '.' ClassName
ClassName ::= [A-Za-z_-]+
ElementName ::= XMLName* | '*'
* XMLName references to http://www.w3.org/TR/REC-xml/#NT-Name
The semantics of this simple subset of addressing directives are the same as in
CSS. A second level title could for example then be addressed by::
section title
The formatting options are also mostly the same as in CSS, but again only
using a subset of the definitions available in CSS and with some additional
formatting options, relevant especially for PDF rendering. The used formatting
options depend on the renderer - unknown formatting options may issue errors
or warnings.
The PDF document wrapper class will implement Iterator and ArrayAccess to
access the layout directives, like the following example shows::
$pdf = new ezcDocumentPdf();
$pdf-createFromDocbook( $docbook );
$pdf-styles['article section title']['font-size'] = '1.6em';
Directives which are specified later will always overwrite earlier directives,
for each each formatting option specified in the later directive. The
overwriting of formatting options will NOT depend on the complexity of the
node addressing like in CSS.
Importing and exporting layout directives
-
The layout directives can be exported and imported to and from files, so that
users of the component may store a custom PDF layout. The storage format will
again very much look like a simplified variant of CSS::
File ::= Directive+
Directive ::= Rule '{' Formatting* '}'
Formatting ::= Name '=' '' Value '' ';'
Name ::= [A-Za-z-]+
Value ::= [^]+
Importing and exporting styles may be accomblished by::
$pdf-styles-load( 'styles.pcss' );
List of formatting options
--
There will be formatting options just processed, like they are defined in CSS,
and some custom options. The options just reused from CSS are:
- background-color
- background-image
- background-position
- background-repeat
- border-color
- border-width
- border-bottom-color
- border-bottom-width
- border-left-color
- border-left-width
- border-right-color
- border-right-width
- border-top-color
- border-top-width
- color
- direction
- font-family
- font-size
- font-style
- font-variant
- font-weight
- line-height
- list-style
- list-style-position
- list-style-type
- margin
- margin-bottom
- margin-left
- margin-right
- margin-top
- orphans
- padding
- padding-bottom
- padding-left
- padding-right
- padding-top
- page-break-after
- page-break-before
- text-align
- text-decoration
- text-indent
- white-space
- widows
- word-spacing
Custom properties are:
text-columns
Number of text text columns in one section.
page-size
Size of pages
page-orientation
Orientation of pages
Not all options can be applied to each element. The renderer might complain on
invalid options, depending on the configured error level.
Special layout elements
===
Footers Headers
-
Footnotes and Headers are special layout elements, which can be rendered
manually by the user of the component. They can be considered as small
sub-documents, but their renderer receives
Re: [Components] PDF generation - design document - CSS parser
Hi Kore, is it right, that for this approach, you'll need a parser for the simplified CSS? If yes, could this parser be an independent component, that could later be enhanced to parse regular CSS? We already have the case of ezcMail, which contains MIME parsing and generation that could be used in other components, too[1]. [1] http://lists.ez.no/pipermail/components/2008-April/003579.html Best regards, Thomas Koch Am Tuesday 24 February 2009 11:25:36 schrieb Kore Nordmann: [1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt -- Thomas Koch, http://www.koch.ro YMC AG, http://www.ymc.ch -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
Kore Nordmann wrote: Hi, After we discussed the requirements during the last two weeks with no major changes, I wrote a design document for the PDF generation. Please ensure to find your usecases covered in the attached design document [1]. Comments on the current design and aspects of the implementation are now also welcome. Kind regards, Kore [1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt Regarding pdf sets: I think other document types should be supported to be added to a pdf, especially images. It is common to take a few TIFF or PNG files and create a PDF out of them. -- Alexandru Stanoi System Developer eZ Systems | http://ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document - CSS parser
On Tue, 2009-02-24 at 11:40 +0100, Thomas Koch wrote: Hi Kore, is it right, that for this approach, you'll need a parser for the simplified CSS? If yes, could this parser be an independent component, that could later be enhanced to parse regular CSS? Not really, because a) Real CSS is *far* more complex to parse then the simplified grammar I used in the design document. That's why I defined a custom EBNF in the first place. b) We do not want cross component dependencies and the PCSS parsing is viable to the functionality of the component. c) I personally do not see a real usecase for CSS parsing in web applications, but prove me wrong on this. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
On Tue, 2009-02-24 at 11:49 +0100, Alexandru Stanoi wrote: Kore Nordmann wrote: Hi, After we discussed the requirements during the last two weeks with no major changes, I wrote a design document for the PDF generation. Please ensure to find your usecases covered in the attached design document [1]. Comments on the current design and aspects of the implementation are now also welcome. Kind regards, Kore [1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt Regarding pdf sets: I think other document types should be supported to be added to a pdf, especially images. It is common to take a few TIFF or PNG files and create a PDF out of them. You are expected to extend from the PdfDocument class for custom stuff you want to add to a PDF set. This can also be some autogenerated bibliography or index. All classes which extend from ezcDocumentPdf and follow its interface should be able to be added to a PdfSet and do whatever they like to do - maybe handling images, like you mentioned. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
On Tue, 24 Feb 2009, Kore Nordmann wrote: After we discussed the requirements during the last two weeks with no major changes, I wrote a design document for the PDF generation. Please ensure to find your usecases covered in the attached design document [1]. Comments on the current design and aspects of the implementation are now also welcome. We should have some form of possibility to control the width of table columns. This has to be done for each table specially, so that means we'd need PCSS ID support. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
On Tue, 2009-02-24 at 10:58 +, Derick Rethans wrote: On Tue, 24 Feb 2009, Kore Nordmann wrote: After we discussed the requirements during the last two weeks with no major changes, I wrote a design document for the PDF generation. Please ensure to find your usecases covered in the attached design document [1]. Comments on the current design and aspects of the implementation are now also welcome. We should have some form of possibility to control the width of table columns. This has to be done for each table specially, so that means we'd need PCSS ID support. Will add ID based addressing of document elements to the PCSS grammar - just like they are implemented in CSS. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] the structure of workflow database
hi, could you help mei to explain the structure of workflow database table structure? I would like to make my workflow system and add some fields, but I do not know how to do this! I want to operate in the flow process with some forms of data transfering ! -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
