Add indentation to listnode elements to compensate for margin-left in list elements

[AyUsH18102001]

Problem Statement

For consecutive lists (ol/ul) which have no relation to each other i.e. nesting, is visually shown as nested lists in html or word like html using margin-left attribute

So currently since we ignore the margin-left from lists, this indented html lists arent reflected in OXML conversion

Resolution

Consider the margin-left value from lists and add it to the listnodes level calculated indentation

Example

<ol type="a">
       <li>
           <p>Rating</p>
       </li>
   </ol>
 <ol style="list-style-type: disc; margin-left: 18pt;">
     <li>
         <p>Collateral</p>
         <p>(this must be explored)</p>
     </li>
     <li><span>Financials</span></li>
     <li><span>Templates</span></li>
 </ol>

[AyUsH18102001]

Hello @onizet

This change overpowers the indentation in abstractNum/level instance in numebring.xml, so even though we maintain the NumerbingProperties as we should, just we are extending the indentation to compensate for the margin-left on the list element

[onizet]

Hello, are you looking for nested lists?

[AyUsH18102001]

Hello @onizet

The lists are siblings to each other, they aren't nested, it's just visually the curated html creates this illusion of nested lists using margin left on second list

[AyUsH18102001]

Hello @onizet

From yesterdays proposed changes I observed that the generated document with list paragraphs overpowering the indentatin to lists might not be the best approach, Although it had the numPr on these paragraphs, the user then cannot change the indentation i.e. move the list through ruler, and this change affected the other lists which shared the same abstractNum instance

So the new proposed change is that we calculate the new indentation i.e. (List Level Indentation + List Margin Left) and add it to the levelOverride in NumeringInstance i.e.

<w:num w:numId="2">
  <w:abstractNumId w:val="0"/>  
  <w:lvlOverride w:ilvl="0">
    <w:startOverride w:val="1"/>
    <w:lvl w:ilvl="0">
      <w:pPr>
        <w:ind w:left="1080" w:hanging="360"/> // override the list indentation with 1080 left value
      </w:pPr>
    </w:lvl>
  </w:lvlOverride>
</w:num>

And keep the list paragarph properties free from the responsibility of list indentation

Also, ontinuation paragraphs inside listnode may still use paragraph indent for alignment

[AyUsH18102001]

Also as a side note, we can then extend this implementation to retain the list marker styling into OXML i.e. font-size, font-color and font-weight into lvlOverride run properties, which is missing from the current list interpretation

[onizet]

Looking at the code, there is no call to the base.Interpret() method. That means, the indentation will never be set prior to this class instance, and thus, there is no need to parse. You can just use a class member to hold the left indentation value.
So removing this whole method and inlining its body

[onizet]

Revert to original code and just add the + indentationOffset

[AyUsH18102001]

In the original snippet, it overrides the indentation left (current level indentation) and any margin-left in the second paragraph in listnode is not considered

<li style="font-size: 6pt; line-height: 115%; color: #4ea72e; font-family: Verdana, sans-serif">
    <p style="font-size: 11pt; line-height: normal; color: #000000">Hello World</p>
    <p style="font-size: 11pt; line-height: normal; color: red; margin-left:22pt">Indented Listnode Paragraph Test</p>
</li>

hence if we invoke SetListItemElementParagraphIndentationLeft() and pass the appropriate args such level, leftIndentationOffset and current p.Properties instance, it will set the indentation with paragraph self indentation + list level indentation

[onizet]

Promote listMarginLeft to a class variable and rename to : indentationOffset
Now, you don't need to pass that offset in helper method, it's just part of this class.
You miss an indentation computation in relation with the nested table TableIndentation.

[AyUsH18102001]

Hello @onizet

comments resovled

[onizet]

Also as a side note, we can then extend this implementation to retain the list marker styling into OXML i.e. font-size, font-color and font-weight into lvlOverride run properties, which is missing from the current list interpretation

This is very interesting finding as I never deal with that override. When I reviewed your PR, I realise that the run inside the list do not respect any particular styling such as color, font size etc...
You just share hints where to start looking at. Thank you, I will create a work item for follow-up

[AyUsH18102001]

Hello @onizet

Thanks for your review, yes I'll share with you the fix for the above created workitem #252