Re: Getting download sizes right: proof of concept

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>>> I'd need someone to take this sketch and integrate it into the
>>> build system (I just don't really understand the build system).
>> 
>> Do we really need this?
>
> Yes, I think this is *very* useful.  It's always nice to know big file
> sizes (i.e., files larger than, say, 1MByte) in advance.  Not everyone
> is using a fast (and cheap) internet connection.
>
>> We could just delete the download size from text and be correct in a
>> much simpler way.  For today's standards, the difference between 6M
>> and 35M isn't really all that relevant.
>
> I strongly disagree.  It's still a very large difference.

Note that there is the simpler solution of having a script run manually
after build, fixing up the sizes in the source which one can then
commit.

Advantage: a no-brainer to have this work for all outputs including PDF
and Texinfo.

Disadvantage: if the computer where the size recalculations have been
done and committed and the computer building the website have, say,
different fonts installed, the numbers can still be off.  Also if one
has some PDF tools in the build that the other hasn't.

I decided that accurate numbers were desirable enough to have them
recalculated every time.  Putting them into the source (like defining
them in some Makefile) would have required some tricky dependencies,
like not writing them in the large HTML file in order to be able to
first build the large HTML file, then calculate its size, and then have
the size available for building the split HTML file.

So this approach of fixing the files up after the fact.  Which again
changes their size minusculy but we use size here for estimating
download times, not for verifying the downloads as being untampered.  If
we put in md5sums (for example), this fixup would of course not work as
an approach and we could not allow for circular dependencies to be
broken by patchup.

-- 
David Kastrup