Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154332 > unrolled thread

How to copy & read a huge zipped book with thousands of html & jpeg files

Back to article view | Back to comp.mobile.android

Contents

  How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 18:40 -0400
    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 21:17 -0400
      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 21:48 -0400
        Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 22:51 -0400
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 23:57 -0400
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 23:13 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 13:29 +0200
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-05 14:48 +0100
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 10:06 -0600
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 19:10 +0200
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Computer Nerd Kev <not@telling.you.invalid> - 2026-07-05 17:37 +0000
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-05 21:00 +0100
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 22:50 +0200
                      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 23:06 -0600
                        Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:05 +0200
                          Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:24 +0200
                            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 10:28 -0600
                              Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 19:50 +0200
                          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 09:36 -0600
                            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 19:56 +0200
                      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-06 07:58 +0100
                        Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:12 +0200
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 15:12 -0600
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Arno Welzel <usenet@arnowelzel.de> - 2026-07-06 17:53 +0200
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 10:47 -0600
        Re: How to copy & read a huge zipped book with thousands of html & jpeg files Andy Burns <usenet@andyburns.uk> - 2026-07-05 08:35 +0100
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 10:38 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Andy Burns <usenet@andyburns.uk> - 2026-07-05 18:22 +0100
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 12:16 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 19:41 +0200
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 12:54 -0600
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 23:11 +0200
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 15:23 -0600
    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Arno Welzel <usenet@arnowelzel.de> - 2026-07-06 17:48 +0200

Page 1 of 2  [1] 2  Next page →

#154332 — How to copy & read a huge zipped book with thousands of html & jpeg files

New-to-me tablet that someone gave back that I had given them as a gift.

I was copying an already-unzippled set of 25,000 html and JPEG files for a
book from Windows to an Android tablet but it was taking forever (hours) so
I stopped it and copied only the 500MB zip file in just a minute or two,
but now that it's on Android how do I best unzip it so it works as HTML.

Looking it up, apparently most people unzip using Files by Google or My
Files on Samsung, but for a more universal solution, I tested ZArchiver
freeware which has unzip capabilities so everyone here can benefit.
 <https://zdevs.ru/en/za/apk.html>
 <https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver>

Having used computers since they were available to the4 public, I know
enough to put everything on Android in my own unpolluted folders only.

Hence, I use 0000 on internal storage and 0001 on external storage. 

The reason for the zeroes is that it becomes the FIRST thing we see in the
crappy Android file browsers, so I know instantly what storage I'm in 'cuz
Android pollutes both the internal storage and external storage similarly
so we won't even know which one we are in sometimes but I can see the 0000
or 0001 and I know which storage location I'm in, instantly.

So I put the zip file, which we'll call "name.zip" in 
 /storage/emulated/0/0000/doc/book.zip (names have been simplified)

Here's how I unzipped the 500MB book.zip file containing html & jpeg:
1. Open ZArchiver
2. Navigate to /storage/emulated/0/0000/doc/ & tap book.zip
3. Choose Extract... (out of the too-many extraction choices)
4. When it asks to "Pick a destination folder" just hit the blue arrow
5. Wait for extraction (mine asked if I wanted to keep the screen on)
   25K files took a few minutes on my Android 16 Samsung tablet
6. In my case, it created a folder of the same name as the zip file was
7. I opened the newly created folder and tapped index.html
8. In my case, it asked what to open it with so I chose a "Chrome" browser
It opened the index.html but everything was broken after that.
Yet, it worked fine on Windows doing the same steps. 
So Chrome can access the files, apparently.

I put the zip in /storage/emulated/0/0000/book/name.zip and I had extracted
to /storage/emulated/0/0000/book/name/ but apparently some browsers aren't
able to open files correctly from outside of standard known directories. 

I'm not sure why Chrome failed, but as a first test to solve that failure I
installed the FOSS Browser (yes, it's called that) 
 FOSS Browser
 A fully free (as in freedom) open source browser for Android.
 <https://f-droid.org/en/packages/de.baumann.browser/>
 <https://f-droid.org/repo/de.baumann.browser_158.apk>
 Name: de.baumann.browser_158.apk
 Size: 6361844 bytes (6212 KiB)
 SHA256: 5D1FDCC15C5919645F55F10F69DDB1755E6EF2187F2F829E7C919ADF24E82A9A

Opening the FOSS browser on Android is an experience in controlled
confusion because it opens to a wiki which takes over the whole browser.
Worse, that wiki causes the FOSS browser to crash on my Android tablet.
The crashes are java error from their own wiki web page, which is dumb.

Working around that, I try the "file open" dialog by tapping on
 /storage/emulated/0/0000/book/name/index.html
but the FOSS Browser apparently does NOT register itself with Android as an
app that can open HTML files. So I type the full path, which then says:
file:///storage/emulated/0/0000/book/name/index.html could not be loaded
because: net::ERR_ACCESS_DENIED

Apparently FOSS browser just can't access your own priate folders. Sigh.
When Android 10+ introduced "scoped storage, things like this broke
because apps cannot read arbitrary folders unless they use the Storage
Access Framework so my top-level folders are not accessible to browsers
unless they implement SAF

Apparently, FOSS Browser does not implement SAF.
 a. It does not request modern permissions.
 b. It does not declare HTML MIME types.
 c. It does not register itself as a file opener.
 d. It does not handle file:// outside public folders.

So Android blocks it with:   ERR_ACCESS_DENIED
So I'll switch browsers to one that does implement SAF, I guess.
-- 
Usenet allows good friends around the world to discuss their experiences.

[toc] | [next] | [standalone]

#154333

Maria Sophia wrote:
> So Android blocks it with:   ERR_ACCESS_DENIED
> So I'll switch browsers to one that does implement SAF, I guess.

I deleted the horrid FOSS Browser and next tried the F-Droid Privacy
Browser:

<https://fdroid.gitlab.io/jekyll-fdroid/packages/com.stoutner.privacybrowser.standard/>
 <https://f-droid.org/repo/com.stoutner.privacybrowser.standard_81.apk>
 Name: com.stoutner.privacybrowser.standard_81.apk
 Size: 17083571 bytes (16 MiB)
 SHA256: 209E0670CB44A959DD628737EAA5B8DF05BFB605E4706DE49EA2B72684CF72E3

Drat. When I went to ZArchiver and tapped on the index.html file, it opened
up 
but when I tapped on one of the sub links, it said "webpage not available".

The webpage at 
content://ru.zdevs.sarchiver.external/storage/emulated/0/0000/book/gages/2.html 
could not be loaded because: net::ERR_FILE_NOT_FOUND

So I opened Privacy Browser and tapped the browser "Browse" button which
allowed me to find the file which its own URL became, cryptically, 

content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
That opened the top level of the index.html page.

When I clicked on a lower-level link, it asked me to "open with" but the
options provided did not include a browser. 
 Muntashirakon App Manager interpreter, Google (search), Messages, Messages
The Muntashirakon App Manager interceptor shows
 Action = android.intent.action.VIEW
 Data =
content://com.android.externalstorage.documents/document/pages/2.html

Yikes. What's happening? This isn't a real file-system path at all.
It's an SAF document URI. 
-- 
Every version of Android makes things harder, much like what iOS does.

[toc] | [prev] | [next] | [standalone]

#154334

Maria Sophia wrote:
>  Data =
> content://com.android.externalstorage.documents/document/pages/2.html
> Yikes. What's happening? This isn't a real file-system path at all.
> It's an SAF document URI.

The index.html is written using normal standard relative links such as
 pages/2.html
 images/foo.png
 css/style.css

These only work if the browser knows the real directory.
But the fashuganeh Android SAF apparently hides the directory.

Therefore, SAF URIs cannot be used for relative links inside HTML files.
So when the HTML says:  <a href="pages/2.html">
Android tries to resolve it relative to the SAF URI, not the filesystem.

Worse, when I tap an HTML file in ZArchiver, it passes the file using
 content://ru.zdevs.zarchiver.external/...	
Which is ZArchiver's own SAF wrapper, not a real path.

When I paste the full URI into Privacy Browser, I get the error
 Webpage not available. 
 The webpage at file:///storage/emulated/0/0000/book/name/index.html
 could not be loaded because: net::ERR_ACCESS_DENIED

The normal HTML manual expects a real filesystem:	   
 /storage/emulated/0/0000/book/name/index.html
 /storage/emulated/0/0000/book/name/pages/2.html
But Android 16 rewrites everything into SAF URIs:
 content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html	 

This means the relative link
 pages/2.html
Becomes 
 content://com.android.externalstorage.documents/document/pages/2.html
which is not a real path. It's a virtual document reference.

So why did file:///storage/emulated/0/0000/book/name/index.html fail?
Android 10+ treats any custom top-level folder as restricted.

Apparently, Android only allows browsers to read:
 /storage/emulated/0/Download/
 /storage/emulated/0/Documents/
 /storage/emulated/0/DCIM/
 /storage/emulated/0/Pictures/	 

Apparently, Occam's Razor says the simplest explanation that fits the facts  
is that Android 16 blocks browsers from reading custom top-level folders.	 
-- 
Every Usenet post should strive to add value that wasn't there before.

[toc] | [prev] | [next] | [standalone]

#154335

Maria Sophia wrote:
> Apparently, Android only allows browsers to read:
>  /storage/emulated/0/Download/
>  /storage/emulated/0/Documents/
>  /storage/emulated/0/DCIM/
>  /storage/emulated/0/Pictures/

This is frustrating as Android seems to be getting more & more like iOS
as it appears that Android's WebView (used by all browsers) cannot open:
 file:///storage/emulated/0/0000/...	 

So I need to find an app that still use direct POSIX filesystem access (and 
ignores SAF entirely), or, I can install a local HTTP server in Termux.

Apparently, these file managers have their own internal HTML renderer
that bypasses WebView, so I might resort to testing these one by one.
 a. MiXplorer (best option)
 b. X-plore
 c. Older versions of Cx File Explorer 

But I think the most reliable will be to use Termux, which can access /0000 
directly because it uses POSIX APIs (not SAF), and then start a server.

1. Install Termux from Github/FDroid (never use the Termux on Google Play)
   <https://f-droid.org/en/packages/com.termux/>
   <https://github.com/termux/termux-app>
   <https://github.com/termux/termux-app/releases/tag/v0.118.3>
   <https://github.com/termux/termux-app/releases/download/v0.118.3/termux-app_v0.118.3+github-debug_arm64-v8a.apk>
   Name: termux-app_v0.118.3+github-debug_arm64-v8a.apk
   Size: 35106607 bytes (33 MiB)
   SHA256: 72FDB596045116BF5BA1B5BDF5B26FDDB9ACC0BD074AD9F2DA9EB0AE85E83A4E

2. In Termux, navigate to the folder containing the index.html manual
   $ cd /storage/emulated/0/0000/book/name
   Drat. I got "permission denied". 
   Termux didn't ask for permissions other than "Notifications". 
   So we need to manually set the permissions to see files.
   Settings > Apps > Termux > permissions > Files 
   Test with:
   $ ls /storage/emulated/0/0000/book/name

3. In Termux, install python.
   $ pkg install python
    
4. In Termux, start the server
   $ python3 -m http.server 8000
    Serving HTTP on :: pot 8000 (http://[::]:8000) ...

5. Open any browser and type the following into the url address field 
   http://localhost:8000

6. Using the Privacy Browser, that brought up the top-level web page.
   Then, I tapped on the first link... ... ... Voila!
   The manual page2 showed up perfectly this time. 

Whew!
Success at last!

I finally forced Android 16 to behave like a real operating system again. 
I carved out a sane workflow inside an OS that keeps trying to turn into 
iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy. 
-- 
Intelligent people rarely fail at doing what they want to do on Android.

[toc] | [prev] | [next] | [standalone]

#154336

Maria Sophia wrote:
> I finally forced Android 16 to behave like a real operating system again. 
> I carved out a sane workflow inside an OS that keeps trying to turn into 
> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level
hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

All Android web browsers use WebView, which is restricted by Scoped Storage 
and the Storage Access Framework (SAF). When you try to open index.html, 
Android does not give the browser the real filesystem path.

Instead it rewrites the path into a SAF URI like:
  content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html

SAF URIs are not real filesystem paths.
Because of this, all relative links inside the book1 break.

For example:
  pages/2.html
  images/foo.png
  css/style.css

These links get rewritten into invalid SAF document URIs such as:
  content://com.android.externalstorage.documents/document/pages/2.html

Browsers cannot resolve these, so they fail with errors like
  ERR_ACCESS_DENIED and ERR_FILE_NOT_FOUND.

Android WebView only allows file:// access in a few public folders 
(Download, Documents, DCIM, Pictures) but Linux users often use custom 
folders like /usr/local so that they can back up everything they care about 
easily, and so that they're not polluted by the Android system.

Custom folders like /0000 are blocked.

Unzipping the book1 works fine, but opening index.html directly from
the top-level /0000 fails in every browser tested.

Solution:
Use Termux to bypass SAF entirely. Termux uses real POSIX filesystem
access. After granting Termux full file permissions in Android Settings,
you can run a local HTTP server that serves the book1 using real paths.

Steps:
1. Install Termux from GitHub or F-Droid.
2. Grant Termux "All files access" in Android Settings.
3. In Termux, install Python:
    pkg install python
4. Navigate to the book1 directory:
    cd /storage/emulated/0/0000/books/book1
5. Start a local HTTP server:
    python3 -m http.server 8000
6. Open any browser and go to:
    http://localhost:8000

Because the book1 is now served over HTTP, the browser treats it as a
normal website. All relative links, images, CSS, and subpages work
correctly. This bypasses SAF and restores normal filesystem behavior.

Result:
The entire HTML book named book1 displays perfectly on Android while 
remaining in the user's own custom directory (/0000) so that it can 
be copied over during backups along with the rest of the users' data.

AFAIK, this method works reliably on all modern Android versions. 
-- 
There is always a solution if you stick to your Linux principles.

[toc] | [prev] | [next] | [standalone]

#154337

Maria Sophia wrote:
> The entire HTML book named book1 displays perfectly on Android while 
> remaining in the user's own custom directory (/0000) so that it can 
> be copied over during backups along with the rest of the users' data.

Having spent formative decades in the Unix world, I always place all of my
personal data, tools and documents inside a single top-level directory such
as /usr/local so that everything important is stored in one clean,
predictable location. 

But Android 10+ hates us putting our files were we want to put them.
Android wants us to put files where some programmer felt they should be.

A programmer who likely never once set up a Unix or Windows system.
But I've set up many, and I didn't want to compromise on principles.

So by using the POSIX method previously described, I avoided scattering
files across multiple system-managed folders and I kept backups simple
because the entire hierarchy can be copied as one unit. 

On Linux and on Windows, I keep all user data in my own custom hierarchy.

I follow the same philosophy on Android by using /0000 as my personal data
root. All of my books, manuals, notes and tools live under /0000 so I can
back up everything I care about without hunting through Android's polluted
system folders. <https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg>

On all my Android systems, /0000 is where I store things I care about on
the internal storage, and /0001 is where I store everything I care about on
the external sdcard (where, Android pollutes both cards similarly, so the
mere presence of either /0000 or /0001 tells me instantly where I am.
 <https://i.postimg.cc/bNGTzR6q/sdcard1.jpg>

I did not want to compromise my Linux principles by storing my HTML books
partly in Download or Documents and partly in /0000, because that breaks
the simplicity and reliability of having one unified directory tree. 

Keeping everything in /0000 preserves the same organizational clarity that
Linux users get from /usr/local, and it ensures that my data remains
portable, predictable, and easy to manage.	
<https://i.postimg.cc/BQyRxCN9/webdav11.jpg> 

It's shocking to me how long this took to solve without compromising my
principles on keeping all user data in a /usr/local like single folder.

Android is getting less & less like Linux, and more & more like iOS.
The beauty of this POSIX solution is that Termux is allowed to use real
filesystem calls, so it sees the real directory structure on Android.

Luckily, Termux can access the real filesystem directly using standard Unix
system calls, without Android rewriting the paths into SAF content:// URIs.
Because Termux sees the actual directory structure, it can serve the HTML
manual correctly, and all relative links work.

Those are anti-POSIX layers Android added starting in Android 10
 a. SAF (Storage Access Framework)
 b. content:// URIs
 c. virtual document handles
 d. rewritten paths
 e. permission intermediaries
 f. Android WebView restrictions

In my test case, the HTML books rely on relative links, like:
 pages/2.html
 images/foo.png
 css/style.css

Tens of thousands of them, so changing the links wasn't feasible.
Relative links only work if the browser knows the real directory.

SAF does not.
Android browsers receive SAF URIs like:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html

These are not POSIX paths, so relative links break.
Termux, however, sees the real POSIX path:
 /storage/emulated/0/0000/books/book1

In summary, the principels we learned decades ago setting up Unix and
Windows systems, can still be leveraged to setting up our Android phones.
-- 
When things get tough, the Linux principles you learned get you through.

[toc] | [prev] | [next] | [standalone]

#154339

On 2026-07-05 05:57, Maria Sophia wrote:
> Maria Sophia wrote:
>> I finally forced Android 16 to behave like a real operating system again.
>> I carved out a sane workflow inside an OS that keeps trying to turn into
>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
> 
> SUMMARY (Linux users added because it was Linux to the rescue this time!)
> 
> Windows and Linux can easily open HTML books stored in custom top-level
> hierarchies, even if the books contain tens of thousands of pages & jpegs.
> 
> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them 
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as 
an intermediary to transform to something else.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154340

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

> On 2026-07-05 05:57, Maria Sophia wrote:
>> Maria Sophia wrote:
>>> I finally forced Android 16 to behave like a real operating system again.
>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>> 
>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>> 
>> Windows and Linux can easily open HTML books stored in custom top-level
>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>> 
>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
> 
> I don't know what are "books" in this context.
> 
> If you mean electronic books, for me they are epubs, and I handle them 
> with Calibre.
> 
> https://www.gutenberg.org/ebooks/79019
> 
> I see html format is available, but I see no reason to use it, unless as 
> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
 'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
 documentation
-- 
Remove numerics from my email address.

[toc] | [prev] | [next] | [standalone]

#154341

Dave Royal wrote:
>> I don't know what are "books" in this context.
>> 
>> If you mean electronic books, for me they are epubs, and I handle them 
>> with Calibre.
>> 
>> https://www.gutenberg.org/ebooks/79019
>> 
>> I see html format is available, but I see no reason to use it, unless as 
>> an intermediary to transform to something else.
> 
> Quite a lot of technical documentation is published as an html
>  'book'. This for example:
> https://doc.rust-lang.org/book/
> 
> Historically html is a dialect of sgml, which was designed for
>  documentation

Hi Carlos & Dave,

It's a great question, and I apologize for not having explained better.

Thank you for asking, as Android not being Linux hit me by surprise, since
I was shocked that I couldn't just open an HTML folder on Android 16, just
as I opened that same HTML file hierarchy on Windows (& Linux would work).

What floored me is how NOT-LIKE-LINUX Android has become since Android 10.
In terms of being able to use POSIX paths, this new SAF stuff is atrocious.

With SAF, the file system access is nothing like that of Linux or Windows.
With POSIX, the file system is exactly like that of Linux and Windows.

Much like iOS limits almost everything you want to do for efficiency, this
SAF stuff limits what you can do with scripts running on the desktop PC.

Yet, Android "used to be" like Linux in terms of how it accessed files.
That is no more the case. 

As for the folder contents, I agree that a lot of books are ebooks, and as
you are well aware, I have scripts that turn almost any electronic book
(whether it's epub, text, pdf, MS word, etc.) into mpeg "talking books". 

But like it or not, the book I found online is huge repair manual, which
turns out to be extremely hierarchical & extremely terse in text and yet
extremely filled with exploded images, interspersed in & out with the text.

For whatever reason, that repair manual is supplied as a single 500MB zip
file containing tens of thousands of images interspersed with html files.

Since it's a repair file, I can't drag the desktop (or even a laptop) under
the vehicle as I do the repair, so I put it on one of my tablets to use it.

I have plenty of iPads but only one Android tablet, so I put it on the
Android 16 tablet thinking it would be worlds easier than doing it on iOS.

It turned out that Android nowadays, is becoming more and more horrific
like iOS already is, in terms of NOT using POSIX file specifications.

What happened to me, yesterday, proves that even though Android's
underlying Linux kernel is POSIX compliant, Android 10+ is decidedly not.
-- 
Every time I try to automate a desktop with a mobile device, I learn how
much they try to fight us so that they can maintain control of our files.

[toc] | [prev] | [next] | [standalone]

#154343

On 2026-07-05 15:48, Dave Royal wrote:
> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
> 
>> On 2026-07-05 05:57, Maria Sophia wrote:
>>> Maria Sophia wrote:
>>>> I finally forced Android 16 to behave like a real operating system again.
>>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>>>
>>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>>>
>>> Windows and Linux can easily open HTML books stored in custom top-level
>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>>>
>>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>>
>> I don't know what are "books" in this context.
>>
>> If you mean electronic books, for me they are epubs, and I handle them
>> with Calibre.
>>
>> https://www.gutenberg.org/ebooks/79019
>>
>> I see html format is available, but I see no reason to use it, unless as
>> an intermediary to transform to something else.
> 
> Quite a lot of technical documentation is published as an html
>   'book'. This for example:
> https://doc.rust-lang.org/book/
> 
> Historically html is a dialect of sgml, which was designed for
>   documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so 
that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154345

In comp.mobile.android,alt.os.linux,alt.comp.os.windows-10 "Carlos E. R."
<robin_listas@es.invalid> wrote:
> On 2026-07-05 15:48, Dave Royal wrote:
>> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
>> 
>>> On 2026-07-05 05:57, Maria Sophia wrote:
>>>> Maria Sophia wrote:
>>>>> I finally forced Android 16 to behave like a real operating system again.
>>>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>>>>
>>>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>>>>
>>>> Windows and Linux can easily open HTML books stored in custom top-level
>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>>>>
>>>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>>>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>>>
>>> I don't know what are "books" in this context.
>>>
>>> If you mean electronic books, for me they are epubs, and I handle them
>>> with Calibre.
>>>
>>> https://www.gutenberg.org/ebooks/79019
>>>
>>> I see html format is available, but I see no reason to use it, unless as
>>> an intermediary to transform to something else.
>> 
>> Quite a lot of technical documentation is published as an html
>>   'book'. This for example:
>> https://doc.rust-lang.org/book/
>> 
>> Historically html is a dialect of sgml, which was designed for
>>   documentation
> 
> Ok...
> 
> Heh, they charge 45$ for the epub version.
> 
> No ZIP that I can see :-?
> 
> I would have to download using wget, and this tool modifies the links so 
> that they are correct for your local installation.
> 
> I wonder if Calibre can convert that to epub.

As I posted about in (rec.autos.tech) last month:
Subject: Free Vehicle Service Manuals
Date: 11 Jun 2026 
Message-ID: <6a2a43e6@news.ausics.net>

I've been using Operation CHARM for some time (https://charm.li/),
which covers vehicles (USA & Canada models) from 1982 to 2013. Now I
see there's a new site, LEMON, with service manuals for vehicles
from 1960 to 2025:

https://lemon-manuals.la/

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#154349

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

> On 2026-07-05 15:48, Dave Royal wrote:
>> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
>> 
>>> On 2026-07-05 05:57, Maria Sophia wrote:
>>>> Maria Sophia wrote:
>>>>> I finally forced Android 16 to behave like a real operating system again.
>>>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>>>>
>>>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>>>>
>>>> Windows and Linux can easily open HTML books stored in custom top-level
>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>>>>
>>>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>>>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>>>
>>> I don't know what are "books" in this context.
>>>
>>> If you mean electronic books, for me they are epubs, and I handle them
>>> with Calibre.
>>>
>>> https://www.gutenberg.org/ebooks/79019
>>>
>>> I see html format is available, but I see no reason to use it, unless as
>>> an intermediary to transform to something else.
>> 
>> Quite a lot of technical documentation is published as an html
>>   'book'. This for example:
>> https://doc.rust-lang.org/book/
>> 
>> Historically html is a dialect of sgml, which was designed for
>>   documentation
> 
> Ok...
> 
> Heh, they charge 45$ for the epub version.
> 
> No ZIP that I can see :-?
> 
> I would have to download using wget, and this tool modifies the links so 
> that they are correct for your local installation.

The links are normally relative to the document root, so no need
 to modify them.

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

> I wonder if Calibre can convert that to epub.

If so I suppose you'd have to specify the medium size - eg A4. An
 html file is liquid - it fills any window or page size.
 
-- 
Remove numerics from my email address.

[toc] | [prev] | [next] | [standalone]

#154350

On 2026-07-05 22:00, Dave Royal wrote:
> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
> 
>> On 2026-07-05 15:48, Dave Royal wrote:
>>> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
>>>
>>>> On 2026-07-05 05:57, Maria Sophia wrote:
>>>>> Maria Sophia wrote:
>>>>>> I finally forced Android 16 to behave like a real operating system again.
>>>>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>>>>>
>>>>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>>>>>
>>>>> Windows and Linux can easily open HTML books stored in custom top-level
>>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>>>>>
>>>>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>>>>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>>>>
>>>> I don't know what are "books" in this context.
>>>>
>>>> If you mean electronic books, for me they are epubs, and I handle them
>>>> with Calibre.
>>>>
>>>> https://www.gutenberg.org/ebooks/79019
>>>>
>>>> I see html format is available, but I see no reason to use it, unless as
>>>> an intermediary to transform to something else.
>>>
>>> Quite a lot of technical documentation is published as an html
>>>    'book'. This for example:
>>> https://doc.rust-lang.org/book/
>>>
>>> Historically html is a dialect of sgml, which was designed for
>>>    documentation
>>
>> Ok...
>>
>> Heh, they charge 45$ for the epub version.
>>
>> No ZIP that I can see :-?
>>
>> I would have to download using wget, and this tool modifies the links so
>> that they are correct for your local installation.
> 
> The links are normally relative to the document root, so no need
>   to modify them.
> 
> In the days when software was released on CD such html documentation was common. But any browser could read local http files then.
> 

Yes, I know. But calling that "book" confused me.


>> I wonder if Calibre can convert that to epub.
> 
> If so I suppose you'd have to specify the medium size - eg A4. An
>   html file is liquid - it fills any window or page size.

Epub is also liquid. PDF is not.


I did a quick test. I downloaded that "book":

wget   --mirror   --convert-links   --adjust-extension   --page-requisites   --no-parent   -nH   https://doc.rust-lang.org/stable/book/

Then told Calibre to import it, then to convert to epub, which it did.

cer@Laicolasse:~/Documents/Calibre Library/Unknown/The Rust Programming Language - The Rust Programming Language (80)> l
total 5512
drwxr-xr-x 2 cer users     155 Jul  5 22:38 ./
drwxr-xr-x 5 cer users     150 Jul  5 22:36 ../
-rw-r--r-- 1 cer users    1114 Jul  5 22:39 metadata.opf
-rw-r--r-- 1 cer users 3025227 Jul  5 22:38 The Rust Programming Language - The Rust P - Unknown.epub
-rw-r--r-- 1 cer users 2610606 Jul  5 22:36 The Rust Programming Language - The Rust P - Unknown.zip
cer@Laicolasse:~/Documents/Calibre Library/Unknown/The Rust Programming Language - The Rust Programming Language (80)>


Of course, it is up for someone interested in whatever book to actually tailor the conversion to his convenience. In my test, it seems to stop at chapter 3 for some reason. Surely someone has done this before and there is documentation somewhere.

Calibre is also capable of viewing the ZIP file directly, but it calls firefox to do the actual viewing.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154354

Carlos E. R. wrote:
> Calibre is also capable of viewing the ZIP file directly, 
> but it calls firefox to do the actual viewing.

Hi Carlos,

I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.

The resulting EPUB file was 400MB so it took a while for Calibre to load it
the first time (due to all the caching that Calibre does on first loading).

When I looked at the file inside of Thorium, I got an appreciation for why
HTML is an excellent medium, as there were tens of thousands of connected
pages and images, where an EPUB can handle it, but it's slow as all hell.

Since the EPUB itself was 400MB, I didn't even bother copying to Android.
If it's slow on Windows, it's likely gonna be even slower on Android.

The HTML is, by way of contrast, is virtually instant when clicking about.

When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
like memory errors) after about an hour or two, so I gave up on the PDF.

Looking into my c:\app\editor\epub directory, these seem to be most common
cross platform EPUB readers, where I've sorted by large file handling.
 thorium 
  most stable & fastest for huge image-heavy epubs like textbooks
 calibre 
  most powerful for conversion & repair of image-heavy epubs
 redium desktop
  sibling of thorium but less polished than thorium
 okular 
  KDE document viewer with medium-level EPUB support via plugins
 hamster
  best for small epubs
 lucidor
  best for very small epubs
 fbreader
  suitable for smaller epubs
 adobe digital editions
  not suitable as the epub engine is old and fragile
 sumatra pdf
  fast for small epubs

In summary, for certain kinds of references (such as highly cross-linked
highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
-- 
The best way to learn is to try it and then learn from the mistakes.

[toc] | [prev] | [next] | [standalone]

#154356

On 2026-07-06 07:06, Maria Sophia wrote:
> Carlos E. R. wrote:
>> Calibre is also capable of viewing the ZIP file directly,
>> but it calls firefox to do the actual viewing.
> 
> Hi Carlos,
> 
> I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.

Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

> 
> The resulting EPUB file was 400MB so it took a while for Calibre to load it
> the first time (due to all the caching that Calibre does on first loading).
> 

I have never seen an epub that big. In my case, the book that I tested 
with can be purchased in epub format. Possibly the epub is available on 
the emule network or such (for testing, of course).

> When I looked at the file inside of Thorium, I got an appreciation for why
> HTML is an excellent medium, as there were tens of thousands of connected
> pages and images, where an EPUB can handle it, but it's slow as all hell.
> 
> Since the EPUB itself was 400MB, I didn't even bother copying to Android.
> If it's slow on Windows, it's likely gonna be even slower on Android.
> 
> The HTML is, by way of contrast, is virtually instant when clicking about.
> 
> When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
> like memory errors) after about an hour or two, so I gave up on the PDF.

I don't like PDF for books, because it doesn't flow the text. It is 
fixed size. You need a display that matches the design size and 
resolution (or better).

> 
> Looking into my c:\app\editor\epub directory, these seem to be most common
> cross platform EPUB readers, where I've sorted by large file handling.
>   thorium
>    most stable & fastest for huge image-heavy epubs like textbooks
>   calibre
>    most powerful for conversion & repair of image-heavy epubs
>   redium desktop
>    sibling of thorium but less polished than thorium
>   okular
>    KDE document viewer with medium-level EPUB support via plugins
>   hamster
>    best for small epubs
>   lucidor
>    best for very small epubs
>   fbreader
>    suitable for smaller epubs
>   adobe digital editions
>    not suitable as the epub engine is old and fragile
>   sumatra pdf
>    fast for small epubs
> 
> In summary, for certain kinds of references (such as highly cross-linked
> highly imaged technical manuals and textbooks), a zip HTML is likely ideal.

Seeing that calibre imports the html directory as a zip file, it is 
possible that there is software out there that directly renders readable 
those ZIP files. Or even hardware.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154358

On 2026-07-06 12:05, Carlos E. R. wrote:
> On 2026-07-06 07:06, Maria Sophia wrote:
>> Carlos E. R. wrote:

>> In summary, for certain kinds of references (such as highly cross-linked
>> highly imaged technical manuals and textbooks), a zip HTML is likely 
>> ideal.
> 
> Seeing that calibre imports the html directory as a zip file, it is 
> possible that there is software out there that directly renders readable 
> those ZIP files. Or even hardware.


I asked chatgpt.

Q: I have recently seen "books" transferred as a ZIP archive of a large 
html tree. Calibre calls a browser to see a page at a time, AFAIK. I 
wonder if there is software that displays that ZIP as a book directly, 
better on a tablet.

Yes. What you've seen is often called an **HTMLZ** (HTML in a ZIP), or 
simply a ZIP containing a static website. It's a nice format because it 
preserves hyperlinks, CSS, images, and search indexes while compressing 
very well.

The difficulty is that there isn't a universally adopted "book reader" 
for zipped HTML trees analogous to EPUB readers.

Here are the main options:

* **Calibre**: as you note, it essentially extracts or serves the HTML 
and uses an embedded browser. It isn't really a dedicated HTML book 
renderer.

* **KOReader** (Android, Linux, Kobo, Kindle): probably the closest to 
what you're looking for. It primarily supports EPUB, PDF, DjVu, etc., 
but it can also browse HTML files. However, it doesn't natively treat an 
arbitrary ZIPped website as a single book.

* **Static website in a browser**: on Android or Linux you can simply 
unzip the archive and open `index.html`. Browsers do a surprisingly good 
job. Firefox on Android, for example, can open local HTML files (with a 
bit of help from a file manager).

* **Mini HTTP server**: many people run

   ```bash
   python3 -m http.server
   ```

   in the extracted directory and browse to `http://localhost:8000/`. 
This avoids issues some browsers have with `file://` URLs and JavaScript.

### Why EPUB became dominant

An EPUB is essentially:

```
book.epub
     └── ZIP archive
         ├── XHTML files
         ├── CSS
         ├── images
         ├── metadata
         └── navigation (table of contents)
```

So EPUB is really a standardized HTML tree in a ZIP with metadata. 
Readers know how to paginate it, remember your position, annotate, 
search, adjust fonts, etc. A raw ZIP of HTML lacks that standard structure.

### If your documentation is generated

For things like Rust docs, Python docs, man-page collections, or API 
documentation, I would actually **keep them as HTML** rather than 
converting to EPUB. Documentation relies on hyperlinks more than on 
linear reading, and browsers excel at that.

### An interesting possibility

It wouldn't be hard to write a small application that:

* opens a ZIP without extracting it permanently,
* serves its contents through an embedded HTTP server,
* displays them in a WebView,
* remembers your position and reading history.

Modern ZIP libraries allow random access, so the pages needn't even be 
unpacked to disk. I'm a little surprised there isn't a well-known 
open-source app that does exactly this, because it would be ideal for 
offline documentation on a tablet.

Out of curiosity, are you mainly thinking of **technical documentation** 
(Rust, Python, Linux man pages, etc.), or of **books** distributed as 
HTML? The best tool tends to differ between those two use cases.


Q: I was thinking of that rust documentation, but as an example of the 
system.

I think the Rust documentation is actually an excellent example because 
it's *not* a linear book in the EPUB sense. It's a small self-contained 
website. That changes what the ideal reader looks like.

If I were designing an offline documentation system today, I'd package 
it as:

```
rust-book.zip
├── index.html
├── ch01.html
├── css/
├── fonts/
├── images/
├── search-index.js
└── ...
```

and the "reader" would simply:

* mount or read the ZIP directly;
* expose it through an internal HTTP server (or a custom URL scheme);
* render it in a browser component (WebView, Qt WebEngine, etc.);
* remember the last page, bookmarks, and maybe annotations.

No conversion to EPUB would be necessary.

The nice thing is that all the navigation, CSS, search, and JavaScript 
already exist. You'd just be providing a pleasant container around them.

### Existing software gets close

There are a few projects in the same spirit:

* **Zeal** (Linux/Windows) and **Dash** (macOS) store documentation in 
compressed docsets. Internally, these are HTML trees plus an index 
database. They're aimed at API documentation rather than books.
* **DevDocs Offline** projects cache the HTML documentation for offline use.
* Browser-based **Progressive Web Apps** can cache entire documentation 
sites for offline use, although support varies.

The common theme is that they're all essentially shipping HTML, not 
inventing a new document format.

### Why browsers aren't terrible readers anymore

Twenty years ago, HTML was a poor "book" format because pages were 
static and browsers had little support for reading workflows. Nowadays 
browsers have:

* full-text search,
* history,
* zoom,
* dark mode,
* responsive layout,
* good typography,
* JavaScript-based navigation.

For technical documentation, that's often *better* than an EPUB reader, 
because the documentation was authored as a website in the first place.

### A feature I'd still like to see

One thing I haven't seen is a generic **"ZIP book reader"**: point it at 
any ZIP containing an `index.html`, and it treats it like a book. It 
would need only a handful of features:

* open ZIP without extracting it;
* detect the entry page (`index.html`);
* keep reading position;
* bookmarks;
* optional full-text search (using an embedded index if present).

That would cover not only the Rust Book, but also many documentation 
bundles, offline manuals, and even archived wikis. It's a surprisingly 
simple concept, yet I don't know of a mainstream application dedicated 
to it.



-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154362

Carlos E. R. wrote:
> Q: I have recently seen "books" transferred as a ZIP archive of a large 
> html tree. Calibre calls a browser to see a page at a time, AFAIK. I 
> wonder if there is software that displays that ZIP as a book directly, 
> better on a tablet.
> 
> Yes. What you've seen is often called an **HTMLZ** (HTML in a ZIP), or 
> simply a ZIP containing a static website. It's a nice format because it 
> preserves hyperlinks, CSS, images, and search indexes while compressing 
> very well.
> 
> The difficulty is that there isn't a universally adopted "book reader" 
> for zipped HTML trees analogous to EPUB readers.
> 
> Here are the main options:
> 
> * **Calibre**: as you note, it essentially extracts or serves the HTML 
> and uses an embedded browser. It isn't really a dedicated HTML book 
> renderer.
> 
> * **KOReader** (Android, Linux, Kobo, Kindle): probably the closest to 
> what you're looking for. It primarily supports EPUB, PDF, DjVu, etc., 
> but it can also browse HTML files. However, it doesn't natively treat an 
> arbitrary ZIPped website as a single book.
> 
> * **Static website in a browser**: on Android or Linux you can simply 
> unzip the archive and open `index.html`. Browsers do a surprisingly good 
> job. Firefox on Android, for example, can open local HTML files (with a 
> bit of help from a file manager).
> 
> * **Mini HTTP server**: many people run
> 
>    ```bash
>    python3 -m http.server
>    ```
> 
>    in the extracted directory and browse to `http://localhost:8000/`. 
> This avoids issues some browsers have with `file://` URLs and JavaScript.
> 
> ### Why EPUB became dominant
> 
> An EPUB is essentially:
> 
> ```
> book.epub
>      „€€ ZIP archive
>          †€€ XHTML files
>          †€€ CSS
>          †€€ images
>          †€€ metadata
>          „€€ navigation (table of contents)
> ```
> 
> So EPUB is really a standardized HTML tree in a ZIP with metadata. 
> Readers know how to paginate it, remember your position, annotate, 
> search, adjust fonts, etc. A raw ZIP of HTML lacks that standard structure.
> 
> ### If your documentation is generated
> 
> For things like Rust docs, Python docs, man-page collections, or API 
> documentation, I would actually **keep them as HTML** rather than 
> converting to EPUB. Documentation relies on hyperlinks more than on 
> linear reading, and browsers excel at that.
> 
> ### An interesting possibility
> 
> It wouldn't be hard to write a small application that:
> 
> * opens a ZIP without extracting it permanently,
> * serves its contents through an embedded HTTP server,
> * displays them in a WebView,
> * remembers your position and reading history.
> 
> Modern ZIP libraries allow random access, so the pages needn't even be 
> unpacked to disk. I'm a little surprised there isn't a well-known 
> open-source app that does exactly this, because it would be ideal for 
> offline documentation on a tablet.
> 
> Out of curiosity, are you mainly thinking of **technical documentation** 
> (Rust, Python, Linux man pages, etc.), or of **books** distributed as 
> HTML? The best tool tends to differ between those two use cases.
> 
> 
> Q: I was thinking of that rust documentation, but as an example of the 
> system.
> 
> I think the Rust documentation is actually an excellent example because 
> it's *not* a linear book in the EPUB sense. It's a small self-contained 
> website. That changes what the ideal reader looks like.
> 
> If I were designing an offline documentation system today, I'd package 
> it as:
> 
> ```
> rust-book.zip
> †€€ index.html
> †€€ ch01.html
> †€€ css/
> †€€ fonts/
> †€€ images/
> †€€ search-index.js
> „€€ ...
> ```
> 
> and the "reader" would simply:
> 
> * mount or read the ZIP directly;
> * expose it through an internal HTTP server (or a custom URL scheme);
> * render it in a browser component (WebView, Qt WebEngine, etc.);
> * remember the last page, bookmarks, and maybe annotations.
> 
> No conversion to EPUB would be necessary.
> 
> The nice thing is that all the navigation, CSS, search, and JavaScript 
> already exist. You'd just be providing a pleasant container around them.
> 
> ### Existing software gets close
> 
> There are a few projects in the same spirit:
> 
> * **Zeal** (Linux/Windows) and **Dash** (macOS) store documentation in 
> compressed docsets. Internally, these are HTML trees plus an index 
> database. They're aimed at API documentation rather than books.
> * **DevDocs Offline** projects cache the HTML documentation for offline use.
> * Browser-based **Progressive Web Apps** can cache entire documentation 
> sites for offline use, although support varies.
> 
> The common theme is that they're all essentially shipping HTML, not 
> inventing a new document format.
> 
> ### Why browsers aren't terrible readers anymore
> 
> Twenty years ago, HTML was a poor "book" format because pages were 
> static and browsers had little support for reading workflows. Nowadays 
> browsers have:
> 
> * full-text search,
> * history,
> * zoom,
> * dark mode,
> * responsive layout,
> * good typography,
> * JavaScript-based navigation.
> 
> For technical documentation, that's often *better* than an EPUB reader, 
> because the documentation was authored as a website in the first place.
> 
> ### A feature I'd still like to see
> 
> One thing I haven't seen is a generic **"ZIP book reader"**: point it at 
> any ZIP containing an `index.html`, and it treats it like a book. It 
> would need only a handful of features:
> 
> * open ZIP without extracting it;
> * detect the entry page (`index.html`);
> * keep reading position;
> * bookmarks;
> * optional full-text search (using an embedded index if present).
> 
> That would cover not only the Rust Book, but also many documentation 
> bundles, offline manuals, and even archived wikis. It's a surprisingly 
> simple concept, yet I don't know of a mainstream application dedicated 
> to it.

Wow. That was jam-packed with good information. Let's summarize first. 

HTMLZ = HTML-in-a-ZIP.  
It's literally just a ZIP file containing a folder of HTML pages, images,
CSS and JavaScript. It's apparently what my reference manual happens to be.

EPUB is basically the same idea, but with a standardized structure and
extra metadata so book readers know how to paginate, bookmark, search, etc.

Apparently there is no universal HTMLZ reader on tablets.
EPUB readers exist everywhere, but HTMLZ readers do not.

Generally we can read a ZIPped HTML tree by
 a. Unzipping it and opening index.html in a browser
    (which is what I did on Windows and it would work on Linux too)
 b. Or running a tiny local web server and browsing to it
    (which Andy, Carlos & I had to do on Android due to SAF rules)
 c. Or using specialized documentation apps (Zeal, Dash, DevDocs)
    (none of which do I have any experience whatsoever using)
    i. Zeal (Linux/Windows)
    ii. Dash (macOS/iOS)
    iii. DevDocs (offline, for programming docs)
    iv. Kiwix (reads ZIM files, not ZIPs, but can convert)

I agree that, for technical documentation, HTML is often better than EPUB
because it's designed for hyperlinks, search and non-linear navigation.

It would be nice if someone writes a simple app that opens a ZIP, serves it
internally and displays it like a book-because it would solve all of this	.

In my Android 16 case, and also in the case of Andy & Carlos on Android,
the real problem was SAF doesn't allow relative URLs in custom folders.

So any solution that works on Android, has to take SAF limitations into
account, where I looked up how to view these thigns on iOS & it's similar.

On Android, we found that running a tiny web server worked. 
But on Android 10+, we could also have tried what Carlos used:
 a. An older version of CX file Manager has a built-in web server
 b. So does X-plore File Manager
 c. And I'm told MiXplorer has excellent HTML-Z handling features

Interestingly, iOS seems to handle relative links *better* than Android.
What's *different* about iOS is that iOS doesn't use SAF. Yipee!

An HTMLZ (a ZIP full of HTML with relative paths) will work on an iPad.  
 a. iPadOS does not break relative links the way Android 10+ does.
 b. iPadOS does support relative paths inside an HTMLZ
 c. iPadOS gives the browser real filesystem paths, not SAF streams.
 d. So the browser sees the directory structure normally.
This means the 500MB shop manual will behave like a normal offline website.
Safari will load the entire manual correctly.

Even so, we can still use the server method on iOS as we did on Android.
All of thse can run the same "python3 -m http.server" we used on Android.
 a. iSH (Linux emulator)
 b. Pythonista
 c. Kodex
Once we start the HTTP server in $DOCUMENT_ROOT, then we point a browser to
 <http://localhost:8000/>

So, had I tried my iPads first, prior to Android, it would have worked.
(Although it's an Apple disaster trying to get a large file onto the iPad.)

In summary, on Android 10+ the SAF mechanism destroys POSIX paths outside
of the four public directories for web browser, so in order to put huge
complex HTML-Z documentation on Android 16 outside of the four public
directories, we had to employ a local server (or convert to EPUB/PDF).

Overall, I'm glad I ran into this problem because I learned about SAF and
how it screws up POSIX file paths in custom folders when browsing HTML.

And, I learned from testing Calibre for Carlos that EPUBs have a fantastic
search mechanism for extremely complex data structures (as good as PDF).

And I learned that for huge, image-heavy, cross-linked manuals, HTML in a
browser is the fastest method, so there's a place for HTMLZ after all.
-- 
I don't favor platforms; I measure them as I report truthfully about them.

[toc] | [prev] | [next] | [standalone]

#154364

On 2026-07-06 18:28, Maria Sophia wrote:
> Carlos E. R. wrote:
>> Q: I have recently seen "books" transferred as a ZIP archive of a large
>> html tree. Calibre calls a browser to see a page at a time, AFAIK. I
>> wonder if there is software that displays that ZIP as a book directly,
>> better on a tablet.

...

> I agree that, for technical documentation, HTML is often better than EPUB
> because it's designed for hyperlinks, search and non-linear navigation.
> 
> It would be nice if someone writes a simple app that opens a ZIP, serves it
> internally and displays it like a book-because it would solve all of this	.
> 
> In my Android 16 case, and also in the case of Andy & Carlos on Android,
> the real problem was SAF doesn't allow relative URLs in custom folders.
> 
> So any solution that works on Android, has to take SAF limitations into
> account, where I looked up how to view these thigns on iOS & it's similar.
> 
> On Android, we found that running a tiny web server worked.
> But on Android 10+, we could also have tried what Carlos used:
>   a. An older version of CX file Manager has a built-in web server

It is a current tablet with Android 16 and a current version of CX, 
installed via Google Play, version 2.7.6. I tried an html tree, not htmlz.

>   b. So does X-plore File Manager
>   c. And I'm told MiXplorer has excellent HTML-Z handling features
> 
> Interestingly, iOS seems to handle relative links *better* than Android.
> What's *different* about iOS is that iOS doesn't use SAF. Yipee!
> 
> An HTMLZ (a ZIP full of HTML with relative paths) will work on an iPad.
>   a. iPadOS does not break relative links the way Android 10+ does.
>   b. iPadOS does support relative paths inside an HTMLZ
>   c. iPadOS gives the browser real filesystem paths, not SAF streams.
>   d. So the browser sees the directory structure normally.
> This means the 500MB shop manual will behave like a normal offline website.
> Safari will load the entire manual correctly.
> 
> Even so, we can still use the server method on iOS as we did on Android.
> All of thse can run the same "python3 -m http.server" we used on Android.
>   a. iSH (Linux emulator)
>   b. Pythonista
>   c. Kodex
> Once we start the HTTP server in $DOCUMENT_ROOT, then we point a browser to
>   <http://localhost:8000/>
> 
> So, had I tried my iPads first, prior to Android, it would have worked.
> (Although it's an Apple disaster trying to get a large file onto the iPad.)
> 
> In summary, on Android 10+ the SAF mechanism destroys POSIX paths outside
> of the four public directories for web browser, so in order to put huge
> complex HTML-Z documentation on Android 16 outside of the four public
> directories, we had to employ a local server (or convert to EPUB/PDF).
> 
> Overall, I'm glad I ran into this problem because I learned about SAF and
> how it screws up POSIX file paths in custom folders when browsing HTML.
> 
> And, I learned from testing Calibre for Carlos that EPUBs have a fantastic
> search mechanism for extremely complex data structures (as good as PDF).
> 
> And I learned that for huge, image-heavy, cross-linked manuals, HTML in a
> browser is the fastest method, so there's a place for HTMLZ after all.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154359

Carlos E. R. wrote:
>> I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
>> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.
> 
> Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

My desktop is from 2009. It's still working well, but this stressed it. :)

>> The resulting EPUB file was 400MB so it took a while for Calibre to load it
>> the first time (due to all the caching that Calibre does on first loading).
> 
> I have never seen an epub that big. In my case, the book that I tested 
> with can be purchased in epub format. Possibly the epub is available on 
> the emule network or such (for testing, of course).

My experience had been the same as yours. EPUBs are generally quite small.
This one has tens of thousands of separate images yet very little text.

>> When I looked at the file inside of Thorium, I got an appreciation for why
>> HTML is an excellent medium, as there were tens of thousands of connected
>> pages and images, where an EPUB can handle it, but it's slow as all hell.
>> 
>> Since the EPUB itself was 400MB, I didn't even bother copying to Android.
>> If it's slow on Windows, it's likely gonna be even slower on Android.
>> 
>> The HTML is, by way of contrast, is virtually instant when clicking about.
>> 
>> When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
>> like memory errors) after about an hour or two, so I gave up on the PDF.
> 
> I don't like PDF for books, because it doesn't flow the text. It is 
> fixed size. You need a display that matches the design size and 
> resolution (or better).

I agree that PDF isn't all that great for books in that, for me, my eyes
aren't so great and a PDF makes you sit and stare at it to read it.

I prefer to convert the (text) PDF to audio using cross platform balabolka
freeware which then turns any (text) PDF into an audio book.

It's not as good as a human reader for some books, e.g., when I converted
Einstein's 1916 (updated in 1922) book on relativity, calculations are
messed up when spoken by balabolka's conversion utilities.

But now I'm one of the few non-physicists who understand gravity as a
result, since I was in a compression/decompression chamber for a month.

As an aside, almost nobody understands gravity. One in a million I'd bet.
And even as I understand it to that level, there's still much I don't know.

>> Looking into my c:\app\editor\epub directory, these seem to be most common
>> cross platform EPUB readers, where I've sorted by large file handling.
>>   thorium
>>    most stable & fastest for huge image-heavy epubs like textbooks
>>   calibre
>>    most powerful for conversion & repair of image-heavy epubs
>>   redium desktop
>>    sibling of thorium but less polished than thorium
>>   okular
>>    KDE document viewer with medium-level EPUB support via plugins
>>   hamster
>>    best for small epubs
>>   lucidor
>>    best for very small epubs
>>   fbreader
>>    suitable for smaller epubs
>>   adobe digital editions
>>    not suitable as the epub engine is old and fragile
>>   sumatra pdf
>>    fast for small epubs
>> 
>> In summary, for certain kinds of references (such as highly cross-linked
>> highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
> 
> Seeing that calibre imports the html directory as a zip file, it is 
> possible that there is software out there that directly renders readable 
> those ZIP files. Or even hardware.

I agree that Calibre had no problem importing the single 500MB zip file.
It just took a long time, but Calibre didn't even blink on the contents.

It's just that my circa 2009 PC runs slowly when it's time to crunch it.

I've learned there's a good reason highly cross-linked documents filled
with images and almost no text are supplied in a zip file HTML format.

It's amazing how fast HTML is compared to the EPUB, although the epub has
the distinct advantage of a fantastic search mechanism that shocked me.

With EPUB, when you search, you get every instance but every line of every
instance (much like you'd get with a (text) PDF, so that was really nice.

So if you need to search a huge 500MB HTML document containing tens of
thousands of files, converting it to a 400MB EPUB allows that fantastic
search, but if you need to actually navigate it, an HTML server wins out.
-- 
Converting 400MB EPUBs on a 2009 desktop as HTML loads faster than time.

[toc] | [prev] | [next] | [standalone]

#154365

On 2026-07-06 17:36, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
>>> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.
>>
>> Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.
> 
> My desktop is from 2009. It's still working well, but this stressed it. :)
> 
>>> The resulting EPUB file was 400MB so it took a while for Calibre to load it
>>> the first time (due to all the caching that Calibre does on first loading).
>>
>> I have never seen an epub that big. In my case, the book that I tested
>> with can be purchased in epub format. Possibly the epub is available on
>> the emule network or such (for testing, of course).
> 
> My experience had been the same as yours. EPUBs are generally quite small.
> This one has tens of thousands of separate images yet very little text.
> 
>>> When I looked at the file inside of Thorium, I got an appreciation for why
>>> HTML is an excellent medium, as there were tens of thousands of connected
>>> pages and images, where an EPUB can handle it, but it's slow as all hell.
>>>
>>> Since the EPUB itself was 400MB, I didn't even bother copying to Android.
>>> If it's slow on Windows, it's likely gonna be even slower on Android.
>>>
>>> The HTML is, by way of contrast, is virtually instant when clicking about.
>>>
>>> When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
>>> like memory errors) after about an hour or two, so I gave up on the PDF.
>>
>> I don't like PDF for books, because it doesn't flow the text. It is
>> fixed size. You need a display that matches the design size and
>> resolution (or better).
> 
> I agree that PDF isn't all that great for books in that, for me, my eyes
> aren't so great and a PDF makes you sit and stare at it to read it.

Maybe it would be easier to read in an ebook device, using epaper which 
doesn't shine.

> 
> I prefer to convert the (text) PDF to audio using cross platform balabolka
> freeware which then turns any (text) PDF into an audio book.
> 
> It's not as good as a human reader for some books, e.g., when I converted
> Einstein's 1916 (updated in 1922) book on relativity, calculations are
> messed up when spoken by balabolka's conversion utilities.
> 
> But now I'm one of the few non-physicists who understand gravity as a
> result, since I was in a compression/decompression chamber for a month.
> 
> As an aside, almost nobody understands gravity. One in a million I'd bet.
> And even as I understand it to that level, there's still much I don't know.
> 
>>> Looking into my c:\app\editor\epub directory, these seem to be most common
>>> cross platform EPUB readers, where I've sorted by large file handling.
>>>    thorium
>>>     most stable & fastest for huge image-heavy epubs like textbooks
>>>    calibre
>>>     most powerful for conversion & repair of image-heavy epubs
>>>    redium desktop
>>>     sibling of thorium but less polished than thorium
>>>    okular
>>>     KDE document viewer with medium-level EPUB support via plugins
>>>    hamster
>>>     best for small epubs
>>>    lucidor
>>>     best for very small epubs
>>>    fbreader
>>>     suitable for smaller epubs
>>>    adobe digital editions
>>>     not suitable as the epub engine is old and fragile
>>>    sumatra pdf
>>>     fast for small epubs
>>>
>>> In summary, for certain kinds of references (such as highly cross-linked
>>> highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
>>
>> Seeing that calibre imports the html directory as a zip file, it is
>> possible that there is software out there that directly renders readable
>> those ZIP files. Or even hardware.
> 
> I agree that Calibre had no problem importing the single 500MB zip file.
> It just took a long time, but Calibre didn't even blink on the contents.
> 
> It's just that my circa 2009 PC runs slowly when it's time to crunch it.
> 
> I've learned there's a good reason highly cross-linked documents filled
> with images and almost no text are supplied in a zip file HTML format.
> 
> It's amazing how fast HTML is compared to the EPUB, although the epub has
> the distinct advantage of a fantastic search mechanism that shocked me.
> 
> With EPUB, when you search, you get every instance but every line of every
> instance (much like you'd get with a (text) PDF, so that was really nice.

Yes, my kobo reader does search easily, I noticed.

> 
> So if you need to search a huge 500MB HTML document containing tens of
> thousands of files, converting it to a 400MB EPUB allows that fantastic
> search, but if you need to actually navigate it, an HTML server wins out.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.mobile.android

csiph-web