DYN-3652 docs browser Artifakt font fails if not installed

[dnenov]

Purpose

This PR addresses DYN-3652 issue: docs browser font fails to load on machines without Artifakt installed already.
Solition: Embedded Artifakt Element as base64

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated

Release Notes

• to ensure the DocumentationBrowser always loads with the correct font, the Artifakt Element font is now included in the css style sheet as base64

Reviewers

@reddyashish
@mjkkirschner

FYIs

@Amoursol

[mjkkirschner]

so I have bad news!

according to @RobertGlobant20 - webView2 currently has a 2 - 3 meg limit when loading html using navigateToString - I think sticking the entire font into the css is not the ideal given this new limitation... (web browser control did not have this).

@RobertGlobant20 can you suggest an approach using the virtual host names so the font can be referenced from disk without embedding?

[RobertGlobant20]

so I have bad news!

according to @RobertGlobant20 - webView2 currently has a 2 - 3 meg limit when loading html using navigateToString - I think sticking the entire font into the css is not the ideal given this new limitation... (web browser control did not have this).

@RobertGlobant20 can you suggest an approach using the virtual host names so the font can be referenced from disk without embedding?

@mjkkirschner well, I'm not completely sure if this case is related to the WebView2.NavigateToString() limit, I will need to reproduce the problem in Dynamo and check if the problem is the html limit.
I can see that the problem is happening in DynamoRevit when seeing the documentation for the Orchid nodes.
Then I guess I need to install the Orchid package (using PackageManager) and see the documentation for any node, am I right?
Thanks

[dnenov]

so I have bad news!

according to @RobertGlobant20 - webView2 currently has a 2 - 3 meg limit when loading html using navigateToString - I think sticking the entire font into the css is not the ideal given this new limitation... (web browser control did not have this).

@RobertGlobant20 can you suggest an approach using the virtual host names so the font can be referenced from disk without embedding?

Should I be doing something on my end to try to resolve the issue? I took this approach as it was a more straightforward solution to the problem at hand, but I could try loading the font that dynamo ships with, the same way we do for WPF.

[mjkkirschner]

yes, I don't think you should be embedding the font.

How critical that is depends on how large it is when base64 encoded.

[dnenov]

We have been chatting with @RobertGlobant20 today and I understood where the 2 MB limitation will come into play. I tried adding the font into the fallback directory and referencing it as 'http://appassets/[FONT_LOCATION]' but that didn't work out.
Regardless, the base64 font string is 74 KB, just to keep that in mind in case creating additional virtual folders adds too much complexity.

[dnenov]

I have now refactored the code to be using a similar structure and ways to process the font as done in the user guide, however it should be known that in essence, the HTML string which processed still contains a base64 version of the font. The difference is that, instead of being hard-coded inside the css part of the MardownStyling.html, at run time, the font (as embedded resource) is dynamically converted to base64 and swapped in the HTML file.

I believe there is a (security) limitation to serving fonts from a file location unless they are installed.

[dnenov]

Hi @mjkkirschner and @RobertGlobant20 - I have asked @sm6srw to merge this PR unless you have any outstanding issues.

[RobertGlobant20]

Hi @mjkkirschner and @RobertGlobant20 - I have asked @sm6srw to merge this PR unless you have any outstanding issues.

Looks Good to Me

[dnenov]

Hi @mjkkirschner and @RobertGlobant20 - I have asked @sm6srw to merge this PR unless you have any outstanding issues.

Looks Good to Me

Thank you, @RobertGlobant20 !

[sm6srw]

@dnenov Looks like there are two failing tests that you need to take a look at:
DynamoCoreWpfTests.DocumentationBrowserViewExtensionContentTests.CheckThatEmbeddedHtmlContentDoesNotSanitize("D:\jenkins\workspace\Dynamo\DynamoSelfServe\pullRequestValidation\Dynamo\src\DocumentationBrowserViewExtension\Docs\MarkdownStyling.html")
DynamoCoreWpfTests.DocumentationBrowserViewExtensionTests.CanCreateNodeDocumenationHtmlFromNodeAnnotationEventArgsWithPackageNodeWithAddtionalDocumentation

[sm6srw]

All tests passed here: https://master-5.jenkins.autodesk.com/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/8303/

[sm6srw]

I will go ahead and merge this.