VL.RichtextKit

there is a little issue with the markdown parsing the string " 1. "

yes, also true for the html variant of this node.
there’s some unallowed things in markdown/html that need to be taken care of.
i don’t think i could catch all of them (defaults, etc.) and also it would be too much work. so far i don’t have a good strategy for this, except leaving it to the user like wrapping the node in a try region. or replace some parts of the string.

example

in a recent project i replaced all
occurrences in a html string with a CRLF for proper parsing.

at least that is what i guess from a screenshot only. might be something different.

btw. here is a new branch that works with versions >= 6.7-177 without modifying the vvvv install folder.

i can make a nuget out of it but i first want to gather some feedback or opinions here and possibly iron out some bugs.

2 Likes

nah its just the parsing that fails with that string: “1.” (a number followed by a dot) and creates an empty snippet. might have been more precise

the thing is, 1. in markdown introduces a list element. as you can see in this screenshot (or if you have a look into [ParseMarkdown]):

at 1. you see some debug output, which basically shows you which part of the markdown string translates to which style.
in this case it’s an empty string with the style li.

but as you can see at 2., there’s no style defined for li in the style dictionary (as is for text, em, strong and code, therefore those work) and the TryGetValue returns a NULL style.


i could add a keep here to swallow the pink node for example:


but then you might wonder, where is my input?
and because there’s no general solution to this (that i know of) i decided to leave it pinkish for now.

of course, there’s a way to define a dictionary with all possible markdown styles. downside is that there are many… but maybe the most common set would be enough?

not much tested, treat it as a prerelease…

inlcudes a new feature from @Rayment that enables to specify fonts by filepaths!

6 Likes

Hi @sebl, I looked into RichTextKit lib but couldn’t find a direct answer for this… Does it support variable font axes?

afair, weight is an int. i guess in variable fonts, more weights are possible (instead of only some like 300, 500, …)
you have to check if it works with the font and if it’s fine enough.
maybe compare it to another font renderer that handles variable fonts to see if there’s a difference.

Thanks for replying. Yeah I checked and it seems neither RichtextKit nor VVVV’s Skia can animate through variable axes (not even weight axis, they make jumps through weights).

Seems like the only ones who have figured this out are web browsers and Cavalry. I asked Cavalry folks how they achieved it, here’s what they replied:

can i see your testpatch along with a testfont?

Sure. Here’s the font I used.

For patches, I have only added a IO Box for font weight. And I am dragging its value and noticing how it affects the weight:

font-weight-skia.vl (7.4 KB)
font-weight-richtext.vl (93.2 KB)

To know and manipulate variable axes, I’m using Wakamai Fondue, the tool that answers the question “what can my font do?”

let’s upvote here and hope it makes it in the next release.

i think one could make extension methods for skiasharp and implement it yourself in the meantime.

2 Likes

Upvoted, thanks for linking! Though on a second thought, doesn’t it make sense for this to be part of RicktextKit instead? I had a related discussion here and seems like even SkiaSharp devs want to offload text heavylifting to RichtextKit.

as i read it:

the main issue is, that there is enough functionality in skia and harfbuzz (the native ones) for variable fonts. but some of those needed API calls are not exposed in skiasharp.

the poster gives an idea on what he did to achieve the kerning (also a ‘feature’):

Ad. 1. Implemented SkShaperFeatured which is basically source copy of SkShaper, but has features parameter enabled.
Ad. 2. PInvoking to already available libHarfbuzz extern functions.
Ad. 3. Had to expose extern static funcs to above api and rebuild libSkiasharp. I didn’t succeed getting SkiaSharp nuget built, but that’s work in progress, so I’m PInvoking to these functions at the moment. This requires maintaining a fork though.

so, no matter where it lives in the end (skiasharp, harfbuzzsharp or even Richtextkit) those native calls need to be exposed (pInvoke etc.).

here’s another issue, that details a bit more on what is needed:

2 Likes

another idea to achieve variable fonts is, to convert the font.
maybe a tool like this can automate.

I used FontLab for that in a recent project:

1 Like

i gave it a go and implemented the needed changes to the underlying lib.
if anyone is interested, you can join the journey here:

at the moment, i have an issue with the DllImport stuff:

[DllImport("libSkiaSharp", CallingConvention = CallingConvention.Cdecl)]
private static extern IntPtr sk_typeface_make_clone(IntPtr typefaceHandle, IntPtr fontArgumentsHandle);

results in:

Unable to find an entry point named 'sk_typeface_make_clone' in DLL 'libSkiaSharp'.
System.EntryPointNotFoundException: Unable to find an entry point named 'sk_typeface_make_clone' in DLL 'libSkiaSharp'.

is there a need to build libSkiaSharp yourself in order to do that?

turns out, the forwarding/exposing must be done on c+++ side. so, if we don’t want to maintain a fork, we have to wait for skiasharp, as mentioned in the above linked issue.
if that is done, my branch should work

4 Likes