COMBINING COMMA ABOVE RIGHT?

[jsbien]

Below I enclose 3 characters from a 16th century font:

In my paper https://www.researchgate.net/publication/380409810 you can see how these characters look in other fonts. You can also consult the font tables at the repository https://github.com/jsbien/early_fonts_inventory.
The fonts come from Polonia Typographica Saeculi Sedecimi which contains 75 font tables and almost 50 of them contain at least one character presented above, hence it does not seem to be a marginal phenomenon. Their occurence in texts is a different matter (some examples are given by Erin Blake at https://www.folger.edu/blogs/collation/brevigraphs/).
We have already discussed how to encode them on two occasions: #134, #233. You suggested the use of COMBINING SHORT STROKE OVERLAY and at that time it seemed OK for me.
After a closer look at the matter I think now that a convenient and natural way to encode them would be to use U+0315 COMBINING COMMA ABOVE RIGHT. Of course it would be nice to adjust somehow the resulting shape to make it closer to original.
What do you think about it?

[jsbien]

More on the topic: https://www.researchgate.net/publication/385781428_Identifying_glyphs_in_some_16th_century_fonts_Hochfeder%27s_font_no_2_a_case_study.
You can also consult all the font tables in a 137MB PDF document: https://github.com/jsbien/early_fonts_inventory/tree/main/summary.

[psb1558]

Sorry to have taken so long to respond to this: I found it a little hard to digest. I'd be glad to add the letters with upward-curving stroke, but accessibility is an issue, since there are very few OT features available. I get it that U+0315 looks like the stroke of these characters, but as U+0315 has another use, I'd need to use an OT feature to distinguish it, and I can't think what that would be.

On the other hand, after we discussed the matter I added this glyph as a variant of U+A749 Latin Small Letter L with High Stroke:

It is on cv64, but also on cv24 as one of several variants of l.

Now, unfortunately, I am out of cvNN features, but I could make these variants of the base letter, as I did with l + cv24. Alternatively, I could make them variants of U+0180 ƀ and U+0127 ħ, accessible via salt Stylistic Alternates, which I am using for new alternates for which cvNN features are not available. salt, like cvNN, is a one-for-one feature: it isn't suitable for substituting glyph for glyph + diacritic (like h + U+0315).

To speak generally, adding characters to Junicode is becoming a big problem, when the characters are not either Unicode-encoded or variants of a basic Latin letter. I don't like using salt for new variants: it's messy and hard to document. I am thinking that soon I may declare Junicode finished, stop taking feature requests, and leave it for others to fork and develop further if they like.

[jsbien]

Sorry to have taken so long to respond to this:

No problem. Looks like nobody need these characters now and my interest in them is purely theoretical :-)

To speak generally, adding characters to Junicode is becoming a big problem,

I think tags are great :-)

I am thinking that soon I may declare Junicode finished, stop taking feature requests, and leave it for others to fork and develop further if they like.

I will fully understand such decision. Thank you very much for your work!