For our YMCA Adventure Guides monthly meeting we want the girls to read a
book that one of the guys' kids found and sent to us in a bunch of formats,
but we want to make a local web page for the kids to read on a 192.168.1.x
local link.

He sent us the following formats.
book.docx, book.mobi, book.htmlz & book.pdf

The "HTMLZ" would seem to be the best but it's one file.
When we use Firefox "File > Open" and point Firefox to the book.htmlz, it
wants to save it (which isn't helpful at all) or open with something else.

If it's HTML, why can't Firefox open it as HTML for the kids to read?

On 01/31/2024 11:55 AM, Bradley wrote:
> For our YMCA Adventure Guides monthly meeting we want the girls to read a
> book that one of the guys' kids found and sent to us in a bunch of formats,
> but we want to make a local web page for the kids to read on a 192.168.1.x
> local link.
>
> He sent us the following formats.
> book.docx, book.mobi, book.htmlz & book.pdf
>
> The "HTMLZ" would seem to be the best but it's one file.
> When we use Firefox "File > Open" and point Firefox to the book.htmlz, it
> wants to save it (which isn't helpful at all) or open with something else.
>
> If it's HTML, why can't Firefox open it as HTML for the kids to read?
I can not answer your question directly, but for small organizations, I
believe it is best to post the book in the PDF format. The PDF format
is near universally available on all devices. And can be opened in 99%
of the programs on the devices of the people at the YMCA.

The format is an exact reproduction of the document including formatting.

If you are reading the PDF format you can add and save comments to the
documents. This can be used to mark where you left of reading the
document.

Docx is a proprietary form belonging to Microsoft. Anybody with a MS
program or has a good compatible program can open it, but from
experience many cannot.

MOBI is as I understand a Kindel format again not all reader programs
can open this proprietary format.

HTMLZ again is a proprietary format and there is a limited number of
programs that can open they

On 2024-01-31 18:28, knuttle wrote:
> On 01/31/2024 11:55 AM, Bradley wrote:
>> For our YMCA Adventure Guides monthly meeting we want the girls to read a
>> book that one of the guys' kids found and sent to us in a bunch of
>> formats,
>> but we want to make a local web page for the kids to read on a
>> 192.168.1.x
>> local link.
>>
>> He sent us the following formats.
>> book.docx, book.mobi, book.htmlz & book.pdf

....

> Docx is a proprietary form belonging to Microsoft.  Anybody with a MS
> program or has a good compatible program can open it, but from
> experience many cannot.

No, .docx is an open format, developed by Microsoft, Ecma, ISO, and IEC.

https://en.wikipedia.org/wiki/Office_Open_XML

>
> MOBI is as I understand a Kindel format again not all reader programs
> can open this proprietary format.
>
> HTMLZ again is a proprietary format and there is a limited number of
> programs that can open they

Calibre can open them all, AFAIK.

--
Cheers, Carlos.

Bradley <bradley@nospam.com> wrote:

> For our YMCA Adventure Guides monthly meeting we want the girls to
> read a book that one of the guys' kids found and sent to us in a
> bunch of formats, but we want to make a local web page for the kids
> to read on a 192.168.1.x local link.
>
> He sent us the following formats. book.docx, book.mobi, book.htmlz &
> book.pdf
>
> The "HTMLZ" would seem to be the best but it's one file. When we use
> Firefox "File > Open" and point Firefox to the book.htmlz, it wants
> to save it (which isn't helpful at all) or open with something else.
>
> If it's HTML, why can't Firefox open it as HTML for the kids to read?

Are these different formats all for the same book content? If so, and
as mentioned in another newsgroup where you multi-posted the same
inquiry, just use PDF.

You didn't ask about .docx, so you already have some software that can
view MS Office compressed document files. .mobi is e-book format.
Calibre should open that.

As for HTMLZ, that's a compressed archive of HTML files used within an
HTML document. HTML documents are rarely nowadays just a single .html
file containing only text. They have images, CSS stylesheets, and other
resources. Those resources are references inside the .html document,
but are separate files. Keep all the files together within the same
folder when you decompress the HTMLZ file. Create a folder for the
document files, unzip into that folder, and open the index.html file
(main doc) which can then find its resources in the same folder using
relative addressing. Difficult to be explicit regarding an unknown file
based solely on its file extension. In your other multi-posted thread,
you showed the contents of the zip archive were for an .html file and
its resources. Whether all the other files (resources) can be in the
same folder depends on the paths specified to those resources in the
index.html file. Once you extract all the document and resource files
from the zip archive, yep, Firefox and other web browsers can open the
index.html file. Web browsers are not archive file decompressors.

If the content is the same among various document formats, use the
document format that is easiest for your users. Firefox is
cross-platform, so we don't know where you will be opening the book
files. You'll need a decompressor (extractor) for the compressed
archive file (likely Zip format) that runs on whatever platform where
you will extract the files. When you extract to a folder, put the
folder on your web server, and point the URL you dole out to the path to
the folder and to the index.html file.

The "guy's kid" cannot tell you how he created the HTMLZ file? How
about asking the "guy" to ask his kid to relay the info back to you?

On 01/31/2024 12:47 PM, Carlos E.R. wrote:
> On 2024-01-31 18:28, knuttle wrote:
>> On 01/31/2024 11:55 AM, Bradley wrote:
>>> For our YMCA Adventure Guides monthly meeting we want the girls to
>>> read a
>>> book that one of the guys' kids found and sent to us in a bunch of
>>> formats,
>>> but we want to make a local web page for the kids to read on a
>>> 192.168.1.x
>>> local link.
>>>
>>> He sent us the following formats.
>>> book.docx, book.mobi, book.htmlz & book.pdf
>
> ...
>
>> Docx is a proprietary form belonging to Microsoft.  Anybody with a MS
>> program or has a good compatible program can open it, but from
>> experience many cannot.
>
> No, .docx is an open format, developed by Microsoft, Ecma, ISO, and IEC.
>
> https://en.wikipedia.org/wiki/Office_Open_XML
>
>
>>
>> MOBI is as I understand a Kindel format again not all reader programs
>> can open this proprietary format.
>>
>> HTMLZ again is a proprietary format and there is a limited number of
>> programs that can open they
>
> Calibre can open them all, AFAIK.
>
What is Calibre, in my 50 years with computers I don't believe I have
ever come across it. Is there a place where it can be downloaded. Is
it free?

In article <upe5u3$1l7d5$1@dont-email.me>,
knuttle <keith_nuttle@yahoo.com> wrote:

[Snip]

> >
> What is Calibre, in my 50 years with computers I don't believe I have
> ever come across it. Is there a place where it can be downloaded. Is
> it free?

Calibre is a most excellent E-Book manager/editor/reader, and yes it is
free, though the maintainer does appreciate contributions.

https://calibre-ebook.com/

D.

knuttle <keith_nuttle@yahoo.com> wrote:

> Content-Transfer-Encoding: base64
>
> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
<and more encoded lines>

Please don't use Base 64 encoding in text-only newsgroups.

knuttle <keith_nuttle@yahoo.com> wrote:

>. . .

>Docx is a proprietary form belonging to Microsoft. Anybody with a MS
>program or has a good compatible program can open it, but from
>experience many cannot.

docx isn't proprietary; it's Microsoft's interpretation of Open XML. I
know you are shocked SHOCKED that other Open XML word processors may
have trouble opening the documents.

Any text or graphic that's anchored somehow -- using a table, text box,
or frame -- ends up someplace else.

>MOBI is as I understand a Kindel format again not all reader programs
>can open this proprietary format.

Kindle devices have always been able to read unencrypted MOBI format but
there is proprietary Kindle file format that's different. MOBI was
developed by a competitor that Amazon bought, intending to put them out
of business.

>HTMLZ again is a proprietary format and there is a limited number of
>programs that can open they

I had to look it up. It's an archive of associated files as CSS and
graphics aren't necessarily inline.

On 2024-01-31 20:09, knuttle wrote:
> On 01/31/2024 12:47 PM, Carlos E.R. wrote:
>> On 2024-01-31 18:28, knuttle wrote:
>>> On 01/31/2024 11:55 AM, Bradley wrote:

....

>> Calibre can open them all, AFAIK.
>>
> What is Calibre,  in my 50 years with computers I don't believe I have
> ever come across it.   Is there a place where it can be downloaded.  Is
> it free?

It is the best software for managing ebooks and ereaders.

Yes, it is free.

https://en.wikipedia.org/wiki/Calibre_(software)

Calibre is a cross-platform free and open-source suite of e-book
software. Calibre supports organizing existing e-books into virtual
libraries, displaying, editing, creating and converting e-books, as well
as syncing e-books with a variety of e-readers. Editing books is
supported for EPUB and AZW3 formats. Books in other formats like MOBI
must first be converted to those formats, if they are to be edited.
Calibre also has a large collection of community contributed plugins.[3]

--
Cheers, Carlos.

On 2024-01-31 18:58, VanguardLH wrote:
> The "guy's kid" cannot tell you how he created the HTMLZ file? How
> about asking the "guy" to ask his kid to relay the info back to you?

Very possibly, the book was created as .docx, then converted to other
formats using Calibre.

--
Cheers, Carlos.

VanguardLH <V@nguard.LH> wrote:
>knuttle <keith_nuttle@yahoo.com> wrote:

>>Content-Transfer-Encoding: base64

>> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
><and more encoded lines>

>Please don't use Base 64 encoding in text-only newsgroups.

Why does Thunderbird do this? There is no answer.

VanguardLH <V@nguard.LH> wrote:
>Bradley <bradley@nospam.com> wrote:

>>For our YMCA Adventure Guides monthly meeting we want the girls to
>>read a book that one of the guys' kids found and sent to us in a
>>bunch of formats, but we want to make a local web page for the kids
>>to read on a 192.168.1.x local link.

>>He sent us the following formats. book.docx, book.mobi, book.htmlz &
>>book.pdf

>>The "HTMLZ" would seem to be the best but it's one file. When we use
>>Firefox "File >Open" and point Firefox to the book.htmlz, it wants
>>to save it (which isn't helpful at all) or open with something else.

>>If it's HTML, why can't Firefox open it as HTML for the kids to read?

>Are these different formats all for the same book content? If so, and
>as mentioned in another newsgroup where you multi-posted the same
>inquiry, just use PDF.

PDF doesn't reflow lines. If PDF is intended to be printed on 8 1/2 x 11
paper with reasonable margins, the e-reader doesn't necessarily have
comparable dimensions.

I don't agree. We use PDF in all sorts of situations in which the
document isn't ever going to be printed. It's just the wrong format for
those circumstances.

>. . .

"Adam H. Kerman" <ahk@chinet.com> wrote:

> VanguardLH <V@nguard.LH> wrote:
>>Bradley <bradley@nospam.com> wrote:
>
>>>For our YMCA Adventure Guides monthly meeting we want the girls to
>>>read a book that one of the guys' kids found and sent to us in a
>>>bunch of formats, but we want to make a local web page for the kids
>>>to read on a 192.168.1.x local link.
>
>>>He sent us the following formats. book.docx, book.mobi, book.htmlz &
>>>book.pdf
>
>>>The "HTMLZ" would seem to be the best but it's one file. When we use
>>>Firefox "File >Open" and point Firefox to the book.htmlz, it wants
>>>to save it (which isn't helpful at all) or open with something else.
>
>>>If it's HTML, why can't Firefox open it as HTML for the kids to read?
>
>>Are these different formats all for the same book content? If so, and
>>as mentioned in another newsgroup where you multi-posted the same
>>inquiry, just use PDF.
>
> PDF doesn't reflow lines. If PDF is intended to be printed on 8 1/2 x 11
> paper with reasonable margins, the e-reader doesn't necessarily have
> comparable dimensions.
>
> I don't agree. We use PDF in all sorts of situations in which the
> document isn't ever going to be printed. It's just the wrong format for
> those circumstances.

Didn't think about printing results since the OP never mentioned
printing the doc, but just having it accessible via web server. Seems
the same book is available in multiple doc formats one of which is PDF,
so seems easiest to open it in the web browser, or have the web browser
hand it off to an external handler.

What I see when viewing an HTML doc in a web browser often does not save
well when "printed" into a PDF. Often a textbox with user input gets
truncated. I've run into that when printing to .pdf a web page with my
grocery order that I want a copy since the order page is never
accessible after submitting the order (so details are lost in the order
when I need to request refunds for wrong items, wrong count, or
especially wrong pricing). How well the conversion works from whatever
the kid originally had to however he got it into a PDF file depends on
in what format the doc was originally, and what he used to produce the
..pdf file.

Several unknowns in the OP's inquiry, but I'd go with PDF since that was
a provided format. No mention they want to print the book, just read
it. While a book can be in HTML format, not much need to use input
textboxes, or other elements that would not convert well to printed
form. HTML doesn't have paging: it's one long document. PDFs do have
paging based on paper output selection, so lines meant to be adjacent
could get split across pages. With .docx, formatting directives can be
used to keep pages adjacent within a page. However, I suspect the kid
didn't create the book, but merely "acquired" it from elsewhere.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:
>>VanguardLH <V@nguard.LH> wrote:
>>>Bradley <bradley@nospam.com> wrote:

>>>>For our YMCA Adventure Guides monthly meeting we want the girls to
>>>>read a book that one of the guys' kids found and sent to us in a
>>>>bunch of formats, but we want to make a local web page for the kids
>>>>to read on a 192.168.1.x local link.

>>>>He sent us the following formats. book.docx, book.mobi, book.htmlz &
>>>>book.pdf

>>>>The "HTMLZ" would seem to be the best but it's one file. When we use
>>>>Firefox "File >Open" and point Firefox to the book.htmlz, it wants
>>>>to save it (which isn't helpful at all) or open with something else.

>>>>If it's HTML, why can't Firefox open it as HTML for the kids to read?

>>>Are these different formats all for the same book content? If so, and
>>>as mentioned in another newsgroup where you multi-posted the same
>>>inquiry, just use PDF.

>>PDF doesn't reflow lines. If PDF is intended to be printed on 8 1/2 x 11
>>paper with reasonable margins, the e-reader doesn't necessarily have
>>comparable dimensions.

>>I don't agree. We use PDF in all sorts of situations in which the
>>document isn't ever going to be printed. It's just the wrong format for
>>those circumstances.

>Didn't think about printing results since the OP never mentioned
>printing the doc, but just having it accessible via web server. Seems
>the same book is available in multiple doc formats one of which is PDF,
>so seems easiest to open it in the web browser, or have the web browser
>hand it off to an external handler.

I thought, since we were discussing formats intended for use on e-book
reading devicing, I might rant about PDF.

As far as viewing a document in PDF that's been posted to the Web that's
never going to be printed, aargh. It's just the opposite of what the Web
was intended for. The user is supposed to set his own parameters for
viewing files, his own colors, his own fonts, his own screen width. The
Web was intended to support the user. With PDF, the user has to conform
with layout that he has no ability to change.

Sorry but what the author thinks is ideal format for presenting files on
the Web has nothing to do with what the user experiences. The Web was
designed for flexibility; PDF is an inflexible format already laid out
in a form intended for printing.

>What I see when viewing an HTML doc in a web browser often does not save
>well when "printed" into a PDF.

Right. If I get an unacceptable mess, then I save it as a Web file with
its associated documents, which apparently HTMLZ is trying to
accomplish.

>. . .

"Adam H. Kerman" <ahk@chinet.com> wrote:

> VanguardLH <V@nguard.LH> wrote:
>
>>knuttle <keith_nuttle@yahoo.com> wrote:
>
>>>Content-Transfer-Encoding: base64
>>>
>>> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
>><and more encoded lines>
>
>> Please don't use Base 64 encoding in text-only newsgroups.
>
> Why does Thunderbird do this? There is no answer.

I've read setting mail.strictly_mime = true forces Tbird to use MIME
parts, but that would only be needed for non-ASCII content or with
attachments. His Tbird is configured to use:

Content-Type: text/plain; charset=UTF-8; format=flowed

but he doesn't use any UTF-8 characters, just ASCII-7. Doesn't Tbird
lets users configure differently the formatting of e-mails versus
formatting of newsgroup messages? Doesn't Tbird let you specify
us-ascii as the default format for newsgroup messages with fallbacks to
UTF-8, and other fallback encodings?

While Carlos uses UTF-8 in his message (to which Knuttle replied), I
don't see any UTF-8 characters in Carlos' message that would require him
to use UTF-8. Tbird shouldn't mandate UTF-8 to match the parent's
article when a reply also does not use any UTF-8 characters. It's
almost as if Tbird decides to match encoding even when not applicable.
However, I'm not using UTF-8 mandates Base 64 encoding. Doesn't seem
they are linked. Base 64 was used to handle attachments or binary
content before MIME showed up, but Knuttle doesn't have any attachments.

https://bugzilla.mozilla.org/show_bug.cgi?id=1379096
Resolution: WONT FIX
"Returning to the Stone Age and sending only 7-bit messages is not a
reasonable solution. 'mail.strictly_mime=true' does this."

Well, Usenet is mostly in the stone age for text-only newsgroups.
Encoding got added as did MIME, but there is nothing wrong about using
ASCII-7 when using only that charset in your content. MIME, Base 64,
and quoted-printable are inappropriate for Usenet in text-only groups.
While Tbird seems perplexed on what encoding or charset to use, I
suspect a lot has to do with how the user configured Tbird to behave
when posting to Usenet.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:
>
>> VanguardLH <V@nguard.LH> wrote:
>>
>>>knuttle <keith_nuttle@yahoo.com> wrote:
>>
>>>>Content-Transfer-Encoding: base64
>>>>
>>>> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
>>><and more encoded lines>
>>
>>> Please don't use Base 64 encoding in text-only newsgroups.
>>
>> Why does Thunderbird do this? There is no answer.
>
>I've read setting mail.strictly_mime = true forces Tbird to use MIME
>parts, but that would only be needed for non-ASCII content or with
>attachments. His Tbird is configured to use:
>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>but he doesn't use any UTF-8 characters, just ASCII-7. Doesn't Tbird
>lets users configure differently the formatting of e-mails versus
>formatting of newsgroup messages? Doesn't Tbird let you specify
>us-ascii as the default format for newsgroup messages with fallbacks to
>UTF-8, and other fallback encodings?
>
>While Carlos uses UTF-8 in his message (to which Knuttle replied), I
>don't see any UTF-8 characters in Carlos' message that would require him
>to use UTF-8. Tbird shouldn't mandate UTF-8 to match the parent's
>article when a reply also does not use any UTF-8 characters. It's
>almost as if Tbird decides to match encoding even when not applicable.
>However, I'm not using UTF-8 mandates Base 64 encoding. Doesn't seem
>they are linked. Base 64 was used to handle attachments or binary
>content before MIME showed up, but Knuttle doesn't have any attachments.
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=1379096
>Resolution: WONT FIX
>"Returning to the Stone Age and sending only 7-bit messages is not a
>reasonable solution. 'mail.strictly_mime=true' does this."
>
>Well, Usenet is mostly in the stone age for text-only newsgroups.
>Encoding got added as did MIME, but there is nothing wrong about using
>ASCII-7 when using only that charset in your content. MIME, Base 64,
>and quoted-printable are inappropriate for Usenet in text-only groups.
>While Tbird seems perplexed on what encoding or charset to use, I
>suspect a lot has to do with how the user configured Tbird to behave
>when posting to Usenet.

Text encoding was part of extending email from 7-bit to 8-bit and was
the way to get around communication limits between two servers in which
the path couldn't be upgraded to 8-bit. In email, if there's an 8-bit
path, then the text should not be encoded.

Encoded text does not belong on Usenet, period. Usenet has never any
such limitation. There is no protocol for upgrading the communication path
from 7-bit to 8-bit. You just connect.

Encoded text causes problems for Usenet while solving none at all. It
should have remained nonstandard.

VanguardLH <V@nguard.LH> wrote:

> While Carlos uses UTF-8 in his message (to which Knuttle replied), ...

And where Knuttle's Tbird used Base 64, Knuttle also replied to Bradley
who is also using UTF-8 (despite he uses only ASCII-7 characters) yet
Knuttle's reply to Bradley did /not/ use Base 64.

> I suspect a lot has to do with how the user configured Tbird to behave
> when posting to Usenet.

Hmm, maybe it's how the user is clicking on which buttons in Tbird. I
wouldn't think Knuttle's config would've change between when he replied
to Bradley to when he replied to Carlos.

The differences in Knuttle's replies are:

To Bradley:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

To Carlos:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

For some reason due to configuration or how Knuttle uses Tbird, the
first says to use 7-bit (so UTF-8 is irrelevant) but the second says to
use base64.

I don't see anything glaringly obvious in Bradley's article that is
different than Carlos' article that would make Tbird switch encoding ...
except for:

Bradley:
Content-Language: en-US
(en-US = English used in United States)

Carlos:
Content-Language: es-ES, en-CA
(es-ES = Spanish as spoken in Spain)
(en-CA = English used in Canada)

Despite writing in ASCII-7 using the English language, Carlos specifies
Espanol (Spanish) and Canadian English, eh. Carlos is specifying a
language (es-ES) other he writes (en-CA). Differences between en-US and
en-CA are minor, and both use ASCII7; see
https://www.grammarly.com/blog/canadian-english-american-english/. So,
the only trigger I've found, so far, is Carlos uses es-ES to indicate
his article might be in Spanish.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language

I have no idea how Thunderbird gets configured to on what it triggers
for it to decides what to specify in its Content-Language header. Seems
a superfluous or obsolete header. You and I don't add that header, we
are not indicating an audience other than already specified in the
Content-Type header.

When Knuttle replies, he uses:

Content-Language: en-US

So perhaps Carlos' specifying the language /could/ be Spanish has Tbird
use base 64 in replies to retain anything Carlos might've used that was
in Spanish although he only used English. That's just a guess on
Tbird's rather erratic behavior of when it chooses base64 encoding.

I would think the kid would provide the same format as used in the
e-book he got that he is "sharing" with others. If it was originally an
HTML doc, that's probably the best format for viewing via web server and
web client.

Note that I've stressed "acquired" and "sharing" in my replies, because
it's quite possible the kid is violating copyright. Kids do that.

On 1/31/2024 12:58 PM, VanguardLH wrote:
> The "guy's kid" cannot tell you how he created the HTMLZ file? How
> about asking the "guy" to ask his kid to relay the info back to you?

The college kid used Calibre from a mobi input file to create them.
We can't expect everyone to have a reader that reads mobi files though.

I've found out subsequently that the HTMLZ is simply html, as you said.
After Paul suggested using 7-Zip, on Windows, the HTMLZ extracted to
./images/
cover.jpg
index.html
metadata.opf
style.css

Then I used Firefox to Open > File on the HTML, which was the entire book.
I didn't realize it was that easy.

For some reason I had thought it was a special format of some kind.
I thought it had a special reader of some kind.

It's all done now, although I don't know what the other files are for.
Are they of any use?

On 1/31/2024 8:57 PM, Adam H. Kerman wrote:
>>What I see when viewing an HTML doc in a web browser often does not save
>>well when "printed" into a PDF.
>
> Right. If I get an unacceptable mess, then I save it as a Web file with
> its associated documents, which apparently HTMLZ is trying to
> accomplish.

I spoke with the kid who is a teenager of his young grade school sister who
is in the YMCA Adventure Guides. The book is not intended to be printed.

We are fathers trying to empower girls to think for themselves and not to
take the opinion from others as gospel, so we give all of them the same
book and we give them only fifteen minutes to figure what the message is.

They spend more than an hour in a circle discussing the book, where it's
almost like one of those "telephone" games we played when we were kids.

It's never going to be printed. It's a one-time event. Each month we have
to have a "craft" which teaches the kids something. The craft is designed
by the father (women aren't allowed in the process) to be "educational".

The teenager explained to me he used Calibre and that he downloaded the
book off the Internet in the mobi format. He converted it to the other
formats (there are something like two dozen possible output formats).

The problem with mobi is we can't expect the kids to read a mobi on their
own phones, iPads, tablets & laptops that they will bring to the meeting.

The file will be hosted at 192.168.1.x on the local home's LAN. We meet
once a month with the hundreds of girls in the YMCA Adventure Guides (moms
are NEVER allowed!), for example, for a weekend camping event or a Saturday
canoeing event or a Sunday sleepover in the local amusement park, or
whatever. https://ymcamontgomery.org/camp/programs/father-child-weekend/

Then once a month we meet with just a dozen fathers and their kids (the
women and brothers are told to stay out of mind, out of sight) for a cozier
tribal get together (we used to be called "YMCA Indian Princesses" but (for
some reason, we're told never to speak about Native Americans at the
events). We even had to change our chant because it was an Indian
expression (we were told) so we reversed the letters - as a nod to the
concept of following the rules in our own way. http://ytribes.com/
https://ymcaoc.org/adventure-guides-history/

Bear in mind the Adventure Guides is about as unlike the Girl Scouts and
Boy Scouts as Hitler Youth are from normal kids - so it's all about
education and having fun with fathers and their school-age small kids.

In the beginning of the year the dozen fathers get together to plan the
rotating home hosting schedule and what the topic of each meeting can be.

Home hosts shoo the ladies away and set up a group meeting with fathers and
girls (or boys for the boys Adventure Guides) that has a learning "craft".

This "craft" is for the host father to choose a book from this list.
https://happyhooligans.ca/best-chapter-books-for-girls/

Then to obtain that book and put it on his local network for the kids to
access locally. The kids will bring their own personal devices to read it.

The HTML seemed most appropriate for that, which is why the HTMLZ showed up
as the teen who did all the work seems to have known what he was doing.

I noted in a different thread that TXT is another output format, but it
loses the images (and their context) that HTMLZ preserves.

What I didn't know at the start was that it doesn't seem like ANYTHING
reads the HTMLZ output. Not even Calibre. The HTMLZ is just a zip output.

So it was wrong of me to assume Firefox would read the HTMLZ file.
What Firefox reads is the index.html file (and associated images).

I'm not sure how much other stuff is needed but this is in the folder.
./images/
./cover.jpg
./index.html
./metadata.opf
./style.css

Bradley <bradley@nospam.com> wrote:

> I spoke with the kid who is a teenager of his young grade school
> sister who is in the YMCA Adventure Guides. The book is not intended
> to be printed.
>
> The teenager explained to me he used Calibre and that he downloaded
> the book off the Internet in the mobi format. He converted it to the
> other formats (there are something like two dozen possible output
> formats).
>
> The problem with mobi is we can't expect the kids to read a mobi on
> their own phones, iPads, tablets & laptops that they will bring to
> the meeting.
>
> The file will be hosted at 192.168.1.x on the local home's LAN.
>
> I'm not sure how much other stuff is needed but this is in the folder.
> ./images/
> ./cover.jpg
> ./index.html
> ./metadata.opf
> ./style.css

Extract the files from .htmlz into a folder, and move the entire folder
to somewhere on your web or file server, and use the path to the folder,
in the URL you dole out, like:

http://192.168.1.x/path/folder/index.html

See if that works. Links to the external resources (images, CSS) should
use relative pathing to their files in the HTML code in index.html. If
that doesn't work, and the web server just doles out a file to download
from wherever you stored the folder on the server, you can also open
..mobi e-books using a variety of ebook apps.

I have Kindle on my Android phone, but I think it came bundled on the
smartphone. Kindle (Amazon) ended support for .mobi back in Aug 2022.
They switched to AZW3, an Amazon proprietary format based on the
outdated MOBI format. Calibre still supports MOBI, as well as AZW and
AZW3 that replaced it.

https://manual.calibre-ebook.com/faq.html#what-formats-does-calibre-support-conversion-to-from

Calibre has apps for Windows, Linux, macOS, Android, and iOS. That
should cover whatever the kids bring with them for devices. However,
it's been too long since I used Calibre on Windows, so I don't remember
if you have to create an online account to use the local app. Their
video (https://calibre-ebook.com/demo) doesn't show creating an account,
just specifying a default location to store ebooks. By downloading the
ebook, the girls would have it to view again later if it still has
interest to them.

On Wed, 31 Jan 2024 13:24:40 -0600, VanguardLH <V@nguard.LH> wrote:

>knuttle <keith_nuttle@yahoo.com> wrote:
>
>> Content-Transfer-Encoding: base64
>>
>> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
><and more encoded lines>
>
>Please don't use Base 64 encoding in text-only newsgroups.

What are you on about? As you've launched this grumble on
a.c.s.Firefox, (ancient) Forte Agent 8.0 as my Usenet client quite
happily handled your whatever-ism without getting hissy.

Bradley <bradley@nospam.com> wrote:

> ./images/ relative path to a folder with image files, if any
> cover.jpg an image file
> index.html main HTML document file (you open this one)
> metadata.opf metadata in the ebook (*)
> style.css CSS stylesheet (aka formatting)

(*) Provided externally for recovery from corruption of the ebook.
Contains: title, publication date, book ID, language, creator, and date
last modified. It's probably an XML file which means it is a
hierarchical text file with tags to identify attributes.

Bradley <bradley@nospam.com> wrote:

>. . .

>What I didn't know at the start was that it doesn't seem like ANYTHING
>reads the HTMLZ output. Not even Calibre. The HTMLZ is just a zip output.

>So it was wrong of me to assume Firefox would read the HTMLZ file.
>What Firefox reads is the index.html file (and associated images).

>I'm not sure how much other stuff is needed but this is in the folder.
> ./images/
> ./cover.jpg
> ./index.html
> ./metadata.opf
> ./style.css

An HTML file needs some sort of pointer to the directory with its
associated files. Try this converter.

https://www.converter365.com/ebook-converter/htmlz/htmlz-to-html

Nobody <jock@soccer.com> wrote:

>> knuttle <keith_nuttle@yahoo.com> wrote:
>>
>>> Content-Transfer-Encoding: base64
>>>
>>> T24gMDEvMzEvMjAyNCAxMjo0NyBQTSwgQ2FybG9zIEUuUi4gd3JvdGU6DQo+IE9uIDIwMjQt
>> <and more encoded lines>
>>
>> Please don't use Base 64 encoding in text-only newsgroups.
>
> What are you on about? As you've launched this grumble on
> a.c.s.Firefox, (ancient) Forte Agent 8.0 as my Usenet client quite
> happily handled your whatever-ism without getting hissy.

Look at the raw source of his message. It's not about whether or not
YOUR client handles base64, especially since your choice is not forced
upon all other Usenetizens. It's about whether or not that format is
appropriate (which it is not) for TEXT-ONLY newsgroups!

If you attend a seminar where all attendees are asked to speak Muscogee,
yes, you could bring along your own interpreter, but that is something
extra to accomodate the attendee (you) that didn't comply.

Base64 precedes MIME for encoding content mostly to accomodate binary
attachments and non-English languages. Most NNTP clients will support
base64 encoding. Not the point. base64, MIME, and quoted-printable are
inappropriate for *Usenet* messages in *text-only* newsgroups. It's not
about you and what client you use. It's about netiquette in Usenet.