want to hide dot before Cutter no. like what desktop app can do

[ClaireCLGUO]

Desktop SpineOMatic can hide Cutter decimal, but there is no such settings could be made in cloud version.

[mgobat]

Available in v1.2.8.

[ClaireCLGUO]

After testing, it doesn't work perfectly. For call numbers of identical structure, some dots before Cutter No. are hided but others aren't.

[mgobat]

Thanks for testing, @ClaireCLGUO. We will take a look.

[ClaireCLGUO]

I noticed that you seem to be hiding the first decimal. However, there may be a decimal within class no. That is, the first decimal isn't always the decimal before Cutter no. Hope this would help you improve the cloud app.

[mgobat]

@ClaireCLGUO, thanks for the additional details.

[mgobat]

@ClaireCLGUO, I think I have this fixed. I will publish a new version of the Cloud App on Monday, 09-January. I don't want to publish a new version right before the weekend.

[mgobat]

New version,v1.3.0, published on Monday, 09-January.

[simonreadnz]

@mgobat we're trying out SpineOMatic and we're having the same problem as @ClaireCLGUO was with the cutter decimal appearing. It looks like you've said you've fixed it so maybe we just don't have the right setting in place - is there a particular setting we need to select? In the desktop app we can just tick the "Hide cutter decimal" to remove it

Desktop app example: BF 76.7 AG49 2010a

Cloud app example: BF 76.7 .AG49 2010a

We're just trying to get rid of the pesky decimal on the 3rd line.

Thanks!

[mgobat]

@simonreadnz, do you have the decimal character set to "." in your template? If so, it is certainly possible that the code isn't working correctly for your call numbers.

[simonreadnz]

@mgobat I didn't have it configured but I do now :)

I have two different variations of that call number in Alma (for holdings in different branches) but neither of them seems to work:

‡h BF76.7 ‡i .AG49 2010a ‡h BF76.7 .AG49 2010a

Another variation we might have is ‡h HF5415.12.A785 MA742 (so no space between the decimalised number and the cutter.

None of these variations seems to work at the moment - not sure if it's because of something further I haven't configured properly or if the functionality isn't working as intended.

Thanks!

[mgobat]

@simonreadnz, just so I be sure I have the same settings while trying to replicate/repair, do you have the "Line breaks between call number parts" option checked, and what is your setting, if any, for "Maximum call number parts"? Thanks.

[mgobat]

@simonreadnz, the SpineOMatic Cloud App defines the cutter to be the cutter decimal character, followed by a single alphabetic character, followed by a numeric character. It isn't finding your cutter since it is the decimal character followed by two alphabetic characters. Admittedly, I'm no call number expert. Is this cutter definition too limiting?

[simonreadnz]

@mgobat I've got the Line breaks between call number parts ticked and the Maximum call number parts are set to 30 (couldn't tell you why I set it to that - happy to change it to something else if that works). We're set to Parse routine 6 in Alma if that makes any difference for testing.

I've tried some other call numbers with just a single letter after the cutter decimal followed by a number but that didn't seem to work either. We have lots of call numbers with two letters after the cutter decimal and then followed by numbers, so if we could get it working we'd want to try to accommodate that scenario. I'm not sure how the desktop apps calculates it and if you could copy that logic?

Some more examples with a single character after the cutter decimal:

‡h PR9639.H84 M9 1982 PR 9639 .H84 M9 1982

‡h D843.KH2 D 843 .KH2

‡h HD70.U5 DS74 HD 70 .U5 DS74

@ClaireCLGUO did you ever get it to work with you call numbers?

[ClaireCLGUO]

@simonreadnz The dots are hided, the configuaration is below: However, we did not print labels using cloud or desktop SpineOmatic because the label size could not be adjusted to exactly match the paper size.

[simonreadnz]

Thanks @ClaireCLGUO Looks pretty similar to our setup except for the Maximum call number parts. Thanks for the heads up about the label sizes - we've haven't looked at that very closely yet

[mgobat]

@simonreadnz, let's try to figure out why call numbers with a single alphabetic after the cutter decimal aren't printing with the decimal removed before we make any changes to the logic. There must be some difference in our settings as it is working for me.

Here are all my settings. Maybe you can point out what I have set differently than you.

Call number parsing setting in Alma:

Bib/holdings MARC records:

"Call number" options in my SpineOMatic Cloud App template:

And the generated label:

For reference, my template is pretty basic. Here's the source code: <p>{{field:item_data.call_no}} <br /> {{field:holding_data.copy_id}} <br /> {{field:item_data.barcode}}</p>

The logic difference between the SpineOMatic Windows application and the Cloud App is that the Windows application looks for the cutter decimal followed by at least one alphabetic character; it doesn't check beyond that.

[simonreadnz]

@mgobat Thanks! I can see the problem now - I've been using the Parsed call number part one, two three etc. fields rather than just the Parsed call number field. I've changed it over and now the cutter decimal is being removed where there is one letter after the decimal. The only outstanding issue I can see is where there are two letters after the cutter decimal then the cutter decimal still shows (as previously discussed).

Good progress!

[mgobat]

@simonreadnz, that's great news. Thanks for the update.

Now for the cutter decimal + 2 (or more) alpha characters. It was written to look for one alpha and one digit, as that was what was found to be the definition for the cutter for LC call numbers. Is this incorrect? If we change it, could it adversely affect other users?

[simonreadnz]

@mgobat I think it'd be OK to loosen the rule to say a decimal followed by one or more alpha characters would work OK. The main thing is that the decimal isn't followed immediately by a digit. I believe we only have one or two alpha characters after the decimal so the criteria could be limited to look for up to two alpha characters followed by a digit but I'm inclined to think it's not necessary to be that restrictive - specifying one or more alpha characters after the decimal should be adequate.

[mgobat]

New release, v1.3.5, now defines the cutter to be the decimal character, followed by an alphabetic, then followed by either an alphabetic or a digit.

[simonreadnz]

Thanks @mgobat - it's looking good!