rgaudin

> Currently we recreate the whole ZIM from scratch, which is not very convenient / satisfying. This is very odd (and lazy). You short term solution for both #934 and...

Well, you justified the need with “Currently we recreate the whole ZIM from scratch”… 🙃

We've also lost `Archive.get_entry_by_title()` which relies on the same `Archive::getEntryByTitle()`. We dont test this properly in pylibzim: https://github.com/openzim/python-libzim/issues/223

It's a behavior change so a decision is mandatory but I think the new behavior is aligned with what we've documented: suggestion is based on FRONT_ARTICLES. I am more concerned...

@kelson42 indeed ; and yes it is present and empty. I do think, but this is debatable, that [`Archive::getEntryByTitle(title)`](https://libzim.readthedocs.io/en/latest/api/classzim_1_1Archive.html#_CPPv4NK3zim7Archive15getEntryByTitleERKNSt6stringE) should work as implied though. I understand and respect that (API-wise)...

Indeed providing a base scraper out of what is currently a strong convention would boost up new scraper development time and reduce maintenance overall. Needs to be considered. @benoit74 I...

You might want to check https://github.com/openzim/wikihow/issues?q=is%3Aissue+503

Indeed, we should define a signature/interface for it. It's not like it's used in many ways anyway

Use case is displaying graphics correctly on devices which screen has higher density of pixels. - https://tomroth.dev/dpr/ - https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio - https://stackoverflow.com/a/8785677 The devicePixelRatio is reported by the device (hence its...

Readers/users will have to implement some matching code anyway since [devicePixelRatio](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio) is a float (even though it often returns an int). What benefit would there be in limiting this to...