Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support passing PNG data directly to SvgLogo #491

Merged
merged 4 commits into from
Apr 3, 2024

Conversation

Shane32
Copy link
Contributor

@Shane32 Shane32 commented Apr 2, 2024

Summary

This PR fixes/implements the following bugs and features:

  • Fixes a bug where extra null bytes are included with the logo embedded within a SVG
  • Adds a constructor allowing for a custom PNG file data to be supplied to the logo embedded within a SVG

What existing problem does the pull request solve?

When using a third-party library to encode image data, or when reading PNG directly from a stream, this additional constructor allows for it to be passed directly to the created SVG file, without passing through the System.Drawing library.

Test plan

Tests have been added to the codebase

@@ -285,7 +285,7 @@ public SvgLogo(Bitmap iconRasterized, int iconSizePercent = 15, bool fillLogoBac
using (var bitmap = new Bitmap(iconRasterized))
{
bitmap.Save(ms, System.Drawing.Imaging.ImageFormat.Png);
_logoData = Convert.ToBase64String(ms.GetBuffer(), Base64FormattingOptions.None);
_logoData = Convert.ToBase64String(ms.GetBuffer(), 0, (int)ms.Length, Base64FormattingOptions.None);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetBuffer() returns the current working memory buffer allocated by MemoryStream, including extra padding that is reserved but not yet used by the MemoryStream. This is unlike ToArray which copies the working data to a new array of the correct length. To properly use GetBuffer, the length must be passed to Convert.ToBase64String so that only the working data is encoded.

@@ -119,7 +119,26 @@ public void can_render_svg_qrcode_with_png_logo()
var svg = new SvgQRCode(data).GetGraphic(10, Color.DarkGray, Color.White, logo: logoObj);

var result = HelperFunctions.StringToHash(svg);
result.ShouldBe("78e02e8ba415f15817d5ed88c4afca31");
result.ShouldBe("7d53f25af04e52b20550deb2e3589e96");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the extra padding was removed from the SVG, the hash has changed.

var svg = new SvgQRCode(data).GetGraphic(10, Color.DarkGray, Color.White, logo: logoObj);

var result = HelperFunctions.StringToHash(svg);
result.ShouldBe("7d53f25af04e52b20550deb2e3589e96");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can see here that the new constructor results in the same hash as using the System.Drawing.Bitmap constructor.

Copy link
Contributor Author

@Shane32 Shane32 Apr 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is false. Well, I was sorta surprised; .NET should re-encode the PNG with the Bitmap constructor. Not sure why I thought otherwise.

@Shane32 Shane32 changed the title Support passing PNG logos directly to SvgLogo Support passing PNG data directly to SvgLogo Apr 2, 2024
@codebude
Copy link
Owner

codebude commented Apr 2, 2024

Can you please re-check the test-cases? It seem like the changes are breaking one of the test cases @Shane32

@Shane32
Copy link
Contributor Author

Shane32 commented Apr 2, 2024

@codebude Done. FYI, I did save and open the outputs of the two affected tests to be sure they still look correct.

@Shane32
Copy link
Contributor Author

Shane32 commented Apr 2, 2024

@codebude Let me know if there's anything else you want me to look at or help review. Some of the outstanding PRs look to be pretty simple fixes and worth reviewing if you plan to issue a new release (please!). For instance, I could write a PR consolidating these bug fixes and ensuring tests pass, etc -- if you want.

Bug fixes that should probably be reviewed:

New features; would take more time to review:

@codebude
Copy link
Owner

codebude commented Apr 3, 2024

@Shane32 thanks for your support. I really appreciate it!

My plan is as follows:

  • Merge your pull requests
  • Update the wiki/documentation (to include the extensions/changes from your PRs)
  • Check other open PRs (especially the ones you listed)
  • Merge the PRs that can be merged without conflict (merging all PRs into a new one takes away the chance to be listed as a contributor in the project from the people who submitted the PRs. That's why I want to see what can be merged before we consolidate).
  • List non-mergeable (but interesting) requests in an issue and create a consolidated PR for them
  • Release a new QRC or version (1.4.4?, 1.5.0? - depending on how many changes are added).

Rough time plan: 4-7 days

Does that work for you? If you want to use the QRCoder with your changes in advance, you could also use the current package from the Github packages: https://github.com/codebude/QRCoder/pkgs/nuget/QRCoder

@codebude codebude merged commit f3c09a8 into codebude:master Apr 3, 2024
3 checks passed
@Shane32 Shane32 deleted the allow_custom_png_image_in_svg branch April 3, 2024 12:27
@Shane32
Copy link
Contributor Author

Shane32 commented Apr 3, 2024

Certainly that works for me and I appreciate your attention. Thanks again, and let me know if I can be of assistance.

Just so you know, as maintainer you can push additional commits to any PR where the contributor checked the “allow edits from maintainers” checkbox, which most people do. It’s great for preserving authorship and due credit towards those contributors, but it’s a bit of pain to actually do. You need to configure another source within Git for the repo, which can be done from within VS, and then you can merge across repos, fix tests, etc. (But me as a contributor the most I could do is to create a new PR.)

@Shane32
Copy link
Contributor Author

Shane32 commented Apr 7, 2024

@codebude I reviewed a number of the outstanding PRs and left comments. Some can be merged as-is; some need tests updated. Let me know if I can be of assistance. Thanks!

@codebude
Copy link
Owner

codebude commented Apr 7, 2024

Hi @Shane32 ,
thanks again. Saw your comments and will check the PRs today. :-)
Btw. updated the wiki and release notes. Feel free to add comments/change the release notes if I didn't got the point of your PRs: https://github.com/codebude/QRCoder/wiki/Release-notes

@Shane32
Copy link
Contributor Author

Shane32 commented Apr 16, 2024

@codebude I also went through all of the outstanding issues and added a couple PRs:

Adding support for Base64QRCode within Linux is a much-requested feature, and as the default implementation creates a PNG, PR #495 leverages the existing PngByteQRCode class to base-64 encode a PNG file without using System.Drawing.Common. Attempting to create a JPG will throw a PlatformNotSupportedException unless on Windows.

Can I ask what your plans are for the remaining bugfix PRs and/or publishing a new release to NuGet?

Thanks again, and let me know if I can be of further assistance.

@codebude
Copy link
Owner

Hi @Shane32 ,

my plan is still to go through the open PRs and merge as many of them as possible. (Ideally all that can be merged with manageable effort. I would like to reserve larger PR for a later release).

Unfortunately, I've already missed the 4-7 days to the next release that I announced in the comments above, but I hope you can see that I'm making (slow but) steady progress. Unfortunately, things are not going as quickly as I would like at the moment. (My little daughter and my main job are currently taking up a lot of my time and they both have priority over my leisure projects). Nevertheless, I hope to be able to release version 1.5.0 soon.

I would still like to look at PRs #495, #411, #474 as well as #430 /#438 and (if possible) merge them. After that, I plan to push 1.5.0 to Nuget before continuing with the other issues and PRs.

@Shane32
Copy link
Contributor Author

Shane32 commented Apr 19, 2024

Sounds great and thanks for the update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants