Rust working plan

I believe @nayuki did an incredible job—check it out for yourself: demo, step-by-step guide, compact segmentation page, and optimization insights.

Memento mori. Every project reaches a stage where development slows down or stops. Clearly, @nayuki has done a lot and owes nothing to anyone. It would be a shame if such valuable work were lost.

The Rust crate qrcodegen has 2´300´000 downloads overall. This crate was built with care, which is why so many people started using it. I’d like to continue developing the crate because I’m interested in the growth of the Rust ecosystem.

If a project can’t continue to evolve, it’s effectively dead. It cannot be considered the best library by definition—even if it meets all stated goals like flexibility, correctness, minimalism, and documentation. For a project to grow, development must be delegated to the motivated community members. It's essential to maintain quality without relying on manual oversight.

Here is my perspective on what can be done to improve the situation. Most of the points below I’ve already implemented in my fork and will publish later. Others will require collaboration. It's okay to disagree with what’s been written. I’m an independent person with my own ideas—concepts I’ve developed through professional experience with Rust, as well as reading the feedback from the issues and pull requests of this repository.

---

Ecosystem

• Logotype
  ^{a stylized postmark with a pixel crab over it? Gonna ask my friend designer to help with it}
• Make it collaborator-friendly
  ^{create .gitignore, CONTRIBUTING.md files, be welcome for improvements}
• Make it user-friendly
  ^{describe common scenarios and integrate with popular rust crates}
• Compare with another crates: rxing, qrcode, qr_code, etc
  ^{present as a table with pros & cons}
• Probably rename the crate to qr
  ^{if @jht5945 is ok with it}

Functionality

• Kanji mode ✔︎
  ^{the Japanese community will love this}
• Bit-length optimizer ✔︎
  ^{the algorithm is present at Java codebase, but not in Rust port
  #40}
• Micro QR
  ^{is supported by another crate}

SVG renderer ✔︎

It's good to have out-of-the-box solution.

It was removed at 5bc7bce3, so everybody now has to copy-paste the same piece of code from examples.

• The generated SVG could be optimized as suggested by @dominikwilkowski
  ^#204
• API should support streaming to a io::Writer
  ^{to not store the whole string in-memory}
• It's good to have some basic customization like colors
  ^{https://github.com/kennytm/qrcode-rust?tab=readme-ov-file#svg-generation}
• Encourage copy-pasting the code

Image renderer ✔︎

It's a common scenario to embed a base64 .png picture into web servers.

• Integrate the image renderer made by @constantoine
  ^{https://github.com/constantoine/qrcodegen-image}
• Choose your own format encoders
  ^{you just need to include jpg, gif, avif features on the image crate}
• Make it optional, under a feature flag
  ^{to reduce the compilation time}

Quality

• Set up rustfmt, reformat code and doc comments ✔︎
  ^#39
• Bring up the linters ✔︎
  ^{cargo check, clippy}
• Cover the code with unit tests
  ^{Especially check the edge cases}
• Benchmarking as a ground for further optimizations
  ^{with divan or criterion}
• Check against Crate API guidelines
  ^{https://rust-lang.github.io/api-guidelines/about.html}
• Merge with #[no_std] code
  ^{make a separate feature flag}
• Highlight panicking methods or avoid panics at all
  ^{to bring trust and provide reliability}
• Compliance with ISO/IEC 18004:2024
  ^{it would be a solid argument for picking this library}
• Introduce demo generator on docs.rs
  ^{version, mask and ecc could be tuned right there}

---

If I had complete freedom, I would do the following:

1. Extract this repository into a separate one, where @nayuki is the owner, and I’m the maintainer with full editing rights. I already have experience with this setup in the yake-rust project.
2. Rebase the entire history to keep only the commits relevant to the Rust library.
3. Grant me publishing rights for new versions on crates.io.

Another option is simply to fork the project—developing an independent version of the crate. But in that case, users would be negatively affected: instead of just updating the version in their Cargo.toml, they would now have to discover that a compatible fork exists.

I am open to discussion, as my intentions clearly may not match those of @nayuki. Which is totally fine.

No source files, tests, or single entry point are named. Start by reviewing the Rust crate and the linked issues, then narrow the plan to one independently scoped item; this issue does not define a single completion criterion.