Representing deleted text

[Eystein-Thanisch]

Text deleted by a scribe is marked up in TEI using <del>. At present, this is being represented in the output using the CSS strikethrough property, which draws a horizontal line through the middle of the text. This can render the results unclear or even not be very noticeable (with "e", for example, the line simply passes right across the existing cross-stroke; when this is the only deleted letter, the deletion is effectively camouflaged).

Ideas are thus being sought as to how deleted text might be represented clearly and effectively in the output.

[conmaol]

I have come up with a few more ideas for this, which I have now implemented and pushed to GitHub. Stevie will pull to the DASG server in the morning.

The overall aim is for the diplomatic transcription to be informative, but unfussy. Readers can click on the word if they need more precise information. I am proposing the following as a first attempt at striking this balance:

• scribal additions: grey superscript

• scribal deletions: gray subscript

• editorial additions: green

NIce and simple, but maybe not sophisticated enough? Beachdan sam bith agaibh?

MM.

[Eystein-Thanisch]

Thanks for this, Mark. It looks very elegant. However, I do have a couple of concerns.

• These are very unlike the conventions used in printed editions, which is what users will be used to; obviously we can innovate on this but that comes at a price in terms of risk of people getting confused and complaining etc.
• I am disappointed that the nature of the scribal addition (from above, from the margin etc.) won't be visually apparent on the page; I realise details will be in the right-hand pane but presumably only one addition can be viewed there at once, whereas making it apparent on the page means it gives a complete picture of the layout.
• Once we get on to hand shifts, glosses, gaps and suchlike, we are going to need to find ways of indicating those. In my current version, I use subscript text for brief editorial notes (e.g. <sub>**_-gap-_**</sub>). Obviously you might come up with another way but, equally, we might find we need subscript for that.

@mnimheachair , you have spent more time than I pondering editions: what do you think?

Maybe I'll feel better once I see it for myself online.

[mnimheachair]

RE: scribal additions: grey superscript/ scribal deletions: gray subscript/ editorial additions: green

I think we would aim to represent these without the use of colours in so far as is possible - e.g. we should consider that end users in a more public sphere could be colourblind or have dyslexia (and I have learned from teaching that placing a blue sheet over a screen/white page makes things much easier to read - incidentally, I wonder if this is the reason that selecting an area of a scanned page on the adobe pdf reader makes it blue but that's besides the point).

Could scribal deletions be represented by a double strike through to make it clearer and avoid problems such as those with the letter e?

Regarding editorial additions, are we talking about additions from us, e.g. when we use <supply>letters</supply>? If so, can we not make them appear inside square brackets as is normal editorial practice?

For scribal additions, we are currently using <add type="insertion" place="above" resp="Hand23"><w>rann</w></add> or <add type="insertion" place="below" resp="Hand23"><w>rann</w></add>' Could it be rendered if that says above it appears as (normal black) superscript and if it says below it appears as (normal black) subscript?

[Eystein-Thanisch]

Sorry, yes: context. We are talking about scribal additions.

I don't know what Mark's thoughts are on editorial additions but I would strongly recommend square brackets. We need zero ambiguity about what is in the original manuscript and what has been added and this is the convention. However, we are concentrating on the dip edition for now so this won't come up immediately.

@steviebarrett also mentioned accessibility issues. We should take these very seriously, although I am not knowledgeable in such things myself.

@mnimheachair , re: the example in your last para. We can't see what you have encoded because GitHub will have rendered your code as if this were a webpage. You need to "escape" it by enclosing your code in `` so that we see everything.

@conmaol , without making this personal, may I ask what you dislike about the system for representing expansions, scribal additions that I sent you? :-) It is the system that was approved by Willie etc. so we'll need some definite reasons for deviating from it.

[mnimheachair]

@mnimheachair , re: the example in your last para. We can't see what you have encoded because GitHub will have rendered your code as if this were a webpage. You need to "escape" it by enclosing your code in `` so that we see everything.

Thanks, changed.

[Eystein-Thanisch]

@mnimheachair , re: the example in your last para. We can't see what you have encoded because GitHub will have rendered your code as if this were a webpage. You need to "escape" it by enclosing your code in `` so that we see everything.

Thanks, changed.

No probs! FYI, I just found out that you can put text in ^superscript or _subscript in these comments by enclosing it in <sup>...</sup> or <sub>...</sub>

[Eystein-Thanisch]

For scribal additions, we are currently using <add type="insertion" place="above" resp="Hand23"><w>rann</w></add> or <add type="insertion" place="below" resp="Hand23"><w>rann</w></add>' Could it be rendered if that says above it appears as (normal black) superscript and if it says below it appears as (normal black) subscript?

That would work very nicely. But how do we handle additions from the margin or additions made in a gap created by erasure?

[conmaol]

I'm really just experimenting with ideas here – nothing personal!

Accessibility is not an issue for the moment, since this is a private system for Faclair staff. If we do eventually make it available to the general public, we would definitely need to take this into account.

The major advantage we have over traditional printed editions is that we can use colour, though we need to do so sparingly. I think that using green rather than italics for expansions is very effective. I also think that using grey to denote something also looks visually attractive, but I'm not sure what the best function of grey text should be. I wouldn't push the use of colour any further than that!

Remember that we are not limited to just one diplomatic view – we can provide both a traditional monochrome version and a more experimental one using colour. Then people can use the one they feel most comfortable with.

[mnimheachair]

Well, software-wise I don't know how difficult this would be but super if we could do: <add type="insertion" place="margin" resp="Hand23"><w>rann</w></add>

Dip: text text text text [marginal addition] text text text ----gap here --- [marginal addition: ---what's written in the margin---]

Semi-dip text text text text ---marginal addition as normal text--- text text text

[Eystein-Thanisch]

So, in the dip, @mnimheachair , the [marginal addition: ...] would come at the end of the line?

Actually, we currently aren't set up to handle anything other than the briefest insertion (one or two words) from the margin and I have just come across a major multi-line insertion from the margin in one of the texts I am working on. I am going to create a new issue on this shortly...

[mnimheachair]

The major advantage we have over traditional printed editions is that we can use colour, though we need to do so sparingly. I think that using green rather than italics for expansions is very effective. I also think that using grey to denote something also looks visually attractive, but I'm not sure what the best function of grey text should be. I wouldn't push the use of colour any further than that!

Having just looked at the current version of T1 on the DASG server, I must respectfully but strongly disagree with the use of colour instead of italics for expansion. I have my computer working normally at 100% brightness and distinguishing the green from the black is not as apparent as if the same thing was italicised. As editors we need to be transparent about what is expanded and what is written plene in the MS and with the amount of info provided about how certain we are of expansions and what abbreviations are used, I think we are really giving the edition good extra tools for the reader.

However, you do say:

Remember that we are not limited to just one diplomatic view – we can provide both a traditional monochrome version and a more experimental one using colour. Then people can use the one they feel most comfortable with.

Maybe we should ask Willie to take a look at the current set-up with green instead of italics and see what he thinks in case he's massively in favour of it and we should go with both?

Also, am I allowed to screenshot the current T1 on the DASG server and show it to someone if we wanted another opinion? Or, a good person to ask who is already involved in the project would be Robby as he would have experience of many of the different areas converging here.

[Eystein-Thanisch]

I'm really just experimenting with ideas here – nothing personal!

Accessibility is not an issue for the moment, since this is a private system for Faclair staff. If we do eventually make it available to the general public, we would definitely need to take this into account.

The major advantage we have over traditional printed editions is that we can use colour, though we need to do so sparingly. I think that using green rather than italics for expansions is very effective. I also think that using grey to denote something also looks visually attractive, but I'm not sure what the best function of grey text should be. I wouldn't push the use of colour any further than that!

Remember that we are not limited to just one diplomatic view – we can provide both a traditional monochrome version and a more experimental one using colour. Then people can use the one they feel most comfortable with.

Indeed, I was forgetting our power to rapidly produce multiple versions! And I wasn't taking it personally, just wanting to understand all the reasoning involved.

Italics for expansions has the merit of being clearer, more accessible, and also what medievalists will be used to. Also remember that expansions of abbreviations have different levels of certainty (@cert) and it would be good to represent that visually. Green has connotations of wellness and health, implying that there is nothing wrong with any of the expansions. This is far from the case! I've been using colour, the traffic light system, for this, which could likewise be problematic from an accessibility point of view. How to represent gradations in a monochrome setting, however, is currently escaping me...

[mnimheachair]

So, in the dip, @mnimheachair , the [marginal addition: ...] would come at the end of the line?

Yes.

[Eystein-Thanisch]

So, in the dip, @mnimheachair , the [marginal addition: ...] would come at the end of the line?

Yes.

But with some sort of indication as to where it should be placed?

[mnimheachair]

So, in the dip, @mnimheachair , the [marginal addition: ...] would come at the end of the line?

Yes.

But with some sort of indication as to where it should be placed?

Exactly. I think we should write 'marginal addition' in square brackets within the text (or some abbreviation/symbol that will expand to that when one hovers over it to know what it's doing there)

[mnimheachair]

Italics for expansions has the merit of being clearer, more accessible, and also what medievalists will be used to. Also remember that expansions of abbreviations have different levels of certainty (@cert) and it would be good to represent that visually. Green has connotations of wellness and health, implying that there is nothing wrong with any of the expansions. This is far from the case! I've been using colour, the traffic light system, for this, which could likewise be problematic from an accessibility point of view. How to represent gradations in a monochrome setting, however, is currently escaping me...

Are we keeping the hover-over feature which tells of the certainty level? If so, the certainty of every reading would still be available to any reader viewing the text in monochrome or who was unable to see the colours

[Eystein-Thanisch]

Italics for expansions has the merit of being clearer, more accessible, and also what medievalists will be used to. Also remember that expansions of abbreviations have different levels of certainty (@cert) and it would be good to represent that visually. Green has connotations of wellness and health, implying that there is nothing wrong with any of the expansions. This is far from the case! I've been using colour, the traffic light system, for this, which could likewise be problematic from an accessibility point of view. How to represent gradations in a monochrome setting, however, is currently escaping me...

Are we keeping the hover-over feature which tells of the certainty level? If so, the certainty of every reader would still be available to any reader viewing the text in monochrome or who was unable to see the colours

We certainly are. However, on the occasions I have demoed the software for people, the feature that everyone remarks on is the colour-coding that presents them with an immediate "map" of the nature of the manuscript page and text. It would be a real shame to lose that.

Could we have a button to switch colour on or off? And is it an accessibility issue if the monochrome version simply contains less information?

[mnimheachair]

Italics for expansions has the merit of being clearer, more accessible, and also what medievalists will be used to. Also remember that expansions of abbreviations have different levels of certainty (@cert) and it would be good to represent that visually. Green has connotations of wellness and health, implying that there is nothing wrong with any of the expansions. This is far from the case! I've been using colour, the traffic light system, for this, which could likewise be problematic from an accessibility point of view. How to represent gradations in a monochrome setting, however, is currently escaping me...

Are we keeping the hover-over feature which tells of the certainty level? If so, the certainty of every reader would still be available to any reader viewing the text in monochrome or who was unable to see the colours

We certainly are. However, on the occasions I have demoed the software for people, the feature that everyone remarks on is the colour-coding that presents them with an immediate "map" of the nature of the manuscript page and text. It would be a real shame to lose that.

Could we have a button to switch colour on or off? And is it an accessibility issue if the monochrome version simply contains less information?

I really like it too! I'm not suggesting losing that at all, just that if you cannot see the colours the back up of the hover-over feature which tells you there are no/moderate/many problems with this reading provides the same information in a different format and so it is still available to every reader.

However @conmaol and @steviebarrett might have more creative ideas for a monochrome version?

[mnimheachair]

Actually, regarding all of the above. If we keep the traffic-light system for abbreviations, would this not make using green for expansions problematic?

Could we try a different colour (maybe blue?) to see if the expansions work better in that than in green?

[Eystein-Thanisch]

Yes, if we can create multiple ways of accessing the same info, that will make this very robust, in terms of different needs. And yes, let's give blue a shot.

[Eystein-Thanisch]

Hello all. I am going to be offline until Wednesday. Before I go, however, I just wanted to reiterate that I think we should be guided in putting the electronic editions together by current conventions in printed editions and then innovate from there. Martina will be able to advise on this and that is also whence the scheme set out in the User Documentation is largely derived.

Good luck! I look forward to reconnecting once I am back :-)

[Eystein-Thanisch]

Looking around online, I found a way of scoring out text using multiple lines: https://jsfiddle.net/cmcculloh/Ud5L4/

Would this be compatible with the new set up?