By explicitly listing the permissions required in general, repositories
without restrictive permissions will only allocate the specified
permissions which is much safer than the default, fairly wide,
permissions grant.
Most workflows don't appear to need any permissions beyond
`contents: read` which is required for checkout (when a repository is
private). By specifying this permission, it tells GitHub not to include
any of its additional default permissions (when a repository is
configured permissively).
The .github/workflows/memcheck_*.sh scripts called by build_ubuntu.yml
require write permissions in order to post their output to a pull
request (as a comment).
In locked down GitHub repositories, unless a workflow/job asks for
write permissions, it will not have them and such API calls will result
in:
{
"message": "Resource not accessible by integration",
"documentation_url": "https://docs.github.com/rest/issues/comments#create-an-issue-comment",
"status": "403"
}
By specifically requesting the permissions, the workflow will continue
to work as expected.
Note that this workflow currently imagines writing a comment.
It does not actually try to do so, and thus there is no need to ask
for permission to use `pull-requests: write`.
If at some point, someone decides to fix that feature, they
will need to add that permission.
OTOH, using a GitHub Step Summary instead does not require any permissions.
For shapes with a stroke that has opacity, anti-aliasing
should be applied to a fill.
The use of a transparent gradient stroke will also be handled
correctly.
For gradients with fill spread set as repeat,
the lack of anti-aliasing between the last and
the first color caused noticeable jagged edges.
Interpolation was introduced between them,
visually improving the gradient quality.
A minor syntactic adjustment to two instances of operator== and one instance of operator!=, both to the end of ensuring these locally-scoped functions are properly identified as const. In the majority of cases, this shouldn't have any impact; however, this change makes these operators play nice in c++20 contexts.
Shapes were incorrectly closed in certain cases -
the decision to close a shape or not should be based on
path commands rather than the number of points and
their distances from each other.
This introduces a managed condition to precisely control the
canvas updates. This prevents a crash when the target is
changed and drawn without any update calls.
issue: https://github.com/thorvg/thorvg/issues/2484
In case of a problem with loading font data, there
is no paint inside a text that can be rendered,
but this should not interrupt the rendering process
of other paints. Now fixed.
@Issue: https://github.com/thorvg/thorvg/issues/2468
Serialization of the "order" attribute caused
the bytes counter to be overwritten, resulting
in the created TVG file being corrupted.
Correctly created tag.tvg file has been included
as a test resource..
If target() is called again after update() is called and the size of the buffer changes, a crash may occur.
Therefore, check the refresh variable and perform drawing after update().
