Should specify... this issue is with SMPTE DCPs, Interop DCPs produce sparse XML files, that seem to be of an appropriate size.

Thanks for the report. DoM is adding font data to the closed caption MXF (which is not needed). Fixed by 577602f032c0a129612efc8015f846f4bf6e64c9 which will be in 2.16.52.

I know this has already been closed, but just checking something...

I had read "timed text file" in the ICDCF doc as referring to the XML file, not the MXF. i.e. in SMPTE DCPs, the XML is wrapped in an MXF, but I'd understood the 256KB limit as being on size of the XML itself (once unwrapped from the MXF), not the size of the MXF in total.

Am I wrong about that?

The document also says that any font that is included is ignored, so there's no benefit in including one. So this change is a good one regardless. But what I'm wondering is if we should recall and remake any DCPs with closed captions made previously with older versions of DCP-o-matic, as they may not play correctly?

I think you are right. Bv2.1 7.2.1 says that the XML must be less than 256kB, and the cumulative file size (including XML, PNGs, and fonts) must be less than 115Mb, with a font smaller than 10Mb. So I'm not sure if the original complaint is correct. However, it seems to be pointless to include fonts with closed captions, so we might as well not do it.

83d63bb331190db4372de4d0aaf8413c51f1eee4 made these fonts come back.

Fixing this on the misleadingly-titled 2525-ccap-fonts

Is the intent to remove font TTFs from CCAP caption tracks again?

Personally, I think it's fine as is in 2.16.65 - font TTFs are included.

In theory font TTFs are extraneous, but pretty much all CCAP DCPs we see from commercial sources (Deluxe etc) do include TTFs. So that seems to be the "vanilla" approach, and it's always possible there's some good reason for that - there may some projector model out there that will baulk at a missing TTF. So in my view the lowest risk approach is to follow the crowd on this, and the downside of a few extra 100KBs in a DCP is pretty insignificant.

If you agree, I believe this issue can be closed.

"the downside of a few extra 100KBs in a DCP is pretty insignificant."
Failing QC is not "insignificant" to me or my clients. We need to be able to generate DCPs that conform to the spec, and particularly with festival (like Sundance) leaning in to accessibility and requiring closed captions... we need to be able to pass QC with those packages.

To add, I've not heard of a single projector "baulking at a missing TTF"... but I have personally had DCP-O-MATIC created DCPs rejected for excessively large CC assets. So at least from my anecdotal datapoint, the harm actual/experienced harm of leaving the TTFs is far greater than the purely hypothetical harm of removing them.

Perhaps the Solomon's solution here is just to make it this a check box in preferences.

@jsalvo do you know how large the CC assets where when they were rejected? Or do you have examples of MXFs from DCPs that were rejected?

@carl yes, they're in the attached images. 423K. With the QC report citing the 256K limit of the specifications.

@jsalvo To clarify, I was not saying that failing QC is insignificant. Of course it's not! My point was that the extra data of a few font TTFs is insignificant in the context of a DCP which overall will weigh up to 300GB for a feature.

A SMPTE captions MXF packages up the captions XML and font TTF in one file.

My understanding of the sections of the spec quoted above is that the size limit for the MXF is 115Mb, and the 256KB limit only applies to the XML itself, which is only a fraction of the MXF's overall size. So it surprises me that this DCP would fail QC.

Are you able to share a copy of the QC report? It'd be useful to know what QC software is producing the fail.

If it's sensitive to share the QC report publicly, perhaps you'd be willing to share it privately with Carl?