u for v, i for j, Other transposed letters/printings..

[afarlie]

A related query to the previous discussion started by another contributor about terminal j in roman numerals How common in manuscripts is it to see v for u , and i for j , in text vs numerals?

Some earlier versions of the Latin alphabet as I understand it, did not necessarily use J(j) and U(u), I also note that some printed works ( The example I am recalling is a volume of Ruffhead's Statutes) follow this in printing some older documents, or transpose the usage. Hence you see for example Iames for James, and Jacbous for Iacbous in some printings.

Would it be possible to have a means to set the transposition, whereby this I(i) for J(j) m V(v) for U(u) rendering can be replicated, whilst still being able to have the meaning of a given word represented for text searches?

This also makes me wonder if there are other transposed letters used in certain printings given the comparative frequencies of the respective letters in a type.

Although a transposition of glyphs rather than letters, I've seen z used to represent a yogh, in a printing of Scottish Statutes from the 17th century.

In Statutes of the Realm, an insluar g may also be used to indicates this , or to represent what it calls a 'y' sound - (see also - https://en.wikipedia.org/wiki/Yogh#Middle_English)

I've also seen W printed as vv.

[psb1558]

In medieval MSS and early printed books v and u are variant shapes of the same letter, and likewise i and j. The rules governing the distribution differ from time to time and place to place. For example, in pre-Conquest MSS V/v is mostly for capitals or numbers, but in, say, early printings of Shakespeare v is used in word-initial position and u everywhere else:

For example, in the 1609 quarto of Shakespeare's sonnets, lou'st, receau'st, but vnion. (Notice also ioy for modern joy: j is not yet a separate letter.)

Yes, in late Middle English MSS z and yogh are sometimes the same letter-shape, and the English w-sound is dealt with in a number of ways through the centuries. The printer of the First Folio seems not to have had a W in the size he wanted, and VV was an okay alternative:

But as to the practicalities, a font can represent this kind of variation if the rules aren't too complicated. For example, Junicode includes rules for the distribution of s and ſ in early printed books, but only for English and French, in which the rules are pretty simple. I gave up the idea of doing anything about German because the rules were too complicated. You could probably write a script to do the job in any traditional programming language, but OpenType isn't designed for that kind of thing.

So the answer for whether variations like u/v, i/j, z/yogh and all the w's can be handled in a font is yeah, probably, depending on how much you want:

• It is easy to make (for example) a variant of j that looks like an i and include it in one of the Character Variant features, leaving it to the user to mark up the text appropriately.
• It's harder, but still possible, to do stuff like Shakespeare's u/v, which vary by position. But when the rules that govern the distribution of u/v vary by era and region, which rules do you use?
• Some things are impossible, or at least not worth the effort.

[afarlie]

I'll leave this discussion open, because I am wanting to hear what other Junicode users have to say as well.

J and j variant that looks like an I (ior i) respectively , is as you say straightforward.

Split W(or w) is a a variant for W or w, again reasonably straightforward. ( And for my purposes would be a change in one template https://en.wikisource.org/wiki/Template:Vv)). (example in use - https://en.wikisource.org/wiki/Page:A_View_of_the_State_of_Ireland_-_1809.djvu/334)

As you say trying to code rules for every language/era in respect of u v wouldn't be practical. Hence my suggestion was that it's a character variant with the user setting an appropriate set of CSS classes to do the switch. Wikisource already uses an approach of a wrapped span for things like long s , and certain abbrevations like (us, et) etc , per previous recomendations.

In HTML you'd then do something like :
<span class="typographic_initial_j">j</span>oy..
<span class="typographic_initial_u">u</span>nion ...
lo<span class="typographic_medial_v">v</span>st ...

And set up CSS classs for .typographic_initial_j .typographic_initial_u .typographic_medial_v and so on.

However, given the concern was about searching , I'm not sure that approach makes it easier either. Is there anyone here that knows about how search engines strip HTML tags when analyzing content?

[psb1558]

I don't know anything about WikiSource templates, but I'm thinking about what OpenType is good at vs. what CSS is good at. OpenType is very good at contextual substitution, e.g. "This variant at the beginning of a word, but that variant inside," or "this variant when preceded by f but that variant following z. It's also good at language-specific variants, so if 18thc printing in English uses one distribution of u/v but printing in Latin uses another, OpenType can handle that. In CSS, as I understand it, it's awkward.

But I wonder what you're after with these individual variants. Do you want an underlying text that reproduces the forms found in the text with an option to view the original or a normalized text? (some good online editions present this option, or even different grades of normalization). Then handling u/v or any other variant at the font level starts to look sadly inadequate—a half measure or a quarter measure. Think of Shakespeare's "receau'ſt" or "receauſt" for "receivest." OpenType can easily make the u searchable as a v, but what good is that when many searches are going to fail because of the rest of the pre-modern spelling?

For the kind of normalization I'm thinking about, I'm a fan of the TEI approach, which would go like this:

Why
<choice>
  <orig>lou'ſt</orig>
  <reg>lovest</reg>
</choice>
thou that which thou
<choice>
  <orig>receauſt</orig>
  <reg>receivest</reg>
</choice>
not gladly,

where the original reading is in the <orig> tags and the normalized or regularized reading is in <reg>. That kind of solution takes care of all problems at once. Can WikiSource do something similar?

[afarlie]

I like the TEI approach which I can implement in a templated form.

See:- https://en.wikisource.org/wiki/Page:Public_General_Statutes_1896.djvu/35 where I display the expanded version as a 'title' for a span.

I could also use ruby tags to display the expanded abbreviation above the original

No changes are needed to the font itself therefore.

[psb1558]

I think that's a good choice. It's infinitely flexible where a font-based solution is not. And there's only so much a font can do.