I want to create a QRcode (with texte or URL) and display it onthe page,
Is there a function to do that ?
Thanks for answers.
Don’t forget to tell us about your stack!
Linux debian 10
apache 2.4
Lucee 5.4.1.8
Ucanaccess 5 (driver Lucee-Access mdb through JDBC)
Does this post help you?
You can try the one I created
https://github.com/webonix/qr-code-generator
Hi @webonix
Do you know if your code can work in a cfdocument, to output a QR Code inside a PDF?
I’m able to output a QR code if the qr code image file is on disk, but for some reason I’m not able to use the base64 string in the img tag in a cfdocument : <img src="data:image/png;base64,#base64String#" height="600px">
Do you know if cfdocument is supposed to support this?
Thank you!
@TonyMonast. This seems to work fine on my local Lucee 5.4.6.9 install:
zxing = new com.google.zxing();
imageContentAsBase64 = zxing.createQRBinary(
content = "https://github.com/webonix/qr-code-generator/",
size = 600,
margin = 1,
fgColorHex = "25292e",
bgColorHex = "ffffff",
errorCorrection = "H"
);
html = '
<!DOCTYPE html>
<html lang="en">
<head><title>Test</title></head>
<body>
<img src="data:image/png;base64, #imageContentAsBase64#">
</body>
</html>
';
cfdocument( format="PDF", name="pdfBinary" ){
WriteOutput( Trim( html ) )
};
cfheader( name="Content-Disposition", value="attachment; filename=#Chr( 34 )#test.pdf#Chr( 34 )#" );
cfcontent( type="application/pdf", variable=pdfBinary );
Thank you for your answer. This allowed me to better direct my research into why it wasn’t working. Basically I don’t use quite the same library for generating the QR code and my code generates a BufferedImage instead of putting it on the disk, and I had misunderstood the nuance to recover the base64 from that. The base64 I was using for the img tag was incorrect and that’s why it wasn’t working.
Now I will do some tests to make sure that both methods are reliable in a cfdocument to refer to a qr code with the img tag : The method on disk with <img src="file:///path/to/my/qrcode.png"> or the method with the base64 <img src="data:image/png;base64,#imageContentAsBase64#">
Hi!
I used it for a project of mine.
Works perfect. Many thanks 
I’ve got a little curiosity.
Why do you work with “localmode= true”?
I know what that means… I would understand why you prefer “localmode= true” to using “var” or “local” scope.
Thanks again!
I installed the latest version of zxing and it works perfectly if I direct the output of cfimage to writeToBrowser, while inside cfdocument the image does not appear.
Solved:
<cfscript>
qrcode=123456;
zxing = new com.google.zxing();
logoPath = expandPath("../pics/aquila-small.png");
Image = zxing.createQRBinary(
content = "https://mysite.it/?q=#qrcode#",
size = 120,
margin = 1,
fgColorHex = "25292e",
bgColorHex = "ffffff",
errorCorrection = "H",
logoPath = logoPath
);
qrCodeImage = imageNew(Image);
</cfscript>
<cfdocument marginBottom="4" marginTop="4" unit="cm" format="pdf" fontembed="yes" pagetype="A4" orientation="portrait">
<cfoutput>#qrCodeImage#</cfoutput>
</cfdocument>
This is great - we use the Zxing library at work, but I had never seen it before; so it was nice to look at your code to get a sense of how it can be used in ColdFusion. We’re just doing 1D barcodes, but I’m happy to know that QR codes will work as well.
I can feel yet another bennadel.com blog post in the making… #lol
the best way to do this with Lucee 6.2 is using the new java maven support
no more messing around with jars!
I have NO IDEA what you’re talking about … Rendering 1-Dimensional Barcodes With Zxing And ColdFusion
This is so cool! I hate having to manually go through and download all the JAR files. Amazing! I also had no idea that a CFC could have its own java settings! does this create an isolated class-loader per CFC or something?
yes it does, the encapsulation for javasettings creates a specfic classloader for the component.
you can specify javasetttings via .CFConfig.json, Application.cfc or per component only the most specific one is used.
You can also prefix objects using the cfml: or java: prefixes for clarity, the namespace resolution is naturally cfml first, then java.
i.e. if you call this component yaml.cfc the debug() would just dump itself, but by using the java: prefix, you can dump out the java object instead
component javasettings='{"maven":["org.yaml:snakeyaml:2.4"]}'{
import org.yaml.snakeyaml.*;
import java.io.FileInputStream;
function read() {
var yaml = new java:Yaml();
try {
var path=expandPath("customer.yaml");
var is = new FileInputStream(path);
return yaml.load(is);
}
finally {
if(!isNull(is)) is.close();
}
}
function debug(){
dump(new java:Yaml());
}
}
I’m already using this lot of this for doing neat stuff for Lucee docs
Since Lucee 6.2, I no longer have PTSD when thinking about using java libraries with CFML!
Our java support is even better with 7.0, there is a bug with 6.2 when a different version of a java library is already loaded (i.e. tika 3.0, while Lucee bundles 1.2.5), which required some substantial re-plumbing, but it’s been fixed!
So freaking cool!!!
I really like the thinking behind this, but my experience so far is that it’s a bit flaky. I know Micha’s working to make this better in Lucee7 but in 6.2 class conflicts still seem to be happening.
I also don’t love the apparently over-eager downloading of dependencies, when they’re not needed.
Don’t get me wrong, I’m using this in production already, but only for small libraries where I’m sure there won’t be a conflict. I need to be certain that the version I specify is the one that’s loaded.
tika-app is ridiculously large, because of all the different file types it can handle
opening up that mvn folder with WizTree, there are a lot of different versions of the same files!
But does Lucee really need to download anything? I’ve been using the tika-app jar for years and never had to download any additional dependencies.
