search

baskerville / plato

Document reader
Other
1.26k stars 105 forks source link

Use mupdf-rs? #257

Open paulrouget opened 2 years ago

paulrouget commented 2 years ago

I have really looked at how the mupdf integration works, but I was wondering if it would make sense to use https://github.com/messense/mupdf-rs instead of relying on the locally built mupdf library?

baskerville commented 2 years ago

I have really looked at how the mupdf integration works,

You meant you haven't?

but I was wondering if it would make sense to use https://github.com/messense/mupdf-rs instead of relying on the locally built mupdf library?

I don't think it'll work:

paulrouget commented 2 years ago

I have really looked at how the mupdf integration works,

You meant you haven't?

Right… typo.

I don't think it'll work

Understood. Thanks.

paulrouget commented 2 years ago

I'm still trying to wrap my head around this.

I'm patching the source.

Can you explain a bit what this is about? What's the evenodd change for?

I need to have precise control over the size

What about linking statically? All the unused symbols would be dropped.

baskerville commented 2 years ago

I'm still trying to wrap my head around this.

I'm patching the source.

Can you explain a bit what this is about? What's the evenodd change for?

It's a commit from upstream that came after the 1.20.0 release. It fixes the handling of the fill-rule attribute in SVG paths. But I guess I could wait until the next release since I'm not making new icons very often.

I need to have precise control over the size

What about linking statically? All the unused symbols would be dropped.

Since I'm referencing fonts stored inside the library: won't the plato binary size increase significantly?

paulrouget commented 2 years ago

Since I'm referencing fonts stored inside the library: won't the plato binary size increase significantly?

Oh then I misunderstand the point of the wrapper :)

Since I'm referencing fonts stored inside the library: won't the plato binary size increase significantly?

plato statically linked with mupdf should be smaller than plato + mupdf.so. So the overall footprint should be smaller?

I'm just curious :) Thank you.

baskerville commented 2 years ago

Since I'm referencing fonts stored inside the library: won't the plato binary size increase significantly?

Oh then I misunderstand the point of the wrapper :)

  • mupdf is shipped along with plato, right?

Yes.

It's not builtin in Kobo system?

No.

  • plato is linked to mupdf. What does the wrapper does then?

MuPDF uses C intrinsics (setjmp and longjmp) to implement its error handling mechanism, since we can't deal with this within Rust, we have to write C wrappers for all the functions that might fail (mostly all the functions that take an fz_context pointer as argument according to the documentation) and bind to the wrapper instead of the wrapped. mupdf-rs has its own wrapper.

Since I'm referencing fonts stored inside the library: won't the plato binary size increase significantly?

plato statically linked with mupdf should be smaller than plato + mupdf.so. So the overall footprint should be smaller?

I trust you on that, but having a smaller plato binary is more important to me.

paulrouget commented 2 years ago

Understood. Thank you.