Log in to start a topic

ActiveReports 13 - QRCodes, ECI values and encoding

Posted by: sandro.puhmeister on 8 August 2019, 9:16 pm EST

  • sandro.puhmeister

    • Post Options:
    • Link
      Copy

    Posted 8 August 2019, 9:16 pm EST

    Hi,

    I have created a .rpx SectionReport with a QRCode component and added some generic data to the QRCode component. Generated QR codes need to meet specific criteria given by our national bank in order to be accepted as valid.

    Data type: byte mode or binary

    ECI value: 4

    Encoding type: ISO-8859-2

    Our generated QR codes aren’t fullfiling shown criteria therefore they are considered as invalid by our national bank.

    How can we correct these settings in the .rpx report designer to meet the given criteria? Are there any alternatives (maybe in C#)?

    I have also noticed that there is no support for ISO-8859-2 encoding so we are trying Unicode (UTF-8) 65001.

    I am looking forward to hearing from you soon.

    Best Regards,

    Sandro

  • mohitg

    Posted 8 August 2019, 10:44 pm EST

    Hello,

    You can provide the Byte value to QR Code. using the following line of codeL

                this.barcode1.ValueBinary = myByte;

    Also, Central European (ISO) 28592 is supported in the QR Code which is same as Iso-8859-2 as per the following link:

    https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding?view=netframework-4.8

    About, ECI, in my understanding, it will automatically set with Encoding. Please confirm if my understanding is correct or not.

    Thanks.

  • sandro.puhmeister

    Posted 9 August 2019, 1:02 am EST

    Hello,

    I have converted the input value to binary at runtime and generated the QRCode as provided above. Validation goes through with the DataType but not with the ECI value. Now it says ECI value isn’t used and it’s absolutely required.

    Regards,

    Sandro

  • mohitg

    Posted 11 August 2019, 5:16 pm EST

    Hello,

    Thanks for the information. I have forwarded this to our development team(274921) and will inform you once I got any reply from them.

    Thanks.

  • sandro.puhmeister

    Posted 11 August 2019, 6:20 pm EST

    Hello,

    Thank you for your help.

    We would also like to point out that some character mappings aren’t correct in the QR code component for the Central European (ISO) 28592 encoding. We have created some data containing our special characters like: 0160, 0161, 017D, 017E, 010C and 010D (ISO/IEC 8859-2 (Latin-2) encoding table) and assigned it to the QR code component. None of our special characters were mapped/displayed correctly when scaning QR codes with our devices. We use QR codes in our other products so our scanning software is well tested.

    Here is our method for encoding/decoding strings in our test report.

    public void Detail_Format() {
	if (rpt.Fields.Contains("QRCode")) {
		string fieldValue = rpt.Fields["QRCode"].Value.ToString();
		if (fieldValue.Length > 0) {
			this.QRCode_Fixed.ValueBinary = Encoding.GetEncoding(28592).GetBytes(fieldValue);
			this.txtQRText.Text = Encoding.GetEncoding(28592).GetString(this.QRCode_Fixed.ValueBinary);
			this.txtSQLText.Text = rpt.Fields["QRCode"].Value.ToString();
		}
	}
}

    We have encoded in decoded our data and displayed it in the report TextBox component and everything looks fine there, encoding is correct.

    Are there any other settings in the QR code component that we should check and correct?

    Thank you.

    Best Regards,

    Sandro

  • mohitg

    Posted 11 August 2019, 7:33 pm EST

    Hello Sandro,

    Just for confirmation, have you set the “Encoding” property of QrCode to “Central European (ISO) 28592”?

    Thanks.

  • sandro.puhmeister

    Posted 11 August 2019, 7:45 pm EST - Updated 30 September 2022, 7:22 am EST

    Hello,

    Yes, encoding is set on both sides, component and script (please check the provided image).

    Thank you.

  • mohitg

    Posted 11 August 2019, 7:58 pm EST

    Hello,

    Is it possible to share the sample database. If you don’t want to share the database publicly, you can upload the db at the following link:

    https://www.dropbox.com/request/pprgRUGcO6evALDBlZUj

    This will help us to narrow down the issue.

    Thanks.

  • sandro.puhmeister

    Posted 11 August 2019, 8:40 pm EST - Updated 30 September 2022, 7:22 am EST

    Hello,

    I can’t share our database over the network since it’s our development database and it’s very large, but I can share the exact same example that I am working with. I have hardcoded my example into the Detail query because we need valid results on the report side first. We can’t process live data until static one works.

    Here is my test query:

    SELECT 
'UPNQR' + CHAR(10) + 
CHAR(10) + 
CHAR(10) + 
CHAR(10) + 
CHAR(10) + 
'Sandro ŽžŠšČč' + CHAR(10) +  
'Some Random Street 1' +  CHAR(10) + 
'1000 Ljubljana' + CHAR(10) + 
'00000009999' + CHAR(10) + 
CHAR(10) + 
CHAR(10) + 
'GDSV' + CHAR(10) + 
'Plačilo ZZZ 01-123-12' + CHAR(10) + 
'09.08.2019' + CHAR(10) + 
'SI56123456712345678' + CHAR(10) + 
'SI002019-99' + CHAR(10) + 
'development' + CHAR(10) + 
'ŽžŠšČč Street 2' + CHAR(10) + 
'2000 Maribor' + CHAR(10) + 
'185' + CHAR(10) AS QRCode

    Characters ŽžŠšČč are not displayed correctly on this forum aswell. Here the Cc characters I wrote should actually be displayed as 010C and 010D (ISO 8859-2).

    Our language is slovenian therefore our database collation is set to Slovenian_CI_AS (Microsoft SQL Server). Our products use ISO 8859-2 encoding and don’t have any issues when encoding our special characters. This stands for our mobile applications, web applications and windows applications.

    I have provided an image of the ISO 8859-2 table and marked our special charcters with red borders (see image encoding.png bellow).

    I have also provided a screenshot from the report viewers result (see image sample.png bellow) and a zoomed-in QR code/result (see image qrcode.png bellow).

    812×594 10.2 KB


    713×829 47.3 KB

    Best Regards,

    Sandro

  • sandro.puhmeister

    Posted 11 August 2019, 8:43 pm EST

    Characters ŽžŠšČč are not displayed correctly on this forum aswell. Here the Cc characters I wrote should actually be displayed as 010C and 010D (ISO 8859-2).

    Just the forums editor issue and not the actual view.

    Regards,

    Sandro

  • mohitg

    Posted 11 August 2019, 9:11 pm EST

    Sandro,

    Thanks a lot for the information. We are working on this and will reply once I get find a solution for this.

    Thanks.

  • sandro.puhmeister

    Posted 12 August 2019, 9:58 pm EST

    Hello,

    Excellent. I’m looking forward to hearing from you soon.

    Thank you.

    Best Regards,

    Sandro

  • mohitg

    Posted 13 August 2019, 1:56 pm EST

    Hello Sandro,

    I am able to reproduce the issue at our end. Barcode scanner read it as “ISO 8859-1” encoding instead of “ISO 8859-2” encoding that’s why unexpected result appears.

    I have escalated this to our development team (274962)and will inform you once I got any reply from them.

    Thanks.

  • mohitg

    Posted 13 August 2019, 5:14 pm EST

    Hello,

    Are you able to print the same barcode successfully in AR3? If yes, could you please share the report with the same barcode exported to PDF format in AR3.

    Thanks.

  • sandro.puhmeister

    Posted 13 August 2019, 7:40 pm EST

    Hello,

    We don’t have a working example for QR codes in AR3 since there are no encoding options for barcodes in our old Report Designer to begin with. Also the Barcode component in AR3 has no ValueBinary property (at least no one has found it so far), meaning we can’t encode our data properly in any way.

    We have completely ignored QR codes in AR3 because we couldn’t produce valid data representations. We used regular barcodes instead until recently. Demands were given that we need to upgrade our regular barcodes to QR codes. This is one of the main reasons why we are testing AR13 QR codes.

    We are planing to upgrade our reports from AR3 to AR13 and migrate at least a portion of our old reports to the new AR13 design/structure ASAP.

    If we can’t represent our data with valid QR codes in AR13 we’ll be forced to find another reporting software that implements what we need, causing us loss of valuable time and money in the process. We are expecting a valid solution for AR13 QR codes since this would be the easiest and fastest transition for us to go with.

    If I can help in any other way, please let me know.

    Thank you for your support and understanding.

    Best Regards,

    Sandro

  • mohitg

    Posted 13 August 2019, 7:51 pm EST

    Hello,

    I understand your concern. We will try our best so that you can achieve your desired result.

    I am discussing your requirements with our project manager and will inform you once I get any information from them.

    Thanks.

  • mohitg

    Posted 19 August 2019, 10:19 pm EST

    Hello Sandro,

    As our developer busy with the current release but due to the criticality of this issue, they research on the issue and found that it is very complex fix which will take time. So they decided to return on this case after we release AR13 SP2(which is scheduled to release at the end of this month).

    Thanks for your cooperation.

    Regards,

  • sandro.puhmeister

    Posted 19 August 2019, 11:00 pm EST

    Hello,

    We fully understand your priorities and wish you all the best with the upcoming release. Expectations are probably high on all ends so we are willing to wait for a while but we have to ask.

    Have you discussed a possible release date for this fix (like, approx. 1 to 3 months from AR13SP2 release or longer)?

    It would be nice to have at least an approx. date to help us narrow down the wait time. In the end, time is money.

    Thank you for all the feedback and support so far.

    Best Regards,

    Sandro

  • Sergey.Romanov

    Posted 19 August 2019, 11:53 pm EST

    Hello Sandro ,

    as Mohit said, the developers team will take your request for the detailed research right after SP2 release, so we should get the research results during September.

    unfortunately, we can’t guarantee that the issue will be fixed with research, because right now the complexity of fix/issue is not clear.

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 20 August 2019, 5:56 pm EST

    Hello Sergey,

    Thank you for valuable information.

    Best Regards.

    Sandro

  • sandro.puhmeister

    Posted 15 September 2019, 7:51 pm EST

    Hello,

    Are there any news on the issue where QRCode component doesn’t encode characters into ISO 8859-2 correctly?

    Best Regards.

    Sandro

  • mohitg

    Posted 15 September 2019, 8:12 pm EST

    Hello,

    I have asked the development team about the same and will inform you once I get an update from them.

    Thanks,

    Mohit

  • Sergey.Romanov

    Posted 15 September 2019, 8:25 pm EST

    Hello Sandro ,

    this issue is on a top of our tasks queue. developers team will take it for research soon. i will let you know results when i get it.

    Thanks,

    Sergey Romanov.

  • Sergey.Romanov

    Posted 22 September 2019, 10:15 pm EST

    Hello Sandro ,

    the fix for ISO-8859-2 encoding is in the tests stage.

    the hotfix package should be ready this week.

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 22 September 2019, 10:34 pm EST

    Hello Sergey,

    This is awesome news! I have just enough trial days left to test the QRCode component once your hotfix is released.

    Thank you so much!

    Looking forward to hearing from you soon.

    Best Regards,

    Sandro

  • Sergey.Romanov

    Posted 23 September 2019, 6:04 pm EST

    Hello Sandro ,

    here is a link to the hotfix:

    https://cdn.grapecity.com/ActiveReports/AR13/hotfixes/ActiveReports-v13.2.18485.0.msi

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 23 September 2019, 8:17 pm EST - Updated 30 September 2022, 7:21 am EST

    Hello Sergey,

    I would like to inform that your hotfix does not solve our QR code issues for our country.

    This is the wrong output before the hotfix:

    This is the wrong output now, with your hotfix:

    This is the desired output:

    Our QR code validation software still returns an error with the ECI value. ECI value must be set to 4 otherwise QR code validation fails, and these forbidden characters must be solved as well.

    Thank you for your help and time looking into this.

    Best Regards.

    Sandro

  • Sergey.Romanov

    Posted 23 September 2019, 9:47 pm EST

    Sandro ,

    i apologize for the confusion. i did not notice the developers comments that fix works when the data is assigned via ValueBinnary property.

    i have attached the sample of report and PDF output.

    unfortunately, ECI feature is sill under consideration.

    Thanks,

    Sergey Romanov.

  • Sergey.Romanov

    Posted 23 September 2019, 9:49 pm EST

    attachment274962.zip

  • sandro.puhmeister

    Posted 23 September 2019, 11:25 pm EST

    Hello Sergey,

    I have tested your attached report and it throws exactly the same result as ours. There are even more issues with your test report. Character encoding is invalid, ECL level is invalid, QR code version in invalid and ECI value isn’t used at all, therefore invalid.

    Character encoding is exactly the same with special ŽžŠšČč characters that aren’t in our alphabet.

    Best Regards.

    Sandro

  • sandro.puhmeister

    Posted 23 September 2019, 11:40 pm EST

    Hello,

    Main issue is still the ECI value and general encoding to ISO 8859-2. Other properties can be fixed in the report. Please focus on these two issues.

    By the way: our mobile phone QR code readers read these characters correctly but our stationary applications don’t. Our QR code testing tool is also written for testing desktop applications not mobile. Our main product is written for desktop workstations and not mobile.

    Best Regards,

    Sandro

  • Sergey.Romanov

    Posted 24 September 2019, 12:15 am EST

    Hello Sandro ,

    Thank you for the detailed explanation. it seems we have to roll back the changes.

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 6 October 2019, 5:11 pm EST

    Hello,

    Are there any updates on the issue with QRCodes not encoding ISO 8859-2 (latin 2) characters correctly and setting up ECI values?

    Thank you.

    Best Regards.

    Sandro

  • mohitg

    Posted 8 October 2019, 4:53 pm EST

    Hello,

    I have asked the development team about the same and will inform you once I get an update from them.

    Thanks,

    Mohit

  • Sergey.Romanov

    Posted 8 October 2019, 6:25 pm EST

    Hello Sandro ,

    if there is a third party barcode API/control with ECI, then you could try to use it with the section report as a custom control or via the export to the image.

    since the direct fix of encoding in barcode did not help, we have to implement ECI support which is a time consuming task.

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 8 October 2019, 7:51 pm EST

    Hello Mohitg and Sergey,

    Thank you for all your responses.

    Mohitg, please let me know if I can provide any further assistance in resolving this issue.

    Sergey, we suspect that the ECI issue will probably be fixed on its own when encoding is fixed. It’s still a bug if encoding isn’t done properly with or without the ECI value control, time consuming or not, 3rd party controls are just a temporary solution and not the fix we are looking for. Such issues can not simply be swept under a rug. This is absolutely unacceptable.

    We are consuming time as well trying to figure out how to migrate to AR13 without breaking our product and we don’t complain because we need a new solution to solve our issues with reports for our clients. If our expectations aren’t met I don’t think my overseer will want to reccomend AR13 for our next big upgrade anytime soon.

    Please provide a stable fix for encoding issues. We will wait for the ECI control implementation if necessary

    I’m looking forward to hearing from you soon.

    Best Regards.

    Sandro

  • Sergey.Romanov

    Posted 9 October 2019, 12:52 am EST

    Hello Sandro ,

    i have received a response from PMs team. ECI support will be re-considered as a new feature for a future release(v15+).

    and according to the developer team, the issue with ISO-8859-2 encoding should be fixed with ECI implementation.

    Thanks,

    Sergey Romanov.

  • sandro.puhmeister

    Posted 9 October 2019, 4:45 pm EST

    Hello Sergey

    Thank you for your feedback. I’ll let my team know of your considerations and future plans. We appreciate your time and effort looking into this.

    Thank you.

    Best Regards.

    Sandro

  • ales.stok

    Posted 24 January 2022, 12:35 am EST

    Hello,

    Is there any solution for problems described above?

    Thanks,

    Ales

  • abdias.michael

    Posted 25 January 2022, 1:36 am EST

    Hi Ales,

    This case in currently part of to-do list of the development team, but currently we are unable to provide an ETA (AR-22555). I have asked the development team if this can be prioritized and I will share an update with you once it is available.

  • tomaz.lipovsek

    Posted 1 August 2022, 11:52 pm EST

    Hello,

    Was ECI actualy implemented or not, we are currently using AR 15?

    Best regards,

    Tomaz

  • akshay.rajput

    Posted 3 August 2022, 4:51 pm EST

    Hi Tomaz,

    The PMs have discussed on this issue. Apologies for the inconvenience but currently, we do not have any plans to implement this feature in ActiveReports.

    Regards,

    Akshay

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.