search

artisticat1 / obsidian-tikzjax

Render LaTeX and TikZ diagrams in your notes
MIT License
454 stars 27 forks source link

Support User Packages #4

Open iamrecursion opened 2 years ago

iamrecursion commented 2 years ago

Pertinent to our discussion in #3, it would be great to support user packages. I know that I, for one, would love to have support for the various \mathbb and \mathcal letters.

I think the most sensible approach is as follows:

  1. Allow users to specify a directory of packages in the plugin settings.
  2. When loading the bundled packages, also check that directory for packages and load them. Afaict this should be fine to do as we'll have access to app at the point we need it.

I'm very happy to have a go at this, but it makes sense for me to wait for #3 to be finalised first as it'll touch lots of the same stuff.

artisticat1 commented 2 years ago

\mathbb and \mathcal are pretty widely used commands, so I'll make an effort to include the amsfonts package by default!

Afaict this should be fine to do as we'll have access to app at the point we need it.

Yep, we have access to app. The web worker doesn't though, so I'm pretty sure we'd need to pass app (or the package contents) to the web worker from the main thread.

I think the procedure would be along the lines of

  1. On plugin load, check the directory for package files
  2. Gzip and base64 encode all the package files
  3. Pass the base64 encoded file strings to the web worker, so that they're available for load in loadDecompress

I'm very happy to have a go at this,

That would be brilliant, thank you!

iamrecursion commented 2 years ago

\mathbb and \mathcal are pretty widely used commands, so I'll make an effort to include the amsfonts package by default!

Yeah that's fair!

I think the procedure would be along the lines of

  1. On plugin load, check the directory for package files
  2. Gzip and base64 encode all the package files
  3. Pass the base64 encoded file strings to the web worker, so that they're available for load in loadDecompress

I fear that such an approach is likely to be quite heavy to load things; it'd be much better to avoid encoding and decoding package files beyond the included ones on load, especially as (at least on mobile) getting access to efficient gzip implementations in a browser-ish context may be difficult.

What's preventing us from having a slightly different path for local resources and passing app in at worker construction?

artisticat1 commented 2 years ago

I fear that such an approach is likely to be quite heavy to load things; it'd be much better to avoid encoding and decoding package files beyond the included ones on load, especially as (at least on mobile) getting access to efficient gzip implementations in a browser-ish context may be difficult.

Ah, you're right! loadDecompress in run-tex.js expects a base64 encoded, gzipped string, but there's no reason we need to conform to that.

What's preventing us from having a slightly different path for local resources and passing app in at worker construction?

That sounds good to me. #3 is done now, so feel free to make a start :) The relevant branch of TikZJax is here: https://github.com/artisticat1/tikzjax/tree/output-single-file

iamrecursion commented 2 years ago

Thanks so much for the pointers! I'll probably get to start taking a look at this in a week or so. The next week seems very busy for me, but after that it should be good!

lunabunn commented 1 year ago

I hate to be that person, but has there been any progress on this? Looking to use the tipa package to render IPA symbols (for my use case, Unicode support would be even better, but that seems like it would require a major overhaul of TikzJax).