Do you think above info is enough to work with Carl? Or would a repro case be helpful?

Oh, by the way, I got some of the details above wrong. This DCP was created on Mac OS 10.14.6, not Ubuntu. Not sure if that's relevant.

@overlookmotel the info is perfect, thanks, I see it - a fix is in the works.

@overlookmotel https://dcpomatic.com/build/2525-interop-ccap/5c8e5ea should fix this, if you want to try it out.

83d63bb331190db4372de4d0aaf8413c51f1eee4

Confirmed fixed in 2.16.56. I ran the same project through with same settings, and this time there are no invalid font IDs. DCP passes dcp_inspect's checks.

However... this time there was a LoadFont node in the XML, and a font TTF was included in the DCP.

My understanding from https://dcpomatic.com/mantis/view.php?id=2505 was that there's not intended to be a font file included for closed captions. Or is that only the case for SMPTE DCPs? (this DCP - both input and output - is Interop).

I tried outputting as SMPTE too with 2.16.56.

Resulting DCP does pass dcp_inspects checks, and captions XML is valid but, this time:

• 3 x LoadFont nodes in the XML (with Ids 1_Font1, 2_Font1, 3_Font1).
• 3 x Font nodes (each containing captions from 1 of the 3 captioned reels in original DCP), each referencing 1_Font1, 2_Font1, 3_Font1.
• 3 x TTF font files included in the MXF (and all identical).

So it looks like this change may have reverted https://dcpomatic.com/mantis/view.php?id=2505, at least in this test case.

A couple of other things which don't make a difference here, but might make a difference for OCAP/subtitled DCPs, if they behave the same:

1. In the output Interop DCP, the font TTF used is Liberation Sans, whereas when output as SMPTE the fonts TTFs are the originals from input DCP. The SMPTE behavior of retaining original font seems preferable.
2. In the input DCP, all 3 reels with captions have their own font TTF, but all are identical. When converting a multi-reel DCP to a single reel DCP, it would be nice if DCP-o-matic recognised that all the TTFs are identical, and de-duplicated them.

The 2nd point is very much a "nice to have" and not at all essential, but thought I'd mention it, since I noticed it.

Interesting - so the DCP that you started with has fonts for the CCAPs? But maybe DCP-o-matic should get rid of them. I'd forgotten about the MXF-size angle. And in fact even newly-created CCAP (e.g. from .srt) get fonts now, with this change. Oh dear.

Yes, the DCP we received from filmmakers has font TTFs for the closed captions. That DCP was made by Postworks New York and made with a Clipster (v5.10.0.17 - no idea if that's recent). But Postworks are one of the big DCP players in US, as far as I can see. You'd think they'd be getting it right, although I've also learned not to defer too much to authority. We've received bad DCPs from even the mighty Deluxe on occasion.

In any case, size of captions MXFs doesn't come into it on this one, as their DCP is Interop. But, as I commented on 0002505, I'm not sure there's a size limit on the MXFs anyway, from my reading of the ISDCF docs.

So, the change in 2.16.56 is overall good - fixes a definite bug in favour of regressing a maybe bug!