merge from upstream: editor supraline fix code

[rla2118]

http://dclp.github.io/dclpxsltbox/output/dclp/131/130167.html
The display of overstrokes on the first two characters (ιη) of the first line in this record is not right. The line should be continuous over both iota and eta.

XML doesn't appear to be correct:
It currently has
< lb n="1"/><num value="18">ῑ<hi rend="supraline">η</hi></num> δ<unclear>ι</unclear>’ ὅλης ἡ<unclear>μέρας</unclear>.

But should be, I suppose,
< lb n="1"/><num value="18"><hi rend="supraline">ιη</hi></num> δ<unclear>ι</unclear>’ ὅλης ἡ<unclear>μέρας</unclear>.

I'm sending to @jcowey for comment and/or forwarding to someone else.

[paregorios]

I've just updated comment from @rla2118 above using three continuous grave accents before and after code snippets so all pointy brackets show up in view

[paregorios]

And, FWIW, the encoding recommendation/fix from @rla2118 looks correct to me.

[jcowey]

This is a known problem with the editor.
In Leiden+ if one adds a supraline to the letters alpha or iota it is not written as proper xml mark up. One can change to proper xml mark up in the xml tab and then preview is correct and subly different from when supraline is added via Leiden+. (The overstroke sits higher when correct).
Ryan has a fix for it which has not yet been implemented on papyri.info where it is also a problem. Most people are unaware of this. I personally correct when finalising and then it goes into the system correctly.
I looked for a ticket in which this is described and where Ryan proposes the fix, but I cannot find it. Sorry I cannot explain why it happens.

[paregorios]

@ryanfb can you point us to a ticket (if one exists) as discussed by @jcowey above? I'd prefer to close this ticket with a pointer to wherever it's being tracked across the larger effort. thanks.

[ryanfb]

See discusion at sosol/sosol#121 (and linked), and particularly now-passing tests in rails-3-nfd branch of papyri/xsugar at: papyri/xsugar@rails-3...rails-3-nfd#diff-a4da66e842ac3a281fe18b9ea50a3345R1069

[jcowey]

ryanfb has made the fix on production in papyri.info, tested it and it is fine. I have cross checked and confirm that it is working for me on production in papyri.info.
This means that this should now no longer happen. That is great. There probably remain a few instances to be fixed. Once that is done everything should be fine.
Closing this and opened a new issue: #161

[paregorios]

Reopening this ticket as we will need to pull changes made by @ryanfb into our fork and branch if we want to see the fix working when we get our version of editor up and running. Taking assignment of this ticket for now ahead of coordination with @Edelweiss to schedule that update/merge.

[jcowey]

Blocked until our editor is up and usable.

[paregorios]

@jcowey @Edelweiss is this still blocked or should we put it back in motion

[paregorios]

Adding this issue to the WBWorkshop milestone since it is a blocker for #161, which is already in that milestone.

[paregorios]

I gather that this issue is no longer blocked, since we now have a working editor. I'm going to remove the "blocked" tag, bump the priority (since it's a blocker for another item in the current milestone), and reassign to @Edelweiss

[Edelweiss]

The master branch of our xsugar repository is now up-to-date with papyri’s master branch.

https://github.com/DCLP/xsugar/commits/master

Is there anything else we need to take into account (rails-3, rails-3-nfd), or does master comprise all the changes that are necessary for the desired feature to work properly?

[paregorios]

I think that's a question for @ryanfb ...

[paregorios]

@ryanfb can you answer the question @Edelweiss poses above? I'd like to get this ticket resolved.

[paregorios]

/me to ping @ryanfb about this

[ryanfb]

@paregorios @Edelweiss Papyri's master branch should have everything we know of for supraline. I believe there may still be some outstanding issues we haven't resolved in any branch:

papyri/xsugar#4
papyri/xsugar#5
papyri/xsugar#10

[paregorios]

thanks @ryanfb

@Edelweiss back to you ... perhaps best to ask @jcowey to confirm that the "it's working" notice he provided above holds true on the current deployment of litpap.info?

[paregorios]

ping @jcowey @Edelweiss