Overview
Hyper.Net supports configuration of its transformation functions at the content type level. For each content type in SharePoint, you can define a document type profile in Hyper.Net. The document type profile defines how all documents having the corresponding content type are to be handled. Configuration areas include:
| |
· |
Selection of the rendition formats (Rich Hypertext, Flat HTML, PDF, etc.) that should be created and populated into the publication created for the document
|
| |
· |
Specification of the way revision marks in the source document should be handled before the renditions are created
|
| |
· |
Association of the Hyper.Net schema used to map metadata and configure fine-grained settings for the Rich Hypertext rendition
|
| |
· |
Advanced settings
|
Document type profiles are especially useful for ensuring the consistency of published content across document sets. For example, consider the situation where it is left to authors to choose which renditions of a document should be created in each document's publication. In this case, it could occur that some documents have Rich Hypertext renditions, some have Flat HTML renditions and others PDF renditions. Because authors are free to choose rendition formats at whim, it is very likely that the result in the corresponding WCMS application would be inconsistent. Such inconsistency is not only confusing and frustrating for the end-user community, it also causes headaches for the WCMS application developer.
Document type profiles make it possible to design centrally controlled solutions that ensure the organization gets what it needs and at the same time avoid burdening users with such decisions.
| |
|
|
Tip
|
If a document type profile for a given content type has not been defined, Hyper.Net applies the document type profile named default. All of the sample documents delivered with Hyper.Net were published with this document type profile. It is thus important to note that a document type profile has everything to do with the way document content is interpreted, converted and published and nothing to do with the source document's file format.
Rather than immediately creating a document type profile for all of your content types in SharePoint, consider modeling your solution in such a way that the default document type profile is used in all cases where specialized requirements do not exist. This can help reduce complexity. Specialized requirements that may indicate that a document type profile is needed can include:
| |
· |
The publication of custom metadata common to one or a limited number of specialized content types, and which may be in name conflict with unrelated metadata used by other content types
|
| |
· |
The processing of specific document sets that contain unusual formatting (such as legacy Word documents that do not use heading level styles to indicate structure and instead relay on section numbers entered as text)
|
On the other hand, if your organization's use of content types and metadata is already very complex, the creation of a one-to-one correspondence between document type profiles and content types may be the most logical and intuitive approach.
|
Let's assume for one moment that you have a set of documents based on the SharePoint content type Procedure. For each procedure, you would like Hyper.Net to create a publication containing a Rich Hypertext rendition, a PDF rendition and a PDF/A rendition for archiving. You additionally require custom metadata entered by the author to be populated into the resulting publication for use within your WCMS application. These configuration steps are required: