Created attachment 20781 [details] call number Let's start here - the CSV, XML and Quick label creator do not have this problem - it's purely the PDF. So see the attached images. The call number is 'Script H82 E45' the label is set to print itemcallnumber only and yet with it prints it makes the label look like this (also attached): SCR .I P T H82 E45 It's adding spaces and a dot that don't belong there. I have changed the font size and it still does it.
Created attachment 20782 [details] pdf call number
Please post an example of the expected split call number.
What do you mean - how should it split? It should split at the spaces and/or dots so Script H82 E45 But instead the PDF is adding in a dot and breaks in the middle of the word (and it's not font size cause I made it super small and it still does it. In the CSV, quick spine label and the XML it's not splitting the word 'Script' like the PDF is. Nicole
(In reply to Nicole C. Engard from comment #3) > What do you mean - how should it split? It should split at the spaces and/or > dots so > > Script > H82 > E45 That's what I was looking for. Thanks!
What call number system does this system use?
LCC
Created attachment 20949 [details] spine label I got this today from another library on 3.10.9 ---------- We have something wacky going on. Our barcode labels are printing out fine, but our spine labels have suddenly gone nuts. The system is: -creating a period at the beginning of the 2nd or 3rd line where none exists in the Call #. -Making lower case text ALL CAPS -Making long lines extend to the following label ------------ It sounds related to me.
Yet another report of this: ----------- It has come to my attention that our spine labels have begun to behave differently since approx. the beginning of this month (September '13): 1) all characters are being transformed into CAPS. We have conventions here where we use lower case: a) for prefixes to indicate collections like "SpColl" and "Diss" -- now they are "SPCOLL" and "DISS" b) for first 5 characters in author name and in title for our dissertations and theses i.e.: Julic Death --which is now: JULIC DEATH 2) the line breaks on the splitting of call numbers are now all screwy (maybe because of the characters being in all caps?). Where there is a call number prefix (like SpColl), instead of keeping it all on the first line, it is splitting it up with character numbering of 3+1+1+1 (cuttered), so it looks like: SPC .O L L and DIS .S and then it continues with the rest of the call number.
Chris, if you need any additional information, please let me know. I have no idea why the spine label pdf conversion would have suddenly gone haywire, but this is a real crisis for us. We are unable to print spine labels, which means that we are unable to put new items on the shelves. Thanks, Howard Freedman Director, Jewish Community Library, San Francisco hfreedman@jewishlearningworks.org
I'm thinking this bug may be a result of a recent code change. I'm away today but will try to have a look tonight.
Nicole, Will you please post an example call number from this system? And is it LLC? (In reply to Nicole C. Engard from comment #8) > Yet another report of this: > > ----------- > > It has come to my attention that our spine labels have begun to behave > differently since approx. the beginning of this month (September '13): > > 1) all characters are being transformed into CAPS. We have conventions here > where we use lower case: > a) for prefixes to indicate collections like "SpColl" and "Diss" -- now they > are "SPCOLL" and "DISS" > b) for first 5 characters in author name and in title for our dissertations > and theses i.e.: > Julic > Death > --which is now: > JULIC > DEATH > > 2) the line breaks on the splitting of call numbers are now all screwy > (maybe because of the characters being in all caps?). Where there is a call > number prefix (like SpColl), instead of keeping it all on the first line, it > is splitting it up with character numbering of 3+1+1+1 (cuttered), so it > looks like: > SPC > .O > L > v > > and > > DIS > .S > > and then it continues with the rest of the call number.
Howard, Would you also post an example of a problematic call number and the expected split. Also the classification system used by your library. Tnx. (In reply to Howard Freedman from comment #9) > Chris, if you need any additional information, please let me know. I have > no idea why the spine label pdf conversion would have suddenly gone haywire, > but this is a real crisis for us. We are unable to print spine labels, > which means that we are unable to put new items on the shelves. > > Thanks, > Howard Freedman > Director, Jewish Community Library, San Francisco > hfreedman@jewishlearningworks.org
(In reply to Chris Nighswonger from comment #11) > Nicole, > > Will you please post an example call number from this system? And is it LLC? > It's LCC. Samples: SpColl PS 3505 .U334 A17 1959 SpColl PS 1322 .S45 1962 BF 173 .L14213 1977 Watts PS 3535 .E75 T4 1969
Sure, Chris. We actually use LC (for adult), Dewey (for children's collection), and have some idiosyncratic ones for audiovisual media. The LC ones are the least impacted. TX 763 S73 becomes TX 763 .S73 And the standard Deweys are behaving in a similar way: J 295.435 K56 becomes J 295.435 .K56 Where it becomes horrible is in the case of the less standard call numbers: Jpic Rouss becomes: JPI .C ROUSS and DVD HOL Counterfeiters cop.3 would normally break with the border of the label into something like DVD HOL Counte rfeiters cop.3 but instead it now comes out as: DVD .H O L COUNTERFEITERS COP.3 (in addition to the other problems, the unbroken word COUNTERFEITERS goes well into the label to its right) Let me know if you need additional information. Thanks, Howard
Ok, the common denominator seems to be LCC numbers. This would seem to point to a recent change made to switch LCC splitting to Library::CallNumber::LC. The change was committed to master on 12 June 2013[1] and to the 3.10.x branch the next day [2]. I'm adding Galen and Bernardo to the cc list. Galen: feel free to correct my ignorant attempt at describing what appears to be happening here. According to the docs on L::CN::LC the module "is mostly designed to do call number normalization..." The operative word here is "normalization." The module docs state that the 'components' method used by the new code does this: "Get components suitable for printing (e.g., number and decimal joined, leading dot on first cutter)" Note the "leading dot on first cutter" statement. I think that what is happening is that call numbers passed into this method are first "normalized" which perhaps includes adding a leading dot to the first cutter. As for it returning all uppercase letters, that is most likely because L::CN::LC performs a 'uc()' on the number when the 'new' method is invoked. The exact code is 'callno => uc($lc)' And, indeed, this appears to my very untrained eye to meet the LC spec (if there is such a thing). [3] All of the examples given appear to "violate" the "spec" in some manner, and so suffer from various unexpected anomalies when run through the methods in this module. If this is the case, I'm not sure how to please all of the people some of the time. We probably need to have a wider discussion of the issue if this is true. Indeed, this is what appears to be happening when I run Labels_split_lccn.t on one of the sample CN's Nicole submitted. [4] The same number split fine under the old algorithm in 3.10.07 [5] Some of Howard's numbers do not claim to be LCCNs yet show a strangeness. The results of running one of the DDCNs through the LCCN test seem to indicate that all of his call numbers are being run through as LCCNs. [6] It so happens (by chance) that most DDCNs split fine under the LCCN split algorithm in 3.10.07. (Yes, I see the fail in there, but the split is fine none-the-less.) [7] The label code looks for the classification system in one of two places: either in the item "cn_source" (call number source) or the DefaultClassificationSource system preference (if the item cn_source is not populated). I would hazard a guess that the cn_source is not populated in the item records in his catalog and that the DefaultClassificationSource is set to 'lcc' which results in all of his call numbers being split as LCCNs. The text wrap issue in one of Howard's examples also appears to be victim of this change as the test shows which lends further support to my previous thought. [8] However, there may be other underlying issues with this as the text wrapping algorithm is not very sound. One might wonder why these problems did not show up when the test suite was run after this patch was committed. But the LCCN numbers included in the test suite are compliant with the "spec" and the test runs fine after the patch is applied. That accounts for some of the problem (ie. the LCCN weirdness). The other part of the problem (ie. "other" cataloging system call numbers weirdness) slipping by is probably hard to catch since libraries will run different configurations as well as use a multitude of variations on the theme of XYZ cataloging system. The bottom line is that we will probably have to have some discussion about whether to "fix" this problem and if the answer is "yes," how to "fix" it to most everyone's satisfaction. NOTES: [1] http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=edb8bddff074769a95744b6a7fa59eff61e0cfc1 [2] http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=56ea58ecda26f6ca4e4e8e437296b2aa2a2419d0 [3] http://en.wikipedia.org/wiki/Library_of_Congress_Classification [4] cnighswonger@cnighswonger-dt:~/Repositories/koha.3.2.labels/t (master)$ perl Labels_split_lccn.t 'Script H82 E45' 'Script,H82,E45' 1..11 ok 1 - use C4::Labels::Label; ok 2 - lccn: Script H82 E45 ok 3 - split expected to produce 3 pieces ok 4 - C4::Labels::Label::_split_lccn(Script H82 E45) not ok 5 - 6 of 3 pieces produced # Failed test '6 of 3 pieces produced' # at Labels_split_lccn.t line 56. ok 6 - (Script H82 E45)[0] populated: SCR not ok 7 - (Script H82 E45)[0] matches: Script # Failed test '(Script H82 E45)[0] matches: Script' # at Labels_split_lccn.t line 61. ok 8 - (Script H82 E45)[1] populated: .I not ok 9 - (Script H82 E45)[1] matches: H82 # Failed test '(Script H82 E45)[1] matches: H82' # at Labels_split_lccn.t line 61. ok 10 - (Script H82 E45)[2] populated: P not ok 11 - (Script H82 E45)[2] matches: E45 # Failed test '(Script H82 E45)[2] matches: E45' # at Labels_split_lccn.t line 61. # Looks like you failed 4 tests of 11. [5] cnighswonger@cnighswonger-dt:~/Repositories/koha.3.2.labels/t (v3.10.07)$ perl Labels_split_lccn.t 'Script H82 E45' 'Script,H82,E45' 1..11 ok 1 - use C4::Labels::Label; ok 2 - lccn: Script H82 E45 ok 3 - split expected to produce 3 pieces regexp failed to match string: Script H82 E45 at /home/cnighswonger/Repositories/koha.3.2.labels//C4/Labels/Label.pm line 126. ok 4 - C4::Labels::Label::_split_lccn(Script H82 E45) ok 5 - 3 of 3 pieces produced ok 6 - (Script H82 E45)[0] populated: Script ok 7 - (Script H82 E45)[0] matches: Script ok 8 - (Script H82 E45)[1] populated: H82 ok 9 - (Script H82 E45)[1] matches: H82 ok 10 - (Script H82 E45)[2] populated: E45 ok 11 - (Script H82 E45)[2] matches: E45 [6] cnighswonger@cnighswonger-dt:~/Repositories/koha.3.2.labels/t (master)$ perl Labels_split_lccn.t 'J 295.435 K56' 'J,295.435,K56' 1..11 ok 1 - use C4::Labels::Label; ok 2 - lccn: J 295.435 K56 ok 3 - split expected to produce 3 pieces ok 4 - C4::Labels::Label::_split_lccn(J 295.435 K56) ok 5 - 3 of 3 pieces produced ok 6 - (J 295.435 K56)[0] populated: J ok 7 - (J 295.435 K56)[0] matches: J ok 8 - (J 295.435 K56)[1] populated: 295.435 ok 9 - (J 295.435 K56)[1] matches: 295.435 ok 10 - (J 295.435 K56)[2] populated: .K56 not ok 11 - (J 295.435 K56)[2] matches: K56 # Failed test '(J 295.435 K56)[2] matches: K56' # at Labels_split_lccn.t line 61. # Looks like you failed 1 test of 11. [7] cnighswonger@cnighswonger-dt:~/Repositories/koha.3.2.labels/t (v3.10.07)$ perl Labels_split_lccn.t 'J 295.435 K56' 'J,295.435,K56' 1..11 ok 1 - use C4::Labels::Label; ok 2 - lccn: J 295.435 K56 ok 3 - split expected to produce 3 pieces regexp failed to match string: J 295.435 K56 at /home/cnighswonger/Repositories/koha.3.2.labels//C4/Labels/Label.pm line 126. ok 4 - C4::Labels::Label::_split_lccn(J 295.435 K56) ok 5 - 3 of 3 pieces produced ok 6 - (J 295.435 K56)[0] populated: J ok 7 - (J 295.435 K56)[0] matches: J ok 8 - (J 295.435 K56)[1] populated: 295.435 ok 9 - (J 295.435 K56)[1] matches: 295.435 ok 10 - (J 295.435 K56)[2] populated: K56 ok 11 - (J 295.435 K56)[2] matches: K56 [8] cnighswonger@cnighswonger-dt:~/Repositories/koha.3.2.labels/t (master)$ perl Labels_split_lccn.t 'DVD HOL Counterfeiters cop.3' 'DVD,HOL,Counte,rfeiters,cop.3' 1..15 ok 1 - use C4::Labels::Label; ok 2 - lccn: DVD HOL Counterfeiters cop.3 ok 3 - split expected to produce 5 pieces ok 4 - C4::Labels::Label::_split_lccn(DVD HOL Counterfeiters cop.3) not ok 5 - 6 of 5 pieces produced # Failed test '6 of 5 pieces produced' # at Labels_split_lccn.t line 56. ok 6 - (DVD HOL Counterfeiters cop.3)[0] populated: DVD ok 7 - (DVD HOL Counterfeiters cop.3)[0] matches: DVD ok 8 - (DVD HOL Counterfeiters cop.3)[1] populated: .H not ok 9 - (DVD HOL Counterfeiters cop.3)[1] matches: HOL # Failed test '(DVD HOL Counterfeiters cop.3)[1] matches: HOL' # at Labels_split_lccn.t line 61. ok 10 - (DVD HOL Counterfeiters cop.3)[2] populated: O not ok 11 - (DVD HOL Counterfeiters cop.3)[2] matches: Counte # Failed test '(DVD HOL Counterfeiters cop.3)[2] matches: Counte' # at Labels_split_lccn.t line 61. ok 12 - (DVD HOL Counterfeiters cop.3)[3] populated: L not ok 13 - (DVD HOL Counterfeiters cop.3)[3] matches: rfeiters # Failed test '(DVD HOL Counterfeiters cop.3)[3] matches: rfeiters' # at Labels_split_lccn.t line 61. ok 14 - (DVD HOL Counterfeiters cop.3)[4] populated: COUNTERFEITERS not ok 15 - (DVD HOL Counterfeiters cop.3)[4] matches: cop.3 # Failed test '(DVD HOL Counterfeiters cop.3)[4] matches: cop.3' # at Labels_split_lccn.t line 61. # Looks like you failed 5 tests of 15.
Thanks so much for pursuing this, Chris. It is true that LCC is our default setting. Through a batch item modification tool, I just switched the classification source from LCC to Dewey in all of the titles for which we want to print spine labels. They now seem to come out fine, with the exception that "Counterfeiters" (in DVD HOL Counterfeiters cop.3) still does not break and goes on to the adjacent label. So the issue seems to be how you characterize it, although I'm disappointed that the breaking problem continues when the item is in Dewey as well. As we can now print labels again, I'm delighted... By the way, I also experimented with selecting the "Other/Generic" classification source option, and it puts the entire call # in a single line. Thanks, Howard
(In reply to Howard Freedman from comment #16) > Through a batch item modification tool, I just switched the classification > source from LCC to Dewey in all of the titles for which we want to print > spine labels. They now seem to come out fine, with the exception that > "Counterfeiters" (in DVD HOL Counterfeiters cop.3) still does not break and > goes on to the adjacent label. This is most likely due to the sorry splitting algorithm I wrote years ago. Generally it has done what was needed, but there are cases where it is clearly broken. It is on my list to fix.
I have filed a feature request for Library::CallNumber::LC - https://code.google.com/p/library-callnumber-lc/issues/detail?id=7
Marking this bug as wontfix since it is not really a problem with Koha's code, but with the underlying module we rely on to do LCCN splitting. Galen has opened a bug request with the module's author so any fix should trickel down to us from there. Howard: Please add a note to bug 2499 regarding the wrapping problem. Be sure to include the example from here. Thanks for everyone's help.
I'm curious why this was marked as wontfix, because, although you draw distinction that it is someone else's module that Koha uses, it was decided to incorporate the module and it therefore affects Koha's functionality. More to the point, it basically breaks a major feature of our ILS because we don't use strict LC call numbers. It seems to me that because MARC allows for local rules and because open source is at it's heart flexible, community-based, creative, solution-oriented and extensible, that Koha's code wouldn't be managed and developed with a prescriptivist attitude. Can you offer a workaround? Can you provide any suggestions for what affected libraries can do in the interim? Will my library have to devolve into manually producing spine labels, a task we were spared from doing by even the ancient, unsupported K-12 school library ILS we used to have before migrating to Koha? We now have hundreds of books that can't be shelved because they are waiting for labels. We've been hoping this would get fixed quickly. It seems to me that if we are waiting for library-callnumber-lc's programmers whose project's entire purpose is to normalize LC call numbers to alter their code to allow for non-LC/customized/local rules, then I am not very optimistic that this will get fixed any time soon. It worked just fine before the code was pushed out to us. Is it possible to tweeze out that bit of code and rollback to the former function for those that don't want this innovative normalization trick? Must we force normalization? Our library and Howard Freedman's can't be the only two libraries in the Koha community that this affects... Hoping for a better way! We appreciate all that you do, but we'd really like to not have to sacrifice a huge, essential, labor-saving feature of the ILS just because we aren't strict LC. Thank you and be well, Kelly Sundin
I'm with Kelly's comments today 100%. We now have to enter our LC catalogued books as Dewey-derived in order to have them print to our specifications. And then we have to do a batch process to turn them back into LC to have them appear in correct shelf order. It now appears that this process may be playing havoc with how items appear in the Browse Shelf function. In any case, it's wasting hours of our time and creating immense confusion. Everything was fine before. I can't understand why the change in how LC spine labels are exported was seen as necessary.
Just a few comments to hopefully assist in understanding what has happened and why. 1. This change was intended to improve the quality of the code underlying LCCN splitting as well as standardize it. It was not intended to radically alter the high-level functionality of this splitting algorithm. 2. This change was routine. In other words, it was well within the norms of code maintenance in the software development profession. 3. This change does not affect the splitting of LCCN standard compliant numbers. It is numbers of this nature that are included in Koha's test suite. The test suite runs fine both before and after the change as expected. 4. While acknowledging the liberty permitted by LCCN for the addition of prefixes and suffixes, we must also acknowledge that anticipating and providing test cases for every library's individual implementation of that liberty would prove to be an unrealistic goal. 5. However, there are some things which can be "loosened up." (ie. dropping normalization, etc.) But this must be done in a forward looking direction with the goal of keeping the code maintainable. This means not going back to code which is less maintainable. As everyone is no doubt aware, much of the work done on Koha is gratis. Indeed, the vast majority of the label code has been provided at no cost. Thus it is important to keep it easy to maintain. We have done this by filing a bug with the new LCCN Perl library's maintainer. I suspect the changes will be forthcoming. 6. It is possible (but probably not a good idea) to overwrite your current version of C4/Labels/Label.pm with a 3.10.07 copy and return to the older algorithm. Do this at your own risk as it may have unintended consequences of which I am incapable of knowing. Please, this is not intended as a snub and "WONTFIX" does not mean "DONTCARE." I have hundreds of hours of coding time into the label tool, working alongside the catalogers at the library here. I completely empathize with your pain. This is why we are constantly stressing the need of pre-testing prior to doing an upgrade of any sort. Setting up a test server, installing the version of Koha you intend to upgrade to on it, loading up your data, and testing the features you use will prevent nasty surprises like this one. Kindest Regards, Chris
The only way I could see to hurry this along, would be send a patch to the Library::CallNumber::LC maintainer to help them implement the feature. You could perhaps persuade (by paying, giving cookies, some other means of reward) a developer to work on that for you.
(In reply to Chris Cormack from comment #23) > The only way I could see to hurry this along, would be send a patch to the > Library::CallNumber::LC maintainer to help them implement the feature. > > You could perhaps persuade (by paying, giving cookies, some other means of > reward) a developer to work on that for you. Hints if you do find one So we do my @parts = Library::CallNumber::LC->new($lccn)->components(); Which doesn't actually call the normalize routine. However I note sub new { my $proto = shift; my $class = ref($proto) || $proto; my $lc = shift || ''; my $self = { callno => uc($lc), }; bless $self, $class; return $self; } The new upper cases the number. components just splits it. So adding a no_uc flag shouldn't be too hard.
*** Bug 11294 has been marked as a duplicate of this bug. ***
For clarification: The "duplicate bug" was mine. A search for terms never brought up this bug so it may be a good warning for future bug reports. Meaningful titles are important. As regards Capitalization: It certainly isn't a deal breaker for us. But the capitalization is not because of using non-standard Library of Congress numbers. LoC itself uses miniscule lettering after publication dates for editions. This is and has been standard practice, so far as I am aware. Thus that part (the easy fix) is a real bug. Regarding the non-standard breaking: It seems that one way of working with such non-standard numbers would be to add a label breaking routine to allow for a special breaking character or customized code. If a library would like a non-standard feature, they can put the work in to write the code for it. "Customized" means doing the work to make it so. If we want out-of-the-box to work, we had better plan on following standards. For us, this did cause some problems for reference books, but we were just recataloging this section. The solution for us was a combination of collection code (Reference), item type (Reference), and Reference stickers. In the end, that was better than the REF prefix. Perhaps that might give ideas for individual solutions to the labeling issue in the meantime.
(In reply to Ian Palko from comment #26) > For clarification: > > The "duplicate bug" was mine. A search for terms never brought up this bug > so it may be a good warning for future bug reports. Meaningful titles are > important. > Actually, it is more likely due to the fact that Bugzilla's simple search does not include bugs marked "RESOLVED." Otherwise a search on 'Library::CallNumber::LC' would have turned up this bug. FFR, typing the word 'ALL' befor the actual search term in the simple search box will search all bugs. So 'ALL Library::CallNumber::LC' returns a result set which includes this bug. HTH
Hi, It's marked Resolved Wontfix but for us it's very critical. We just have 3.12 and we can not print our labels correctly. We are in lcc and for a call number like HQ759.96 C58 1986, we have this: HQ 759.96 .C58 1986 and for this STV B46ga 2013 Saison.2 DVD 1/5, we have STV .B46 G A2013 SAISON.2 DVD 1/5 We don't want to put our call number in dcc. How can we go back for print lcc call number correctly? Thanks, Marjorie
(In reply to Marjorie Barry-Vila from comment #28) > Hi, > > It's marked Resolved Wontfix but for us it's very critical. > We just have 3.12 and we can not print our labels correctly. Please see comment 22.
This bug is affecting us now, as well. Reading through the issue and the comments, I noticed two things: 1. It's now been more than six months since it was re-filed with the Library::CallNumber::LC project, with no new activity, and nearly six months since the project had any activity at all. It seems unlikely to be fixed any time soon. 2. RESOLVED WONTFIX seems like the wrong status for this bug. While WONTFIX isn't far off from the perspective of the koha team, pairing that with RESOLVED gives the impression that there's nothing wrong. I can tell you: something is *very* wrong here, and the issue is far from resolved. Perhaps BLOCKED is a better option, though I understand if the koha team only wants to use that status when they can point to a specific other bug that is the cause of the block. But something with the state of this needs to change. Anything that starts with RESOLVED tends to make devs think everything is okay. Much better to have a state that shows this is still broken in koha. That will help generate pressure to fix the upstream perl module.
(In reply to Joel Coehoorn from comment #30) > This bug is affecting us now, as well. > > Reading through the issue and the comments, I noticed two things: > > 1. It's now been more than six months since it was re-filed with the > Library::CallNumber::LC project, with no new activity, and nearly six months > since the project had any activity at all. It seems unlikely to be fixed any > time soon. > > 2. RESOLVED WONTFIX seems like the wrong status for this bug. While WONTFIX > isn't far off from the perspective of the koha team, pairing that with > RESOLVED gives the impression that there's nothing wrong. I can tell you: > something is *very* wrong here, and the issue is far from resolved. Perhaps > BLOCKED is a better option, though I understand if the koha team only wants > to use that status when they can point to a specific other bug that is the > cause of the block. But something with the state of this needs to change. > Anything that starts with RESOLVED tends to make devs think everything is > okay. Much better to have a state that shows this is still broken in koha. > That will help generate pressure to fix the upstream perl module. I think you are putting way too much value on the status of it and how/what developers decide to spend their free time on. Unless someone is willing to fund a fix for this, it won't get fixed, no matter what the status is. When it's our free time, you are competing against spending time with our families, reading a book, etc. The status being blocked will not make it any more likely that someone will decide to work on this.
I dug into the Library::CallNumber::LC code yesterday and the problem here is much more complex than it may seem on the surface. Removing the forced (partial) normalization is actually trivial, and I have a patch to do that which I plan to submit later this week or early next as I have time to fixup the tests. However, L::CN::LC will only tolerate a certain level of non-compliance to the LCCN standard. The root of this is in the complex regexp used to match and split callnumbers. The bottom line is that this regexp would have to be modified for nearly every variation on the theme of LCCN. Such a proposition is a nightmare. The best fix for any non-standard CN system will be a syspref which allows one to formulate and use a custom regexp for one's custom CN system. I have opened bug 12201 for this and will implement it over the next two months as time permists. Hopefully it will be of help to those in a bind. This would also allow the sharing of regexps among users.
A patch for L::CN::LC has been submitted. https://code.google.com/p/library-callnumber-lc/issues/detail?id=7
(In reply to Chris Cormack from comment #23) > The only way I could see to hurry this along, would be send a patch to the > Library::CallNumber::LC maintainer to help them implement the feature. > > You could perhaps persuade (by paying, giving cookies, some other means of > reward) a developer to work on that for you. You can increase the priority of this bug by clicking on the 'star' icon next to 'ID 7' in the bug list here: https://code.google.com/p/library-callnumber-lc/issues/list?cursor=library-callnumber-lc%3A7
For all interested parties, the fix for this has been applied in Library::Callnumber::LC. Hopefully the new release will be showing up on CPAN in the little bit and in a deb repo near you soon. Upgrading to version 0.23 should fix the symptoms noted in this bug. Many thanks to Dan Wells for rolling up a new release with this fix in it.