Spine label sheet printing

[Kathy Lussier]

The MassLNC Evergreen Development Initiative is working with Emerald Data Networks to support printing spine labels to 8 1/2 x 11 sheets. The code will allow staff to:

* set top and left margins for the sheet
* identify the number of columns and rows on each sheet
* identify how many spine and pocket labels should be part of each label set. For example, you could say use stock that include one spine and one pocket, one spine and two pockets, or all spines.

All of these settings will be available on the Settings tab of the Print Item Label interface, along with current settings to set label size, fonts, etc.

One known use case that will not be supported are sheets with 1 spine / 2 pockets where the two pockets are on top of each other. See example at https://www.demco.com/products/Library-Supplies/Labels/Processing/Demco-reg-Processing-Circulation-Label-Sets-13-16-x-2-9-10/_/A-B00169566

[Kathy Lussier (klussier)]

I have one question I would like to pose to the community.

When item label printing was added to the web client, phasefx noted in bug 1704873 that they called it Item labels to make it a little more generic. I'm guessing this is also why the spine and pocket labels were renamed as left and right label.

We've been trying to maintain the spirit of a more generic interface, but have been struggling with the left / right designations under this project.

Here is the problem. Under our current implementation, which is still a work in progress, a label set doesn't always have to be one spine (left) label and one pocket (right) label. There is a place where users can designate the left label to be used for column 1, the right label to be used for column 2, and another right label to be used in column 3. They could also conceivably put the right label in column 1. With this additional flexibility, the 'left' and 'right' labels don't really make sense.

I tried to keep things generic by renaming them as label 1 and label 2, but these terms may be a little too generic. I think the lack of description in this case leads to a less intuitive UI.

I would like to float the idea of returning to spine / pocket as the labels. Staff understand what these labels mean, and it will help us in providing clearer explanations on what different settings do.

I'll also send a question out to the general list to cast a broader net for feedback on this question.

[Elaine Hardy (ehardy)]

+1 to returning to spine/pocket terms

[Terran McCanna (tmccanna)]

I'm also in favor of spine/pocket. Even though they can be used in different ways on actual items, librarians still understand what they mean.

[Kathy Lussier (klussier)]

Pointing to the current work-in-progress collab branch. We still have a few minor bugs to work out, but I'm posting so that others can start to take a look at it.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/kmlussier/lp1787479-spine-labels-on-sheets

[Terran McCanna (tmccanna)]

PINES staff has done intensive testing on this work and we are very happy with it:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/kmlussier/lp1787479-spine-labels-on-sheets

[Terran McCanna (tmccanna)]

I have tested this code and consent to signing off on it with my name, Terran McCanna, and my email address, <email address hidden>

[Dan Wells (dbw2)]

Terran wrote me about this branch, and I am fine with it going in yet today if anyone is able to manage it. I would kindly suggest some commit squashing would also be a good idea.

[Chris Sharp (chrissharp123)]

Squashed, rebased, and pushed to master. Thanks to all involved!