Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Integrate with LibTeXPrintf.jl #232

Open
Suavesito-Olimpiada opened this issue Sep 24, 2022 · 8 comments
Open

Integrate with LibTeXPrintf.jl #232

Suavesito-Olimpiada opened this issue Sep 24, 2022 · 8 comments

Comments

@Suavesito-Olimpiada
Copy link

Suavesito-Olimpiada commented Sep 24, 2022

I just write a small wrapper around a C library called LibTeXPrinf.jl, for rendering LaTeX to a Unicode string, maybe this can be used to display in the terminal.

I'll be registering this in the next days.

@gustaphe
Copy link
Collaborator

Latexify.jl generates LaTeXStrings. How those are rendered is a question for LaTeXStrings.jl.

@gustaphe
Copy link
Collaborator

Okay, I'm slightly wrong. But I think it would be a lot more versatile if your package had a method to accept a LaTeXString. Then Latexify and other LaTeXStrings will work automatically, and the package import overhead is minimized.

@Suavesito-Olimpiada
Copy link
Author

It does have methods accepting LaTeXString.

@Suavesito-Olimpiada Suavesito-Olimpiada changed the title Integrate with [LibTeXPrintf.jl](https://github.com/Suavesito-Olimpiada/LibTeXPrintf.jl) Integrate with LibTeXPrintf.jl Sep 24, 2022
@Suavesito-Olimpiada
Copy link
Author

What it does for LaTeXStrings is to remove the trailing and leading '$' by default from the underlying String representation and pass that to the C library. Then it captures the output and prints or from the Julia side, this is to be about to integrate with IO from Julia.

@gustaphe
Copy link
Collaborator

gustaphe commented Sep 25, 2022

So texprintf(@latexify 3x^2 + y/z) already does the right thing?

@gustaphe
Copy link
Collaborator

Okay, I've played around with it a bit. It feels like a somewhat immature project: it supports a limited subset of TeX syntax, the errors are cryptic and documentation is lacking when it comes to available arguments. For instance, the root project, libtexprintf and its utftex command, has an option to set math in italics, which should certainly be the default for math being fed to the function.

When the package is a bit more mature it would certainly be possible, depending on its weight as a dependency, to create a render method with texprintf as the engine. Until then, I would suggest just using LibTeXPrintf and substituting texprintf for render.

@stevengj
Copy link

has an option to set math in italics, which should certainly be the default for math being fed to the function

I suspect that most people wanting plain-text output for don't want italic plain-text using Unicode italics. If you have $x+ y$ and you ask for a text rendering, would you want "x + y" or "𝑥 + 𝑦" as the "text/plain" output string? I'm guessing the former for most people?

Note that the underlying library here is GPL (JuliaStrings/LibTeXPrintf.jl#6), so you might want to be cautious about adding it as a hard dependency. However, it might be reasonable to add it as an optional depenency of LaTeXStrings, so that if you do using LibTexPrintf, LaTeXStrings it will use this for text/plain display.

@Suavesito-Olimpiada
Copy link
Author

and substituting texprintf for render .

The package is now registered, but instead of render, it went like texstring (render is a lot better name, I just didn't see this).

I think this can be considered now that the concerns have been solved

  • the library is lightweight, now only depends on libtexprint_jll,
  • the library is in better shape and can render even more TeX
  • all the errors detected by the library are returned now, although I need to improve the formatting
  • you can pass fail=false to log and error instead of thowing it, this way the function still returns the string formed, this helps in finding the bad formatting.

I've basically rewriten the wrapper. The wrapper and underlying library are in better shape, thanks in part to stevengj, as he did several necessary contributions on both the wrapper and the library. :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants