Font doesn't look like it should

[Sami S]

Hi!

Im trying to figure out how to use specific fonts in DCP-O-Matic. I'm trying to load a font Arial Rounded MT Bold but it doesn't look correct.

The font is a .ttf 39KB font. Im on Mac OS Tahoe and using 2.18.37 version of DCP-O-Matic.

Are there some restrictions on what kind of fonts can be loaded or is my .srt file overriding some setting? I see the font change when I change to some other fonts but it won't accept anything "rounded".

Please see image of what the rounded font should look like and what I see in the preview window.

Screenshot 2026-03-07 at 15.49.25.png

[Carsten]

Hmm, you are right. I see the same on my old Sierra Mac Book using DOM 2.18.36

I downloaded the font from here:

https://freefonts.co/fonts/arial-rounde ... ld-regular

I installed it in the system and can use it e.g. in Word. It shows correct there - rounded.

When I load it into the font dialog of DCP-o-matic - the preview font changes, but clearly not to Arial Rounded. Not when I use timed text, not when I use burn-in.

When I create the DCP with burn-in, still no Arial Rounded in the DCP shown in player. However, when I create the DCP as Interop and look into the subtitle folder, DOM has added the actual Arial Rounded font to the subtitle folder so it should diplay correctly on a DCI projector. So it seems that just preview and burn-in are broken. Probably some sort of a hidded system font replacement. I remember I came across that issue before, I think there was even a Mantis entry.

[Sami S]

Another thing Im seeing is that if I export .srt subtitles from Resolve "without formatting" and a line has "\N" before the subtitle text it will fail importing into DMO. Is the \N denoting line change I think? If I export the same .srt with formatting it ingests properly. All other programs I have open both .srt files properly.

If I delete the "\N" manually before trying to import to DMO it will ingest smoothly.

Second screenshot from Aegisub.

Screenshot 2026-03-10 at 9.57.41.png

Screenshot 2026-03-10 at 9.57.55.png

[IoannisSyrogiannis]

In terminal, "\n" is line change. I would expect it to be case-sensitive, but I can't tell for sure.
Backslash I don't remember seeing. Escapes are usually in the form of & and so on.
Yet, I couldn't tell what the line change would do, if it was to be translated to DCP subtitles.

Normally, when there is one line of text, it is positioned at the same height as the lower of two.
So, if there is an escape character that would change the form, how that would be interpreted...?

[Sami S]

I would hope in this case DoM would issue a warning but still import the .srt instead of an error and not being able to import it.

[IoannisSyrogiannis]

If you can not edit the subtitles within DCP-o-matic (in order to fix the issue) what would be the purpose of importing the file?
Wouldn't it just move the problem further down the workflow and inaccurately show the subtitles in the meantime?

What is it that you would hope to do? I mean, what would be the goal?
Have DCP-o-matic disregard the \n there, or implement a new, different positioning?

[carl]

The subrip format is rather imprecisely specified, and so far DCP-o-matic has taken quite a strict approach to parsing it. We could consider accepting this extra line, though then you have to start guessing whether the thing after a new line is another part of the same subtitle, or the start of the next. I suppose it's a fairly safe bet given that the next subtitle can only start with one thing (the next number in sequence).

I think it would be OK to fix this in DCP-o-matic.

[IoannisSyrogiannis]

Let's say that it is fixed...
How is that interpreted?
If there is only one line, like in the example in hand, where would that line be put?
At the same place, as if it was just the line of text, or even lower on the screen?
If that was defined automatically, how would that work, in terms of secure placement?

It seems to me that a line brake before the only line of subtitles doesn't make sense to translate into a DCP subtitle for a low and centered SRT subtitle. At least in such a case.
If the goal here is to discard the escape character, so there is no problem adding the subtitles, it feels to me like a fix that could introduce more subtle issues down the road.
I, for one, would prefer such details to be pointed out to me and taken care of (by me) right from the start. Yet, I know a lot of people that are not even allowing DCP-o-matic to examine the material, before starting to "bake" a DCP. So, I am not the average user.

[Sami S]

The subrip format is rather imprecisely specified, and so far DCP-o-matic has taken quite a strict approach to parsing it. We could consider accepting this extra line, though then you have to start guessing whether the thing after a new line is another part of the same subtitle, or the start of the next. I suppose it's a fairly safe bet given that the next subtitle can only start with one thing (the next number in sequence).

I think it would be OK to fix this in DCP-o-matic.

I guess for me the issue was that as my native language is not English it took me a very long time to figure out what was wrong with the .srt. The "formatted" .srt imported fine although it has the same exact extra line break and other programs imported / exported both without any warnings or issues so I had to examine the .srt file in multiple programs before I figured out to try to remove the extra line break. Once I understood it, no issue at all. Going forward I understand it can be a small thing that prevents import to DoM.

BUT I'd love to get a reply to the original more important issue of the font not looking like the font should in my original post? Is this something that could be fixed (by me?) or by you?