Is it possible to add a Table of Contents field to a SQL Reporting Services 2005 report given that the report is generated using the Aspose.Words libraries? If so, how is this accomplished?
The assumption is that the only output format generated for this particular report will be .DOC.
Hi,
Thank you for your inquiry. I actually thought about implementing such a capability. One thing to clarify, do you wish the TOC to be inserted at an arbitrary point in the document or simply at the very beginning?
If possible, it would be at an arbitrary point in the report.
This will provide the most flexibility for different document requirements.
Thanks for the quick response.
Okay, then I’m going to think on how to implement that. I suppose it could be a special tag such as placed within a textbox that would be replaced with a TOC field in the resulting document. Do you think this is a good idea?
There’s probably a bit more to it as for the TOC to work you also need to have the heading styles defined. If you’re after my opinion…
Taking the placeholder idea at it’s simplest using an XML style of tagging:
\o "1-3" \h \z \u - This would translate to {TOC \o "1-3" \h \z \u}
\o "1-4" \h \z \u - This would translate to {TOC \o "1-4" \h \z \u}
Heading 1 Text
- This would print ‘Heading 1 Text’ with a style of Heading 1
Heading 2 Text
- This would print ‘Heading 2 Text’ with a style of Heading 2 etc…
Would probably be worth supporting up to five or six headings…
That would satisfy the base case and is probably not a bad way to start.
If there is an attribute that is not used by the existing Reporting Services plugin that can be set (eg. TextBox.Label or TextBox.ValueLocID), this would be preferable to a tag as the text would look cleaner in preview mode and is probably easier to code as you don’t need to parse the text.
It would be good if the styling (font etc) defined for the textbox is carried through to the Heading text. I think if you set the Style first, and then set the other Font customisations it should work.
Food for thought 
What do you think?
Sounds great, but are headings required in your particular case? The point is that you can specify the Label property for report items you wish to make the TOC “points”. Labels are then converted to the TC fields whose values will comprise the TOC.
If using labels is not suitable, then yes, we need to apply heading styles to appropriate items.
The only reason for headings is to specify the levels (indentation) of different pieces of text.
My understanding is the TOC in Word can be generated from:
- Headings: e.g.
{TOC \o "1-3" \h \z \u} - Styles: e.g.
{TOC \t "Style1,1,Style2,2" \h \z \u} - Levels e.g.
{TOC \l "1-3" \h \z \u}
So it might better to use levels as this doesn’t impact the Style.
So as an example:
If I set TextBox.Label to TOC and the Value to 3, this will render the text {TOC \l "1-3" \h \z \u}
If I set TextBox.Label to L1 and the Value to “Main Heading” this will render the text “Main Heading” and mark it as Level 1.
If I set TextBox.Label to L2 and the Value to “Sub Heading” this will render the text “Sub Heading” and mark it as Level 2.
If I set TextBox.Label to L1 and the Value to “Next Main Heading” this will render the text “Next Main Heading” and mark it as Level 1.
The resulting TOC tree would look like:
- Main Heading
- Sub Heading
- Next Main Heading
Is that what you were thinking?
Yes, almost, a little correction is that the level is set automatically depending on the nesting level of the report item. For instance, an item contained directly in report’s body will have the level 0, its children will have the level 1 etc. If this satisifies you, then all we have to add is TOC itself; otherwise we’ll have to stick with the headings approach.
I am aware that you can nest sub-reports.
Can you nest textboxes in that way? e.g. I have two textboxes…
‘textbox1’ has a value of “Heading 1”
‘textbox2’ has a value of “Heading 1.1”
How do I specify that ‘textbox2’ is a child of ‘textbox1’?
How will you distinguish heading text from normal text?
I think we’re almost there…
Well, textboxes themselves cannot be nested, but you can use the Rectangle report item to construct the hierarchy. If you put textbox1 outside of the rectangle and textbox2 inside it, the former will be of level 0 and the latter will be of level 1.
Why would there be the need to distinguish headings if you specify the labels?
From a user perspective, I believe it would be simpler to use the Label property to adjust the levels.
The report designer could get fairly messy drawing rectangles around all the text.
I agree that as long as the label property is set, that will distinguish the heading text from the normal text. What value would you put in the labels to denote that it is a Heading (and/or the different levels) and not normal text?
You should only put a TOC entry there, i.e. the text you wish to appear on the TOC. The level is determined automatically based on the nesting of the item. That’s why rectangles are required additionally to the lables approach.
Labels are then converted to the TC fields that denote TOC entries. So you are not limitied to headings to designate TOC entries. Any text may be marked with a TC field.
I agree that using rectangles only to specify the level may end up with messy design. So maybe using headings is more acceptable indeed.
I’m actually thinking of the possibility to specify any arbitrary Word style when designing report. The awkward part of this idea is that it cannot be previewed in the designer. Instead, the user will have to deal with tags within the text which is not good visually.
I think it would be fairly safe to assume that users would only use the word-specific functionality if they were outputting directly to a Word format e.g. Word styles, TOC
Have you considered using the Label property to specify an arbitrary word style? e.g. Heading 1, Strong, Quote etc This can then be used for the TOC text as well as other styles and will still look good in preview mode (no tags in the text) and clean in the designer (no rectangles). The exception to this would be setting the Label value to TOC which would render the TOC merge field based on the textbox value e.g. {TOC \o "1-3" \h \z \u}.
Would it be possible to implement this feature? Very keen to test it out.
That said, I’m not certain of the value for the Styles (other than Heading 1, 2, 3 etc) as the formatting of the text will be specified in the report designer. One benefit would be that it would make updating the text formatting easier after the document is produced but in most cases, you would update the original report template anyway. Your thoughts?
I’ve been thinking on this possibility, having in mind styles are something SSRS lacks. Specifying a style as a rarely used property value is not quite convenient but probably the best we can do.
Okay, at least it is easy to implement. However, I’m currently working on Aspose.Words for Reporting Services 3.0 and therefore planning to attend the styles feature in a couple of weeks. Is this timeline acceptable for you?
The timeline sounds reasonable to me. The sooner the better but obviously you have your own development work to manage
Good to hear you are working on the next version of the plugin.
Is there any documentation on new features or a release timetable for the new version?
If it works out, would the TOC/Styles feature be released with v3? or as a separate minor release for v2?
Well, the most noticeable changes to come are:
- Full support for SSRS 2008 final
- Improved balance between appearance and editability of exported documents
- Optimized positioning of report items when exporting in flow layout
- Bugfixes
As to the TOC/Styles feature - well, I’m not sure whether it will be included in v3.0, but anyway you’ll get it very soon (in case the idea is as easy to implement as I imagine :).
Dmitry,
How is this enhancement going? I am very keen to test the functionality out as it will reduce alot of the post-processing effort required to add a TOC to the Word document produced.
Hi,
Please expect this feature to test next week.
Thanks.
Dmitry, is this feature ready to test?
Sorry for delay and thank you for your patience. I’m working on it right at the moment. Please expect the dll within 1-2 days.