Get precise font information from Sdt control properties

Aspose.Words Product Family
1

Hi


I have a document in which the OOXML below is found.

The Sdt element has a run property attached (w:rPr) in which both the style, bold and size is set.

<w:sdt>
<w:sdtPr>
<w:rPr>
<w:rStyle w:val=“FormFooter”/>
<w:b w:val=“0”/>
<w:sz w:val=“10”/>
<w:szCs w:val=“10”/>
</w:rPr>
<w:tag w:val=“FormTemplateReference”/>
<w:id w:val="-109899966"/>
<w:lock w:val=“sdtContentLocked”/>
<w:showingPlcHdr/>
<w:text/>
</w:sdtPr>
<w:sdtEndPr>
<w:rPr>
<w:rStyle w:val=“DefaultParagraphFont”/>
<w:rFonts w:ascii=“Arial” w:hAnsi=“Arial”/>
<w:b/>
<w:color w:val=“auto”/>
<w:lang w:val=“en-US”/>
</w:rPr>
</w:sdtEndPr>
<w:sdtContent>
<w:r w:rsidRPr=“00554EB2”>
<w:rPr>
<w:rStyle w:val=“PlaceholderText”/>
<w:rFonts w:ascii=“Verdana” w:hAnsi=“Verdana”/>
<w:b/>
<w:sz w:val=“10”/>
<w:szCs w:val=“10”/>
<w:lang w:val=“en-US”/>
</w:rPr>
<w:t>[Reference]</w:t>
</w:r>
</w:sdtContent>
</w:sdt>

And when I use the following code to get the font of the Sdt it returns the correct size.

var testFontSize = sdtControl.ContentsFont.Size; //The font size is 5 (half of w:sz = 10)

The problem comes when I have a SdtControl in which the font size is not explicitly set like this:

<w:sdt>
<w:sdtPr>
<w:rPr>
<w:rStyle w:val=“FormTextHeaderSub”/>
</w:rPr>
<w:tag w:val=“FormApproverUpdateUserTitle1”/>
<w:id w:val=“1608234946”/>
<w:lock w:val=“contentLocked”/>
<w:placeholder>
<w:docPart w:val=“E9D80B75078B42DFA02F0573C2396EA8”/>
</w:placeholder>
<w:showingPlcHdr/>
<w:text/>
</w:sdtPr>

When I ask this SdtControl for the Font size, it goes through the inheritance rules for Fonts (i guess) and returns Font size 10 pt.

This means that to do what Word does, namely use the explicit font if set, or use all settings from Style if font size is not explicitly set I need a way to differentiate the two.

Are there anyway in Aspose I can see on a Font object whether or not the size is inherited or do I need to go through the Open XML my self to figure it out? (or any other way to end up with the same result as Word does. In the last example the text ends up being 5 pt due to that font in the style, not 10 pt as the sdtControl.ContentsFont in Aspose returns)

Let me know if I need to explain anything furher.

(Edit - I have attached a file showing the situation)

Best regards
/Anders



(For personal reference once fixed : CP 176492)
2

Hi Rasmus,

Thanks for your inquiry.

Please note that formatting is
applied on a few different levels. For example, let’s consider
formatting of simple text. Text in documents is represented by Run
element and a Run can only be a child of a Paragraph. You can apply
formatting 1) to Run nodes by using Character Styles e.g. a Glyph Style, 2) to the parent of those Run nodes i.e. a Paragraph node (possibly via paragraph Styles) and 3) you can also apply direct formatting to Run nodes by using Run attributes (Font). In this case the Run will inherit formatting of Paragraph Style, a Glyph Style and then direct formatting.

A useful thing to note about the Aspose.Words’ API is
that querying direct formatting (Run.Font, Paragraph.ParagraphFormat) will normally return the “calculated”
formatting value based on all direct formatting, styles and document
defaults etc. Therefore, using the direct formatting properties are the
best way to find the visible formatting of the content.

Please use the Run.Font property to get the direct formatting (font formatting) of Run nodes inside content control.

Hope this answers your query. Please let us know if you have any more queries.

3

Hi Tahir


It doesn’t answer my question at all. :slight_smile:

I am aware that the Font property returns the calculated Font.

The problem in my case is that the object I am querying, namely a Sdt controls ContentsFont should reeturn the explicitly set values - not inherited. And I need to know if nothing is set explicitliy.

So what I need is the exact value from the Run properties under the Sdt Control - using a calculated value in this case is wrong, since it is “template” information. The properties needs to be copied to the actual run when inserting text.

So my query to you was if there are any way in Aspose to get the explicit Font information - not the calculated ones. Else I think I have to load the document as OpenXml besides Aspose to figure this out.

Best regards
/Anders
4

Hi Anders,

Thanks for your inquiry.

licenselogimatic:

The problem in my case is that the object I am querying, namely a Sdt controls ContentsFont should reeturn the explicitly set values - not inherited. And I need to know if nothing is set explicitliy.

StructuredDocumentTag.ContentsFont property returns font formatting that will be applied to text entered into SDT. If you want to get the explicitly set values, please use Run.Font property.
licenselogimatic:

So what I need is the exact value from the Run properties under the Sdt Control
So my query to you was if there are any way in Aspose to get the explicit Font information - not the calculated ones.

To get the explicit Font information, please use Run.Font property. Please insert some text inside the contents control and check the font size using following code example.


Document doc = new Document(MyDir + "SdtTagFontSize.docx");

foreach (StructuredDocumentTag sdt in doc.GetChildNodes(NodeType.StructuredDocumentTag, true))

{

foreach (Run run in sdt.GetChildNodes(NodeType.Run, true))

{

MessageBox.Show(run.Text + " " + run.Font.Size.ToString());

}

}

Hope this answers your query. Please let us know if you have any more queries.

5

Hi, I have updated the attached document - it seemed like the placeholder text wasn’t showing for FirstSdt.


What I want to achieve is, that when Aspose inserts text into the Sdt controls, the visual result should be that same as in Word. Currently I can’t seem to make that happen. The first run in Sdt Control have properties from the placeholder text - which is incorrect to use, both due to font, color and size.

So to recap (font size only, other font properties has same behavior):
FirstSdt :
* Placeholder text font size is 11pt
* Style is set on Sdt control to Title, font size 28 pt
* But text, if you enter in Word becomes 8 pt since Font size is set explicitly on the Sdt Control (as well as style)

SecondSdt:
* Placeholder text font size is 11 pt
* Style is set on Sdt Control to Title, font size 28 pt
* Text entered in Word becomes 28 pt - inherited from style.

If I use what you propose above i get the following results:
FirstSdt:
firstRun.Font.Size = 11 pt (This is the placeholder text’s size)
sdt.ContentsFont.Size = 8 pt (This is the one I should end up with)
sdt.ContentsFont.Style.Font.Size = 28 pt (The size of the Title style)

SecondSdt:
firstRun.Font.Size = 11 pt (This is the placeholders text’s size)
sdt.ContentsFont.Size = 10 pt ( inherit from I don’t know where)
sdt.ContentsFont.Style.Font.Size = 28 pt (this is the one I should end up with )

What I lack is something in Aspose that can help me determine which one is correct to use. There is nowhere in Aspose (i have found) that can tell me whether I should use the ContentFont.Size or ContentsFont.Style.Size.

But in both cases the Run.Font is wrong - since this will take the font property of the placeholder text.

And yes, the reason is that we don’t control the input document, and have source documents that has the above settings.

I’m not sure that I can explain it better. Try to open the document manually and enter in text in the Sdt’s and you can see the fonts Word chooses. Try to run your code and see if you can find any code that deterministic can tell that for FirstSdt font size should be 8, and for SecondSdt font size should be 28.

I hope you understand what I mean, and what the purpose is.

If i’m unclear let me know and I will try to rephrase.

Best regards
/Anders
6

Hi Anders,

Thanks for your inquiry.

licenselogimatic:

FirstSdt:
firstRun.Font.Size = 11 pt (This is the placeholder text’s size)
sdt.ContentsFont.Size = 8 pt (This is the one I should end up with)
sdt.ContentsFont.Style.Font.Size = 28 pt (The size of the Title style)
SecondSdt:
firstRun.Font.Size = 11 pt (This is the placeholders text’s size)
sdt.ContentsFont.Size = 10 pt ( inherit from I don’t know where)
sdt.ContentsFont.Style.Font.Size = 28 pt (this is the one I should end up with )

I have tested the scenario and have found the ContentsFont.Size return incorrect font size for second content control. For the sake of correction, I have logged this problem in our issue tracking system as WORDSNET-10164. I have linked this forum thread to the same issue and you will be notified via this forum thread once this issue is resolved. We apologize for your inconvenience.
licenselogimatic:

What I lack is something in Aspose that can help me determine which one is correct to use. There is nowhere in Aspose (i have found) that can tell me whether I should use the ContentFont.Size or ContentsFont.Style.Size.

If direct formatting is not applied to content control, you can use ContentsFont.Style.Size. Please compare the Run.Font.Size and ContentsFont.Style.Size to check either direct formatting is applied to content control or not. If direct formatting is applied to content control, please use Run.Font.Size.
licenselogimatic:

But in both cases the Run.Font is wrong - since this will take the font property of the placeholder text.

The Run.Font.Size is correct. Please check the Font of text ‘Click here to enter text’. It is ‘Placeholder Text’ which is based on ‘Default Paragraph font’ and its font size is 11.

Please open your document and move the cursor to the end of document. Clear the formatting and insert new content control. The font size of new content control is 11. Please check the attached image for detail.
7

Hi Tahir


If just the ContentsFont.Size in the second example would return “nothing” I would be happy. Then I could programmatically distinct the two scenarios. Whether “nothing” is 0 or null doesn’t really matter to me. Or take it from the applied Style’s Font size.

But the point is that in the second case, there is no additional information about font size, other than the style applied, and thus I shouldn’t explicit mess with the size.

When i wrote “In both cases the Run.Font is wrong” - I meant “In both cases using the Run.Font is wrong” - because that is the font and style of the placeholder text - which in Word is ignored when you start entering text.

I will wait for an answer to the issue until we do further - and for now my users must just suffice with the generated documents being different to what Word does. At least we have a workaround by fixing the source document so the three different Fonts in play are identical.

Thanks for your reply.
/Anders
8

Hi Anders,

Thanks for your inquiry.

licenselogimatic:

If just the ContentsFont.Size in the second example would return “nothing” I would be happy. Then I could programmatically distinct the two scenarios. Whether “nothing” is 0 or null doesn’t really matter to me. Or take it from the applied Style’s Font size.

The StructuredDocumentTag.ContentsFont property return the font formatting that will be applied to text entered into SDT. This property would not return “nothing” or “null” value.
licenselogimatic:

When i wrote “In both cases the Run.Font is wrong” - I meant “In both cases using the Run.Font is wrong” - because that is the font and style of the placeholder text - which in Word is ignored when you start entering text.

When you write the text inside content control, you can insert the text using 1) Run node, 2) DocumentBuilder.write method. In both cases you need to set the font size. In your case, the ContentsFont.Size return incorrect value which is a bug. You can use ContentsFont.Size value to set Run.Font.Size value or DocumentBuilder.Font.Size value. After the fix of this bug, you can insert the text inside content control according to font size of content control using ContentsFont.Size.
licenselogimatic:

I will wait for an answer to the issue until we do further - and for now my users must just suffice with the generated documents being different to what Word does. At least we have a workaround by fixing the source document so the three different Fonts in play are identical.

Unfortunately, there is no workaround available for this issue. we will update you via this forum thread once this issue is resolved.

We apologize for your inconvenience.