Bug 10821 - label pdf adding in strange breaking
Summary: label pdf adding in strange breaking
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: master
Hardware: All All
: P1 - high major (vote)
Target Milestone: ---
Assignee: Chris Nighswonger
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
: 11294 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-09-04 17:20 UTC by Nicole C. Engard
Modified: 2018-01-10 20:53 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
call number (9.60 KB, image/png)
2013-09-04 17:20 UTC, Nicole C. Engard
Details
pdf call number (9.97 KB, image/png)
2013-09-04 17:20 UTC, Nicole C. Engard
Details
spine label (45.52 KB, image/jpeg)
2013-09-10 12:54 UTC, Nicole C. Engard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2013-09-04 17:20:08 UTC
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.
Comment 1 Nicole C. Engard 2013-09-04 17:20:35 UTC
Created attachment 20782 [details]
pdf call number
Comment 2 Chris Nighswonger 2013-09-04 17:41:46 UTC
Please post an example of the expected split call number.
Comment 3 Nicole C. Engard 2013-09-04 18:30:41 UTC
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
Comment 4 Chris Nighswonger 2013-09-04 19:21:05 UTC
(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!
Comment 5 Chris Nighswonger 2013-09-04 23:32:35 UTC
What call number system does this system use?
Comment 6 Nicole C. Engard 2013-09-05 11:04:52 UTC
LCC
Comment 7 Nicole C. Engard 2013-09-10 12:54:06 UTC
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.
Comment 8 Nicole C. Engard 2013-09-10 15:49:42 UTC
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.
Comment 9 Howard Freedman 2013-09-10 16:39:50 UTC
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
Comment 10 Chris Nighswonger 2013-09-10 16:46:31 UTC
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.
Comment 11 Chris Nighswonger 2013-09-10 17:43:37 UTC
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.
Comment 12 Chris Nighswonger 2013-09-10 17:46:47 UTC
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
Comment 13 Nicole C. Engard 2013-09-10 17:59:40 UTC
(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
Comment 14 Howard Freedman 2013-09-10 18:15:59 UTC
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
Comment 15 Chris Nighswonger 2013-09-11 02:10:43 UTC
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.
Comment 16 Howard Freedman 2013-09-11 05:36:56 UTC
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
Comment 17 Chris Nighswonger 2013-09-11 10:37:32 UTC
(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.
Comment 18 Galen Charlton 2013-09-11 14:26:40 UTC
I have filed a feature request for Library::CallNumber::LC - https://code.google.com/p/library-callnumber-lc/issues/detail?id=7
Comment 19 Chris Nighswonger 2013-09-11 14:49:04 UTC
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.
Comment 20 Kelly Sundin 2013-09-20 20:45:09 UTC
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
Comment 21 Howard Freedman 2013-09-20 21:04:33 UTC
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.
Comment 22 Chris Nighswonger 2013-09-21 01:16:56 UTC
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
Comment 23 Chris Cormack 2013-09-21 21:25:15 UTC
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.
Comment 24 Chris Cormack 2013-09-21 21:32:34 UTC
(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.
Comment 25 Chris Nighswonger 2013-11-24 02:39:43 UTC
*** Bug 11294 has been marked as a duplicate of this bug. ***
Comment 26 Ian Palko 2013-11-27 18:12:35 UTC
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.
Comment 27 Chris Nighswonger 2013-11-27 18:59:41 UTC
(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
Comment 28 Marjorie Barry-Vila 2014-02-19 14:26:12 UTC
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
Comment 29 Chris Nighswonger 2014-02-19 15:03:59 UTC
(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.
Comment 30 Joel Coehoorn 2014-05-05 03:05:25 UTC
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.
Comment 31 Chris Cormack 2014-05-05 03:30:53 UTC
(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.
Comment 32 Chris Nighswonger 2014-05-06 17:51:03 UTC
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.
Comment 33 Chris Nighswonger 2014-05-07 16:30:26 UTC
A patch for L::CN::LC has been submitted.

https://code.google.com/p/library-callnumber-lc/issues/detail?id=7
Comment 34 Barton Chittenden 2014-12-10 20:58:08 UTC
(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
Comment 35 Chris Nighswonger 2014-12-12 19:22:38 UTC
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.