PreTeXtBook
Ensure xml:id restriction works with `generate`
Yeah I think we have hit this issue with the TBIL project - the numbering of images without xml:ids is borked. Thanks @siwelwerd for making the connection.
So an author can avoid the issue for now by giving images xml:ids, but we need to figure out where things are breaking down.
And there is going to be some major changes w.r..t @xml:id and @label, especially with regard to image and a child latex-image (and similar). Working on it now. The goal is to keep this from getting out of hand.
The whole subtree drill was meant to appease people who wanted to author-compile-debug quickly, so I'm not going to be too upset of it is not producing production-quality results.
In the work to revise @xml:id and @label, it would be nice to consider how those can interact with generating specific assets. The new and very well received feature of the CLI to automatically generate those assets that have changed uses the subtree options. It would be a shame if this wasn't preserved or reimplemented somehow.
It would be a shame if this wasn't preserved or reimplemented somehow.
Nobody suggested any abandonment of any feature.
It has always been the case that images with filenames like image-67.pdf are an expedient meant to provide rapis startup and prototyping for new or throwaway projects. In-progess work on @label is meant to improve the situation.
But I am not surprised that the numbering could be a bit off. Dave Rosoff recently hit a problem with the numbers being off by two. Once he was given a quick (undocumented() fix, he has not been interested in making further contributions to help debugging the root cause.
The issue is likely only showing up on projects that have some images with xml:id and some without. Will look at more.
I should have this fixed by the end of the day (after almost completely rewriting the generate method, fun fun fun). Once it is done, I will release 2.1
Okay, I have refactored the generate function in #622, and I think this solves any issues that were present. Tested all the cases I could think of (but did not do exhaustive testing with every possible configuration). When that pr is merged, we will close this. If anyone notices strangeness, we can revisit.
Okay, I have refactored the generate function in #622, and I think this solves any issues that were present. Tested all the cases I could think of (but did not do exhaustive testing with every possible configuration). When that pr is merged, we will close this. If anyone notices strangeness, we can revisit.
It'd be good to have written tests for this stuff, even if they are slow (we don't have to run them on every commit).
I agree! Need to spend some time thinking about a good DOE for capturing a large percentage of the use cases.
We're hitting this again at https://github.com/TeamBasedInquiryLearning/precalculus so I'm reopening pending investigation.