[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EPUB 3.3 spec conformity issues
From: |
Daniel Cerqueira |
Subject: |
Re: EPUB 3.3 spec conformity issues |
Date: |
Wed, 21 Aug 2024 22:27:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Patrice Dumas <pertusus@free.fr> writes:
> On Tue, Aug 20, 2024 at 09:23:57AM +0100, Daniel Cerqueira wrote:
>>
>> The dcterms:modified meta element is MANDATORY in order to create a
>> valid EPUB 3.3 file. It is missing in the current Texinfo EPUB file
>> creation. Here is an code example on how to implement this inside the
>> EPUB file:
>>
>> According to: https://www.w3.org/TR/epub-33/#sec-metadata-last-modified
>
> I agree on the issue, but I do not think that the last modified date
> should be the date of the epub file generation, it should rather be the
> date of the publication contents or style modification. None of the
> Dublin core nor the EPUB format specification are clear on what the
> modification date should correspond to in term of changes, but my
> reading of the EPUB specification is that it is about the published
> material, not about the epub file creation date. I also think that it
> is much better to have this date correspond to the change in contents
> not to the generation.
>
> To me this should be specified by the manual authors. One possibility
> could be to use the last modification time of the input Texinfo file,
> possibly through automake setting the UPDATED flag, but this should be a
> user's choice, not something automatic.
In that same link (above)
```
Note
The requirements for the last modification date are to ensure
compatibility with earlier versions of EPUB 3 that defined a release
identifier [epubpackages-32] for EPUB publications.
```
Going to "release identifier"...
```
To ensure that a Release Identifier can be constructed, each Rendition
MUST include exactly one [DCTERMS] modified property containing its
last modification date. The value of this property MUST be an
[XMLSCHEMA-2] dateTime conformant date of the form:
```
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.
Also:
Texinfo PDF file generation changes every time a new build is made. Are
you concerned about this? Don't seem like it.
Which brings us to your argument about reproducible builds... More on
this latter.
> We do not try to follow standards for the sake of it, but if there are
> actual issues. Here it would be better to be conforming, as the
> modification date is used in readers, but it is not such a big issue
> either, as it does not prevent the readers to render the epub files.
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.
Gavin Smith <gavinsmith0123@gmail.com> writes:
> There is also an issue that some have argued that builds of software
> packages should be reproducible as far as possible.
>
> https://reproducible-builds.org/
>
> If the generation date went in the output it would not be reproducible.
You are taking reproducible builds out of context and making it fit
where is was not meant to.
Reproducible builds have to goal of making sure a given installed
binary program corresponds to a given source code. Not the generation
of document files corresponding to some source.
PDF files (created by Texinfo) are not reproducible builds either. And
you don't seem concerned about this.
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.
My patches are simple, and it should take you very little time, less
than 3 minutes, to figure out what they are doing.
- Re: EPUB 3.3 spec conformity issues, (continued)
- Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Daniel Cerqueira, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Gavin Smith, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Daniel Cerqueira, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Per Bothner, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/21
- Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/21
Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/21
Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/22
Re: EPUB 3.3 spec conformity issues, Patrice Dumas, 2024/08/23