Repository navigation
Conversation
|
Hello, very nice finding for the frame creation. It's always annoying to generate a corrupted file as this breaks confidence in this library. About the shading cascading issue. This library follows the "Interpreter" design pattern, in which ParsingContext stores global information required during interpretation, such as variables, data structures, or state information. That's why I don't like a second "context" class such as StyleCascade. Thank you for this PR, this counts a lot for me as an open-source maintainer. |
|
Hello, I added StyleCascade so that later we could control any other inherited properties. I’ll drop StyleCascade, keep InsideTable on the context, and remove run shading there Thanks, |
|
Hello @onizet Just wanted to follow up, its been about a week, let me know if there is any other changes you want from my side Thanks |
|
Hello, yes I left a comment during the review. Please see this link: https://github.com/onizet/html2openxml/pull/241/changes/BASE..2ccef12d3da23f6642d182917ec9aa7cc7982b27#r4062204747 |
|
Hello @onizet I didn't find any other comments apart from sonarcube flag comments |
|
Ok but now that you see my comment, will you address it? ParsingContext should be agnostic of the discovered nodes. The logic for the table must remains ownership of TableExpression only. It's just about moving your code to the most appropriate location. |
…ic i.e. no OOXML node based styling
…es cascading on table elements
|
Hello @onizet , Changes:
Thanks |
|
hello, I was thinking about this issue and my understanding of what people would like is that What do you think of this simpler solution? Just replacing this method ParsingContext.CreateChild: public ParsingContext CreateChild(HtmlElementExpression expression, bool isStyleScoped = false)
{
var childContext = new ParsingContext(Converter, HostingPart, ImageLoader) {
propertyBag = propertyBag,
parentExpression = expression,
parentContext = isStyleScoped? null : this,
IsLandscape = IsLandscape
};
return childContext;
}Now, the only code needed sits in TableExpression: |
|
Hello @onizet So
yes, the CascadeToParentContext() method explicitly removes the shading from run elements, by your fix we would skip all the styles added by parent div tags cause |
|
Hello, So, let me know how can we cherry pick, will wait for your response after you merge your change in dev branch |
|
I didn't created any new branch, just testing locally with no commit, but that passes all my unit tests. So happy for you to proceed with that simpler solution. Thank you! |
|
Hello, Great, so I'll keep the CreateFrame() change (BlockElementExpression.cs) and add your borrow your suggestion and keep the tests just to make sure the shading rule on table is satisfied |
|
Hello @onizet Sorry for the delay, please review thelatest changes Thanks |
|
|
Very good, thank you so much for your valuable contribution. |




Problem Statement:
The html content provided is from TinyMCE editor, this content is referenced from Word/Outlook like source, hence we have this white background parent/wrapper divs for the copied content
the table run elements inherit the shading value of "#fff", this is due to the cascading of parent styles onto childrens
This behaviour is not what we desire in and its also stated in TableExpressionBase ComposeStyles method i.e.
Proposal:
During cascading of styles i.e. parent and childeren we explicitly propoagte this idea that table elements (runs) Shading must not be initialized
Introduce struct StylesCascade to keep in check of such cascading rules
PS. Also fixed the CreateFrame method to ensure all table cell elements <w:tc/> have Paragrsphs (<w:p/>) as the last child element, we encountered corruped xml for the above mentioned html