Make Cyrillic diacritics display correctly.

[jcoyne]

The font of the "e" and "iaa" (with the diacritics) in the 710 looks too big in the SearchWorks display.

Message sent from: https://searchworks.stanford.edu/view/413028

From Vitus:

Not exactly precomposed letter with diacritic vs. two separate characters but in this case two ways to encode the ligature. MARC21 uses to map the ligature as two Unicode characters (U+FE20 and U+FE21) but in 2004 the mapping was changed to one character (U+0361). Symphony followed that, so all ligatures in Symphony were U+0361. But OCLC still to this day uses U+FE20 and U+FE21. I have argued with them for years about that. If you compare the word Strategii︠a︡ in https://searchworks.stanford.edu/view/in00000002927 with Strategii͡a in https://searchworks.stanford.edu/view/4152692 you will see this difference.
What's interesting is that in the Folio instance record of in00000002927, the two halves look just fine, but in SearchWorks it appears bolded.

[dnoneill]

@saseestone Is going to see if someone can edit the record on folio-test. I believe this might be a data issue that we don't necessarily want to fix. The way that the record displays in folio is shown below. Based on the view in folio it is showing up correctly (just with more spacing) in searchworks.

[dnoneill]

Alisa updated the the title for https://searchworks-stage.stanford.edu/view/in00000002927 on folio-test from Strategii︠a︡ to Strategii͡a. It is displaying correctly in searchworks. I think the only fix for this would be possibly change the font but from what I am understand we are using Stanford standards so we probably won't want do this. I am moving this into the backlog.

[saseestone]

@dnoneill I'm actually hoping that we can do something in SW (maybe in the indexer?) that would correct this. Does the FOLIO update that Alissa did yesterday give us a clue about something we could do to render the correct ligature? (i.e. U+0361)?

Chatting with @cbeer just now, it seems like maybe there are some things we could try?

I also chatted with @ahafele yesterday, wondering if there was a chance that this would be fixed in FOLIO. She wrote "The data on our side will remain the same until OCLC changes their policy on this character..." I guess it's possible down the road that FOLIO could do what Symphony used to do, but it feels like we should continue to pursue managing this in the indexer or display until then. That's my $.02 worth. :)

[jcoyne]

This was reverted in sul-dlss/searchworks_traject_indexer#1415

[jcoyne]

But was it not fixed again by sul-dlss/searchworks_traject_indexer#1418 ?

[jcoyne]

And then disabled in sul-dlss/searchworks_traject_indexer#1419

[cbeer]

The previous Cyrillic fix throws tons of honeybadger errors:
sul-dlss/searchworks_traject_indexer#1589