v. 1.066 Greek glyphs reformatting as small caps

[ischaap]

Testing v. 1.066 static TTF at medium weight in MS Word.

I'm noticing some odd behaviour with Greek glyphs. When entered in lowercase using their codes or even when copy/pasted, they seem to reformat themselves as small capitals. If placed next to punctuation, they revert to their expected forms. Alpha and gamma don't seem to be doing this, but:

etc., etc. The reversion to lowercase also occurs if the punctuation is adjacent to a second instance of the same Greek glyph, and it can also be separated from the Greek glyph by one or more spaces. It's not possible to use the case selector in Word to change to the small cap glyphs back to lowercase or to uppercase.

This behaviour also occurs with LATIN SMALL LETTER SCHWA U+0259, but in this case an adjacent latin glyph will also allow the reversion to lowercase. IPA glyphs do not allow reversion, though:

Finally, I'm also finding that certain hooked glyphs also reformat as small capitals if placed next to the Greek glyphs, but again, placing punctuation next to them will revert them to lowercase. I didn't do an exhaustive search, but I've noticed this with:
LATIN SMALL LETTER B WITH HOOK U+0253
LATIN SMALL LETTER D WITH HOOK U+0257
LATIN SMALL LETTER G WITH HOOK U+0260

Edited to add that it's hilarious that this bug (or whatever it is) is the only way to get true small caps in Word! :D

[psb1558]

This is bizarre, but there is, I believe, an issue somewhat like it in the archives somewhere. Here's what was going on in that case. The person who reported the issue had done a lot of formatting and reformatting of text in MS Word, and when I peeked into the Word file I found that the formatting was a terrible muddle. I didn't have a copy of Word to test in (I still don't), but I asked the person to copy the text out of Word into a plain text editor (like Notepad in Windows or TextEdit in MacOS, or any programming editor, like Emacs or Visual Studio Code). Then copy the text from the plain text editor onto the clipboard and paste it into a fresh Word document and change the font to Junicode.

This is radically sanitizing the text. Try it out and report what happens. If the problem persists, I'll look into it farther.

[ischaap]

I did as you suggested -- pasted the text into Notepad to sanitize, recopied, and then pasted into a fresh .docx -- and it did work as long as the Greek glyphs were at the beginning of a line. But when they were inside running text, they continued to exhibit the behaviour I described initially. Likwise if I added or changed any text following the line-initial glyphs.

Schwa meanwhile reformatted itself as a small cap no matter where it was, unless adjacent to punctuation or to other characters from the regular latin range (but not characters from the IPA range). But of course there are cases you won't have punctuation or latin-range characters nearby:

versus (with punctuation added to force the schwas back to lowercase):

Even stranger, when I directly keyed the any of the Greek glyphs or schwa into the same fresh document using their Unicode points, either within running text or even at the beginning of a line, they also showed the buggy behaviour.

[ischaap]

Looking at the examples in my last post, I've just realized that this issue affects LATIN SMALL LETTER OPEN E U+025B and LATIN SMALL LETTER OPEN O U+0254 as well:

[kenmcd]

Not seeing this in Word 2019 with v1.067 Medium static.
Seems to work as expected.

[ischaap]

@kenmcd thanks for checking!

In case it's of help to @psb1558 in looking into this, I'm using Word for MS 365 version 2307 build 16626.20068. So possibly something has gone wrong in Word 365 -- though I should add that I don't see this behaviour with any other font.

[psb1558]

The only version of Word I have access to is on my wife's Mac, but I will test there.

I get it that Word is exhibiting this behavior only with Junicode—but I would guess that few other fonts have so complicated an OT setup. Junicode's OT programming will be going through pretty rigorous testing, though, and it may be that, as we locate and fix problems there, your problem will be fixed.

At present, Junicode appears to be working properly in every other application where I can check.

[kenmcd]

@psb1558 I also tested it in the FontCreator OpenType Designer.
It has two shapers - their own, and an alternate (is HarfBuzz I think). Tested with both.
Entered the various character sequences above, and then activated various OpenType features (calt, ccmp, dlig, liga, smcp, ssXX, etc., etc.) - and they all worked as expected.
So... ???

[ischaap]

An update on this issue for v. 2.000beta1 in MS Word for 365. The issue as originally described seems to have been resolved -- excellent!

However a new issue along the same lines has cropped up in its place. The Greek letters, the hooked letters, and U+0259 schwa (but not the other IPA glyphs that were previously affected) now reformat to small caps when italicized. Various punctuation marks still force them back to lowercase.

[psb1558]

Could you try an experiment for me (since I can't do it myself)? Uninstall all of Junicode except for the traditional four styles: Regular, Italic, Bold, BoldItalic. Sanitize your text as outlined above (copy into plain text editor and back into new Word document), and then see how it works.

The most bizarre aspect of this whole issue is the way Word is producing small caps when Word does not support small caps! There is literally no way to make Word access the small caps included in most text fonts these days: instead it scales capitals down, producing thin and spidery looking small caps.

[ischaap]

Yes, happy to help. Unistalled everything except Regular, Italic, Bold, and Bold-Italic, copied the text into Notepad, copied from Notepad into a fresh .docx, and unfortunately, same results.

Same results too if I key them in by their Unicode points into that fresh .docx.

Please let me know if I can try anything else for you!

[ischaap]

Whoops, I spoke too soon when I said earlier that this new italic issue wasn't affecting LATIN SMALL LETTER OPEN E U+025B and LATIN SMALL LETTER OPEN O U+0254 -- it is.

[psb1558]

Oh well, worth a try. Thanks very much for performing my experiment, which was about (you probably guessed) whether the name-length issue was at all connected with this formatting issue.

Apparently it is not.

[ischaap]

You're most welcome!

And now I've just noticed another affected character: with b with dot below, but not other letters with dot below:

I feel like the continual bearer of bad news, but, truly, I hope these reports are helpful and not irritating! Do let me know if there's any thing else I can try.

[ischaap]

Update for v. 2.000beta2. Things have now reverted to the situation described in my first three posts in this thread -- which is that a selection of Greek and IPA letters are reformatting as small caps unless next to punctuation. The italic b with dot below is behaving normally once again.

Actually, while I say the situation has gone back to how it was when I first described it, I'm now noticing some additional wrinkles. They may or may not have been there initially. When I return to my document illustrating the problem, if I add a period after the upper, small cap, glyph, in the example chi, it now turns it into a full capital. If I click undo, it goes to lowercase (leaving the period there). But after doing this, adding and removing the period just toggles the chi between lowercase and small cap, though I can, as long as the period is there, use Word's case selector to toggle between full cap and lowercase. Once this stage is reached, adding a period won't make the chi full cap again unless I close and reopen the doc.

The behaviour seems really complicated, and I apologize because I know I'm not describing it very coherently at this point.

[psb1558]

Don't apologize--you've actually given me some valuable information, namely that updating from beta1 to beta2 changed the behavior. Since there weren't many changes between beta1 and beta2, and we have already identified some issues with beta2 . . . well, it's useful information.

[ischaap]

Quick update on this issue for 2.000beta7 static ttf in Word for 365. The dotted letters and unicode characters seem to be behaving normally. Most of the behaviour for the Greek letters seems to have calmed down, at least in isolation. However, in running text there is still some acting up, and from after some experimentaton it seems that nearby footnote indicators are involved in some way.

[psb1558]

Okay, I finally fired up my son's old gaming computer (Windows 11 Home) with MS Word (I don't know how to find out the version--the UI confuses me totally) on my wife's account (I've blacked that out for privacy). There was some problem with the license, but it let me type a bit of Old English and paste (a bit of New Testament text from some website), and here's what I got when I set the font to "Junicode" (static TrueType version):

I spent some time trying to make it misbehave: changing to italic, to bold, to Condensed, adding a footnote . . . and it persisted in working well.

I'll try out the otf version next.

The one important thing that's different with the version I'm testing is that I've corrected a problem with the style names (see #224). I doubt that it would produce the kind of problem you're seeing, but I'll post a new corrected version as soon as I've got it built.

[kenmcd]

MS Word (I don't know how to find out the version--the UI confuses me totally)

File > Account > About Word
That will open a dialog box with the version info.
And, yes, having to go to "File > Account" makes no ******* sense.

[ischaap]

Thanks for checking, @psb1558. Using 2.000beta8 I began to reproduce your text, keying it into a fresh document, and it didn't give me any trouble either, so far as I got.

I thought the verse numbers might be preventing the behaviour, but eliminating them caused no change, as you can see in section no. 1 below -- so long as the initial capitals remained. But with the words at the beginning of a line, when the capitals are deleted the whole words went to small caps (no. 2). When I re-pasted, highlighted the full capital initials, and used Character > Insert to try to switch to the lowercase equivalents, the whole word also went to small caps (no. 3).

In no. 4, I pasted χριστου̑ a few times -- it pasted correctly. When I inserted various punctuation marks between chi and rho, the result was a full cap chi. Clicking undo does however revert the uppercase to lowercase.

In other contexts, small caps are produced (note the footnote indicator below in the first paragraph only). I can find no way to revert or change the small caps that appear in these situations:

If you're not able to produce something similar in your version of Word, I wonder if the problem is specific to the way Junicode interacts with Word for 365?

[psb1558]

I tried what produced your problem, step by step. Still can't reproduce. I have MS 365, v. 2307.

The really bizarre thing here, if you know something about what goes on inside fonts, is that you're getting the small cap equivalent of lowercase letters, as if the smcp "Small Caps" feature were turned on, and not some random character. The only way that can happen is (1) applying smcp to a lowercase letter or (2) applying c2sp to an uppercase letter. The font can't do that by itself; only the app (or a system routine called by the app) can do it.

MS Word (infamously) does not give users any way to turn on smcp or c2sc, but instead produces pseudo-small caps by scaling down a font's capitals. What you are seeing are true small caps, not scaled capitals. So how/why is Word turning on the smcp feature to produce small caps here? I can't make any sense of it.

At all.

[ischaap]

Ah, I didn't realize yours was Word for 365 too. Mine is also v. 2307, specifically build 16.0.16626.20170 (32-bit). Sounds like it's just me then. I wonder what on earth is going on in my system?

I always thought it would be nice to have true small caps in Word, but not like this, haha!

[psb1558]

I've created a new release (2.001) that fixes a significant bug in MS Word. I suppose it's too much to hope that that fix will resolve this issue as well, but do try it out.