I've done some debugging of the problem I mentioned. The in
and out
data strings are shown below:
E8 87 BA E7 81 A3 E5 9C B0 E5 8D 80 E5 9C 8B E6 B0 91
E6 89 80 E5
BE 97.
YAZ correctly translates this string to (output in MARC8,
hex, ignore
spaces):
1B 28 42 21 54 2B 21 49 43 21 37 79 21 34 55 21 37 6f
21 46 4d
21 3F 75 21 30 6A
esc $ 1
In handling each of these input triples, the library follows
this path:
yaz_write_marc8
yaz_write_marc8_2
lookup_marc8 - this process sets the page_chr string to
<ESC>$1 -
correct for EACC
flush_combos
yaz_write_marc8_page_chr
The problem is that the last triple also returns
<ESC>$1 as the
page_chr, and since this is the value already stored in
cd->write_marc8_page_chr from the first ESC sequence
written out, the
ESC sequence is never properly closed. I noticed that the
last flag is
correctly set to 1 as the last triple is being converted,
but the last
flag seems to have no influence on resetting the page
character back to
ASCII. I'm wondering if I received all of the patch.
Gary
_______________________________________________
Yazlist mailing list
Yazlist lists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
|
