Generate SVG rather than GIF for embedded pictures

[BoboTiG]

A successfull experiementation was done in https://github.com/BoboTiG/ebook-reader-dict/issues/1182#issuecomment-1027245425 about moving embedded pictures from GIF to SVG. Results are way better, so let's do the move.

We first need to ensure this works with PyGlossary and StarDict display.

Note: PyGlossary 4.4.2 or newer is required.

[Moonbase59]

Would using scour (instead of svgo) help for this project? (By reducing overhead with Node or such?)

I could investigate and see what comes out of it… Might be nice to have it "pure Python" overall.

[Moonbase59]

Thanks for reminding me of scour—must have been using svgo for too long now to even remember it. ;-)

It seems scour can produce even more compact SVGs, and it’s Python. I will rework latex2svg to be able to use scour.

[Moonbase59]

Ok, v0.3.0 now defaults to scour optimizer. Tested by converting the German Wiktionary into StarDict and Kobo dicthtml, without any visible differences.

https://github.com/Moonbase59/latex2svg

Let me know if we need more LaTeX preamble additions to cope with oddities in the Wiktionary in other languages, i.e. French.

[lasconic]

What would be the preferred way to use latex2svg in this project ? Is it possible to add it in requirements.txt ?

[BoboTiG]

What would be the preferred way to use latex2svg in this project ? Is it possible to add it in requirements.txt ?

Yep :+1:

[BoboTiG]

@Moonbase59 do you plan to release it to PyPi?

[Moonbase59]

@Moonbase59 do you plan to release it to PyPi?

That would probably be the right thing to do, but honestly, I have no idea how to do that and what more might be required. I also doubt a little they’d accept a Python module that calls Node apps?

I already feel bad that I have so little time to care about the DE dictionary here…

So if it’s not super-easy and someone can assist me with PyPi, I fear it’ll take a while. Then again, it’s actually just one file, could that somehow be required in this project in a transparent manner?

Using: I’d propose to use it as a Python module, by doing an from latex2svg import latex2svg, and setting any desired parameters in the params dict.

[Moonbase59]

Ok, I started learning about Python packaging, created a PyPI account and made it an installable module, see https://github.com/Moonbase59/latex2svg#installation. Unfortunately there still is an issue on PyPI because they don’t take the name latex2svg, albeit there is no module with that name on PyPI.

@BoboTiG, @lasconic: It should already be possible to use a direct GitHub link to a package (which it now is) in requirements.txt, only I’m unsure about the specifiers needed, probably one of these.

EDIT: Just tried

pip3 install git+https://github.com/Moonbase59/latex2svg.git#egg=latex2svg

and it installs just fine. So at least using something simple like

git+https://github.com/Moonbase59/latex2svg.git#egg=latex2svg

in a requirements.txt should work (installing what’s currently at HEAD in the default branch).

Checking with pip3 freeze > test-requirements.txt gives me latex2svg==0.4.1, which is correct for the current test.

Btw, installing it as a package will also produce a command line shim (in ~/.local/bin/latex2svg on my machine), so latex2svg is available from the CLI.

[BoboTiG]

Actually if you could use tags for your releases, it would help here. So that we could put in requirements.txt:

git+https://github.com/Moonbase59/latex2svg.git@0.4.1

Given that the tag would be 0.4.1.

[Moonbase59]

Sounds like a workable idea. Could you live with tags being of the form "vmajor.minor.patch"?

I don’t want to warm up the old "with or without a 'v'" discussion here, but SemVer once recommended using the v, I did it in all my other software, Git and the Linux kernel do it this way, and one can’t have branches and tags have the same name. So I’d like to stick using tags with the v. Apparently now GH can strip the 'v' when building packages, so this should work as well.

Done, starting at "v0.4.1". Works as expected when doing a

pip3 install git+https://github.com/Moonbase59/latex2svg.git@v0.4.1#egg=latex2svg -U

[Frenzie]

@Moonbase59 As a heads up, the next KOReader release will use the latest MuPDF, 1.24.2. A nightly build will be available tomorrow at http://build.koreader.rocks/download/nightly/ if you want to test anything.