markdown document preview improvements by haidubogdan · Pull Request #9240 · apache/netbeans

haidubogdan · 2026-03-02T08:37:28Z

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:

Was this PR correctly labeled, did the right tests run? When did they run?
Is this PR squashed?
Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
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)

ide/libs.flexmark/nbproject/project.properties

mbien · 2026-03-02T09:02:43Z

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 · 2026-03-02T22:29:43Z

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 · 2026-03-03T08:30:29Z

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 · 2026-03-03T14:20:20Z

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

haidubogdan · 2026-03-03T14:30:23Z

: )) 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 · 2026-03-03T14:39:55Z

Bundle could be also fine, yes.

neilcsmith-net · 2026-03-03T14:42:50Z

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 · 2026-03-03T15:56:04Z

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 · 2026-03-04T11:09:59Z

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 · 2026-03-04T11:20:00Z

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 · 2026-03-04T11:42:40Z

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 · 2026-03-04T14:31:54Z

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

haidubogdan · 2026-03-04T21:02:45Z

I think I somehow nailed it.
Still need to do some cleanup of the code, but the general idea is here.
The coloring is linked to font the configs and using #6662 event listener idea the redraw is triggered on profile change.

35d4077

mbien

this looks promising IMO!

the pre-block seems to use a hardcoded value still. NB's README.md using "FlatLaf Dark" looks like:

ide/markdown/src/org/netbeans/modules/markdown/StyleUtils.java

ide/libs.flexmark/nbproject/project.properties

ide/markdown/src/org/netbeans/modules/markdown/resources/Coloring.md

ide/markdown/src/org/netbeans/modules/markdown/StyleUtils.java

ide/markdown/nbproject/project.properties

matthiasblaesing

In general I think this is a good improvement. I left a few inline comments though.

ide/markdown/src/org/netbeans/modules/markdown/MarkdownDataObject.java

ide/markdown/src/org/netbeans/modules/markdown/MarkdownViewerElement.java

ide/markdown/src/org/netbeans/modules/markdown/resources/layer.xml

ide/markdown/src/org/netbeans/modules/markdown/utils/StyleUtils.java

ide/markdown/src/org/netbeans/modules/markdown/MarkdownViewerElement.java

ide/markdown/src/org/netbeans/modules/markdown/resources/Coloring.md

ide/markdown/src/org/netbeans/modules/markdown/utils/Bundle.properties

mbien

noticed this warning while testing (used the dev build with fresh config):

WARNING [org.netbeans.modules.editor.settings.storage.ProfilesTracker]: Ignoring profile 'Earth' (Editors/text/x-markdown-nb-preview/FontsColors/Earth) in favor of 'NetBeansEarth' (Editors/FontsColors/NetBeansEarth) with the same display name.

interestingly this warning shows only up mentioning the Earth profile. (I used the default FlatLafLight and Dark themes)

ide/markdown/src/org/netbeans/modules/markdown/MarkdownViewerElement.java

matthiasblaesing · 2026-03-16T08:38:48Z

ide/markdown/src/org/netbeans/modules/markdown/utils/StyleUtils.java

+        appendColoringCssRulesFromFontConfigs(ss);
+    }
+
+    public static void addRule(StyleSheet ss, AttributeSet attributeSet, AttributeSet defaultAttributes) {


I found a problem while experimenting with this. I tried to set the headings all to a "fancy" font, so that I can recognize the change. See this preview:

The preview shows, that H1 is changed, but H2 remains the base font. That is in contrast to the configuration:

The configuration (FontAndColors.xml) indicates that H2 should inherit from H1 and in the settings this is correctly recognized (see final "Font" setting for H2).

I think the problem is that the attribute application here does not follow the inheritance tree.

Yes, the inheritance is not really working and another thing might be that the anchor link element doesn't have any styling options.
The thing is that I've never thought about styling a markdown preview. I don't know what are the end-user behavior and needs.
So, I would try to limit to these 2 feature analysis to free up time.
I think it's at a workable level so far :) .

Other possible todos:

use 14px for the inline code size (it seems there is some render issue)

decrease contrast on code background color for dark modes.

line height or padding for code text

Ok - lets keep this minimal. Please have a look here:

matthiasblaesing@8a71205

There are two different things in here:

Remove the inheritance marker. I had a prototype for inheritance, but that is even more complex and brings more questions than answers. For real inheritance you'd need to gather all AttributeSets that are chained using the default attribute and create a composite set (there is a helper in the editor settings for that).

Simplify the StyleUtils. With the current implementation addRule will be invoked for each attribute name, in effect adding the AttributeSet multiple times. I removed the iteration over the attributes as there is alreay a guard inside addRule.

haidubogdan · 2026-03-17T05:23:11Z

I thought I could "humble" Swing's Html editor but I think in the future we might need to replace html and css content rendering with something like JavaFX WebView .
I still can't make <span> elements to have padding.

For the moment at least it looks a bit more modern and there is the option to customize using Netbeans font config themes.

matthiasblaesing

Thank you very much. Seems to work nicely. Here is a before (left) and after (after) shot:

To me this looks sane.

@lkishalmi as you are active in this area, could you please also have a look?

mbien · 2026-03-17T13:36:08Z

also: don't forget to squash before merging ;). There is also a optional checklist in the PR template in case its useful - if not, feel free to remove it on future PRs. (its mostly intended as a guide for less active committers)

haidubogdan · 2026-03-17T14:11:40Z

All right :) . I think I began to get used to the PR flow, so I think I could remove it in the future.

Closes apache#6652 - bump java release version to 17 - custom <hr> tag renderer - added flexmark strikethrough extension - update vscode regex for striketrhough detection - updated mime type to the latest official text/markdown - created new mime type for preview - using a default skeleton css code for margin, paddings ... - added font configs for markdown preview - link coloring and font size customization css to font config settings

BradWalker · 2026-03-18T13:20:02Z

Hey @haidubogdan , just wanted to say thanks for your efforts on this!

mbien

i agree, looks great!

haidubogdan added Editor Markdown labels Mar 2, 2026

mbien added this to the NB30 milestone Mar 2, 2026

mbien added the ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) label Mar 2, 2026

mbien reviewed Mar 2, 2026

View reviewed changes

ide/libs.flexmark/nbproject/project.properties Outdated Show resolved Hide resolved

haidubogdan force-pushed the t_markdown_improvements branch from af46460 to 1982844 Compare March 2, 2026 20:50

mbien reviewed Mar 5, 2026

View reviewed changes

haidubogdan force-pushed the t_markdown_improvements branch from 8fc9b91 to 120d595 Compare March 6, 2026 09:42

mbien reviewed Mar 6, 2026

View reviewed changes

ide/markdown/nbproject/project.properties Outdated Show resolved Hide resolved

haidubogdan force-pushed the t_markdown_improvements branch from 120d595 to da16438 Compare March 8, 2026 12:50

matthiasblaesing reviewed Mar 14, 2026

View reviewed changes

haidubogdan force-pushed the t_markdown_improvements branch from bd27cea to 93a4bc5 Compare March 15, 2026 09:22

mbien reviewed Mar 15, 2026

View reviewed changes

ide/markdown/src/org/netbeans/modules/markdown/MarkdownViewerElement.java Outdated Show resolved Hide resolved

matthiasblaesing reviewed Mar 16, 2026

View reviewed changes

matthiasblaesing approved these changes Mar 17, 2026

View reviewed changes

haidubogdan force-pushed the t_markdown_improvements branch from f52af58 to 3f4b0ef Compare March 18, 2026 06:32

mbien approved these changes Mar 18, 2026

View reviewed changes

haidubogdan merged commit b53dd61 into apache:master Mar 18, 2026
30 checks passed

Conversation

haidubogdan commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Know limitations

PR approval and merge checklist:

Uh oh!

Uh oh!

mbien commented Mar 2, 2026

Uh oh!

Chris2011 commented Mar 2, 2026

Uh oh!

haidubogdan commented Mar 3, 2026

Uh oh!

Chris2011 commented Mar 3, 2026

Uh oh!

haidubogdan commented Mar 3, 2026

Uh oh!

Chris2011 commented Mar 3, 2026

Uh oh!

neilcsmith-net commented Mar 3, 2026

Uh oh!

haidubogdan commented Mar 3, 2026

Uh oh!

mbien commented Mar 4, 2026

Uh oh!

neilcsmith-net commented Mar 4, 2026

Uh oh!

mbien commented Mar 4, 2026

Uh oh!

neilcsmith-net commented Mar 4, 2026

Uh oh!

haidubogdan commented Mar 4, 2026

Uh oh!

mbien left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

matthiasblaesing left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mbien left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matthiasblaesing Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

haidubogdan Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

haidubogdan Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthiasblaesing Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

haidubogdan commented Mar 17, 2026

Uh oh!

matthiasblaesing left a comment

Choose a reason for hiding this comment

Uh oh!

mbien commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

haidubogdan commented Mar 17, 2026

Uh oh!

BradWalker commented Mar 18, 2026

Uh oh!

haidubogdan commented Mar 2, 2026 •

edited

Loading

haidubogdan Mar 16, 2026 •

edited

Loading

mbien commented Mar 17, 2026 •

edited

Loading