Barcode Professional on SQL Azure Reporting CTP?

Yesterday, Microsoft announced SQL Azure Reporting CTP at PDC10. Although this new version provides many of the features of SQL Server Reporting Services 2008 R2, in this CTP the “Extensibility” part is not available as stated at the comparison table (see “Developer Extensibility” entry where for SQL Azure Reporting it says “Extensibility is not yet enabled”).

So, because Barcode Professional for Reporting Services is a CRI (Custom Report Item) and is based on the “Extensibility” features of Reporting Services, it seems that you won’t be able to use our product on SQL Azure Reporting CTP version. But well, this is a CTP and all indicates that Microsoft will add extensibility feature to SQL Azure Reporting in some future version. Of course, we’ll provide Barcode Professional for SQL Azure Reporting when that happens.

GS1 Data Matrix, MICR E-13-B and EAN.UCC Composite added to Barcode Professional product lines

We are finishing the launch of our Barcode Professional product lines in all platforms (ASP.NET, Windows Forms, Reporting Services, WPF & Silverlight). This time, these major releases added support for GS1 Data Matrix, MICR E-13-B, all the EAN.UCC Composite family as well as some enhancements to QR Code, Aztec Code & Data Matrix which now support ECI (Extended Channel Interpretation) & FNC1

With these new versions, our Barcode Professional is one of the most complete packages out there supporting all Linear, Postal, MICR and 2D barcode standards.

Regarding the new symbologies, one that was interested to design and develop was MICR E-13-B (Magnetic Ink Character Recognition). In fact, this “barcode” is not made of bars but are specially designed characters and symbols intended to be used in financial markets and the like.

You will see that most MICR E-13-B offers from competitors are just font files (TrueType TTF, Open Type, etc) a.k.a. fontware products. And this could sound logic based on the fact that MICR E-13-B is mainly a set characters and symbols. However, we went for another approach and the MICR E-13-B solution you will find in our Barcode Professional product is ALL rendered/drew by using .NET Drawing classes!!!

Why did Neodynamic choose drawing each character/symbol with .NET Drawing classes and not just pick up a font for it?

The answer is because we know about the .NET dev needs our customers face every day. The barcode font file approach has the following cons:

  • Fonts require registration in the Windows Fonts folder. You need to consider this when deploying your app. In addition, users can delete the font and break your app functionality.
  • Fonts do not scale well
  • Fonts do not support rotation

Sincerely, write the routines for drawing EACH character/symbol of MICR E-13-B was a big task using .NET System.Drawing (GDI+) for Windows Forms & ASP.NET editions of Barcode Professional, and not to mention for WPF & Silverlight where they are rendered using geometries available in those vector-based platforms. Anyway, we’re very happy with the end result and hope it helps you with your dev needs.

To conclude, here is the list of new additions for all Barcode Professional editions:

  • New! Barcode Symbologies added:
    • GS1 DataMatrix (You can now use Data Matrix for encoding GS1 GTINs and any other number of Application Identifiers (AI))
    • MICR E-13-B (It’s not a font! All characters are generated using .NET drawing engine)
    • ALL EAN.UCC Composite Barcodes:
      • EAN-13 with CC-A/CC-B
      • EAN-8 with CC-A/CC-B
      • UPC-A with CC-A/CC-B
      • UPC-E with CC-A/CC-B
      • GS1 128 (UCC/EAN-128) with CC-A/CC-B/CC-C
      • GS1 DataBar Omnidirectional (RSS14) with CC-A/CCB
      • GS1 DataBar Truncated (RSS14 Truncated) with CC-A/CCB
      • GS1 DataBar Stacked (RSS14 Stacked) with CC-A/CCB
      • GS1 DataBar Stacked Omnidirectional (RSS14 Stacked Omnidirectional) with CC-A/CCB
      • GS1 DataBar Limited (RSS Limited) with CC-A/CCB
      • GS1 DataBar Expanded (RSS Expanded) with CC-A/CCB
      • GS1 DataBar Expanded Stacked (RSS Expanded Stacked) with CC-A/CCB
    • USPS Intelligent Mail Container Barcode
    • Australia Post Domestic eParcel Barcode
    • Kodak Patch Code
  • Improved! Data Matrix:
    • Fixed some bugs when using Auto encoding, ECI (Extended Channel Interpretation) and Structured Append features.
    • Added three new properties for Structured Append feature.
  • Improved! QR Code:
    • Added support for FNC1. You can now use QR Code for encoding GS1 GTINs and any other number of Application Identifiers (AI)
    • Added support for ECI (Extended Channel Interpretation)
    • Added new way for encoding data using tilde char. This allows you to easily specify byte values in dec/hex notations as well as Kanji double byte chars, ECI and FNC1.
  • Improved! Aztec Code:
    • Added support for FNC1. You can now use Aztec Code for encoding GS1 GTINs and any other number of Application Identifiers (AI)
    • Added support for ECI (Extended Channel Interpretation)
    • Added new way for encoding data using tilde char. This allows you to easily specify byte values in dec/hex notations, ECI as well as FNC1.
  • Improved! UPC-A and UPC-E:
    • Now you can specify 6-digits for UPC-E codes that will also be automatically converted back to UPC-A when using that barcode symbology.
  • New!
    BarcodeUtils class offering different methods for calculating most popular Checksum/Check-digit available on barcode symbologies

Available in:

Reporting Services & Excel – File error: data may have been lost.

If you try exporting a Reporting Services RDL report containing our Barcode Professional CRI product to Microsoft Excel and get this error:

“File error: data may have been lost.”

then you are experiencing a known bug of Excel regarding bitmap images (bmp format). This likely happens when you configure our Barcode CRI to render barcodes in BMP format. To solve the issue, just change the ImageFormat property to ONE of the following formats: GIF, JPEG or PNG

ThermalLabel SDK 4.0 future plans

Our team is working on next major release of our ThermaLabel SDK for .NET product and customer’s feedback is always appreciated. Since ThermalLabel SDK first release, we’ve tried our SDK leverages Zebra Programming Language (ZPL) as well as Eltron Programming Language (EPL) for generating outputs to thermal printers. Sadly, forcing our product to stick with those printer languages make that some high requested features sent by our customers become impossible to accomplish. Some of the most requested features are the following:

  • Landscape printing
    A very simple concept but it is not provided by ZPL or EPL natively and the only workaround with current release of our product is that you have to design the label applying 90 or 270 degree rotation on EACH item placed on it for simulating a Landscape printing scenario. This is a big problem (and a waste of time) because if you have to support Portrait printing too, then you are forced to design the same label with the same items but without rotation. But that’s not all… in EPL most 2D barcodes like Aztec, Data Matrix, Maxicode, etc DOES NOT support rotation!!!
  • Print Preview
    With current release of ThermalLabel SDK you need a real printer to test your label outputs. A Print Preview feature would add some nice advantages like coding with ThermalLabel without the need of having a printer, great savings by not printing physical labels (“Go Green ” touch) as well as a visual preview for application’s end-users.
    One approach to get this out would be a conversion of the generated ZPL or EPL commands to some image format. Sadly, the main issue to accomplish this regards on barcodes because some symbologies have different algorithms that generate different barcodes although all of them could be valid. Because we do not know how the barcode algorithms inside the firmware printer are coded, we cannot provide an accuracy preview of a label i.e. in other words it’d not be WYSISWYG. Other problem is also with text and fonts which is very difficult to port from ZPL/EPL to GDI+ or WPF drawing engines. And not to mention that we’ll need to write two different conversion tools for each printer language.
  • Visual Label Designer
    This would be a great/big feature. Sadly, the same issues apply on this scenario as described above for Print Preview feature.
  • ASP.NET Client-side Printing
    Some customers commented us the need of having this feature added. The fact is that since v1.0 of ThermalLabel SDK, we tried to fill this gap without success. The main problem here is that in ASP.NET, printing on the client-side relies on the client’s browser printing support or on some plug-in technology based on ActiveX, Java, Flash or Silverlight. In all our tests, we have not found one approach that is 100% reliable. The current issue here is to find a way for sending raw plain text commands to the printer from the browser.

Those are the most requested features for ThermalLabel SDK. We are brainstorming v4.0 and we think we need to provide some of those features with it. Based on all limitation about ZPL/EPL to get them out, we’re seriously thinking about changing our labeling engine and port it to a “Graphic-based” approach.

In v3.0 we introduced some barcodes that are not present in ZPL or EPL firmware like 4-State Postal barcodes, Telepen and Pharmacode as well as a new GraphicTextItem with more features than the standard TextItem like Text Sizing, Multiline, Unicode support, Right-To-Left (Hebrew, Arabic, etc.), Custom Windows TTF files, etc. All these new additions were added thanks to our Barcode Professional product lines as well as .NET drawing classes. Here we just convert the .NET drawings generated by Barcode Professional algorithms to ZPL or EPL image commands.

So, the idea in v4.0 is to move ALL items to a graphic-based approach including barcodes and texts. Now that our Barcode Professional product lines provides almost all barcodes found in ZPL or EPL, then it’d be simple to replace them with our algorithms. In addition we could provide some Human Readable Text features like custom font settings, justify alignment and centering which are not supported by ZPL or EPL. And for texts, we could provide from simple text to rich text formatting!
If we move our labeling engine to that graphic approach, then all most requested features i.e. Landscape printing, Print Preview and Visual Label Designer could be a reality (ASP.NET Client-side printing is simplified too although it will require further testing)
One more important benefit on this new approach is that you NO longer will need to create separated labels for each printer language (ZPL or EPL)! With the graphic-based engine you’d create one label design for both printer languages 😉

But what would be the cons by going for that Graphic approach? Well, our product will continue generating ZPL or EPL commands but because now all items are in a “graphic” surface, the printer commands for it will increase the print job size a bit and printing speed performance could decrease in some way.

In conclusion, our main idea for v4.0 is move to a new graphic-based labeling engine for providing better new features while saving development time to our customers. Anyway, this post is for our current and future customers so all of you can comment or provide us further feedback. Thanks for your time!