I am trying to convert existing code from the deprecated builder class to the new generator class.
A property that was previously available was BarWidthReduction, which I cannot find any documentation for in relation to the generator class.
What I noticed when comparing in my old code, is that if XDimension was 2mm and BarWidthReduction was 0 then all black and white bars would be 2mm - giving a certain overall barcode width.
However, if XDimension was 2mm and BarWidthReduction was 0.5mm then all bars would be 1.5mm but the overall width remained the same (ie. white bars are now 2.5mm).
This is different to setting XDimension to 1.5mm because then the overall bar code width becomes smaller.
I did find the documentation relating to “Setting Wide Narrow Ratio For Bars In BarCode” which maybe can achieve this, however this functionality was previously available for all barcode types and definitely worked for Codabar.
Are you able to point me in the direction of an example that shows how to achieve the same functionality within the generator class?
@t1jsw,
You may please create a simple runnable console application which was working fine previously with deprecated builder class and exact version which you were using. Also share the output of the program from the previous version which you want to generate using the latest version. We will analyze your expected output and share our feedback by using the latest version.
I actually think the AspectRatio is something else that is only applicable to certain barcode types. I think it relates to the ratio of thickness between thin and wide bars.
BarCodeReduction was available for all barcode types and is usually a very small amount that is to help deal with ink bleeding during printing. For example if you had minimum 1mm bar width (xDimension) but when you print it the ink bleed means it is actually 1.05mm then it can cause issues with barcode readers as the corresponding gap to next bar is now 0.95. In this case you set BarWidthReduction to .05 and then the minimum bar width is actually .95mm and the minimum gap to next bar is now 1.05 (ie you take from Bar and give to Gap). The .95 bleeds to 1 and the 1.05 is bled into and is actually 1. Happy times! This is different to setting x to .95 because then the gap would also be .95 so when your .95 bar bled to make 1mm your white is now .9 (0.95 - .05 bleed) and the printing issue is not solved as the bar and gaps are not a consistent width.
Below are examples to show what I mean. In my example I have set minimum bar width to 2mm and the bar reduction to 1mm so that it is visually obvious about the difference. You can see with the reduction you get “effective” 1mm minimum bars but the entire width of the barcode remains unchanged to when minimum x is 2mm (this is different to when an actual minimum of 1mm is used). However, practical applications would have very small numbers as explained above.
With old code I can generate two very different bar codes when the same 2mm value is used for XDimension. It is clear that using 1mm for XDimension does not achieve the same thing. I do not know how to achieve the same using the new classes. It appears BarWidthReduction is not supported in the new classes.
As I understand, BarWidthReduction was used to fix problem with printing on ink printers by reducing black bar size? This can solve inks flowing problem.
I will raise the question on our technical meeting.
Discussed about the problem. We decided to implement property BarWidthReduction (the name of the property could be different) for 1D and 2D barcodes. However this can be implemented in 20.9 (September release).
Thanks Amjad. However I am after the BarWidthReduction (or whatever it will be called) that is planned to be released in 20.9.
From Alexander:
“We decided to implement property BarWidthReduction (the name of the property could be different) for 1D and 2D barcodes. However this can be implemented in 20.9 (September release).”
Currently this property already implemented for 1D and 2D barcodes, but there were some issues in some special cases with 2D, so the final implementation have been transferred to 20.9.