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

Update jquery.qrcode.js to support Chrome & Opera #70

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tamcloug
Copy link

Update to determine actual canvas size based on pixel size and getModuleCount(). Canvas width and height options are used as a guideline to determine approximate resulting image size.

Update to determine actual canvas size based on pixel size and getModuleCount().  Canvas width and height options are used as a guideline to determine approximate resulting image size.
@jeromeetienne
Copy link
Owner

Thanks for your contributions!

the code seems clean. i dont understand the relation with chrome or opera tho.
im no expert in qrcode. Another question, what is a module here ?

@tamcloug
Copy link
Author

getModuleCount() was the existing function, it returns the number of tiles across / high that will be needed to generate the final QR Code. I'm not a QR Code expert either so I assume this was a recognized term and retained the convention.

The code defaults to a 256x256 final graphic size which originally was divided by the getModuleCount() to get the individual tile size. With one our our messages that being encoded, this resulted in 49 modules and a tile size of 5.22 pixels to make up the overall image size of 256px. When IE and Firefox process this they use 5px for the tile size and the override the overall image size for a final image that is 245px. Chrome and Opera try to honor the overall image size more than the individual tile size, resulting in every 5th column and 5th row being 6px wide / tall (all others are 5px), rendering an unscannable QR Code. One option is to set the final image size to 245px, but with a variable message length (we're encoding several messages at once dynamically), this would just shift the problem to somewhere else.

The changes I proposed take the 256px requested overall image size, divide that by columns / rows needed to encode the message (module), floor the result to an integer, then multiply that back to get the true final image size. In my case, 256px / 49 cols = 5.22px --> 5px tile size * 49 cols = 245px overall image size.

This issue was also reported by rasec as issue #31 (that defect was key in helping me figure out that the cell sizes were off). Hope this helps clear up my madness :-)

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.

None yet

2 participants