Re: EPUB 3.3 spec conformity issues

[Patrice Dumas]

On Wed, Aug 21, 2024 at 10:27:54PM +0100, Daniel Cerqueira wrote:
> One common scenario:
> 
> I just finished my book. My texi file is finished and I won't modified
> it. I want to only change the first image of my EPUB, which is the
> interior cover image.
> 
> If you are generating the dcterms:modified based on the .texi file
> timestamp, the Renderer won't know the difference between your EPUB
> with the old cover and the EPUB with the new cover. This might have
> effects on the cover thumbnail of the EPUB file, making the Renderer
> not know that there is a new cover.
> 
> A solution to this is to always generate a new dcterms:modified upon
> EPUB compilation.

I agree that it is a potential use case that makes using the Texinfo
file modification time to set the time incorrect.  Another similar case
is if a user wants to set the modification date because of a change in
texi2any EPUB conversion in the published work.

However, I still do not think that it justifies changing the
dcterms:modified upon EPUB compilation.  This could lead to a change in
the modification date even if nothing of importance changed.

I still think that only a user can know when to change the last modified
date.  Changing it when the Texinfo file timestamp changes could be a
rule relevant for some users.  Your use-case, changing the last modified
date at each EPUB generation is also a valid use-case.  But I also think
that changing only sparingly when a user thinks that a change is needed
is also a possible use-case.

My current thinking is that the best would be a way to specify the last
modification time in the manual 'manually', and if users want to modify it
using an external information, such as the EPUB file generation time or
the Texinfo file modification time, they should set it up in their build
process, and we should make it as easy as possible by designing how it
is specified in Texinfo accordingly and/or adding customization
variables to support the most wanted use-cases.

> Also:
> 
> Texinfo PDF file generation changes every time a new build is made. Are
> you concerned about this? Don't seem like it.

I know next to nothing about PDF, in particular I have no idea what the
timestamp in it means semantically.

> Which brings us to your argument about reproducible builds... More on
> this latter.

On that subject, having non reproducible PDF files is a hurdle.

> If you don't follow the EPUB standard (for the sake of it) you should
> not be calling this generated file an EPUB. Create your own filetype,
> give it a name, and make Texinfo produce whatever that filetype is.
> And make Texinfo stop calling it an EPUB file.

I do not think that non-conformance is a reason enough to stop calling
the generated file an EPUB file.  My feeling is that it is more useful
to call it an EPUB file, as it indeed is an EPUB file, and it is
readable at least with some epub readers (I did check).  We could and
maybe should document better the conformity, though, as I am pretty sure
that even with your patch, epubcheck shows some non conformity for some
Texinfo manuals EPUB output.

> When there is some good faith person trying to contribute to make
> Texinfo project better, there you have an issue with reproducible
> builds. I am sensing poor Free Software project leadership.

This is not a theoretical issue, even before reproducible builds, we
need to have reproducible tests which requires some care in generating
output files.  Nothing insurmountable, but we need to make sure that
with setting some variable (typically the TEST customization variable)
we get a reproducible output.

Having the possibility to have reproducible output is also a relevant
goal that is clearly not, by itself, a mark of poor project leadership.

> My patches are simple, and it should take you very little time, less
> than 3 minutes, to figure out what they are doing.

Your patches are clean and simple, which is good, and indeed, it takes
little time to figure out what they are doing, however the issue here is
not only understanding your patches, but also being sure of, or at least
convinced that they fix the issues in the right way and that they do not
have unintended effects, for instance on other output formats or on
other aspects of the EPUB output.  (And again, there is the timing to
consider.)

-- 
Pat