Comment 13 for bug 1352542

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 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