The HCL Conncetions 360 asset provides a module for PDF export functionality of all major HCL Connections content objects (Wikis, Blogs, Activities, Forums). The creation process of this PDF is highly customizable to meet the demands for the countless use-cases of PDF documents, such as marketing, documentation, compliance or archiving.
The PDF generation uses HTML documents to determine what should be rendered, and in what way. Therefore, the PDF content can also be styled and altered as such – just by providing the desired html, css (stylesheets) and javascript code. With this, we also offer the necessary hooks and interfaces to inject your changes into the predefined rendering process. Just define a template with the desired changes and the generation process will take them into account.
In this document, we will provide information on how to define and use templates, and how to customize them to let the PDF outcome match your needs and expectations.
There can be multiple defined templates for different scenarios. In the generation overview the existing ones will be available via a selection dialoge. The templates have to be saved in a configurable location and have to satisfy the following file-structure:
Mandatory, as stated for some files above, means that without those files a template will not be valid and therefore will not be included in the template selection dialoge.
To make a template available to the PDF export, copy a template folder containing the necessary files into the templates directory. This will be the ic360.configpath configuration path defined by your administrators, followed by /pdf-templates. As an example, if your configuration path is /tmp (temporary files directory on unix), your template named ‘Example’ should be in the following path:
/tmp/pdf-templates/Example
Remember that at least the files header.html and footer.html have to be inside your template. After a restart of the service, this template will now be available in the User interface template selection dialoge.
After this, your template will be read in during runtime, which means that changes will always take effect immediately after saving them.
This way you can also test your template. Update it and refresh the website rendering your pdf to find out how certain changes effect the outcome.
The Example-PDF-Template-Archive.zip zip archive contains a sample PDF template that can be used as a foundation for creating your templates. After downloading extract the archive content and edit the files as per your requirement. Rename the folder as per your preference and copy it into the templates directory. The name of the folder will be reflected in the PDF template selection dropdown in the PDF Export UI.
Websites can show anything you want them to. And they use the same underlying technologies as our PDFs. Therefore, the header and footer can be customized any way you want.
It has to suffice the general rules of HTML. This means, all content has to be put into the appropriate HTML attributes (div for containers, p for paragraph, img for pictures and so on).
Additionally, only the content withing the HTML body tag has to be on the file. The surrounding content will be generated in the process.
An example header could therefore look like this:
<div class="header"> <div class="app_icon {content.type}"></div> <div class="header_content"> <h5 class="header_title">{content.title}</h5> <p class="header_creation_time">{pdf.creationtime}</p> </div> </div>
An example footer could therefore look like this:
<div class="footer"> <p class="pull-left">Created with {pdf.createdwith}</p> <p class="pull-right">Page {pdf.page.current} of {pdf.page.count}</p> </div>
The {something} attributes are placeholders, that will be replaced during execution. For more information on this, see section properties
Styles (CSS) and Scripts (JavaScript) can also be included inline. However, you can also use the supported templating files described in section styles and section scripts
The styling for the content can be done in CSS (Cascading Stylesheet) files. As always, style information can be given on an attribute-, class- or id level. There are various predefined rules for the current styling, that can be found in the Appendix at default styles appendix
The rules defined in your template will overwrite them if necessary, so that you can take complete control over how content will be rendered. The comments in the file will give you information about what containers are available and how they can be styled.
Note that with styling the HTML, you are still bound the nature of PDF-appearance, especially regarding the size of content. You will have to suffice DIN-norms and your containers have to be big enough to fit the content defined within. Otherwise, the outcome might not look the way you imaged.
As with the aforementioned topics, JavaScript (ECMAScript 5) can also be used for PDF generation. This can analyse the created content to modify certain things before the final export happens. JavaScript is the most restricted content altering technique of the mentioned ones. This is because of an obvious reason: Once a PDF is created, it can not be changed.
JavaScript however, mainly is used to dynamically change content based on events and actions. This can not be done for the PDF generation. JavaScript can alter the content but has to have a static result in the end. This can be compared to taking a picture of a website. Even if JavaScript always changes the view dynamically, the things seen on the picture will not.
Things that JavaScript can be used for, are:
Change the table of contents based on how long the document content is
Change the sequence of the different content items, or within the content items (e.g. comments before the actual content)
Highlight specific words or sections, that can’t be highlighted by pure CSS (e.g. because they weren’t annotated with appropriate classes or ids)
Remove certain content for compliance reasons
Beware, that JavaScript will always increase the processing power necessary to generate the PDF. For Websites the amount of JavaScript executed can usually be very high due to client side processing. In this case, the client (PDF export tool) is on the server too. Therefore, with too many functions executed during PDF creation (and many people possibly simultaneously using it), the creation duration and server load will increase.
The only thing out of the ordinary regarding HTML techniques are placeholders. This basically means, that placeholders in a form of {placeholder_name} can be added within the templates, opposed to static strings. The advantages of this are, that templates can be reused by just changing the properties and often used dynamic attributes such as the content editor, creation time, content name and so forth can be leveraged (without having to use JavaScript functions).
An example usage of placeholders would be to have a department name change within different templates.
For this, define a template (e.g.) header, such as:
<div class="header"> <h5 class="header_title">{mycompany.department.name}</h5> </div>
Then create a file template.properties within the template and add following content:
mycompany.department.name=Finance Group
In the rendered version, all occurrences of {mycompany.department.name} have then be exchanged for Finance Group.
For dynamic placeholder, we provide the following ones:
Additional requests for dynamic placeholders will be evaluated and implemented, if the placeholder is generic enough to be used in various scenarios.
To be able to use the PDF export functionality, following requirements have to be met.