Printing: LC Call number formatting (2.5.2)

We have had reports of this from our academic libraries at C/W MARS.

Testing a fix.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dpearl/LP1352542_spine_labels

I'm not sure how to make automated tests for this.

Hi Dan,

Since this change is to javascript code, I don't think any tests are required. However, what might be helpful is a test plan in the git commit to provide some guidance to whoever tests the code. Don's original report provides some details on what to look for, but it would be great if the test plan could point to the change in formatting we should see for a specific Concerto record.

Kathy

Testing notes: Before the fix, the special code to format LC spine call numbers was not invoked. This caused the LC spine labels to be generated so that each whitespace-separated chunk would appear on a single line.

So, in Concerto, a call number like "ML 60 R78" would produce a reasonable spine label like
ML
60
R78

even though that is not a proper format for a call number. The first (and only in this case) cutter number needs to be preceded by a period.

There are a few correctly formatted call numbers in Concerto. Oh, here's one:
 MT 125 .H667 C12

That one will appear correctly because the components are separated by spaces.
MT
125
.H667
C12

There are *NO* instances of "squashed" call numbers in Concerto, so unless you modify a call number, then you can't use the stock Concerto for testing. I would suggest finding a call number like "MT 125 .H667 C12" and get rid of most of the spaces and maybe add a second cutter number for fun, so that it looks like: "MT125.H667L12 C12". This would be an example of a more demanding test of the feature. It should produce output like this:
MT
125
.H667
L12
C12

Per the LOC MARC specification, the call number (from MARC 50) can be built up in different ways. Here are examples:
050 #4$aNB933.F44$bT6
050 10$aBJ1533.C4$bL49
050 00$aJK609$b.M2
050 00$aZ7164.N3$bL34 no. 9$aZ7165.R42$aHC517.R42

The takeaway is that the first cutter number must be preceded by a period. Any non-conforming call number will be passed through unprocessed.
Bad call numbers that should be unprocessed:
MT124.3.3.H234 (extra decimal)
MT124H23 (no period before cutter number)
MT123.H23L23M23 (too many cutters. Can only have a max of two)

More grist for your mill.

There are rare ... exceedingly rare ... instances when a legitimate LC call
number can have two cutter numbers that contain a decimal.
ISBN: 0385053169
Title: Ruth : |*b* a new translation with introduction, notes, and
commentary
05000 |*a* BS192.2.A1 1964 |*b* .G3 vol. 7
BS
192.2
.A1
1964
.G3
vol. 7

There is also the case of some bible call numbers that do not contain *any*
cutter numbers and no $b. In the old days it was common for two blank
spaces to separate the call number and the date. That doesn't seem to hold
true anymore.
LCCN: 60037444
Title: The Holy Bible
05000 |*a* BS180 1960
BS
180
1960

There is a slightly odd example of a call number that has a number/letter
where a cutter typically occurs.
ISBN: 0385154569
Title: A child's look at the Twenty-third Psalm
050 00 |*a* BS1450 23d |*b* .K4

BS
1450
23d
.K4

On Tue, Feb 23, 2016 at 11:40 AM, Dan Pearl <email address hidden> wrote:

> Testing notes: Before the fix, the special code to format LC spine call
> numbers was not invoked. This caused the LC spine labels to be
> generated so that each whitespace-separated chunk would appear on a
> single line.
>
> So, in Concerto, a call number like "ML 60 R78" would produce a reasonable
> spine label like
> ML
> 60
> R78
>
> even though that is not a proper format for a call number. The first
> (and only in this case) cutter number needs to be preceded by a period.
>
> There are a few correctly formatted call numbers in Concerto. Oh, here's
> one:
> MT 125 .H667 C12
>
> That one will appear correctly because the components are separated by
> spaces.
> MT
> 125
> .H667
> C12
>
> There are *NO* instances of "squashed" call numbers in Concerto, so unless
> you modify a call number, then you can't use the stock Concerto for
> testing. I would suggest finding a call number like "MT 125 .H667 C12"
> and get rid of most of the spaces and maybe add a second cutter number for
> fun, so that it looks like: "MT125.H667L12 C12". This would be an
> example of a more demanding test of the feature. It should produce output
> like this:
> MT
> 125
> .H667
> L12
> C12
>
> Per the LOC MARC specification, the call number (from MARC 50) can be
> built up in different ways. Here are examples:
> 050 #4$aNB933.F44$bT6
> 050 10$aBJ1533.C4$bL49
> 050 00$aJK609$b.M2
> 050 00$aZ7164.N3$bL34 no. 9$aZ7165.R42$aHC517.R42
>
> The takeaway is that the first cutter number must be preceded by a
> period. Any non-conforming call number will be passed through unprocessed.
> Bad call numbers that should be unprocessed:
> MT124.3.3.H234 (extra decimal)
> MT124H23 (no period before cutter number)
> MT123.H23L23M23 (too many cutters. Can only have a max of two)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352542
>
> Title:
> Printing: LC Call number formatting (2.5.2)
>
> Status in Evergreen:
> Confirmed
> Status in Evergreen 2.8 series:
> New
> Status in Evergreen 2.9 series:
> New
>
> Bug description:
> LC Call numbers do not format properly for printing. Example:
>
> 050 00‡aBS1430.5.P68 ‡b E63 2001...

Hi Don,

I was planning to load this code on to a MassLNC Sandbox next week after the beta release to make it easier for people to test. Would you be willing to help test the code once I do that to see how it works and to possibly sign off on it if it leaves to an overall improvement to the way call numbers print?

If so, let me know, and I'll send out connection details once it's loaded.

Kathy

Glad to do it Kathy.

On Tue, Feb 23, 2016 at 1:32 PM, Kathy Lussier <email address hidden>
wrote:

> Hi Don,
>
> I was planning to load this code on to a MassLNC Sandbox next week after
> the beta release to make it easier for people to test. Would you be
> willing to help test the code once I do that to see how it works and to
> possibly sign off on it if it leaves to an overall improvement to the
> way call numbers print?
>
> If so, let me know, and I'll send out connection details once it's
> loaded.
>
> Kathy
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352542
>
> Title:
> Printing: LC Call number formatting (2.5.2)
>
> Status in Evergreen:
> Confirmed
> Status in Evergreen 2.8 series:
> New
> Status in Evergreen 2.9 series:
> New
>
> Bug description:
> LC Call numbers do not format properly for printing. Example:
>
> 050 00‡aBS1430.5.P68 ‡b E63 2001 displays as
>
> BS1430
> .6
> .P68
> E63
> 2001
>
> It should display as
>
> BS
> 1430.6
> .P68
> E63
> 2001
>
> Path taken to print
> Actions for the record > Holdings Maintenance > Highlight copy line >
> right click > print item spine label
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1352542/+subscriptions
>

--
Don Butterworth
Collection Management Librarian /
Faculty Associate
B.L. Fisher Library
Asbury Theological Seminary
<email address hidden>
(859) 858-2227

I'll test this in the sandbox on Bug squashing day

Don Butterworth and Beth Fogler tested LC call number formatting changes and found that the spine labels are not printing correctly. A sample of our findings is below:

Marc 050 _ _ $aBX8495.W5 $b A3 1775
Item BX8495.W5A3 1775
Spine BX8495
                .W5A3
                1775

Marc 090 _ _ $aBX8495.W5 $b A3 1775
Item BX8495.W5
Spine BX8495
         .W5

Marc 050 _ _ $aBX8495.52.W5 $b A3 1775 pt. 2
Spine BX8495
                .52
                .W5A3
                1975
                pt.
                2

BUG SQUASHING DAY (3/4/2016) TEST PROCEDURE

For testing purposes the following LC call number was used:
BS1430.52.P68 ǂb E63 2001 pt. 1

A random bibliographic record was selected and the number was added with the following tag/field variations: 050 \\, 050 \0, 050 \4. In every case when a copy/item record was created the call number displayed as:
BS1430.52.P68E63 2001 pt. 1

and the Spine label displayed as:
BS
1430.52
.P68
E63
2001
pt.
1

However when a 090 tag/field was created with the identical call number, the copy/item record displayed as:
BS1430.52.P68
That is, no subfield b data was displayed.

TEST RESULTS

The testing revealed three areas that still need to be addressed.

1. It is standard practice for the Library of Congress to create call numbers that have a space in their suffixes. E.g. vol. 1, pt. 2, etc. These suffixes should be on a single line of the spine label. The logic to address this problem would be, “in an LC call number field, whenever a decimal and a space directly follow an alpha character, include any numbers which follow on a single line of the spine label.”

2. The format of the call number on the copy/item record has a direct impact on the display and sorting of that number in the Available Copies area of the Record Summary screen and potentially on the sorting of a Call Number Browse Results Screen. The standard formatting practice that Library of Congress uses for call numbers with two cutter numbers is: “BS143.53.P68 E63 2001 pt. 1” The format for a call number with only one cutter number is: “BS1430.53 .P66 2001 pt. 1” Note how a single space is always placed in the position where a ǂb is found on the corresponding MARC record. This standard spacing should be the default display format for the copy/item record.

3. The data following the ǂb must display.

CONCLUSION

Item 1 would be nice to have, but it happens so seldom that it shouldn't hold up the sign off.
Item 2 is important because we are not following LC standards which results in the need to make a manual adjustment to the call number for every title that enters through the Z39.50 portal. However, this still shouldn't hold up sign off.

Item 3 is a showstopper. 090 call numbers do include subfield b data in Evergreen Production, so this behavior was accidentally introduced in the patch. When this behavior is fixed, sign off can occur.

Thank you for the analysis.
I can address point #1. (Keep the text together in "V. 1").

I'm not sure what point #2 is asking for. My test code currently displays the one-cutter BS143.53.P68 E63 2001 pt. 1 as
BS
14353
.P68
E62
2001
pt. 1

Is this desirable or not?

Point 3: This point might be addressing a different issue entirely. My test code parses something called "callnum" which has been already formed. I wonder if this issue is located elsewhere.

Hi Dan,

First let me say, THANK YOU for taking on this project. It is going to make
life much, much easier for the people to print LC call number labels.

Now let me speak to the points.

I'm so glad that you are going to be able to address the point #1 issue.
There are systems out there that do not.

Let me restate point #2

First a cataloger goes into the MARC record of a title and adds the 050
tag: BS143.53.P68$bE63 2001 and saves the record.

Next the cataloger clicks the Add Volumes button. On the Copy/Item screen
that appears, the call number displays as BS143.53.P68E63 2001. That is,
the .P68 and the E63 are squashed together.

As far as the label printing code is concerned, it just needs to account
for when cutters are squashed and when a space is included.

My point is, whenever a $b is present in either an 050 or an 090 tag a
single space should be included in the call number display of the Copy/Item
screen. This is how Library of Congress does it; hence this is the way
Evergreen should do it.

BS143.53.P68$bE63 2001 = BS143.53.P68 E63 2001
BS143.53$b.P68 2001 = BS143.53 .P68 2001

Having the number display correctly in the Copy/Item screen call number
display has a direct impact on the indexing and display of the Copy/Item
area on the Record Summary OPAC View and in the call number search Results
Screen.

Clear as mud?

Point #3

The 090 tag is also an LC call number. The difference is that the 050 00
tag is one assigned by the Library of Congress. The 090 \\ is an LC number
assigned by a library other than the Library of Congress.

Something has happened in the test coding that is impacting how the 090 tag
is displaying on the Copy Item screen. In the production releases the
entire call number is displayed in the call number area of the Copy/Item
screen BS143.53.P68 2001. In the test case only the subfield "a" data is
displaying. BS143.53.

It would be awesome if when you fix the 090 you could fix the $b spacing
issue too!

Thanks again for all your hard work Dan. It is *very* much appreciated.

Don

On Fri, Mar 11, 2016 at 4:48 PM, Dan Pearl <email address hidden> wrote:

> Thank you for the analysis.
> I can address point #1. (Keep the text together in "V. 1").
>
> I'm not sure what point #2 is asking for. My test code currently displays
> the one-cutter BS143.53.P68 E63 2001 pt. 1 as
> BS
> 14353
> .P68
> E62
> 2001
> pt. 1
>
> Is this desirable or not?
>
> Point 3: This point might be addressing a different issue entirely. My
> test code parses something called "callnum" which has been already
> formed. I wonder if this issue is located elsewhere.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352542
>
> Title:
> Printing: LC Call number formatting (2.5.2)
>
> Status in Evergreen:
> Confirmed
> Status in Evergreen 2.8 series:
> New
> Status in Evergreen 2.9 series:
> New
>
> Bug description:
> LC Call numbers do not format properly for printing. Example:
>
> 050 00‡aBS1430.5.P68 ‡b E63 2001 displays as
>
> BS1430
> .6
> .P68
> E63
> 2001
>
> It should display as
>
> BS
> 1430.6
> .P68
> E63
> 2001
>
> Path...

Thanks for the elucidation. This issue has grown from the original issue, I think! I'll consider dividing the issue, or maybe I'll just fix it.

Pushed
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dpearl/LP1352542_spine_labels2

to implement the first of Don Butterworth's issues.

If this is well-received, then we'll likely split off Don's other issues into new LP items.

Dan,

I've read through the patch, and just eyeballing it the code looks both good and clever.

One issue, though. You've got a bunch of 2.8.3-specific path changes, like this: /xul/rel_2_8_3/server/ ... I think if you change those back to /xul/server/ things will be good for heavy testing. Thanks!

--Mike

Mike is correct! Here is the revised branch.
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dpearl/LP1352542_spine_labels3

Adding a pullrequest for above branch.

Never mind... the pullrequest already set.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dpearl/LP1586509_spine_label_blank_A

Use this branch which also includes minor tweak for LP#1586509.

Thanks Dan! I finally tested the code today. Initially, I forgot to set the call number classification scheme to LC and then I thought I updated the class scheme, but apparently didn't hit the 'Modify' button. After getting past user error, spine label printing appeared to work as designed by the branch and, overall, leads to improvement in the software.

If there are outstanding issues with LC call numbers, I suggest that new LP bugs be filed on those specific issues.

Merged to master and backported to 2.11 and 2.10. Woo hoo!

Hello, we just upgraded from 2.10 to 3.3.4 and this change caused a problem for us. I know that no work on the xul client will be done anymore, so I'm just going to comment here in case anyone else has this issue.

We want all words in call numbers to be on new lines, which was the previous behavior. Including words in the prefix.

So prefix = "BB E"
Call Number ="M"

Used to result in a spine label of
BB
E
M

but with this change results in a spine label of
BB E
M

It looks like it is because the prefix is entered as a whole with a tab separator, unlike before when space was used as the only separator, and then space was used to split into lines.

Copying back the spine_label.js file from the previous version worked to fix this for us.
Josh