Comment 6 for bug 1352542

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