Barcode Capacity

[Former Community Member]

To provide more information on this question, here is a summary of what we are trying to achieve and the problems we are having & questions we have:

Background

* We have two different forms that we want to capture data using 2D barcodes.

* The intention is that the main form is completed & signed, given to the second party who then fills out their form and faxed together to a central server.

* It is critical for us that we capture the form data via the same channel as the physical signature & electronic signatures are not viable.

* For the main form, we need to fit the barcodes on to the existing pages -- this is a very limited amount of space.

The problem

* The main form is the problematic form - we have ~ 200 fields on the main form

* We are planning to fix the max length of each field - some based on existing systems & others not.

* Current total length count is ~ 3200 but we expect to strip this back to 2000-2500 chars, of which some will be all numeric or uppercase.

* We are currently assuming 3 barcodes for the main form but we may be able to get the max chars low enough to fit in 2 barcodes if they hold 1598 chars each.

* Based on our understanding the Adobe barcoding presentation ...

     * PDF-417 is restricted to a maximum of 34 columns (30 data) wide x 90 rows high

     * This gives a maximum of 928 code words in a bar code

     * Level 6 error correction redundancy uses 129 code words

     * This leaves 799 code words for data.

     * Each code word holds 1-2 data chars (2 if all numbers or all uppercase, 1 is worst case if swap from upper/lower/number/symbol for every char)

     * This theoretically gives 799 to 1598 screen chars per barcode.

     * Originally had intended to use XML data in the barcode, but now understand the cost and plan to use delimited data only (probably tab)

     * It is quite important to have a minimal (preferably zero) rate of barcode overflow as these forms may have to be manually re-typed.

     * Barcode compression is reported to give ~10-30% saving in space for typical data

     * With compression it may be hard to guarantee that there is no overrun unless the max field lengths are < the barcode stores uncompressed

     * Before commitments are made within our organisation, we need to be sure:

          - how many barcodes we need to store the max length of data

          - how much space does each barcode need on the page

          - whether we can fit the required number into the available space!

Specific Barcode Questions

1. How can we find out in livecycle designer (a) the number of rows/cols in a barcode, or (b) how many chars it can actually hold?

2. What is the max # of uppercase-only chars we can fit in one barcode?

3. What is the minimal space occupied by one barcode that is holding the max # of chars?

4. If we make a barcode smaller does this reduce the max # of rows/cols (and therefore chars) that it can store?

5. How do tab delimiters or commas count towards filling the barcode?

6. Can we stop the barcode from greying out when it overflows so we can capture the "first half" of the data?

7. What proportion of reduction do you typically get with the Livecycle compression?

8. If using compression to fit more data in, how do we avoid the problem with an unusual case having poor compression & overflowing the barcode?

9. We don't understand the limit of 928 code words given that 30 data cols x 90 rows would be 2700 code words?

10. We have found a couple of cases where barcodes are greyed out in LiveCycle Designer but the same form / same data has a good barcode when using Adobe 8 Standard - are there known differences / limitations between the products.

I have attached our test form below.

The barcode is 100mm x 45 mm but we can only get 868 uppercase chars to fit in it - it greys out in Livecycle designer with more.

Do we have to make it bigger to get more chars or have we done something wrong?

Any help or advice much appreciated.

[Former Community Member]

Here are some of the answers to your questions:

1. How can we find out in livecycle designer (a) the number of rows/cols in a barcode, or (b) how many chars it can actually hold?

- Designer does not provide you with an indication of the number of rows or columns but does try to estimate whether or not the barcode will hold all of the data you've selected for inclusion.  It is a rough very estimate though.  Capacity-wise with Reader 8.1.3 and higher if the barcode is not filled to capacity then the modules will increase in size automatically helping to improve read-rates so the number of rows and columns will change dynamically based on the data entered into the barcode.

2. What is the max # of uppercase-only chars we can fit in one barcode?

- This depends on the size and orientation of the barcode and the error correction used.  I've attached a sample that will allow you to test the capacity of different barcodes.  In the example you can enter the number of characters you wish to store and a random string of characters will be generated with either upper-case only, mixed case, and Japanese.  This should help you quite a bit.

3. What is the minimal space occupied by one barcode that is holding the max # of chars?

- This is always determined by the workflow.  Who are your end users and how will the forms be printed, delivered, and scanned?  The larger you make the barcode the larger the module size.  If you expect your end users to be using low-quality paper and ink jet printers then you need to ensure your modules are slightly larger to compensate for ink-bleeding.  Let me know your workflow and I'll try to make some recommendations.

4. If we make a barcode smaller does this reduce the max # of rows/cols (and therefore chars) that it can store?

- Yes, the smaller the barcode, the smaller the capacity and the smaller the modules.

5. How do tab delimiters or commas count towards filling the barcode?

- Tabs and Commas have the same "cost" inside the barcode itself.  As long as you are not using XML then either a tab or comma will suffice.  Just be aware that will need to make sure that end-users cannot enter commas into any of your data fields if you are using a comma as your delimiter.

6. Can we stop the barcode from graying out when it overflows so we can capture the "first half" of the data?

- No, currently there is no property that will tell you if the barcode is grayed  out.  You need to test your forms and set the limits in your form and code.  I will be publishing a sample later on that can detect whether or not a barcode is grayed out or not.  Expect it within the next month or so.

7. What proportion of reduction do you typically get with the Livecycle compression?

- This depends on the data being compressed but can average anywhere from 10 to 20 percent in the cases I've seen.  Flate compression is very good with repeating data.  If you do not have a lot of repeating data you may actually lose capacity by introducing Flate compression especially on non-English content.

8. If using compression to fit more data in, how do we avoid the problem with an unusual case having poor compression & overflowing the barcode?

- Again, testing with random data is the only way to ensure the barcode does not get overridden.

9. We don't understand the limit of 928 code words given that 30 data cols x 90 rows would be 2700 code words?

- These details are the specifications from the original design from Symbol (20 years ago) but it's not 2700 code words, it's 2700+/- characters.  Assuming no error correction and only upper-case characters and no punctuation of any kind.

10. We have found a couple of cases where barcodes are grayed out in LiveCycle Designer but the same form / same data has a good barcode when using Adobe 8 Standard - are there known differences / limitations between the products.

- Barcoded forms MUST be properly Reader Extended with the Barcoded Forms right.  If you do not apply this correctly then the barcodes will gray out when using the free Adobe Reader.  Both Acrobat and Acrobat within Designer should display the same results.

[Former Community Member]

Thanks Lee - there was a lot of useful info there.