garretrieger
commented
5 months ago I included a partial invalidation format number for Brotli since it's technically possible to craft Brotli patches that wouldn't invalidate each other (eg. one modifies a fixed range of bytes at the start of the file, another blindly copies those bytes and modifies the bytes afterwards). However, I don't think this is something that's practical or really would ever see use, so I'm ok with removing the partial invalidation format number for Brotli patches.
The formats summary section indicates that there can be partial invalidation brotli patches (as distinct from per-table-brotli patches), but the current spec doesn't provide much in the way of explanaton. If those do make sense we should add a note somewhere about how and when they do.
It seems to me that (non-per-table) brotli patches can't be mixed with per-glyph patches, so therefore per-glyph patches can't be those that aren't invalidated. And the application of any brotli patch would presumably change the contents of the file and invalidate another brotli patch. So that leaves per-table brotli patches as what might not be invalidated. So the brotli patch happens to not modify table x, and there might be another per-table patch that only modifies table x, so you can apply the latter after the former.
However, how likely is it that you have a whole IFTX table full of such per-table-brotli patches that happen to only modify table x, and thus aren't invalidated?
I guess the categorization might be future-proofed, but in that case do we really need to "define" partial invalidation brotli patches in this spec?