Do not use the object returned from obs_data_get_obj to set new
settings. It could be the default object, which means you'd just end up
modifying the default data, which won't get saved. Always create a new
object when setting sub-object data. It doesn't particularly hurt
anything.
It would try to move data from the old pointer even if the pointer was
changed via realloc, which would cause it to copy data from freed
memory. Instead, just get the position of the data and call memmove to
move it up.
On release of obs_data, if the default/autoselect values pointed toward
a sub-object or a sub-array, it would look up the data for the regular
user value. (Palana must have forgot to change these functions around
when adding the default/autoselect functionality)
When looking up translated font names within font files, it was not
checking for null on the 'charset' variable (the translation character
set wasn't added/availble).
On fedora, the freetype cmake module would not find the correct
location. This is because it wasn't using the pkg-cofig include
directory, which is different from the main ft2build.h header directory
(which is /usr/include).
This modification may be a good thing to do on all the cmake packages,
actually. Currently, they all just search for the location of a
specific header, and ignore the pkg-config includes if they find it in
specific hint locations.
Multiplication of the matricies was being done in the wrong direction.
This caused source transformations to come out looking incorrect, for
example the linux-xshm source's cursor would not be drawn correctly or
in the right position if the source was moved/scaled/rotated. The
problem just turned out to be that the gs_matrix_* functions were
multiplying in the wrong direction. Reverse the direction of
multiplication, and the problem is solved.
it is now possible to build text-freetype2 on linux if you comment out a return() otherwise there would have been an error
Also i made the word iconv in find_package lower case, to match the APPLE cmake code
This changes the font plugin from using a font file to using a specific
installed system font, which is searched for on each specific system and
associated with the font file. It now uses a font property instead of a
path property, and font size has been removed because the font property
now handles that.
When the module is first loaded, it will build up a list of system fonts
in order to be usable by Freetype. It was quite painful to program this
because font files can contain multiple localized versions of their face
names, and then there was the issue where windows likes to mangle
custom style types to the font name. Regardless, it all seems to have
worked out pretty well.
Minor issues:
- Truetype/Opentype fonts sometimes do not automatically have
italic and/or bold styles available, it seems that the system applies
transformations manually in those cases. We don't do this yet,
however, so right now a user might select a font with italic/bold
only to discover that italic/bold doesn't always work. Not entirely
sure what to do about this yet. There's probably a freetype function
to do something like that somehow,
This also requires that iconv be used for non-windows systems to be able
to look up localized font names within font files. Windows will use
the win32 API and code page IDs to translate font names.
Adds the following function:
------------------------------
obs_properties_add_font
This function creates a 'font' property to allow selection of a system
font. Implementation by the UI should treat the setting as an obs_data
sub-object with four sub-items:
- face: face name (string)
- style: style name (string)
- size: size (integer)
- flags: font flags (integer)
'flags' can be any combination of the following values:
- OBS_FONT_BOLD
- OBS_FONT_ITALIC
- OBS_FONT_UNDERLINE
- OBS_FONT_STRIKEOUT
The alpha source and destination blend values were always being set to
one and zero, when they should have been set to the same as the color
values. This caused the alpha of the source texture to always overwrite
the alpha of the destination texture, rather than apply the blend
function upon it. Needless to say that it seriously screwed up the
render target if you rendered something with alpha on it.
Thanks to paibox for pointing this issue out and yelling at me to fix
it. I apologize for not getting to this sooner.
This moves some functions that are generic to a separate source
file. While doing so the api to those functions was improved to
be more generic and not depend on knowledge about the internal
structure of the plugin.