I am trying to right justify a bar code I am printing using ZPL from a .Net program. Here is my current code:
^FO10,50^FB500,1,0,R,0^AO,40,40^BY3^BCN,100,Y,N,N^FD1234567^FS^XZ
The Field Block seems to be ignored when working with a bar code, but for text it justifies it correctly. Any ideas?
Newer Zebra firmware supports a third parameter on ^FO and ^FT. If you want to right justify something, specify the right edge as the x parameter, and include a 1 as the third parameter.
^XA
^BY3
^FO85,30^GB500,450,3^FS
^FO100,50^BCN,30,Y,N,N
^FD>;12345678^FS
^FO100,120N^BCN,30,Y,N,N
^FD>;123456^FS
^FO100,190^BCN,30,Y,N,N
^FD>;1234^FS
^FO570,260,1^BCN,30,Y,N,N
^FD>;12345678^FS
^FO570,330,1^BCN,30,Y,N,N
^FD>;123456^FS
^FO570,400,1^BY3^BCN,30,Y,N,N
^FD>;1234^FS
^XZ
We had the same issue at our company. The barcode doesn't respond to the Field Block. Based on your example since you are using ZPL commands directly to generate your barcode (as opposed to an image of a barcode), you could do something similar to how we did. We know roughly how wide the barcode is going to be based on the data we write to it. So we created a method to determine the x-axis location of the barcode based on our also known label widths.
For example: We use the s4M printers and estimate the full label width to be about 780 dots wide. So in order to left/center/right justify, we take the rough barcode (estimated) width and calculate accordingly (left is set to xaxis = 0, center is set to xaxis = ((780 - barcodeWidth) / 2), and right justified would be xaxis = (780 - barcodeWidth). It isn't a perfect solution but is very close at least for our needs. You could certainly be more precise in your algorithm by looking at more barcode setting information like the data square size, columns, rows, etc... depending on your needs.
If you were to come up with a solution of generating an image of a barcode (which is what we are also trying to come up with now) then you should be able to easily get the width of the barcode image using build in .net graphics functionality.
Related
It seems not possible to view the exact margin between font-elements in XD (dev-view). Below you'll find a screenshot of a situation where we need to measure the exact distance between two Font-elements (XD developer-view).
It needs to bypass the line-height, but it doesn't. To be able to do this, we need the line-height to be zero. But when we edit the line-height in XD for a word or sentence on a single row, XD does not change that line-height.
Anybody encountered the same situation?
In this example the line-height is 32. We go to XD. Change it to zero, save it and SHARE FOR DEVELOPMENT. But the line-height remains 32. Also changing it to 1 instead of zero won't make any difference.
To fix this issue, you have to select the Text within Adobe XD. Right Click and select Path > Convert to Path. The margins around the Text will disappear and when in DEVELOPMENT view it becomes possible to see the right margin. A small problem remains. When you want to edit the text when it's a shape, you have to delete it and place a new text and turn it into a shape again. the text when converted to a shape
The default selector in Adobe XD will not give you the exact margin between two text. You have to convert the text layer into paths (Convert to Outlines) to get the exact margin.
But remember after converting text layer into path the text cannot be edited because now the letter are separate vector shapes.
To convert text layer into Path, select the layer and goto Object>Path>Click Convert to Path
You can use the Guides to drag one below your text and another one on top of the second text, and then you can see the distance between the 2 guides.
Check this youtube video for a quick tutorial on it. This is going to be a manual action. I don't think there's a key to press to check the distance automatically.
I have a problem with bar codes on labels. I have two Zebra printers ZTC ZM600-200dpi ZPL(unreadable code) and ZTC ZT420-300dpi. The problem is that one of them prints for long barcodes, which then can not be scanned by a scanner (screen). What may be the problem, I tried to compare the settings. I changed to identical and nothing. How to change barcode size?
The problem is that one of them prints for long barcodes
Do you mean the barcode length is too long and getting cropped/cut-off and that is why it is not scannable?
What software is generating the ZPL? And what values are being set with ^BY, which controls the module width of barcodes? Since the 300dpi label is readable, it sounds like you need to reduce the module width set by ^BY for the 200dpi label.
I would like to reduce my barcode's size but still be the same ratio like picture below.
From
Original Size
To be
Reduced Size
Here is my ZPL code.
^XA
^FO50,20
^BY2,2,20
^BCN,,N,N,N,D
^FDZWW011601512345^FS
^XZ
Please help me how do I deal with it?
Thank you.
This website is great for testing against: http://labelary.com/viewer.html.
Assuming you don't want the position to move it should just be changing
^BY2,2,20
to
^BY1,1,10
The API Reference guide can be found https://www.zebra.com/content/dam/zebra/manuals/en-us/software/zpl-zbi2-pm-en.pdf
Don't forget to take into consideration the print density, i.e. at 152 DPI you probably want something like
^FO150,20
^BY1,1,10
But at 600 DPI
^FO550,80
^BY4,1,40
EAN-13 Text Modifications
If you are using the the inbuilt EAN-13 text function i.e. ^BEN,40,Y,N you can't modify the text. It is to a standard. You can however add your own text e.g.
^XA
^FO100,20
^BEN,40,N,N
^FD011601512345^FS
^CF0,48
^FO90,80^FD011601512345^FS
^XZ
^BEN,40,N,N The first N tells the printer to not generate the number underneath.
^CF0,48 Is the select font function of the printer, its first parameter is a default printer font (can be found in the Standard Printer Fonts section of the link above). The second parameter is the font height. If needed there can be a 3rd parameter which alters the font width, though isn't needed.
^FO90,80^FD011601512345^FS Sets the field origin of the string starting at the location defined by ^FO. ^FDXXXXXXXX^FS draws the string.
I am working on conversion of pdf in to ZPL. I am using zebra programming language(zpl).
I am trying to control the barcode(any barcode) width using By command.
^By4 is giving lower width and ^By5 is going out of the box.
My use case is I want to achieve narrow bar width in float number(here 4.5). We can not pass float number in By command.
Please let me know if we can achieve this using some other method in ZPL.
You don't mention what barcode format you're using. Some of them, like 2of5, can also accept the ratio parameter for ^BY. The default is ^BY2,3, changing that to ^BY2,2 can make a smaller version:
^XA
^POI
^CFO,20
^BY5,3
^FO100,400
^BJN,100,Y,N
^FD200940^FS
^BY5,2
^FO100,700
^BJN,100,Y,N
^FD200940^FS
^XZ
This generates two barcodes in 2of5, one with the default ratio and one with a smaller ratio. The second one has a tighter barcode that uses less space. Valid values are 2.0-3.0 (although many round off to the same values) so there is some flexibility. Please note, this only works with barcode formats that are not fixed ratio formats.
You can check the manual page for ^BY in the ZPL programmers guide, p123, for the table that shows valid values and which ones round off to the same value (ie, 2.0 and 2.1 give the same results)
So I've recently had to create a report that emulates a Canadian customs form. The problem is that the report is printed on 11" x 14" paper, but uses a metric layout. As my FoxPro installation is on a machine with US-English units-of-measure, FoxPro tries to oblige by using an English ruler, and doing snap-to-grid on inch-based measurements. This creates some minor design issues obviously.
I understand that the reports are really just tables in disguise, and I have figured out how to turn on the Metric ruler (instead of the English one) by changing a record, and that is working as intended. However, the snap-to-grid functionality appears to want to snap on 48 units-to-an-inch, instead of something Metric. So moving a box around using a mouse results in the box being offset (again) in English measurements.
To get around this, I have taken to openning up the report as a table and manually converted all Metric units with a spreadsheet, and entered the offsets and sizes by hand. While this has worked well and appears to be very accurate, it's still error-prone.
So the question is, how do I get FoxPro 8 to snap-to-grid in Metric units on the report, so that I don't have to keep re-entering numbers by hand? It would be nice to get FoxPro to accomodate Metric in a fashion where I can align objects in the report using a mouse, rather than punching them in as numbers and "flipping" the report into design view to check it.
For reference, currently there are the following translations:
25.4 mm = 1 inch = 10,000 report units = 48 grid snap points
Obviously I'd like something closer to this:
25.4 mm = 1 inch = 10,000 report units = 25.4 grid snap points
Note: Yes, I have considered setting up a Virutal Machine with FoxPro that uses a Metric install, i.e. a Windows XP install set up for Canada. However, that will take another day or so to get the installation done, along with the rest of the development environment, so I'm trying to avoid that.
Hidden unless you've been exposed to more of it...
Modify your report.
Right-click, get to properties of the report.
On the tab for Ruler / Grid, there is a combobox which is defaulted to ruler of "inches", but you can change it to Metric/cm or Pixels. Below that is your grid snap and you can change the default of how many pixels to snap to.
Additionally, if you use your cursor keys, you can move the controls one pixel at a time for more precise alignments as needed. And if you need to resize a control's width, if you hold the Ctrl key down and use the arrow keys left/right, will shrink / strecth one pixel at a time instead of moving the control. Likewise for the moving and sizing if you pick multiple controls, they will ALL move or resize respectively.
HTH
Just spoke with a freind lastnight who has VFP8 installed. Based on that version, there MIGHT be a way to get metric for your reports. There is a setting on the reports from showing based on PIXELS, or SYSTEM METRIC. If you system configuration is based on inches, so too is the report. If you change your system metric to that of centimeters (or whatever equivalent it would be), so too should the report respect in design time.
HTH