Another solution to this problem, not as elegant as by Nicolas Garfinkiel, but much much simpler, is the following one.
Fundamentally the problem with Code 128 is that it is variable width. But is real life situation, we anyway use it as fixed width. This needs explanation. We position the code somewhere, and we expect it be no wider than some, otherwise it wouldn't fit, and we must reserve (keep empty) the space it is allowed to fill. Thus, even though it's variable width, we always need to allocate for it fixed area on a label.
So the solution to the centering problem would be to make Code 128 fixed-length.
If this is subset C (pairs of digits), then you need:
- Get any big enough number, of the form 100000..., so there are in total even number of digits.
- Add you code to it.
For example, if your code was 94100101140001, then you can add it with 10^16, and get this:
10000000000000000
94100101140001
=================
10094100101140001
Thus the code becomes fixed-width, and can be hard-centered.
If your code is not subset C, and contains text, then (in pseudocode) you do:
my_code = "S/N:941001-0114-0001"
const_max_code_length = 24 (for example)
if my-code.length > const_max_code_length then error
padding_char = "="
result = ""
for (0..(const_max_code_length - my_code.length)) do
result += padding_char
end_for
result += my_code
In case of your code, it will produce:
====S/N:941001-0114-0001
Then, no matter what text you put into it, it'll always be fixed length, and so will be positioned consistently.
I used it myself, before found this post. It's not OK, it's a hack, and what Nicolas Garfinkiel suggested is more right. The most appropriate solution would be, though, if ZPL itself would support code centering, and unfortunately it doesn't.