← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:58 | owen | Is anyone here familiar with the barcodes generator? |
| 12:58 | Or should I ask, is anyone here? :) | |
| 13:06 | tim | owen: All I know is that it won't work with the newest version of PDF::API2 |
| 13:07 | owen | It seems to have other problems as well :) |
| 13:07 | tim | And I haven't been able to get the output right with the correct version. |
| 13:07 | owen | I wish I knew someone who was using it in production to find out how it's /supposed/ to work |
| 13:13 | tim | Also the Generate Barcodes button at the bottom of the NPL page doesn't do anything. |
| 13:14 | But if I just press enter after I fill in the information it will try to generate barcodes. | |
| 13:14 | owen | Yeah, I'm correcting the templates now...which is why I'm coming up with questions |
| 13:14 | tim | Not formatted the best. But at least they're barcodes. |
| 13:14 | owen | We don't actually use it |
| 13:15 | Is it something you would be using in production? | |
| 13:16 | tim | Yup |
| 13:17 | owen | Then I'd better get it working ;) |
| 13:17 | The 'add country code' process seems to be broken, FWIW | |
| 13:17 | tim | I've been trying, but I don't know how to get the formatting right. |
| 13:19 | owen | I wish I knew what the 'inventory codes' choice was for |
| 13:23 | tim | I noticed the arrows point the wrong direction where you select individual inventory codes. |
| 13:25 | I just tried using a barcode number for the inventory code and it worked. | |
| 13:25 | Now if I need to get the barcode formatted. | |
| 13:26 | I also want it to not add digits to the beginning of the barcode number. | |
| 13:30 | owen | Whenever I use it, the inventory codes box is empty. What is it supposed to do? |
| 13:30 | tim | It's also printing in a barcode format that's currently locked out on the scanner. |
| 13:31 | I put a barcode number in the inventory code box and cliked on the << (should be >>, but that's the one that worked). | |
| 13:31 | It adds it to the list box on the right. | |
| 13:34 | owen | I see...it's a way for the user to input specific barcodes to be printed. |
| 13:34 | I was confused by the 'inventory code' terminology | |
| 13:35 | tim | D'oh! I should've changed that while I was fixing the directions the arrows pointed. |
| 13:36 | owen | Knowing what it's for, it makes a lot more sense now :) and it works. |
| 13:41 | tim | We have 8 digit barcodes and it's adding 4 digits at the start. |
| 13:42 | I thought I read somewhere that it outputs code 39. I can't get our scanners to read it. | |
| 13:43 | owen | tim, when you use printer configuration to set parameters for the barcodes, is Koha saving a configuration file to the server? itemsLabelConfig.conf? |
| 13:44 | I have a feeling printer configuration doesn't work for the same reason custom country codes don't: that Koha won't or can't write to the configuration files | |
| 13:47 | tim | I have the file, but the timestamp is the date I installed Koha. |
| 13:47 | So it doesn't look like it updated. | |
| 13:47 | owen | Supposedly Koha should write to that file whenever you update your configuration |
| 13:49 | tim | It had to write to it at one time or other because the paper size is letter and I know it wasn't when I installed it. |
| 13:54 | I guess I copied that from the other computer, but permissions weren't copied. | |
| 13:54 | The one on the other computer is chmod 757 | |
| 13:54 | It saves now | |
| 14:00 | owen | Hmmm... not for me. |
| 14:06 | tim | Did you chmod the file? |
| 14:07 | owen | Yup |
| 14:08 | tim | Wierd. Worked fine for me. |
| 20:15 | thd-away | chris, rach: owen and tim were looking at issues of barcode printing earlier today. |
| 20:15 | chris, rach: Do you have any libraries using it? | |
| 20:17 | chris | nope |
| 20:18 | thd-away | chris: For whom was it written? |
| 20:18 | chris | no idea |
| 20:18 | i didnt write it :) | |
| 20:18 | its a fairly recent thing | |
| 20:19 | itll be in the devel list archive somewhere | |
| 20:19 | thd-away | chris: :) |
| 20:55 | thd | chris: It may be new to Koha, November 2004, but it is old code, Copper Mountain Elementary School Library 1992 :) |
| 21:04 | rach | sounds like steve tonnenson then |
| 21:10 | thd | rach: Title: barcode.ps; Creator: Willem van Schaik; CreationDate: aug 1992 |
| 21:15 | rach: my $libraryname='Copper Mountain Elementary' | |
| 01:31 | osmoze | hello all |
| 01:46 | hdl | hi. |
| 06:54 | kados | hi all |
| 06:56 | paul: do you have a moment? | |
| 06:56 | paul | hi joshua |
| 06:56 | i'm here | |
| 06:57 | kados | great ... I'm having trouble with a MARC conversion script for a client |
| 06:58 | when I view the marc file with dump.pl | |
| 06:58 | there are a few records with many many 852s | |
| 06:58 | 60-70 | |
| 06:59 | they are periodicals (journals) | |
| 06:59 | I run that script | |
| 06:59 | and I get very strange results for those records | |
| 07:00 | I'll paste in an example in a second | |
| 07:01 | ok ... it's a large dump: | |
| 07:01 | NUMBER 39969 => | |
| 07:01 | LDR 196903cas 22207015 a4500 | |
| 07:01 | 000 6Periodical5Publisher7Periodical820050503aPeriodical Storage p405,810kPi6/26/74mVol.91/No.24bPeriodical Storage6Periodical5Publisher7Periodical820050 | |
| 07:01 | 503aPeriodical Storage p405,811kPi7/3-10/74mVol.91/No.25bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p405,812kPi7/17-24/7 | |
| 07:01 | 4mVol.91/No.26bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p405,813kPi7/31/74mVol.91/No.27bPeriodical Storage6Periodical5P | |
| 07:01 | ublisher7Periodical820050503aPeriodical Storage p405,814kPi8/7-14/74mVol.91/No.28bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Stor | |
| 07:01 | age p405,815kPi8/21-28/74mVol.91/No.29bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p405,816kPi9/4-11/74mVol.91/No.30bPeri | |
| 07:01 | odical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p405,817kPi9/18/74mVol.91/No.31bPeriodical Storage6Peri | |
| 07:01 | 000 8/81mVol.98/No.12bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,053kPi4/15/81mVol.98/No.13bPeriodical Storage6P | |
| 07:01 | eriodical5Publisher7Periodical820050503aPeriodical Storage p406,054kPi4/22/81mVol.98/No.14bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriod | |
| 07:01 | ical Storage p406,055kPi4/29/81mVol.98/No.15bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,056kPi5/6/81mVol.98/No.16bP | |
| 07:01 | eriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,057kPi5/13/81mVol.98/No.17bPeriodical Storage6Periodical5Publisher7Periodi | |
| 07:01 | cal820050503aPeriodical Storage p406,058kPi5/20/81mVol.98/No.18bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,059kPi5/ | |
| 07:02 | 27/81mVol.98/No.19bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,060kPi6/3-10/81mVol.98/No.20bPeriodical Storage6Period | |
| 07:02 | ical5Publisher7Periodical820050503aPeriodical Storage p406,061kPi6/17-24/81mVol.98/No.21bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodic | |
| 07:02 | al Storage p406,062kPi7/1-8/81mVol.98/No.22bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,063kPi7/15-22/81mVol.98/No.2 | |
| 07:02 | 3bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,064kPi7/29-8/5/81mVol.98/No.24bPeriodical Storage6Periodical5Publisher7 | |
| 07:02 | Periodical820050503aPeriodical Storage p406,065kPi8/12-19/81mVol.98/No.25bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p40 | |
| 07:02 | 6,066kPi8/26-9/2/81mVol.98/No.26bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,067kPi9/9/81mVol.98/No.27bPeriodical Sto | |
| 07:02 | rage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,068kPi9/23/81mVol.98/No.29bPeriodical Storage6Periodical5Publisher7Periodical820050503a | |
| 07:02 | Periodical Storage p406,069kPi9/30/81mVol.98/No.30bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,070kPi10/7/81mVol.98/ | |
| 07:02 | No.31bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,071kPi10/14/81mVol.9 | |
| 07:02 | 8/No.32bPeriodical Storage6Periodical5Publisher | |
| 07:02 | 7Periodical820050503aPeriodical Storage p406,072kPi10/21/81mVol.98/No.33bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406 | |
| 07:02 | ,073kPi10/28/81mVol.98/No.34bPeriodical Storage6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,074kPi11/4/81mVol.98/No.35bPeriodical Storag | |
| 07:02 | e6Periodical5Publisher7Periodical820050503aPeriodical Storage p406,075kPi11/11/81mVol.98/No.36bPeriodical Storage6Periodical5Publisher7Periodical820050503aPe | |
| 07:02 | riodical Storage p406,076kPi11/18/81mVol.98/No.37bPerio | |
| 07:02 | 300 _7Periodical | |
| 07:02 | that's the result I get when I view the record with dump.pl _after_ running my conversion script | |
| 07:02 | paul | mmm ... quite unreadable... |
| 07:02 | kados | (the record continues) |
| 07:03 | it seems like there is a bug in MARC::Record | |
| 07:03 | but it's strange that dump.pl can read the record | |
| 07:03 | paul | did you try dumpmarc with -w ? |
| 07:03 | kados | no ... I will |
| 07:03 | paul | because without, it can accept some errors in iso2709 file |
| 07:04 | with -w it is much more strict. | |
| 07:04 | (or is it without -w ?) | |
| 07:04 | kados | with w is off |
| 07:04 | paul | if i read correctly, you want to move 852 to 952 ? |
| 07:05 | kados | correct |
| 07:05 | (while preserving 852) | |
| 07:05 | (just in case ;-)) | |
| 07:05 | paul | just in case : |
| 07:06 | MARC::Field->new('952','','', | |
| 07:06 | #u=> $itemnumber, | |
| 07:06 | b=>'NBBC', #holdingbranch | |
| 07:06 | c=>$field852_b, #location | |
| 07:06 | d=>'NBBC', #homebranch | |
| 07:06 | if $field852_b is empty you will have BIG problems | |
| 07:06 | as Perl consider : | |
| 07:06 | b=> 'NBBC', | |
| 07:06 | c=> d | |
| 07:06 | 'NBBC' => k | |
| 07:06 | ... | |
| 07:06 | to avoid this, always do : | |
| 07:07 | c=> $field852_b."", | |
| 07:07 | (adding ."" to all subfields you want to create | |
| 07:07 | ) | |
| 07:07 | kados | ok ... I'll try this |
| 07:07 | paul | ALWAYS do this, if it is useless, forgetting it may be harmful ;-) |
| 07:11 | kados | paul: now i get: |
| 07:11 | Use of uninitialized value in concatenation (.) or string at ./sagebrush2koha.pl line 310. | |
| 07:12 | paul | means your problem is there ;-) |
| 07:12 | kados | 310 is: |
| 07:12 | MARC::Field->new('952','','', | |
| 07:12 | #u=> $itemnumber, | |
| 07:12 | b=>'NBBC'."", #holdingbranch | |
| 07:12 | c=>$field852_b."", #location | |
| 07:13 | paul | right. |
| 07:13 | kados | did I do it wrong? |
| 07:13 | paul | (note you don't need ."" on subfields that are 100% sure defined, like 'NBBC' ;-) |
| 07:13 | kados | :-) |
| 07:13 | paul | drop all fields and reintroduce them 1 by one to see which one is the culprit |
| 07:14 | (s/drop/comment/) | |
| 07:14 | http://marcpm.sourceforge.net/[…]ml#subfield_code_ | |
| 07:15 | If no matching subfields are found, undef is returned in a scalar context and an empty list in a list context. | |
| 07:15 | kados | so should I do: |
| 07:15 | p=>$field852_p."" if $field852_p; | |
| 07:15 | ? | |
| 07:16 | paul | would not work. Better is : $field852_p?$field852:"" |
| 07:16 | (or you could try "$field852_p" | |
| 07:17 | that should not be managed as a concat | |
| 07:18 | kados | ok ... but I think the 'uninitialized value' error is probably ok |
| 07:18 | probably some fields (like notes) don't exist with every record | |
| 07:18 | paul | you may be right : can be due to "use warnings" |
| 07:19 | hdl | rach, chris, paul, kados : Sorry to bother you. table aqorderdelivery is never used in my Acquisition.pm. |
| 07:19 | So I am wondering if one CAN receive books he didnot expect from a supplier with our system. | |
| 07:19 | But More, how partial deliveries are managed. | |
| 07:19 | I ordered 4 books, only One was delivered. | |
| 07:19 | If system is given a delivery date, it is true I received sthg. | |
| 07:19 | But also false my order is not complete. | |
| 07:19 | And If aqorderdelivery is never used, maybe we should drop it. | |
| 07:22 | paul | hdl, you should ask koha-devel, as chris is in bed (hopefully for him) & joshua & I ignore the answer to your question. |
| 07:22 | kados | hehe ... it's true ... I've never use acquisitions |
| 07:23 | paul: the same problem happens when I run the script with the ."" modif | |
| 07:23 | paul | (if you want to make monay on Koha, you will have to know this module as well as others) |
| 07:23 | kados | paul: i don't know if it happens with many records |
| 07:23 | (of course ;-)) | |
| 07:23 | paul | you mean it sometimes happends & sometimes not ? |
| 07:23 | kados | paul: only for some records |
| 07:23 | Periodicals with many 852s | |
| 07:24 | paul | sometimes yes & often no you mean ? |
| 07:24 | & periodicals with only a few 852 are working well ? | |
| 07:24 | kados | yes |
| 07:24 | in fact, I've only seen two records with the problem | |
| 07:24 | but as there are 50,000 records I could be missing many | |
| 07:25 | here's the start of one record that has the problem (before I convert it) | |
| 07:25 | NUMBER 39969 => | |
| 07:25 | LDR 99943cas 2210645 a 45 0 | |
| 07:25 | 001 ocm06083626 | |
| 07:25 | 003 OCoLC | |
| 07:25 | 005 20050503171633.0 | |
| 07:25 | 008 800314c19029999iluer1p 0 a0eng d | |
| 07:25 | 010 _a 04019837 | |
| 07:25 | _zsc 84007725 | |
| 07:25 | _zsn 80008287 | |
| 07:25 | 040 _aNSD | |
| 07:25 | there are many 040 (about 30) | |
| 07:26 | paul | maybe splitting line 309 / 322 in 2 step could be helpfull : my $newfield=MARC::Field->new ..; $record->append_fields($newfield) |
| 07:27 | (if could be a complex memory allocation problem. | |
| 07:27 | kados | ok |
| 07:27 | paul | why not also : |
| 07:27 | warn "=>".$record->as_formatted on line 323 | |
| 07:27 | you would see when the record becomes corrupted | |
| 07:27 | 1st 852 or 10th for example ? | |
| 07:55 | kados | paul: there are 372 852s |
| 07:55 | paul: and printing as_formatted within the foreach loop reveals no problems | |
| 07:56 | paul | an idea that maybe not really a MARC::Record problem ! |
| 07:56 | that's really many 852 | |
| 07:56 | and iirc, the iso2709 has a length limit, you may have reach it | |
| 07:57 | (so, you should try again deleting 852 when copied in 952) | |
| 07:57 | kados | maybe ... so I should delete the existing 852s then? |
| 07:57 | to make room? | |
| 07:57 | :-) | |
| 07:57 | paul | 1st :-) |
| 08:05 | kados | paul: you're a genius! |
| 08:05 | paul: it worked! | |
| 08:05 | paul: thank you very much | |
| 08:05 | paul | I know I know... |
| 08:05 | ;-) | |
| 08:05 | kados | hehe |
| 08:06 | paul | the invoice is to send where ? |
| 08:06 | (what ? It seems I hear : "Trash road, 0001 desktop") | |
| 08:07 | kados | hehe |
| 08:07 | paul | interesting info : http://linuxfr.org/2005/08/05/19390.html |
| 08:08 | (stallman reaction after european parliament rejected software patents) | |
| 08:31 | hdl | Unfortunately, qemu is not too fast on my box. Should have kqemu. |
| 09:28 | http://www.jpcheney.org/rubriques/00000061.htm if you need some fun now :) | |
| 10:02 | kados | select subfieldvalue from marc_subfield_table where tag='952' and subfieldcode='y' limit 0,20; |
| 10:02 | Empty set (0.51 sec) | |
| 10:02 | paul: maybe bulkmarcimport is taking the value from 952y, putting it in notforloan, then taking it out of 952y in the marc_subfield_table | |
| 10:03 | paul | nope |
| 10:03 | 100% sure | |
| 10:04 | kados | select * from marc_word where tagsubfield='952y' limit 0,20; |
| 10:04 | Empty set (0.02 sec) | |
| 10:05 | but it does show up in items.notforloan | |
| 10:05 | and items.notforloan is (presumably) getting it's value from 952y | |
| 10:22 | thd | please explain the length limit for MARC::Record issue to me |
| 10:23 | paul | hi thd. |
| 10:23 | thd | hello paul |
| 10:23 | paul | is iso2709, positions 0->4 contains "record length" |
| 10:23 | so, it's limited to 9999 Bytes. | |
| 10:23 | (99999 in fact) | |
| 10:23 | no, I'm wrong here. | |
| 10:24 | the limit is lower. | |
| 10:25 | thd | paul: where might it be documented? |
| 10:29 | paul: are you identifying an issue in the ISO standard itself or MARC::Record itself? | |
| 10:29 | kados | iso standard i think |
| 10:29 | paul | iso iirc |
| 10:31 | thd | Is it easy to create a record that exceeds the standard if you start filling it with detailed table of contents. book reviews, and extensive holdings information? |
| 11:02 | kados: in your recent conversion, do I understand correctly that there was so much information in some of your records that merely doubling the 852 fields exceeded the maximum length for a single record? | |
| 11:03 | kados | thd: yes |
| 11:04 | thd | kados: so what was in these records then to cause that problem? |
| 11:04 | kados | thd: too many 852 fields |
| 11:04 | thd: over 300 of them | |
| 11:06 | thd | kados: is that an 852 field for every issue of a serial? What were they storing that needed over 300 852s? |
| 11:06 | kados | thd: periodicals ;-) |
| 11:06 | thd: and the record came from OCLC ;-) | |
| 11:08 | thd | kados: Do you mean the holdings information was for many libraries or only the one you were converting? |
| 11:08 | kados | thd: I don't understand the question |
| 11:10 | thd | kados: Why did these records have so many 852 fields? What information was being stored there that required so many fields to store it? |
| 11:10 | kados | thd: periodicals ;-) |
| 11:11 | paul | I leave now |
| 11:11 | see you next week | |
| 11:12 | thd | kados: I understand that these were periodical records. What aspect of periodical information was being stored so as to require many 852s? |
| 11:15 | kados: maybe if my question is not well understood would you send me an example of one of these records so I can understand better how this problem can arise? | |
| 11:15 | kados | thd: I understand now ... it was just standard holdings information that's kept in 952 |
| 11:15 | thd: it's just that there was a lot of it | |
| 11:16 | thd: over 300 852s | |
| 11:16 | thd: so when I created duplicate 952s | |
| 11:16 | thd: that record was mangled | |
| 11:16 | thd: as soon as i started deleting the 852s before I created the 952s it worked like a charm | |
| 11:17 | thd | kados: was it over 300 different issues, each with its own 852? |
| 11:17 | kados | yep |
| 11:34 | shaun: howdy! | |
| 11:34 | shaun: how's the website coming? | |
| 11:34 | shaun | howdy |
| 11:35 | well thanks, but due to Russel's request i won't be sharing the actual design until the meeting | |
| 11:37 | i have replaced the last link that i shared here, and the new design is more polished, with specific design aspects like rounded corners and gradients, all made to comply with standards and accessibility guidelines so far | |
| 11:39 | in terms of content, i have yet to make some draft homepage content with Ben's assistance, and i am waiting for an outcome to the current thread on the first paragraph | |
| 11:54 | thd | shaun: where is your original design description? I only saw Russel's wireframes. |
| 11:57 | shaun | thd: what do you mean by design description? the original, unfinished, deprecated design candidate was at http://dev.shaunevans.co.uk/koha/ |
| 11:58 | thd | shaun: that is what I mean. I just never saw it. :) |
← Previous day | Today | Next day → | Search | Index