Open pbchase opened 2 months ago
Consider the value of using Labelary or its ZPL Web Service as a preview tool of label appearance
If we wanted to take a different approach and help people craft their own ZPL for novel labels, consider zpl_generator written by Michael Bentz
Probable design idea for this
If we want to make this module reusable, we need to keep the coding at a minimum while allowing the label content to be configurable in a REDCap-py way. I propose we add chunks of pre-written ZPL that define a useful layout for a particular label. We would make the ZPL code blocks pickable from a select menu. We'd describe each label with dimension, a part number, and an image of the ZPL will print to it. This eliminates coding but allows configuration.
Each such label would have named regions into which content could be poured. After selecting a label, you would also add one or more sets of text fields. Each text field would be labeled for the region it fills. Each set of text fields would include an integer field labeled "How many of this label do you want?" to indicate how many of this field set to print. It would default to 1. The text fields would accept content in REDCap field piping syntax. e.g.
[record_id]-[visit_number]-P-!!counter-!!checksum
. The first half of that is basic REDCap syntax.!!counter
is an optional, module-defined substitution variable that indicates the instance if the multiple labels printed need to be uniquely identified.!!checksum
is another optional, module-defined substitution variable. It is a calculated checksum that can be included in the label string to reduce the risk of scan errors.As the end user adds multiple sets of fields, they define additional configurable text strings to be printed on additional labels. All of these labels will be printed in a batch.
This system allows one-to-many labels to be printed. The labels can all be identical or they can be in groups with multiples of identical or serialized labels.