markdown document preview improvements

[haidubogdan]

This PR proposes some hard coded styling improvements for markdown preview renderer.
Swing html renderer has a lot of Css limitations, so future improvements could look at using other html java renderers

Before:

After:

---

Closes #6652

• hardcoded swing html renderer compatible css styling
• custom <hr> tag renderer
• strikethrough flexmark extension preparation
• update vscode regex for striketrhough detection

Know limitations

• strikethrough element parser requires binary extension from flexmark
• <code> don't apply padding

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[mbien]

only took a quick look at the output of some readme files and I think it looks better. Will need some tweaks for the dark theme since the background renders as white atm etc.

[Chris2011]

We already talked about "customization" and it is fine to make it hard coded, but can't we do it direclty inside a css file. it is still hard coded but I can change this, if i want in the settings. So my idea is to add the css to the css file and read it from there.

[haidubogdan]

We already talked about "customization" and it is fine to make it hard coded, but can't we do it direclty inside a css file. it is still hard coded but I can change this, if i want in the settings. So my idea is to add the css to the css file and read it from there.

I remember being a hustle to include a css resource file and after in runtime in the compiled state to read it.
@lkishalmi used this solution which seems to work.

            String configPath = "Editors/" + MarkdownDataObject.MIME_TYPE +"/FontsColors/" + profile + "/Defaults/viewer.css";
            FileObject config = FileUtil.getSystemConfigFile(configPath)

And this is my worry about this, in my personal opinion it doesn't seem to be efficient.
I would be inclined to use a static String or a bundle property value to be more adapted with how java works.

[Chris2011]

Ok, no worries, I forgot that problem. So everything seems fine :)

[haidubogdan]

: )) thanks.
Actually adding the css in a bundle property could be a good idea.
It will be better for maintaining and searching the configuration.

[Chris2011]

Bundle could be also fine, yes.

[neilcsmith-net]

Bundle would be OK for allowing platform applications to override. Not sure if any are using this. But the config file system is probably a better choice if we want to allow IDE users to override?

Also, in reference to what @mbien mentioned above, probably a light and a dark CSS file should be available, with the correct one loaded on the basis of checking for the dark theme flag?

[haidubogdan]

I think there is enough time to see where this goes :) .
I will start with a bundle property implementation and after that if I have time I can look into the darktheme auto-detect logic.

The problem with custom css upload is that Java Swing doesn't really render well css styling, so it's not really useful for users.

Maybe combining Fonts & Colors and styling content with placeholders could work to give some level of customization.

[mbien]

I can look into the darktheme auto-detect logic.

taking the editor background might be good enough or not setting it at all (-> transparent?) which would inherit it automatically from the theme / customized flatlaf properties.

[neilcsmith-net]

Better to use an isDarkLaf check similar to https://github.com/apache/netbeans/blob/master/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java#L383 which delegates to -

return UIManager.getBoolean("nb.dark.theme");

Although given how use of this pattern is growing, we could probably do with providing an API for it, probably in the adjacent Utilities class.

[mbien]

checking for dark theme would imply that it would switch between two sets of hardcoded colors or css. Which I believe would be good to avoid and simply inherit the color from somewhere else.

I am somewhat skeptical that exposing the css to the user is needed and/or useful, given that it would clash with theming if not done carefully. This started as attempt to improve the defaults which is great (defaults are important!), but the customizable css is kept being added as feature creep distracting from the original goal.

Looking through this changeset it appears that there are only a few colors needed atm - with a bit of luck they all can be derived from already existing colors in the IDE.

[neilcsmith-net]

Customization is secondary to the fact that this belongs on the system filesystem, like other similar configuration.