spine labels assume LC

[James Fournie]

The spine label print interface in EG 2.0 makes some LC-centric assumptions. For example, one of our sites using the following:

M3 650.1 HIL

M3 is a prefix they use to indicate MP3 recordings. The spine label printer breaks the M3 onto M on one line and 3 on the next line. While this makes sense for LC numbers, it doesn't really work for any dewey prefix that may contain numbers or letters.

I've created a patch which maintains the existing LC assumptions by default, however it use the call number sortkey org unit setting and if your setting is not LC (3) it will skip the LC-centric bits of code.

This hardcodes 3 as the LC value in asset.call_number_class -- while this is not ideal, this is probably the most reasonable quick fix short of a larger fleshing out of call number support in the spine labels interface. Code comments may require some adjustment depending on your opinion on the matter.

 ~James

[Mike Rylander (mrylander)]

I'll defer regression testing and application of this to someone else (Jason?), but I do have some thoughts on how to move forward with classification-based label prep.

First, I believe we should use the label's classification (or, more specifically, the label_class field on the volume object). The OU setting is meant to be a default when adding call numbers.

Then, we need a way to tie print normalization code (that is, for LC, the code that's adding spaces in all the right places) to a class. Since we already have a mechanism for sort normalization (the in-db function named in asset.call_number_class.normalizer) I suggest we add a new column (print_normalizer?) to point at a function that does what it says. Now, this function could be a database stored proc, or it could be a pile of JS source that accepts a string (the label) and returns another string (the print-normalized string). The former is perhaps more correct, but the latter would make things much simpler to implement (no round-trip to the db with a string just to add some spaces).

Thoughts?

[Jason Etheridge (phasefx)]

On Thu, May 12, 2011 at 12:35 PM, Mike Rylander <email address hidden> wrote:
> I'll defer regression testing and application of this to someone else
> (Jason?), but I do have some thoughts on how to move forward with
> classification-based label prep.

Sure. Dan probably has more familiarity with that bit of code than me
at this point. He did a lot of work with it most recently.

> First, I believe we should use the label's classification (or, more
> specifically, the label_class field on the volume object).  The OU
> setting is meant to be a default when adding call numbers.

This sounds sane.

> Then, we need a way to tie print normalization code (that is, for LC,
> the code that's adding spaces in all the right places) to a class.

If you replace spaces with line breaks, then I'm with you.

I imagined at some point we would we refactor the javascript so that
you could have different call number wrapping plugins (which would get
selected based on something like the more recent call number class),
but I'm not adverse to the server/db doing the work.

--
Jason

[Dan Scott (denials)]

James, thanks a ton for this patch. I would suggest that, given that Evergreen use is dominated by public libraries, Dewey would be the right call-number splitting scheme to default to. Would you be willing to code that up and push it to a public git branch?

Side note the call-number splitting algorithm(s) don't touch prefixes. In which case, if "M3" in James' example was an acn.prefix or a shelving location prefix, it wouldn't be affected by the LC algorithm anyway.

Jason - hah, "a lot of work with it most recently" was last September! But I'm flattered nonetheless...

I agree with the need for a longer-run per-call-number based approach for print normalization, but would support committing a Dewey-defaulting version of James' patch through 2.0 (or 1.6.2 if'n'you like) as a solid improvement over the existing code in the interim.

I'm of two minds about a database method vs. the database containing a mess of JavaScript. The latter can be cached in the staff client, which is great for performance, but I fear the testing implications (pgTap + pljs for unit testing?).

A third way would be to avoid the database roundtrip by treating this something like the Action/Trigger bits, where the database points to specific Perl methods (or better, perhaps, OpenSRF methods) that simply must exist (open-ils.cat.format_callnumber.lc vs. open-ils.cat.format_callnumber.dewey?). This should be a bit faster than hitting the database, and a bonus is that unit-testing the call-number splitting algorithms gets easy - but the cost is the need for a bit more documentation on how to add your own classification scheme.

[James Fournie (jfournie)]

Here's a patch for trunk

[Dan Scott (denials)]

James - thanks! Tested and applied from master through rel_2_0 (considered a bug fix as we're restoring the expected default behavior of Dewey formatting unless otherwise indicated by the specific call number class):

master: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=677037301876d90eba1c181cd6f0cd1f13981e26

rel_2_1: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb8d70d4e4c475e9f948e5fab27ee2fb43567cef

rel_2_0: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=566b43cac3abdb7f107078e9724acf790ab8ce1f

The broader issue of where to store these splitting algorithms, etc remains but probably should be the subject of a different ticket or mailing list discussion.