Bug 15241

Summary: Allow lowercase letters in spine labels
Product: Koha Reporter: Theodoros Theodoropoulos <theod>
Component: Label/patron card printingAssignee: Chris Nighswonger <cnighswonger>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low    
Version: 3.20   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9370
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10821
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Theodoros Theodoropoulos 2015-11-23 14:01:58 UTC
There are cases[*] when one might want to have LOWERCASE letters in a spine label.  These include 'a','b','c','d',... and 'z' after the date.

Although in the items table, itemcallnumber already allows (and in our system already has) lowercase letters in such cases, when printing the spine label PDF, all these are converted to UPPERCASE.
I believe that call numbers should not be converted to uppercase prior to PDF export.


[*] For example:

PS
3603
.L548
R43
2011a    <--- meaning the item is a Photocopy

PS
3603
.L548
R43
2011b    <--- meaning the second edition

or
PS
3603
.L548
R43
2011z   <--- meaning the year is uncertain

(You may find more such cases here: https://sites.smu.edu/cul/cip/docs/CAT/cpm-050-090.htm)
Comment 1 Chris Nighswonger 2015-11-23 16:49:24 UTC
This issue was addressed in bug 10821 and has since been fixed in Library::Callnumber::LC (https://github.com/libraryhackers/library-callnumber-lc/commit/1b42bed2a42ce73679739edce6586339b192dc5b)

Two things to consider here:

1. Are you using the latest release of Library::Callnumber::LC?

2. Are you using a localized variation of the LCCN system? (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10821#c32)
Comment 2 Theodoros Theodoropoulos 2015-11-24 06:40:53 UTC
Chris you are right!

We had Library-CallNumber-LC v0.22 installed. We upgraded to 0.23 and the problem was solved! 
Having said that, with the new version, new problems with callnumber splitting were found, but they are not related to this case.

Thanks again for such a prompt reply! I will close this case right away.