Template styles and HTML fragments

0
james posted this 16 January 2018

I'm doing an evaluation of Docentric and hope someone can answer a (hopefully) quick question for me. In my use of this tool, I'd often need to pull in HTML fragments from a database. Using the Subdocument element, I've already created a sample template that pulls in the content just fine. The problem I run into is with the styling of the inserted content. The fragments are unstyled markup (usually nothing inline), but when inserted into the Word template, the content doesn't reflect the styles of the template. For instance, the Normal style is Calibri 11, but the inserted content shows up as Times New Roman 12. In the Style Explorer, the inserted content shows as having the Normal style, but it's clearly not the template's Normal style.

Is there something I'm missing in configuring the Subdocument element? There aren't many options (and unfortunately the Visual Format property doesn't include options for fonts and size), and when I select the Subdocument placeholder in the template, it does show as having Calibri 11 font. How can I get the unstyled HTML fragment to use the template style (without re-editing the generated document, of course)? If this can be addressed, I think that this might be a perfect tool for at least one upcoming project at my company.

Thanks in advance for any information, tips or suggestions. My apologies if this question has been asked before and I just didn't see it.

3 Posts
3 Points
5 Comments
Order By: Standard | Newest | Votes
0
jles posted this 23 January 2018

Thank you for the positive feedback, I really appreciate it. Just let us know when you will need help again.

Kind regards, Jure

154 Posts
294 Points
0
james posted this 23 January 2018

Thanks for the offer, Jure, but I don't think I need to see 6.0RC. Just knowing that particular issue with the font names has been addresses is sufficient for my needs right now.

Also, it is really gratifying to know how responsive your company is to questions, and that new features and fixes are constantly being added to your product. That will definitely figure into my analysis. (Actually, I had done an eval on Docentric a couple years back; I saw the potential in it then, and it's neat to see what's changed and improved since.)

3 Posts
3 Points
0
jles posted this 18 January 2018

James,

It sounds like you made it work. Yes, I completely agree, this is definitely a "low tech" solution to the problem that should be solved out-of-the-box by Docentric Toolkit. And this is on our TODO list but cannot be solved immediately due to the way the engine currently works. In one of the future versions we will add a flag that will enable you to choose whether to leave default styles or to use User Agent CSS.

As far as I know, we have already fixed the problem with multi-font-name entries in font-family style properties. This fix should be part of the version 6.0 (release candidate, stable). If you would like to try it, send us an email to support at documentric.com and we will send the download link.

Best regards, Jure

154 Posts
294 Points
0
james posted this 17 January 2018

Hi Jure,

Thanks for the response; the information and suggestions have been most helpful. What you describe makes complete sense; I've seen a similar issue with other projects I've had to help on.

Obviously, the best solution would be for the inserted document or fragment to pick up the styles of the parent document. The second best solution would be your second bullet, exposing a property that could take user-defined CSS. Extracting a CSS version of a document's styles is not difficult, so if you had a property that could programmatically accept a file path or CSS string, that, I think, would work really well.

Since that might be a feature in an unspecified future version, I tried the suggestion of your first bullet. I had to clean up the CSS* extracted from my parent template (as would be the case even if a property was exposed and being used), but with the style prepended to the HTML fragment, the generated document elements looked as good as one could hope. Sure, it's kind of a "low-tech" way of getting the desired result, but it's still progress. Thanks for the suggestion.

I still have a bit more testing and evaluation to do, but things seem really promising for what needs to be done. Thanks for your help.

* The big thing that needed to be cleaned up was the font-family properties. Word will export the property with typical cascaded values, e.g., "Calibri, Arial, sans-serif." When that property gets picked up and applied to the fragment, the resulting style has "Calibri, Arial, sans-serif" as if it were the name of the font. Once I set the font-family properties to be just "Calibri," the inserted fragment looked correct.

3 Posts
3 Points
0
jles posted this 17 January 2018

Hi James,

Thank you for posting a question on our forum. The problem you are describing is because of how our engine works. Insertion of an HTML fragment currently works without the target template document. The engine performs a conversion of an HTML fragment into a Word document and then injects the converted document into the target template document. The main problem here is the fact that all MS Word converted elements use inline styles which are calculated based on the CSS style resolution rules.

So, even though there is no explicit, e.g. font size, defined on a 'p' element, the corresponding MS Word paragraph will still have an inline font size value because the engine has got it from the User Agent default CSS. This works in exactly the same way as browsers work. But I completely agree with you that this is not the best or the the most proper way of solving CSS styles.

There are two options:

  • Add a <style> element to your HTML fragment that contain styles that matches format values of default character and paragraph styles in the template document. The downside of this approach would be that you need to know the default styles of your template in advance. But you can fix this by using DOM and reading these values and composing such a <style> dynamically.
  • We already have a default User Agent CSS embedded in our assembly. We could expose a property where you could provide your own User Agent CSS. This would basically be the same solution as the one above, except you don't have to merge styles into an HTML fragment. Currently, such property is not available and we would need to add it.

Let me know if the solution described above would work for you.

Thanks, Jure

154 Posts
294 Points

Our 225991 members have posted 342 times in 101 discussions