Draw and measure barcodes: 113 linear, postal, stacked, 2D and GS1 Composite symbologies with OCR-A and OCR-B fonts

.editorconfig

@@ -19,6 +19,7 @@ indent_size = 4
 end_of_line = lf
 insert_final_newline = true
 trim_trailing_whitespace = true
+max_line_length = 160
 
 ##########################################
 # File Extension Settings
@@ -134,6 +135,10 @@ csharp_style_prefer_null_check_over_type_check = true:warning
 # C# Style Rules
 # https://docs.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/language-rules#c-style-rules
 [*.{cs,csx,cake}]
+# Report lines exceeding the shared editor limit during analysis and builds.
+roslynator_max_line_length = 160
+dotnet_diagnostic.RCS0056.severity = warning
+
 # 'var' preferences
 csharp_style_var_for_built_in_types = false:error
 csharp_style_var_when_type_is_apparent = false:error

.gitattributes

@@ -140,6 +140,8 @@
 *.avif              filter=lfs diff=lfs merge=lfs -text
 *.hvc1              filter=lfs diff=lfs merge=lfs -text
 *.hvcc              filter=lfs diff=lfs merge=lfs -text
+*.ivf               filter=lfs diff=lfs merge=lfs -text
+*.y4m               filter=lfs diff=lfs merge=lfs -text
 *.yuv               filter=lfs diff=lfs merge=lfs -text
 *.bit               filter=lfs diff=lfs merge=lfs -text
 ###############################################################################

.github/workflows/build-and-test.yml

@@ -81,7 +81,7 @@ jobs:
             sdk-preview: true
             runtime: -x64
             codecov: false
-          - os: ubuntu-22.04-arm
+          - os: ubuntu-24.04-arm
             framework: net11.0
             sdk: 11.0.x
             sdk-preview: true
@@ -103,7 +103,7 @@ jobs:
             sdk: 10.0.x
             runtime: -x64
             codecov: false
-          - os: ubuntu-22.04-arm
+          - os: ubuntu-24.04-arm
             framework: net10.0
             sdk: 10.0.x
             runtime: -x64

.gitignore

@@ -234,3 +234,7 @@ SixLabors.Shapes.Coverage.xml
 /plans/
 
 samples/Avalonia**
+
+# Specifications are licensed documents and stay on the local machine only.
+/src/ImageSharp.Drawing/Barcodes/specs/
+/src/ImageSharp.Drawing.FontGenerator/specs/

AGENTS.md

@@ -4,9 +4,12 @@ These instructions apply to the entire repository. More-specific `AGENTS.md` fil
 
 ## Working Practices
 
-- Inspect the relevant implementation, tests, benchmarks, project files, and nearby code before proposing or making changes. Do not infer current behavior when the source is available.
+- Inspect only the source and supporting files needed for the task before proposing or making changes. Do not infer current behavior when the source is available.
 - Make the smallest complete change that solves the requested problem. Avoid unrelated cleanup, speculative abstractions, and formatting churn.
-- Match established architecture, naming, formatting, documentation, and test patterns. Treat `.editorconfig`, analyzers, and repository build settings as authoritative.
+- Trace the existing execution path before changing it. Extend and optimize the existing implementation within the requested behavior and affected path.
+- Before implementing an operation, find and inspect the existing APIs that provide it. Use or extend those APIs instead of writing equivalent logic elsewhere. This includes color conversion, pixel conversion, memory management, and vectorized operations. If an API lacks required behavior, improve its owning implementation rather than bypassing it with a separate implementation.
+- Follow existing naming, formatting, documentation, and test patterns. Treat `.editorconfig`, analyzers, and repository build settings as authoritative.
+- Use simple technical English in all communication, documentation, and comments. Use short sentences, active voice, and existing code terminology.
 - Preserve public API and observable behavior unless the task explicitly requires a change. Public API documentation must describe observable behavior, not implementation details.
 - Do not use reflection against built assemblies, ad hoc assembly loading, or temporary probe projects unless explicitly requested.
 - Build .NET projects in Release configuration unless explicitly instructed otherwise.
@@ -15,27 +18,26 @@ These instructions apply to the entire repository. More-specific `AGENTS.md` fil
 
 - Treat throughput, latency, memory use, and binary size as design constraints, especially in pixel-processing, drawing, parsing, encoding, and other hot paths.
 - Avoid unnecessary allocations, copies, boxing, closures, interface dispatch, repeated enumeration, and extra passes over data.
-- Reuse the repository's existing memory ownership, pooling, span, vectorization, and parallelization patterns. Do not introduce a new mechanism when an established one fits.
-- Keep hot loops simple and bounds-check-friendly. Hoist invariant work, preserve locality, and use the narrowest suitable data types without sacrificing correctness.
-- Do not trade correctness or maintainability for assumed speed. Support non-obvious optimizations with measurements or clear evidence, and add or update benchmarks when performance is the purpose of the change.
+- Reuse existing memory ownership, pooling, span, vectorization, and parallelization mechanisms.
+- Use a SIMD-first design for suitable data processing code. Build on existing vectorized operations, dispatch mechanisms, and scalar fallbacks. Keep hot loops simple, hoist invariant work, and preserve memory locality.
+- Preserve correctness and maintainability during optimization. Distinguish source-based reasoning from measured results. Claim a speedup only with measurements. Use existing benchmarks first. Add or update cases only when they measure relevant behavior that existing benchmarks miss.
 - Consider all supported target frameworks and runtime capabilities. Do not regress fallback paths while optimizing newer runtimes.
 
 ## C# Conventions
 
-- Follow the existing code around the change; local patterns take precedence over generic preferences.
+- Follow local patterns when they comply with the explicit rules.
 - Do not use `record` or `record struct` types.
 - Prefer established invariants over redundant guards. Validate at real external boundaries and do not add defensive checks for internally controlled states.
-- Do not extract single-use helpers merely to name a block. Extract only for genuine reuse, an established local pattern, or meaningful complexity reduction.
+- Do not extract single-use helpers merely to name a block. Extract only for genuine reuse, an established local pattern, or independently complex logic.
 - Add vertical whitespace after multi-line statements and declarations and between distinct logical stages. Never add trailing whitespace.
-- Document every method, constructor, and property, regardless of whether it is public, internal, protected, or private. Keep public API documentation limited to observable behavior; use private and internal documentation to capture the contract and intent needed to maintain the code.
-- Add inline comments throughout complex code. Explain algorithms, formulas, invariants, ownership, compatibility behavior, and performance tradeoffs at the operations and decisions they govern. Explain why the code is shaped that way rather than narrating the syntax.
-- Document SIMD code especially thoroughly. Explain the vector layout, lane meaning, widening or narrowing, masks, shuffles, constants, alignment or remainder handling, supported instruction paths, scalar equivalence, and the reason each non-obvious operation is correct.
-- Write algorithm and SIMD comments for a maintainer who is unfamiliar with the implementation. The reader should not need to reconstruct intent from external documentation, issue history, or benchmark results.
+- Document every added method, constructor, and property, regardless of visibility. Update documentation when a member's behavior or contract changes. Keep public API documentation limited to observable behavior. Use private and internal documentation to explain the contract and intent.
+- Add inline comments that explain why complex code works. Explain algorithms, formulas, invariants, memory ownership, compatibility behavior, and performance decisions where they apply.
+- For SIMD, explain lane layouts, operations, alignment, remainders, and scalar equivalence so an unfamiliar maintainer can follow the code.
 
 ## Verification
 
-- Add or update focused tests when behavior changes, following the test framework and conventions already used by the project.
-- Never hack, weaken, skip, conditionally bypass, or otherwise manipulate a test to make it pass. Fix the production defect or the genuine test defect while preserving the test's intended coverage and sensitivity.
-- Do not update golden files, reference images, snapshots, baselines, or expected-output artifacts to resolve a test failure. Treat a mismatch as evidence to investigate and correct the implementation.
-- Run the narrowest relevant formatting, test, and Release build commands, then expand verification in proportion to the risk and scope of the change.
+- Add or update tests only when they prove a required behavior or expose a real defect. Derive expectations from established contracts, explicit requirements, or defect evidence. Use source to identify contracts and integration points, not to copy implementation results into expectations. Prefer extending existing tests. Avoid redundant cases and assertions that merely repeat the implementation.
+- Never weaken, skip, or bypass a valid test to make it pass. Fix the production defect or the genuine test defect. Replace or remove a test only with evidence that its expectation is invalid or its coverage is redundant.
+- Do not update golden files, reference images, snapshots, baselines, or expected-output artifacts merely to silence a failure. Investigate mismatches. Update expected results only for an established requirement change or an incorrect reference result proved by independent contract or defect evidence.
+- Test the actual behavior through the existing execution path. Synthetic inputs must exercise an established requirement or reproduce a real defect. Do not invent requirements or substitute internal structure and helper calls for assertions about required behavior. Run the narrowest relevant formatting, test, and Release build commands.
 - Report what changed, the verification performed, and any remaining risks or unverified assumptions.

ImageSharp.Drawing.All.slnx

@@ -18,6 +18,9 @@
     <Project Path="src/ImageSharp.Drawing.WebGPU/ImageSharp.Drawing.WebGPU.csproj" />
     <Project Path="src/ImageSharp.Drawing/ImageSharp.Drawing.csproj" />
   </Folder>
+  <Folder Name="/tools/">
+    <Project Path="src/ImageSharp.Drawing.FontGenerator/ImageSharp.Drawing.FontGenerator.csproj" />
+  </Folder>
   <Folder Name="/tests/">
     <File Path="tests/Directory.Build.props" />
     <File Path="tests/Directory.Build.targets" />

ImageSharp.Drawing.slnx

@@ -23,6 +23,9 @@
     <Project Path="tests/ImageSharp.Drawing.ManualBenchmarks/ImageSharp.Drawing.ManualBenchmarks.csproj" />
     <Project Path="tests/ImageSharp.Drawing.Tests/ImageSharp.Drawing.Tests.csproj" />
   </Folder>
+  <Folder Name="/tools/">
+    <Project Path="src/ImageSharp.Drawing.FontGenerator/ImageSharp.Drawing.FontGenerator.csproj" />
+  </Folder>
   <Folder Name="/tests/Images/" />
   <Folder Name="/tests/Images/Input/" />
   <Folder Name="/tests/Images/Input/Bmp/">

SECURITY.md

@@ -2,16 +2,23 @@
 
 ## Supported Versions
 
-Six Labors provides security fixes only for the latest major version of each library.
+Six Labors provides security updates for the latest major version of each library.
 
-Older major versions are end-of-life and do not receive security fixes.
+Each major version remains eligible for security updates for 12 months after the first stable release of the next major version of that library.
+After this period, that major version is end-of-life and does not receive security updates.
 
-Users must upgrade to the latest major version to receive security fixes.
+Users must install the latest available patch or minor release within a supported major version to receive security fixes.
+Older releases within that major version are not maintained separately.
 
-| Version              | Supported |
-| -------------------- | --------- |
-| Latest major version | Yes       |
-| Older major versions | No        |
+| Version | Supported |
+| ------- | --------- |
+| Latest major version | Yes |
+| Superseded major version within 12 months of the next major's first stable release | Yes |
+| Superseded major version after that 12-month period | No |
+
+Security updates may require a license key under the existing license terms. This does not change the license terms.
+
+This policy covers security fixes only. It does not include feature backports or extend support for underlying .NET versions.
 
 Security fixes, if any, are provided at Six Labors' discretion.
 

THIRD-PARTY-NOTICES

@@ -38,3 +38,77 @@ MIT License. The full license texts are available in the Vello repository
 LICENSE-APACHE and LICENSE-MIT files.
 
 ================================================================================
+
+.NET Runtime (https://github.com/dotnet/runtime)
+License: MIT
+
+Portions of this software were developed with reference to the .NET runtime
+project, including the pooled string and list building buffers.
+
+Copyright (c) .NET Foundation and Contributors
+
+The .NET runtime project is distributed under the MIT License. The full license
+text is available in the .NET runtime repository LICENSE.TXT file.
+
+================================================================================
+
+Barcode Writer in Pure PostScript (https://github.com/bwipp/postscriptbarcode)
+License: MIT
+
+Portions of this software were developed with reference to the Barcode Writer
+in Pure PostScript project, including barcode symbology encodation.
+
+Copyright (c) 2004-2024 Terry Burton
+
+Barcode Writer in Pure PostScript is distributed under the MIT License. The
+full license text is available in the project repository LICENSE file.
+
+================================================================================
+
+bwip-js (https://github.com/metafloor/bwip-js)
+License: MIT
+
+Portions of this software were developed with reference to the bwip-js
+project, including barcode symbology encodation.
+
+Copyright (c) 2011-2026 Mark Warren
+
+The bwip-js project is distributed under the MIT License. The full license text
+is available in the bwip-js repository LICENSE file.
+
+================================================================================
+
+Zint (https://github.com/zint/zint)
+License: BSD-3-Clause
+
+Portions of this software were developed with reference to the Zint barcode
+library backend, including barcode symbology encodation.
+
+Copyright (C) 2008-2026 Robin Stuart and the Zint contributors
+
+The Zint backend is distributed under the BSD 3-Clause License. The full
+license text is available in the Zint repository LICENSE file.
+
+The GS1 DataBar element width routine derives from the combins and getRSSwidths
+functions of ISO/IEC 24724 Annex B, which the Zint backend carries with this
+notice: "Copyright (C) 2006 BSI ... This does not preclude the free use, in the
+course of implementing the standard, of necessary details such as symbols, and
+size, type or grade designations."
+
+================================================================================
+
+GS1 Barcode Syntax Dictionary (https://github.com/gs1/gs1-syntax-dictionary)
+License: Apache-2.0
+
+Portions of this software incorporate the GS1 Barcode Syntax Dictionary and
+were developed with reference to its Syntax Tests.
+
+Copyright (c) 2020-2021 BWIPP project
+Copyright (c) 2020-2021 Zint Project
+Copyright (c) 2021-2026 GS1 AISBL
+
+The GS1 Barcode Syntax Dictionary is distributed under the Apache License,
+Version 2.0. The full license text is available in the gs1-syntax-dictionary
+repository LICENSE file.
+
+================================================================================