c3er/mdview

Support for external fonts

mmillar-bolis opened this issue · 9 comments

mmillar-bolis commented

Hey there!

First of all, as a vim user, your project is my preferred markdown viewer. Thank you so much for your hard work and support of this tool!

One feature that would be very handy is support for loading external font files.

Generally in Markdown, I can declare fonts by using in-line CSS like so:

<style>
@font-face {
    font-family: MyFont;
    src: url("/path/to/font.ttf") format('truetype');
    font-weight: medium;
    font-style: normal;
}
</style>

However, in mdview, it appears that I can only load images as external resources. However, I am able to load a font if I embed it as base64 within my style tag like so:

src: url(data:font/truetype;charset=utf-8;base64,<BASE64_CONTENTS>) format('truetype');

So base64 fonts embedded within the markdown file will load, but external files will not.

Again, thank you so much for mdview and thanks for your time and consideration!

c3er commented

Thanks🙂

Does loading the font file also fail, if you put an absolute path as URL parameter?

I have a theory for the cause. But if I'm right, absolute paths should work (though that would not be practical). The reason, why images can be loaded, is that the image paths are manipulated to be relative to the Markdown document before rendering. If the tool would not do this, the paths would be assumed to be relative to the tool (or the containing index.html) itself, i.e. in some system directory.

I will see when I have time to investigate this. Maybe this weekend or next week but without promise.

mmillar-bolis commented

You are most definitely right! I had not tried an absolute path but it does load the font without issue. A path issue makes a lot of sense!

Please, take your time. This has not truly impeded my workflow. In fact, I have already been working around it with some scripts, but I thought it would be a good idea to let you know about that observation.

If I have noticed some other things, is it okay with you to open more respective issues? I could alternatively keep it to one thread, if preferred. Of course, your time is yours and I don't mean any pressure.

c3er commented

I see two solutions for the path issue - a cheap and and a good solution.

  • Cheap: Change handling of the CSS url path parameter
  • Good: Look, what HTML and CSS elements might also get a file path and change handling of all of them accordingly

I'll see, which solution I will implement.

I prefer opening an extra issue for every bug and feature request. That's the way I know from almost all projects. I will close each issue after I fixed them in the code but before publishing the release, if it's okay for for you. I don't want to publish a release for each "minor" fix.

c3er commented

@mmillar-bolis

I could not manage to reproduce your problem. When I extended a test file, the font appeared as one would expect. See screenshot below:

Screenshot of test file

I pushed the test file together with the font.

Can you attach a file, where your problem occurs?

mmillar-bolis commented

@c3er

How strange! I pulled your test folder down keeping rm_almanack.ttf in the correct subdirectory. I could not get the font to render on my system. In fact, placing another font beside it and attempting to load that instead did not work either. I checked the process for font handles and it looks like only Arial, Consolas, Segoe, and Times were open in mdview's process tree.

To further test my eyes, I tried this:

<style>
#special {
    font-family: MyFont;
    src: url("font1/rm_almanack.ttf") format('truetype');
}
#not-special {
    font-family: MyFont;
    src: url("font1/definitely_not_real.ttf") format('truetype');
}
</style>

And both lines rendered with Times. Unfortunately, I was unable to get any custom font to display with a relative or an absolute path when using #special. I even changed the font family to no avail. To be sure, I attempted this on another system and was able to reproduce the results.

I have attached text files below, but they can also be acquired from this repo. The source code to the font can be found here, if curious.

Attached is a screenshot that demonstrates all three running scenarios: base64, loose file at relative path, and loose file at absolute path. Only the center one is putting up a fight.

Please do let me know what more information I can provide to help.

screenshot01_mmillar-bolis_github

screenshot02_mmillar-bolis_github

dunmeris_template.zip

c3er commented

Actually, I failed at reproducing the issue. The used serif font was too similar to Times. The test file uses now your font. Also, I added your attached package to the test directory.

I hope this works now for you. Using the id attribute and defining a corresponding CSS selector seems not to work.

Do you open additional issues soon? If yes, I tend to wait releasing the update, if it is okay for you. If you have Node.js installed and npm in your system path, it should be easy to build a setup for testing by yourself:

npm install

npm run dist

After executing the above commands, a Setup EXE file should be in the dist directory.

Feel free, to reopen this issue, if you still encounter problems at using fonts in Markdown files.

mmillar-bolis commented
c3er commented

Many apologies as work as been a bit busy.

No apologies needed! I don't pay you for creating issues here ;)

And yes, absolutely feel free to use my example! It's very much appreciated.

Thanks! I recommend to add a license file to your repositories. Technically (or juridically), no one is allowed to use anything from your projects for any purpose under any condition. That's the reason, why my projects have usually an MIT license.

mmillar-bolis commented

Thanks for the heads up! I must have missed creating a license in my rush to get that repo up. I have now added it, so you should be covered as well.