Summary: | Standing enhancement request for adding/updating call number splitting algorithms in C4/Labels.pm | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | Label/patron card printing | Assignee: | Chris Nighswonger <cnighswonger> |
Status: | ASSIGNED --- | QA Contact: | Bugs List <koha-bugs> |
Severity: | enhancement | ||
Priority: | P3 | CC: | andrew, cnighswonger, cookie.wolfrom, dcook, flyingendpaper, gmcharlt, iming, italo.barbosa.brasileiro, jhannert, koha, marjorie.barry-vila, patrick.robitaille, tmisilo |
Version: | unspecified | ||
Hardware: | PC | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15836 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25939 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28691 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 9370 | ||
Bug Blocks: | |||
Attachments: |
Patch to correct incorrect cutter number splitting
Corrected patch to make TAP::Parser happy Split LCCN on "segmentation" markers: '/' |
Description
Chris Cormack
2010-05-21 00:51:53 UTC
Adding code to accommodate LCCN numbers containing "segmentation" markers. Ie. 917.1/0022/2 which is expected to split to 917.1 0022 2 Created attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' (In reply to comment #2) > Created attachment 3298 [details] [review] > Split LCCN on "segmentation" markers: '/' This patch may also be picked up here: http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=commit;h=b1cab59d94670817eb4955ac9ad324f98ed7918d This bug is mentioned in: Bug 2500 - Standing enhancement request for adding/updating call number splitting algorithms in C4/Labels.pm http://lists.koha-community.org/pipermail/koha-patches/2011-March/014049.html What's the status of this? I see a patch but not sure it was pushed, needs rebasing or sign-off. I think the 'standing issue' part of the title means that as people report problems with splitting this is the bug to use to attach the patches to. Hi Nicole, I agree :) But there is a patch and I wondered if that was integrated or not since I found no 'patch pushed' status or comment for the patch attached last to the bug. There are actually more patches under this bug than are attached, IIRC. Both of these patches have been pushed. (The first no longer applies as there is not label.pm any longer) I'm not sure that changing the priority of this bug or listing as "patch-pushed" etc. makes sense in light of this being a standing enhancement request. Changing these from the default status would imply that every patch submitted was at that status level which may not be true. Ok, leaving open. Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' LCCNs do not have segmentation markers. The example is for DDC, and the feature is already implemented for that classification. (In reply to comment #10) > Comment on attachment 3298 [details] [review] > Split LCCN on "segmentation" markers: '/' > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > is already implemented for that classification. IIRC this was specifically added at the request of someone on the mailing list. See http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 From this statement: "That's kind of surprising, I have been playing around a bit on my test box and for me Library of Congress numbers never seem to get split. They usually come in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 and that is obviously too long." in one of the posts, it appears that at least one person does get LCCN numbers with a '/' as a segmentation marker. Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' Removing obsolete because this has been requested and should make no difference to LCCN numbering which contains no sort of segmentation markers. (In reply to comment #11) > (In reply to comment #10) > > Comment on attachment 3298 [details] [review] > > Split LCCN on "segmentation" markers: '/' > > > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > > is already implemented for that classification. > > IIRC this was specifically added at the request of someone on the mailing list. > See > http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 > > From this statement: > > "That's kind of surprising, I have been playing around a bit on my test box and > for me Library of Congress numbers never seem to get split. They usually come > in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 > and that is obviously too long." in one of the posts, it appears that at least > one person does get LCCN numbers with a '/' as a segmentation marker. Ah, I assumed it was a typo for ddcn that wasn't applied because the issue was identified as user error, since the example given is a DDC call number not an LC call number. Sorry about that. (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Comment on attachment 3298 [details] [review] > > > Split LCCN on "segmentation" markers: '/' > > > > > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > > > is already implemented for that classification. > > > > IIRC this was specifically added at the request of someone on the mailing list. > > See > > http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 > > > > From this statement: > > > > "That's kind of surprising, I have been playing around a bit on my test box and > > for me Library of Congress numbers never seem to get split. They usually come > > in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 > > and that is obviously too long." in one of the posts, it appears that at least > > one person does get LCCN numbers with a '/' as a segmentation marker. > > Ah, I assumed it was a typo for ddcn that wasn't applied because the issue was > identified as user error, since the example given is a DDC call number not an > LC call number. Sorry about that. Sorry. As you can see, I took what was requested and added it assuming the requester knew what he/she was talking about. I'm by no means a call number expert. :-) If this is not a valid LCCN, then feel free to correct and/or obsolete. Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' 917.1/0022/2 is indeed a Dewey call number, not an LC call number, and I agree with Jared that LC call numbers aren't entered with segmentation marks. Consequence, as your previous comment indicated, I'm marking the patch as obsolete. For the record, I'm adding the following example to this standing bug: The LC number 'QH541.15.C6 C25 2012' is currently being split like this: QH 541 .15 .C6 C25 2012 It should actually be split as follows: QH 541.15 .C6 C25 2012 However, the fix for this is being handled via bug 9370, which is proposing using a CPAN module to handle LC call number parsing. Hello, 1. The DDC number: 629.283042 2. Class format: Dewey 3. I would like the call number to appear as: 629. 283 042 Automatically text wrap in groups of three after the decimal point. This is how spine labels from our previous system generated, and fits perfectly to our current stationery. Please also keep <space> (found in the current splitting algorithm) as this is useful for call number like: DVD 629.283042 FRAS to appear as: DVD 629. 283 042 FRAS So I've recently encountered a call number like this: 361.250994 REP NO. 11/10 The section "361.250994" is DDC, I believe. However, "REP NO. 11/10" is entirely local. When printing labels and splitting call numbers, the slash between 11 and 10 gets removed using _split_ddcn. This isn't desirable, so I opted to use a different splitting sub. However, if I use _split_ccn, "REP NO. 11/10" gets turns into "REP NO. 11 /10", which is also undesirable, as that means "11" gets printed on one line and "/10" gets printed on the next. This is due to some regexp found in _split_ccn, which pulls apart the last element in the @parts array. Is there are a reason why the last element in the array is being pulled apart like this? I used git blame but the original 2009 commit message from Chris Nighswonger didn't really tell me much. I'm sure there is a reason, but it might make more sense for this - or another - sub to just split on spaces. -- Another thought...currently there is no way to associate splitting subs with call number classification schemes. The only way I see is to hardcode it into Label.pm. Perhaps it would be an idea to specify the call number splitting rule in the "Classification sources" part of the Administration module. This could be useful in several contexts. For instance, we're currently using the _split_lccn sub for LCC and NLM, but it could also be useful for the KF Modified classification scheme (which is a legal scheme based on LCC) and other schemes. KDC (Korean Decimal Classification) would also probably use DDC. Admittedly, since the behaviours are likely the same, people using KF Modified or KDC should probably just use "LCC" or "DDC" as classification sources rather than making new ones, so perhaps I don't actually have a good point there :p. However...there might be times when a library wants to use the DDC filing rules but have call number splitting just on spaces. Like in the above case where they want to preserve those local slashes. I don't know. Just a thought. I've already set up "z" to use _split_ccn in the past. I might adjust it so that it uses a different sub which just split on spaces... 1. The call number in question. C 3.278/3:996/9 C 3.278/3:995/2 C 3.278/3:999/5 ... 2. The formal name of the classification system (ie. LOC, Dewey, etc.) SuDoc Superintendent of Documents (SuDocs) Classification Scheme 3. Any other information you feel may be helpful. http://libweb.lib.georgiasouthern.edu/wiki/index.php/Sample_Gov_Docs_Spine_Labels This new dev might help a bit, we could add slitting rule definitions to the wiki if there is interest too (similar to the SQL or Serial pattern libraries): Bug 15836 - Labels: Offer configuration option for splitting call numbers I'm having problems with two types of call number splits in LC; children's literature and numbers that incorporate a military regiment. Here are examples of each: Children's lit example: PZ7.1 .P6213 St 2018 appears as PZ 7.1 .P6213 S T2018 I would like it to be split as PZ 7.1 .P6213 St 2018 Military regiment example: E492.94 1st .H53 1982 appears as E 492.94 1 .S T H53 1982 I would like it to be split as E 492.94 1st .H53 1982 |