Comments on: Supporting Right to Left languages in MarcEdit http://people.oregonstate.edu/~reeset/blog/archives/692 On my work (programming, digital libraries, cataloging) and other stuff that perks my interest (family, cycling, etc) Wed, 28 Oct 2009 05:56:39 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: caleb http://people.oregonstate.edu/~reeset/blog/archives/692/comment-page-1#comment-107602 caleb Thu, 09 Jul 2009 07:17:49 +0000 http://oregonstate.edu/~reeset/blog/archives/692#comment-107602 Terry, I think this is awesome. I'll probably never look at another MARC record in Arabic, but the implications are mind-boggling. Lets make simple tools that work all the time! Terry, I think this is awesome. I’ll probably never look at another MARC record in Arabic, but the implications are mind-boggling. Lets make simple tools that work all the time!

]]> By: Administrator http://people.oregonstate.edu/~reeset/blog/archives/692/comment-page-1#comment-107601 Administrator Thu, 09 Jul 2009 06:34:51 +0000 http://oregonstate.edu/~reeset/blog/archives/692#comment-107601 Ayman, That's good to know. Indicators are easy enough to deal with (just a quick change to the algorithm -- so that's been updated). I'm going to need to see an example of what would be correct in say the 300a or 300c so I can update the function. --TR Ayman,

That’s good to know. Indicators are easy enough to deal with (just a quick change to the algorithm — so that’s been updated). I’m going to need to see an example of what would be correct in say the 300a or 300c so I can update the function.

–TR

]]> By: Ayman Bustanji http://people.oregonstate.edu/~reeset/blog/archives/692/comment-page-1#comment-107600 Ayman Bustanji Thu, 09 Jul 2009 06:06:45 +0000 http://oregonstate.edu/~reeset/blog/archives/692#comment-107600 On the screenshot I found the following changes: Correct changes: Subfield codes (letters a, b, c) are now in the right place – located before subfield content. Subfield content that contains numeral data only (without letters) is also Ok. Example, 082/a Still Not Correct: Subfield content, combining both numerals and text, is still inverted (not correct) – text precedes the numbers. Example: subfields 300/a, 300/c. Indicators are still inverted (not correct) On the screenshot I found the following changes:

Correct changes:
Subfield codes (letters a, b, c) are now in the right place – located before subfield content.
Subfield content that contains numeral data only (without letters) is also Ok. Example, 082/a
Still Not Correct:
Subfield content, combining both numerals and text, is still inverted (not correct) – text precedes the numbers. Example: subfields 300/a, 300/c.
Indicators are still inverted (not correct)

]]> By: Ayman Bustanji http://people.oregonstate.edu/~reeset/blog/archives/692/comment-page-1#comment-107599 Ayman Bustanji Thu, 09 Jul 2009 06:05:23 +0000 http://oregonstate.edu/~reeset/blog/archives/692#comment-107599 On the screenshot I found the following changes: *Correct changes: Subfield codes (letters a, b, c) are now in the right place – located before subfield content. Subfield content that contains numeral data only (without letters) is also Ok. Example, 082/a *Still Not Correct: Subfield content, combining both numerals and text, is still inverted (not correct) – text precedes the numbers. Example: subfields 300/a, 300/c. Indicators are still inverted (not correct) On the screenshot I found the following changes:
*Correct changes:
Subfield codes (letters a, b, c) are now in the right place – located before subfield content.
Subfield content that contains numeral data only (without letters) is also Ok. Example, 082/a
*Still Not Correct:
Subfield content, combining both numerals and text, is still inverted (not correct) – text precedes the numbers. Example: subfields 300/a, 300/c.
Indicators are still inverted (not correct)

]]> By: Jonathan Rochkind http://people.oregonstate.edu/~reeset/blog/archives/692/comment-page-1#comment-107598 Jonathan Rochkind Thu, 09 Jul 2009 02:32:47 +0000 http://oregonstate.edu/~reeset/blog/archives/692#comment-107598 That 'close but not perfect' output is in fact what we actually _get_ in our (proprietary) user-facing OPAC display from MARC records with right-to-left languages and numbers. Except I've never been able to wrap my head around _why_ it looks like it does, and what if anything could be done about it. Sounds like it's an understandable consequence of the standard unicode display algorithms -- and if I read your post over again three or four more times, I might even understand why, which might be the first step to figuring out how to get it to display 'right' in, for example, blacklight. That ‘close but not perfect’ output is in fact what we actually _get_ in our (proprietary) user-facing OPAC display from MARC records with right-to-left languages and numbers. Except I’ve never been able to wrap my head around _why_ it looks like it does, and what if anything could be done about it. Sounds like it’s an understandable consequence of the standard unicode display algorithms — and if I read your post over again three or four more times, I might even understand why, which might be the first step to figuring out how to get it to display ‘right’ in, for example, blacklight.

]]>