Prepare documents for ESEF
In this trail, we'll provide you with the knowledge to properly prepare InDesign documents for ESEF tagging. We will cover topics such as:
- Workflow suggestions
- What is an ESEF report and how does it differ from the PDF report?
- Best practices for setting up documents
- InDesign settings to avoid issues in the ESEF report
- About fonts in ESEF projects
- TextBlock Tagging Planning
- Estimated time for this trail: 5 min
Workflow suggestions
CtrlPrint offers you the freedom to design your workflow just the way you want it. However, if you ever find yourself in need of guidance to kickstart your journey, we've thoughtfully provided some helpful suggestions:
- Workflow suggestions for new and recurring clients – without ESEF
- Workflow suggestions for new and recurring clients – with ESEF
Steps and information for ESEF reporting clients
What is an ESEF Report?
ESEF stands for European Single Electronic Format. This is a type of annual report that is submitted digitally to a national authority. This is important because it is now the legally mandated form of the annual report for listed companies within the EU, which means that this is to be prioritised over the production of the PDF which has been submitted in the past. The new ESEF report is in a format called XHTML and the significance of this is explained further forward on this page as it will affect the way in which you need to work with the file in InDesign. An ESEF report has technical requirements that must be met if the reporting company is to submit it successfully and the information on this page will assist in delivering this.
How Does it Differ from the PDF Report?
It is no longer mandatory to report a PDF as the legal annual report for an organisation subject to ESEF. Since the introduction of ESEF, the mandatory reporting file is an XHTML based document on which XBRL tags are applied. This change means that you now need to take a number of things into consideration as the expected document is not a PDF but an XHTML. The reason that designers of the document must account for this is that the PDF that is produced in InDesign, is converted to the XHTML format. The conversion from PDF to XHTML is not straight forward and through experience with projects, the information that will follow gives the most consistent results.
Project Chapter Structure
We recommend that you separate the primary financial statements from the notes that need to have TextBlock tagging applied into separate chapters. It is also prudent to separate the notes into several chapters rather than having them all as a single chapter on the server. This means that changes in the document will not have an effect on all the tags that have been done.
General information
- When you create your ESEF report, a PDF is converted to XHTML. Converting PDF to XHTML is complicated and it’s important that you have the right settings in your InDesign documents to avoid issues.
- Most of the issues are related to OpenType features in the documents’ fonts. In InDesign you can use different variants (glyphs) of the characters. If you use two or more glyphs of a character with the same Unicode in your report the Tagger cannot distinguish between them. Only one of the glyph variants will be used in the report. This could make the report look different in the Tagger compared to the PDF.
- Ligatures and different Figure Styles are known to create issues. For example, you cannot mix different Figure Styles in the report. The Tagger will then choose one Figure Style in the report and this may cause the XHTML not to be generated correctly. The recommendation is to set the report to Default Figure Style to avoid issues.
- The fonts you are using must be Unicode compatible. Most fonts today are compatible, but older or custom fonts may not be.
- Do not use Variable fonts in your report. You need to use Static fonts to avoid conversion issues.
- Variable fonts have many different variations of a typeface to be incorporated into a single file.
- Static fonts have a separate font file for every width, weight, or style.
InDesign Settings to Avoid Issues in the ESEF Report
1. Create a test document for testing XHTML conversion
- We recommend creating a test document including all Paragraph Styles that are used in the document/project.
- You can then test the XHTML conversion in CtrlPrint.
Read more about exporting an XHTML version of a chapter to test the PDF conversion here.
2. Turn off OpenType features
- Ensure that OpenType features are turned off in your Paragraph Styles.
- The recommendation is to use Default Figure Style in the report.
- If you want to change the Figure Style (e.g. Tabular Lining) you need to be sure to change the setting in the whole report to avoid issues in the conversion to XHTML. If you use different Figure Styles in your report the Tagger will choose one of them and this may cause the XHTML not to be generated correctly.
3. Turn off Ligatures
Ensure that Ligatures (e.g. “fi” and “ff”) are turned off in your Paragraph Styles. Ligatures are default in InDesign and must be turned off to avoid issues.
4. Avoid “White Space”
Avoid using “Insert White Space” in your report. “White spaces” can result in issues with spacing between words and letters in the XHTML. “Nonbreaking Space” is commonly used by designers but often creates issues. The recommendation is to use “Nonbreaking Space (Fixed Width)” instead. This space is more likely to work.
5. Avoid Character Superscript/Subscript
When creating superscript/subscript numbers in InDesign, you avoid using InDesign's own "Superscript" and "Subscript" options. This is because they do not result in a unique Unicode character, so their formatting will be lost and they will become a standard-sized number when using the "Force" setting in the ESEF settings. For correct superscript/subscript formatting:
- Glyphs panel: Find and insert the correct superscript/subscript numbers
(Window -> Type & Tables -> Glyphs).
6. Issues with “Small Caps”
Depending on the font you are using there could be issues if you use “Small Caps”. The recommendation is to avoid it. If you need to use “Small Caps”, pay attention to how the text looks after the conversion to XHTML.
7. Issues with “Section Marker”
If you insert a “Section Marker” in InDesign, it’s important that you do not use “All Caps” in the “Section Marker”. If you use “All Caps” font issues can arise in the Tagger and some Lowercase characters may be replaced with Uppercase characters in the report. If you want Uppercase characters in the “Section Marker” you can use Uppercase characters in the “Numbering & Section Options/Section Marker”.
8. Do Not Use Private-use Characters
“Private-use characters” are quite unusual to use in InDesign. If you use a “Private-use character” it will not be displayed correctly in XHTML. To get information about characters open the Glyphs panel (Type>Glyphs).
“Private-use character”: A character whose use is defined by private users and companies rather than defined by a standard such as Unicode, and which therefore has no universally accepted meaning.
9. Substituted Glyphs
In InDesign you can highlight the “Substituted Glyphs” that may create issues in the ESEF report. Not all of the highlighted glyphs will create issues.
- To highlight Substituted Glyphs in InDesign, go to Preferences > Composition and tick the “Substituted Glyphs” box
Note: The hyphen generated during word hyphenation at line breaks is always highlighted as “Substituted Glyphs” in InDesign.
About fonts in ESEF projects
When you convert a PDF to XHTML (this occurs when documents are saved to the server from the Tagger for creating ESEF reports) some issues with fonts can arise. If you use the settings below the XHTML file will not have font issues and you will avoid “Hidden facts”.
What are Hidden Facts and How to Avoid Them
When converting and tagging a PDF report in the XBRL Tagger, some facts (tags) might become hidden. The reason for this is that the Inline XBRL Specification does not allow individually formatted numbers to be tagged. E.g. when the font requires special spacing between single characters by using HTML tags like <span>, the number is then no longer taggable. In order to preserve the spacing and formatting of the PDF in the XHTML report, the XBRL Tagger moves the tag to an unformatted hidden section of the document and includes a link to the visual original number.
Read more about avoiding issues with Hidden Facts
Planning for TextBlock Tagging
The anticipated timeline for the project as to when the reporting company will go in and carry out a preliminary TextBlock tagging of their notes will be determined by when they intend to submit for a preliminary audit. In most cases this is carried out some time during fall. This is important because at present, changes in the text content and layout could result in TextBlock tagging to have to be carried out again. This is primarily to avoid having to redo this more than necessary.
Once the preliminary audit has been carried out, we do not recommend that a substantial amount of TextBlock tagging is carried out as it seems that the content and layout are likely to change quite a lot during this time.
The final TextBlock tagging should be done once the layout of the document has been finalised and as much as possible of the content is locked as well.
The advice above is mostly relevant to the TextBlock tagging which has not been done with the CtrlPrint Frames functionality. It also does not apply to the tagging of the primary financial statements. Both of these types of tagging are less likely to be affected by changes to content and layout changes.
CtrlPrint Frames Setup
CtrlPrint Frames is a layer in the Tagger which allows users to TextBlock tag the content of one, or multiple threaded InDesign Stories (text frames). The intended use of these is to allow users to TextBlock tag whole notes and avoid doing it repeatedly.
This functionality is related to the InDesign text frames, and as such, their location is easier to convert to XHTML from a PDF, so this type of tagging is less likely to be affected by content changes. However, it can be affected if the layout changes drastically and new InDesign text frames are inserted in the middle of the sequence.
You should discuss how the reporting company wants their text frames threaded and their intended use for CtrlPrint Frames.
Prepare Your Documents for Text block Tagging with CtrlPrint Frames
Layers in InDesign
The text content in a Layer in InDesign needs to be sorted in the same way the reading order is displayed on the page/spread.
Avoiding issues that can be caused by InDesign
InDesign is used to create a PDF which is then converted to the XHTML format when the document is opened in the CtrlPrint Tagger. The XHTML document is where the tags can be applied. Actions taken in InDesign can have consequences for how the document is converted and should therefore be avoided. The recommendations below are general and there could be other things that impact this conversion and as they are discovered. It is important to note, that significant changes to the layout of the document such as adding or deleting pages, or moving content location on a page, will most likely have an impact on the TextBlock tagging in the document.
Layout Related Issues
- It is important to make sure there are no overlapping text frames in the InDesign document. This will cause an issue when using the CtrlPrint Frames functionality called “Nested Continuations” and is an error that must be rectified to submit a valid report. Read more about Nested Continuations
- Make sure to use the table functionality to make proper tables rather than using tabs and custom spaces.
- Leaving blank spaces in tables where numbers should be make it harder for the XHTML to be parsed correctly so we strongly recommend using dummy numbers until the real ones have been entered into the report.
- Colour transparency on coloured objects such as a rectangle that has text in it does not translate to XHTML. This can be resolved by using the correct colour for the desired visual and then placing the coloured element behind the text.
To ensure accurate tagging, careful consideration and planning are necessary when implementing columns in landscape-oriented reports. Testing indicates that using one text frame on the page and the native functionality for columns within the frame will have more consistent results for selecting text.
How to Use the CtrlPrint ESEF Best Practices
For you to get the most out of our ESEF Best Practices, we have recorded this introduction to help you navigate through the content.
Watch tutorialWritten step-by-step instructions
Test your knowledge
We want to ensure you have the best learning experience possible. That's why we've designed this quiz to help you solidify your new knowledge. Please answer these questions to confirm that you've gained the most critical insights from this trail.
Start the quiz