Jump to content

QR special character problems


NPN

Recommended Posts

Hi, I guess this one is for Dan:

 

I've made a QR-code for business cards in FP 8.0 published on DSF (DSF only supports FP 8.0)

 

The business card sometimes contain special norwegian characters like Æ Ø Å.

 

I've tested with two of the most downloaded and well known QR-readers in the appstore: i-nigma and QRReader. The special characters displays correctly in QRReader but not in i-nigma. However, if I generate a Vcard from an online generator i-nigma suddenly displays the special character correctly, thus eliminating that the functionality is lacking in i-nigma. Concluding (in my head) that it's the FP QR-code generator that is lacking.

 

In FP I use a graphic rule to generate a vcard (2.1)

 

Online I use: http://keremerkan.net/qr-code-and-2d-code-generator/

 

In which I am careful to specify vcard, version 2.1.

 

Why does FP generate a 'lesser' code, or more importantly; can this be fixed somehow so that the QR-code generated from FP displays correctly on both QR-readers?

 

I'm attaching two examples, one from Fusion Pro and one from the online generator, both vcard version 2.1.

 

If you test using i-nigma and QRReader you should get different results. The online one working on both readers, the FusionPro generated code only displays correctly with QRReader.

(The FP Code contains name: Testæøå Test, the online one only name:ÆØÅ)

QR_Vcard_2_1_DSF.jpg.a7d173da871defb9fd5443d4784f467c.jpg

QR_Vcard_2_1_From_web.png.a03829f2ff058f6f21fb650921435259.png

Edited by NPN
Link to comment
Share on other sites

Hi, I guess this one is for Dan:

Hello! :p

Why does FP generate a 'lesser' code, or more importantly; can this be fixed somehow so that the QR-code generated from FP displays correctly on both QR-readers?

This is an encoding issue. If you scan the "from web" barcode, and look at the raw data, it says, "CHARSET=utf-8". However, the JavaScript engine in FusionPro supports only 8-bit characters, without UTF-8 escapes. So Unicode characters don't really work. The fact that some readers still handle the barcode while others don't just proves that different scanning apps have different capabilities, especially regarding Unicode.

Link to comment
Share on other sites

So what your saying is that there's nothing I can do to make this work, and there's nothing Printable can/will do to change this?

 

I understand that Norwegian support isn't exactly prioritized, but there's a lot of other languages that uses special characters, like spanish and german. Don't they have the same problem?

Edited by NPN
Link to comment
Share on other sites

So what your saying is that there's nothing I can do to make this work, and there's nothing Printable can/will do to change this?

No, I didn't say that. It's something that could be fixed. It's a problem that we acknowledge and recognize, and we will give resolving it consideration for a future release. However, the nature of the way that the JavaScript engine is embedded into FusionPro is not something that can be easily changed.

I understand that Norwegian support isn't exactly prioritized, but there's a lot of other languages that uses special characters, like spanish and german. Don't they have the same problem?

Yes. However, we haven't had any other reports of problems as far as I know. QR barcode technology is still emerging.

 

I have created case FP-11928 to track the lack of Unicode support in QR barcodes. And I apologize for the inconvenience. That's all I can do in the context of this forum. If you want to escalate the issue further, please contact Support or Sales.

Edited by Dan Korn
Link to comment
Share on other sites

  • 5 months later...

This will be fixed in an upcoming release which fully supports Unicode throughout the FusionPro composition.

 

EDIT: The new version which supports Unicode characters in QR barcodes is FusionPro 9.2.

 

There is a workaround for older versions of FusionPro, which is to encode the entirety of the barcode data as UTF-8, with a UTF-8 byte order marker ('\357\273\277') at the beginning. The UTF-8 encoding can be accomplished with the unescape and encodeURIComponent functions, as described here:

http://ecmanaut.blogspot.com/2006/07/encoding-decoding-utf8-in-javascript.html

 

This creates a barcode which returns the Norwegian characters properly when scanned, in FusionPro 9.0:

var barcodeData = "Testæøå ÆØÅ";

if (StringToNumber(FusionPro.version) < 9.2)
   barcodeData = '\357\273\277' + unescape(encodeURIComponent(barcodeData));

return MakeQRBarcodeGraphic(barcodeData);

The check for the FusionPro version is in there because setting the encoding manually like this will actually not work in the new (as yet unreleased) fully Unicode-compliant version of FusionPro.

 

Encoding actual UTF-16 characters, such as Japanese or Chinese, is more complicated, since you have to parse the <unicode> tags that FusionPro generates. The upcoming release of FusionPro will be able to encode any Unicode character, including Norwegian, Danish, Japanese, and Chinese, in a QR barcode.

Edited by Dan Korn
The new FP version with Unicode support is 9.2, not 9.3.
Link to comment
Share on other sites

  • 2 weeks later...

Hi Dan,

Thanks for the reply and workaround. I really appreciate it. Today we have to manually change all the generated cards that has special characters(and generate new QR-codes).

 

Speaking of which, I haven't been able to make this work. How would I include this workaround in my rule?

 

var result = ["BEGIN:VCARD", "VERSION:2.1"];

for (var label in info)

{

if (info[label])

result.push(label + ":" + info[label]);

}

result.push("END:VCARD");

 

return MakeQRBarcodeGraphic(result.join(Chr(13) + Chr(10)));

Link to comment
Share on other sites

Hi Dan,

Thanks for the reply and workaround. I really appreciate it. Today we have to manually change all the generated cards that has special characters(and generate new QR-codes).

 

Speaking of which, I haven't been able to make this work. How would I include this workaround in my rule?

 

var result = ["BEGIN:VCARD", "VERSION:2.1"];

for (var label in info)

{

if (info[label])

result.push(label + ":" + info[label]);

}

result.push("END:VCARD");

 

return MakeQRBarcodeGraphic(result.join(Chr(13) + Chr(10)));

Comment out or delete the last line of the rule and replace it with this:

var barcodeData = result.join(Chr(13) + Chr(10));

if (StringToNumber(FusionPro.version) < 9.3)
   barcodeData = '\357\273\277' + unescape(encodeURIComponent(barcodeData));

return MakeQRBarcodeGraphic(barcodeData);

Link to comment
Share on other sites

  • 1 year later...

I've made a QR-code for business cards in FP 8.0 published on DSF (DSF only supports FP 8.0)

 

The business card sometimes contain special norwegian characters like Æ Ø Å.

 

 

Hi,

First, sorry for my bad english.:p

I have the same problem...

I use FP 9.2.16 and DSF 7.2.0.20726+

 

I try to make QR-codes on business cards wich generate VCARDS.

Using special french characters like "é à è ê oe" wich are not supported on some Android 's QRCode reader applets.

Some applets reads correctly the specials characters and some other don't.

 

In the last post, "Dan Korn" said that the problem was a fusionpro's javascript engine issue and would be resolved in next release.

Could you tell me in what release it will be ?

Or is there any other solution to solve it ?

Like embedding special characters with specifics programmation lines ? In the vcard format (as "FN;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:=41=72=6D=C3=A9=6E=69=6F=20=50=45=52=52=45=49=52=41") or in the javascript Rule ?

 

Thanks in advance.:)

Link to comment
Share on other sites

In the last post, "Dan Korn" said that the problem was a fusionpro's javascript engine issue and would be resolved in next release.

Could you tell me in what release it will be ?

Or is there any other solution to solve it ?

The version to which I was referring in that earlier post here:

This will be fixed in an upcoming release which fully supports Unicode throughout the FusionPro composition.

Is FusionPro 9.2, which you are already using. The Unicode characters are now encoded as UTF-8 in the QR barcode. Basically, FusionPro itself is now automatically doing what the workaround I posted in that other post does.

Using special french characters like "é à è ê oe" wich are not supported on some Android 's QRCode reader applets.

Some applets reads correctly the specials characters and some other don't.

That's an issue with those applets, then. If some apps are reading the barcode correctly, then the barcode that FusionPro is generating is valid. Those other apps probably are not handling the Unicode characters correctly. Therefore, the problem can't be fixed in the barcode, it can only be fixed in those apps.

 

That said, if you can prove me wrong and come up with an example of a QR barcode that all of your apps can read correctly, then I will be happy to examine the barcode and figure out exactly how it's encoding the data, and then we can figure out how to get that same data to be encoded by FusionPro.

Like embedding special characters with specifics programmation lines ? In the vcard format (as "FN;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:=41=72=6D=C3=A9=6E=69=6F=20=50=45=52=52=45=49=52=41") or in the javascript Rule ?

I'm not sure what you mean by "special characters with specifics programmation lines." What exactly is that data supposed to be encoding? If you can provide a more complete example of the barcode data, or even post a barcode, that would give me more context to work with.

Link to comment
Share on other sites

Hi Dan Korn,

First, thanks for your quick answer.

 

So, if i have understand, that's a UTF-8 reading's problem in some applets and not a javascript bug.

 

I'll try to be more precise :

- if i don't use specifics characters, any applet will read the qrcode.

-if i use specifics characters:

- When i scan my code with "QR Droïd" there 's no problem, it generate a vcard and offer to create a contact.

 

- When i scan my code with "Mobiletag","QR Code Reader",or "Barcode Scanner", the code only generate the vcard content in a text format and don't offer to create a contact.

 

Here is my files to let you test.

 

In my zip file, you will find :

- a folder wich contains android's screen results of scan.

- my pdf/fusionpro file

- an output test PDF file.

 

maybe i 've done something wrong or is it just an applet problem ?

 

Thanks in advance for your precious help.

QR TEST.zip

Link to comment
Share on other sites

So, if i have understand, that's a UTF-8 reading's problem in some applets and not a javascript bug.

Yes, it's a problem with those applets.

I'll try to be more precise :

- if i don't use specifics characters, any applet will read the qrcode.

Yes, it's easier for someone making a free Android barcode scanner app to program it to just read Latin-1 characters than to program it to read Unicode. (Although, somewhat ironically, this QR technology was originally designed in Japan, where it obviously worked with Unicode. It's Western implementations of scanning apps that suffer from encoding issues.)

-if i use specifics characters:

- When i scan my code with "QR Droïd" there 's no problem, it generate a vcard and offer to create a contact.

 

- When i scan my code with "Mobiletag","QR Code Reader",or "Barcode Scanner", the code only generate the vcard content in a text format and don't offer to create a contact.

Right, different scanning applications have different features and capabilities in this regard. Some have the ability to add contacts, and some don't. And some can handle different formats for contact data than others can. And some can handle accented Unicode characters in a contact, and others can't.

 

The QR barcode just contains some data. It's up to whatever app is scanning it to figure out how to interpret that data. In this case, the QR code just happens to contain data representing a VCARD contact, but not every app knows what to do with that.

 

At any rate, any such limitations in this regard are limitations in the scanning application, and there's nothing you can change in FusionPro, which is already generating a perfectly valid QR code with VCARD data, to get around them.

 

Now, that said, some apps might interpret a barcode containing MECARD data as a contact, even if they don't handle VCARD. So you could try that. Again, though, it's all specific to the app.

Here is my files to let you test.

 

In my zip file, you will find :

- a folder wich contains android's screen results of scan.

- my pdf/fusionpro file

- an output test PDF file.

I don't see anything wrong with your template. I get exactly the same results that you got scanning the output, with the same Android apps.

maybe i 've done something wrong or is it just an applet problem ?

I'm not sure how else I can word it, but yes, it's an applet-specific issue.

Link to comment
Share on other sites

Thanks a lot for your quick response and your professionalism Dan.

No problem. Like I said before, there may be a particular contact format that's slightly different than what FusionPro is generating, which more mobile apps might be able to handle properly embedded in a QR barcode. If you can find such a barcode, which scans correctly in all of those apps, then I will be happy to take a look at it and figure out how to write a rule to make FusionPro generate barcodes like it.

 

But, if you're looking for a way to embed contact data into a QR barcode that every mobile barcode scanning app out there will handle correctly, I don't think you're going to have much luck finding that mythical creature, regardless of what program you're using to generate the barcode. It's a bit like the early days of the Internet, where you could write a perfectly valid HTML page, but different browsers would render it differently, and some browsers were just plain broken. (Actually, that's still kind of the way things are on the Internet.)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...