[Koha-bugs] [Bug 10821] label pdf adding in strange breaking

Wed Sep 11 04:10:43 CEST 2013

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10821

Chris Nighswonger <cnighswonger at foundations.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |In Discussion
                 CC|                            |bgkriegel at gmail.com,
                   |                            |gmcharlt at gmail.com

--- Comment #15 from Chris Nighswonger <cnighswonger at foundations.edu> ---
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 at 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 at 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 at 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 at 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 at 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.

-- 
You are receiving this mail because:
You are watching all bug changes.