July 2006 - Koha-devel - lists.koha-community.org

problem with using the value_builder plugins
by Robert Lyon 04 Jul '06

04 Jul '06

Hi I'm looking at using the /value_builder/ plugin feature of helping create MARC21 records using the form here /cgi-bin/koha/acqui.simple/addbiblio.pl and I'm wanting to know if the popup javascript functions related with them are meant to map data in the popup window to only one field in the MARC form or can one easily access repeatable subfields I'm wanting to add information into the 651a subfield from a plugin that has a bunch of checkboxes I can get the information added to the field 651a as a string like so -> Place 1|Place 2|Place 3 and on saving this will make a bunch of 651a subfields like so a Geographic name Place 1 a Geographic name Place 2 a Geographic name Place 3 but now how do i get the the clicking of the ... on the end of the field to grab not only the info in it's field but also the other ones related to the 651a subfield? any ideas Bob -- Robert Lyon Katipo Communications

1 0

Panjabi In notes or/Title
by Ramandeep Singh 04 Jul '06

04 Jul '06

Hello All, I've got Koha 2.2.5 running on Linux. I am trying to put Panjabi (Panjabi Unicode) value into the notes field to store some information about the Panjabi book title. So I paste the Unicode value (ਰਮਨਿਪ) in Koha admin notes field. I then query the database to see the value stored. It looks like it has stored the html code equivalent i.e #223232;#34343;etc. I also noticed that it splits this whole value into multiple rows in the marc_* table values. so tag 500a will have multiple rows with the html code values above and it is split randomly. Next, when I go back to the admin interface--the notes field it repeated multiple times with the html code values and I cannot edit the original value I had placed. I am by no means an expert/adv on Unicode but have general understanding. I would appreciate any one's input in this. BTW, I did read the posts from the achieves that did mention how to get Chinese/Arabic in the titles and it seems to be working......i need to know how I can get Panjabi to work. Thanks! Raman -- ਰਮਨਿਪ ਸਿੱਗ Ramandeep Singh RamanTX(a)gMail.com

1 0

Head & rel_2_2 merged.
by Antoine Farnault 03 Jul '06

03 Jul '06

Hi all, I 've just merged Head and rel_2_2 and i prepare a big commit soon. I think this merged version has no "Internal Server Error" but, as i'm new in the koha code, it's possible that i 've made some mistakes by resolving conflits between these 2 versions... I hope i haven't made too much errors and/or bugs ! Cheers, -- Antone Farnault antoine(a)koha-fr.org

1 0

M:F:USMARC & UTF8 problems
by Tumer Garip 03 Jul '06

03 Jul '06

Hi all, It has been months since devel-week and we are still struggling with UTF8 problems. Anyone following the IRC may have noticed that with ZOOM now working and everything looked normal and UTF8 we had a display problem when accented characters were in the search term. This was occurring when the new version of MARC::Record (version 2) package was being used. This package is regarded as a MUST for our MARC8 to UTF8 conversions and also hopefully to handle UNIMARC correctly. Well after all this time and effort I can report that the handling of UTF8 within this package is buggy. For a reason I did not understand line 170-174 of USMARC.pm says: # if utf8 the we encode the string as utf8 if ( $marc->encoding() eq 'UTF-8' ) { $tagdata = marc_to_utf8( $tagdata ); } which simply means if you have an UTF8 marc record re-decode it to UTF8. Which in itself calls Encode::decode and changes everything to bytes. In simple terms it messes all the accented UTF8 characters you may have on your template. I do not know any need of usage for this conversion and especially in KOHA_head everything being UTF8 this definitely does more harm than good. I have corrected the error with this package and a copy is sent to Joshua to raise the question with the package maintainer. In the meantime I have added another functionalty of conversion MARC8-UTF8-MARC8 to this package so one can go MARC::File::USMARC::decode($marc,&\somefunction,$encoding,$normalize); Where $encoding could be "UTF-8" or "MARC-8" and the record will get converted to that encoding as it is decomposed. Rather than the current method of converting to XML and back to MARC in order to get this. The fourth argument(is 1 or 0) is a more complicated issue of composed(precomposed) and decomposed character sets. I will not go into details of this but I suggest you supply 1 to this argument when converting to UTF8. This will make sure you get composed characters which are more browser and XML friendly.(More info on this subject can be found at Unicode::Normalize and the at the links in document) This correction resulted in another problem solved. The issue of having to use LibXML (and a specific version of that) seems to have gone away. Your SAX filter may stay as PurePerl and still your XML wont break. (see the article by Joshua http://www.mail-archive.com/address@hidden/msg01006.html) However extensive testing has to be done to make sure on this. An important note though. Whatever parser you use you must have PurePerl defined as one of those parsers in your ParserDetails.ini otherwise it will not work. I hope this problem is solved once and for all so that we can continue developing more ZOOM functionalty into KOHA. Cheers, Tumer Garip -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.9.8/380 - Release Date: 30.06.2006

1 0