@huukhanhnguyen/model / nodeMethods/barcode

nodeMethods/barcode#

barcode()#

barcode(text, symbology, width, height): BrepData[]

text as barcode geometry: filled faces in the XY plane spanning [0, width] × [0, height].

Parameters#

text#

string

symbology#

string

width#

number

height#

number

Returns#

BrepData[]

code128Modules()#

code128Modules(text): string

Symbol values → the symbol's module string, 1 = bar, 0 = space.

Parameters#

text#

string

Returns#

string

code128Values()#

code128Values(text): number[]

text → the full sequence of Code 128 symbol VALUES: start code, data, check character, stop. This is the encoder proper; the geometry below is only a rendering of it, so the reference vectors in the test assert against THIS.

Code sets B and C only. Code set A exists to carry ASCII control characters (0..31), which a printed label has no use for — and a silent substitution for one would be exactly the plausible-wrong-answer this repo forbids, so a character outside code set B's ASCII 32..126 THROWS rather than encoding something a scanner would read back as different text.

Code set C (digit pairs, two digits per symbol) is entered per ISO/IEC 15417's recommended encodation: a run of four or more digits at the start or end of the data, or six or more in the middle, is worth the switch symbol. Only an EVEN number of digits can be carried in C, so an odd run gives its last digit back to code set B — a deterministic tie-break, since encoding the odd digit at the front instead would produce a symbol of identical length.

Parameters#

text#

string

Returns#

number[]