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
