On Mon, Sep 02, 2024 at 06:23:10PM +0100, Gavin Smith wrote: > > Been the compliance done with CSS, or maybe not using the Texinfo HTML > > generator, and creating a dedicated EPUB's XML generator. In order for > > the index table border to be in compliance. > > I believe it should be fairly easy to override the border attribute > for EPUB output only, for the 7.2 release.
It won't be the only issue, there are other removed attributes that we use. All should probably be fixable, but it will involve some relatively important changes (more or less every <table> use), although it will be conditional on a customization variable being set. > After that we could revise > Texinfo indices not to use <table> at all (as said in previous email > by Per Bothner) which would ameliorate the issue. I have not checked the thread, but I recall that the output we obtained with <div> only was not good, at least for some browser. I do not think that we need to change to <div> for epubcheck compliance, though. > In terms of implementation > all we would have to do is set something when the init file epub3.pm > runs that would be checked by the code in HTML.pm - some kind of internal > variable. It seems to me that a customization variable would be better, as those change are in general needed to have HTML compliant with recent standards, so having that possibility should be interesting outside of EPUB. It would be set in epub3.pm only by default. > > Regardind the dcterms:modified, you may want to increase complexity, > > trying to make Texinfo builds reproducible.... For me that is a lost > > cause since the pdftex does not, and won't, make PDF builds reproducible > > either (and Texinfo depends on (La)TeX). > > I am not an expert on reproducible builds and you make a valid point > about PDF builds not being reproducible. > > It appears that pdftex obeys the SOURCE_DATE_EPOCH variable and we > could do the same for texi2any for EPUB (as mentioned by Werner Lemberg > on this list). I do not think that it would be needed, we only generate EPUB for tests, and we need to have reproducible tests even more than we need reproducible builds. We should use TEST customization variable for that, and would not need SOURCE_DATE_EPOCH. To me the issue with dcterms:modified is not about reproducible builds or reproducible output, the issue is that it is not right to set dcterms:modified automatically without a possibility for the user to override the value. > > I would like to discuss your opinions in regard of the EPUB compliance, > > to see where you stand, and to summarize which ideas do you think is the > > best approach, for the next release. > > I am in favour of automatic compliance with no further action needed on > the part of the user of texi2any as it seems that this should be easy > to achieve, although I would like to take more time to understand Patrice's > view on this matter. I agree that there is no need for user action for compliance. Although, as I said above, there is a need to hold up setting dcterms:modified until we have added the possibility for the user to set it. We could add a customization for that if this cannot wait for after the release, but it would only be needed for one release. -- Pat
