| Age | Commit message (Collapse) | Author |
|
|
|
|
|
This seems to fix problems where letters were scaled individually, but
their spacing didn't change (when x scale was applied).
Big thanks to user1768761
https://stackoverflow.com/questions/58528024/pangocairo-shows-cluttered-text-when-cairo-context-is-scaled
|
|
|
|
Otherwise it looks further away in the preview than in in the final DCP
(if the preview is smaller).
|
|
|
|
We're already using ceil on the return value everywhere we need to, as
far as I can see.
|
|
|
|
raw_convert<string> is gone, so here we use fmt::{to_string,format} instead.
Other raw_converts now use fast_float.
|
|
|
|
add_to_cairo_context().
This helps with #2813 and should fix #2474.
We started using add_to_cairo_context() again in
72c3a5f0f32f553a1f8abee2494f31d29b976383
because the rendering looked better. However colour changes within
lines cannot easily be rendered using add_to_cairo_context() it seems,
as the text is just added as a path and then you can stroke/fill it
with a single colour.
I hope that this change, which reverts 72c3a5 but also adds some calls
to enable hinting and use better anti-aliasing, looks OK. I looked
at some white-on-black subs close-up and the hinting seems to help.
|
|
|
|
|
|
|
|
|
|
one VPosition.
Previously if HPosition changed we would still use a single "line" (i.e. Pango layout)
for all the text, meaning that HPosition would not be respected.
|
|
|
|
|
|
Previously we would fail to make a font available if it came from
a SMPTE MXF. In that case we have a memory buffer containing the
TTF/OTF file but no file; here we add a hack/workaround so that
in-memory font files can be used by FontConfig.
|
|
|
|
|
|
|
|
a new setup_layout() which can do some more stuff.
|
|
when placing subtitles (e.g. SRT). Also default to outputting 2014-era
alignment.
|
|
|
|
Previously, text coming out of the player would have things like
& escaped to &. This escaping is also done by libxml++ when
writing XML, so doing it in the player would mean it was done
twice.
We do, however, need to escape things before passing them to Pango
as otherwise it gives errors and renders nothing for the line.
Here we move the escaping to just before the rendering, meaning
that in the reset of DoM we should pass unescaped strings around.
|
|
Previously we would not account for the differences in what vertical
position means between Interop and SMPTE. For interop, vertical
position is the distance from the reference point to the text
baseline, whereas for SMPTE it is the distance from the reference
point to the top/middle/bottom of the subtitle (depending on the
reference).
This caused differences between the preview and the DCP for some
cases (notably, using SRT/SSA and making Interop DCPs, or converting
Interop DCP subs to SMPTE, or vice versa).
|
|
Interop and SMPTE.
|
|
|
|
Here was use get_ink_extents() rather than get_pixel_size() to
find out how big the rendered subtitle will be, then use the
x/y values of this extents rectangle to offset the rendering
within the image. This allows the removal of some hacks to make
accents visible.
|
|
With this change each subtitle coming out of the player has a reference
to a dcpomatic::Font that belongs to the TextContent. This hopefully
solves a few problems which all basically stemmed from the fact that
previously the decoders/player were deciding what the font ID in the
output DCP would be - they can't do that properly.
|
|
|
|
|
|
|
|
In this case we can't do any fade out.
|
|
Adding horizontal space to a Pango layout is hard, and I think this
change probably gets it slightly wrong, but it's a step in the right
direction.
|
|
|
|
alignment and pixel format.
|
|
|
|
|
|
Previously we would convert > to > then the ampersand to &
resulting in &gt;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
they have borders. This fix will cause some movement of border-less
subtitles (in existing projects) within the video frame.
|
|
|
|
On Linux, at least, doing
add_to_cairo_context()
fill()
add_to_cairo_context()
stroke()
gives a nicer output than
show_in_cairo_context()
It's not clear exactly what the difference is, but the anti aliasing
looks better and the font outlines basically look smoother.
May help with #1815.
|