We always appreciate your contribution. ThorVG doesn't expect patches to be perfect; instead, we value contributions that make ThorVG better than before. This page outlines the ThorVG contribution format.

## Reviewers Hermet Park (hermet) is the lead maintainer. Moreover, there are designated maintainers you can contact for individual modules when submitting pull requests. gl_engine: Ruiwen Tang (RuiwenTang)
svg_loader: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
tvg_loader: Mira Grudzinska (mgrudzinska)
webp_loader: Junsu Choi (JSUYA)
tvg_saver: Mira Grudzinska (mgrudzinska)
capi: Mira Grudzinska (mgrudzinska)
test: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
svg2png: Junsu Choi (JSUYA)
examples: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)

## Self Test & Verification After updating the ThorVG code, please ensure your changes don't break the library. We recommend conducting unit tests. You can easily run them using the following build commands:

` $meson . build -Dtests=true -Dloaders="all" -Dsavers="all" -Dbindings="capi" -Dtools="all" -Dlog=true `
` $ninja -C build test `

Please make it sure running all tests and no any fail case.

Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0

## Commit Message [Module][Feature]: [Title] [Description] - [Module] refers to the sub-module primarily affected by your change. Most of the time, this indicates the name of a sub-folder. This also suggests who might need to review your patch. If your change doesn't belong to any sub-modules, you can either replace this with a suitable name or skip it. The name should be written entirely in lowercase letters. - e.g., build, doc, infra, common, sw_engine, gl_engine, svg_loader, examples, wasm, svg2png... - [Feature] indicates the primary function or feature you modified. Typically, this represents a class or file name. This is an optional. - e.g., canvas, shape, paint, scene, picture, task-scheduler, loader, builder, ... - [Title] provides a brief description of your change and should be encapsulated in a single sentence. - e.g., "Fixed a typo." - e.g., "Addressed compile warnings." - e.g., "Refactored code." - e.g., "Resolved a rendering bug causing overlapped shapes to display improperly." - [Description] doesn't have a strict format. However, it should detail what you accomplished in this patch as comprehensively as possible. If you've resolved bugs, include the following details: - The type of bug. - Steps to reproduce it. - The root cause. - The solution applied. For new features or functions, cover: - The nature of the feature. - Full API specifications (if there are any API additions). - Its necessity or rationale. - Any conditions or restrictions. - Relevant examples or references. Finally, include any related issue ticket numbers in this section, if applicable. Here's a sample commit message for clarity: - renderer/paint: Introduced path clipping feature We've added a new method, Paint::composite(), to support various composite behaviors. This allows paints to interact with other paint instances based on the chosen composite method. Initially, we're introducing the "ClipPath" method for path-based clipping. targetPaint->composite(srcPaint, CompositeMethod::ClipPath); Note: If the source paint lacks path information, clipping may not produce the desired effect. @API Additions: enum CompositeMethod {None = 0, ClipPath}; Result Paint::composite(std::unique_ptr target, CompositeMethod method) const noexcept; @Examples: Introduced ClipPath @References: [Provide any relevant links, such as screenshots.] @Issues: [Link to the issue]
## Pull Request Once you've submitted a pull request (PR), please ensure the following checklist is completed: - Reviewers: Check the Reviewers List. - Assignees: You should be assigned. - Labels: Mark the appropriate Patch Purpose. - Automated Integration Test: All must pass.