Unable to embed OTF version in Microsoft Word

[adunning]

In Microsoft Word, I can embed Junicode using the Font Embedding options under Save to have documents with the font render with Junicode correctly. This is especially key when exporting to PDF, since the Microsoft online service for creating an accessible PDF only works if the fonts are embedded.

Embedding works for me if I am using the TTF fonts, but if I am using the OTF versions from the release, the fonts appear still to be embedded (the file becomes larger) but the resulting PDF does not use Junicode. Is anyone able to confirm this? I would guess that it is a bug in Word rather than Junicode.

[psb1558]

I don't have Word, so I can't confirm this myself, but see here:

https://learn.microsoft.com/en-us/office/troubleshoot/office-suite-issues/fails-embedding-adobe-opentype-font

Looks as if there's nothing to be done until Microsoft fixes their crappy program.

[adunning]

Thank you for confirming! Unfortunately most journals still seem to require Word submissions – it might be worth pointing users who run into this to version 2.209?

[psb1558]

It may, actually, get in the way of my plan to stop supplying the ttf version.

[adunning]

Your call – I know I would drop the TTF version anyway if it were to save enough time to improve the quality of the fonts in other respects.

[kenmcd]

It may, actually, get in the way of my plan to stop supplying the ttf version.

Saw this issue title and immediately thought about your note regarding not supplying static TTFs in the future.

Office applications will not embed OTF fonts. And... Word still does not embed variable fonts. So the static TTFs may still be needed for awhile.

[psb1558]

Words cannot express how much I hate MS Word. As Andrew points out, they've got a nearly complete lock on the publishing industry: everyone who publishes a book or article has got to submit in MS Word (this is why I did camera-ready copy or PDF for five of my books--basically whenever my publisher would let me, and I sometimes chose publishers because they would). And they totally abuse that market power. It's completely insane that the flagship text-processing app for an industry leader in type technology only supports a tiny subset of the OpenType spec and can't do something as basic as embedding an otf font. And that failure does not come with any explanation or apology or promise to do better: their very minimal page addressing the subject basically just tells us to suck it up.

Oh well, there's nothing I can do about it. End of rant.

[alerque]

I feel your pain, that is not an unhinged rant it's just baseline facts. Adobe is just as bad on the design side, they still can't do basic things right in shaping basic Unicode input in Photoshop/Illustrator/InDesign by default. If you jump through some hoops and use a non-default input composer you can get much closer to sanity, but even that they manage to botch. And it just goes on like that year after year after year. But yes, Word is a bane for anybody that knows how publishing can/could/should work.

[psb1558]

@alerque: Absolutely. I've completely given up on InDesign for any purpose other than testing fonts, and now that I'm retired it's getting hard to justify the expense. I cannot understand why Adobe won't get behind the standard it had a big part in developing and come up with a simple UI for applying OpenType features--especially when the existence of Roland Dreger's open-type-features script shows that it could be done. Or why they can't come up with a decent shaping engine.

For me, it's been true since around the beginning of this century that if I want to do anything serious, I turn to XeTeX or LuaTeX.

[kenmcd]

What Word or Office apps support or do not support is insane. About half the OpenType features in Aptos, their new Office default fonts, are not supported in any of the applications. Same with most of the core fonts, supplemental fonts, Office fonts, and the cloud fonts. It make no freaking sense.

Let's not leave out Affinity from the "doing dumb stuff" list. Automatically replacing characters without any OpenType code. Legacy ligature code points replace individual characters. (Luc(as) called them out on that one.) The other day I helped a user where a long s substitution done with OpenType features results in an actual irreversible character replacement. Totally ######-up their PDFs. I used Junicode as one of the demo fonts to show how this was happening. Fake small caps cannot be turned-off. (my pet peeve) Any space character replacements (such as for tnum) breaks the line-breaking - so basically the entire text is one block without any spaces. Then, like any block of run-on text, it just breaks it in odd places. So the user wonders why their "justified" text looks crazy. People bitch, I bitch - no response. Don't even get me started on the variable fonts dumb stuff...

Sigh... what is wrong with these people? (Adobe, Affinity, Microsoft)

Peter, I fully understand and appreciate your frustrated rant about Word stupidity. With you 100% on that.

OK. My turn to rant. I feel better now.

[psb1558]

@kenmcd: Sad. I thought Affinity was doing better. I knew about their failure to support variable fonts, but figured there was just a lot on their to-do list, and they would get around to it eventually.

We should, however, celebrate the ones that have gotten it right, more or less. LibreOffice, which has for a long time had good OpenType support and recently added support for variable fonts (though they still haven't gotten around to fixing the wretched font handling in the Mac version). LuaTeX, which since TeX Live 2023 has, as far as I can tell, done everything right, as long as you remember to use the amazing Harfbuzz as renderer.

Are there others?

[adunning]

Variable fonts did not work in the past, but I just tried embedding Junicode VF using Word 16.87, and amazingly it generated a PDF from that with Junicode displayed. It's a bit wonky: my resulting PDF file is much larger (3.3 MB rather than 940 KB with plain Junicode TTF; the source DOCX is 7 MB rather than 1.2 MB), and Junicode VF Light is appears instead to be rendered with the regular weight, but it's probably good enough for most people.

[psb1558]

Are you able to get any styles (at least bold and bold italic)? Or is it just using the default outlines in each of the two font files? Sounds as if it is dumping in every darn thing in the font, not subsetting or anything.

[adunning]

Bold and italic work, but nothing else (and Bold renders a touch differently). Here is an example showing Word on the left and its PDF output on the right:

I have also found that the fonts are not updated on subsequent saves after turning on the 'Only embed the characters used' option, but small file sizes are broken anyway.

Curiously pdffonts shows that it is trying to embed a version of the font for each weight:

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BCDEEE+___WRD_EMBED_SUB_1415         CID TrueType      Identity-H       yes yes yes      5  0
BCDFEE+___WRD_EMBED_SUB_1415         TrueType          WinAnsi          yes yes no      12  0
BCDGEE+___WRD_EMBED_SUB_1415,Italic  CID TrueType      Identity-H       yes yes yes     14  0
BCDHEE+___WRD_EMBED_SUB_1415,Italic  TrueType          WinAnsi          yes yes no      19  0
BCDIEE+___WRD_EMBED_SUB_1420         CID TrueType      Identity-H       yes yes yes     21  0
BCDJEE+___WRD_EMBED_SUB_1420         TrueType          WinAnsi          yes yes no      26  0
BCDKEE+___WRD_EMBED_SUB_1422         CID TrueType      Identity-H       yes yes yes     28  0
BCDLEE+___WRD_EMBED_SUB_1422         TrueType          WinAnsi          yes yes no      33  0
BCDMEE+___WRD_EMBED_SUB_1424         CID TrueType      Identity-H       yes yes yes     35  0
BCDNEE+___WRD_EMBED_SUB_1424         TrueType          WinAnsi          yes yes no      40  0
BCDOEE+___WRD_EMBED_SUB_1426         CID TrueType      Identity-H       yes yes yes     42  0
BCDPEE+___WRD_EMBED_SUB_1426         TrueType          WinAnsi          yes yes no      47  0
BCEAEE+___WRD_EMBED_SUB_1426,Italic  CID TrueType      Identity-H       yes yes yes     49  0

[psb1558]

Well, that's progress, anyway. The export problem is probably one of those things they can fix fairly easily once it comes to their attention.

I forgot, when I replied before, that variable fonts cannot at present be embedded in a PDF. Instead, the app has got to generate a subsetted static font for every style used in the document. The Junicode Manual PDF contains thirty-five subsetted fonts, generated from the two variable font files! I hope that Adobe will sooner or later come up with a way to embed variable fonts, but given the speed with which they typically move, I'm not counting on it happening anytime soon.

I see, at any rate, that Word is actually subsetting the fonts before embedding them. That's what should happen, so good. Credit where due.

[adunning]

I've reported the problem via MS Word's internal mechanism. For now, hopefully this is working well enough that it won't derail your plan to retire the TTF version.

[kenmcd]

Wow. This appears to be progress. But it does look like the condensed examples are actually the normal width.

I have not tested Word variable embedding to PDF in quite awhile. Think the last time was with Bahnschrift (which did not work).

Think I still have a .docx with all the Junicode instances. Have to test that with Word in Office 2024 (I have in a VM).

[kenmcd]

PDF export of Junicode Variable does not appear to be working in Word 2024.

Ran a test on 2024-06-10 from LibreOffice using v2.208 fonts. Included variable TTF and static TTF fonts side-by-side. All looks good. And the VF and static look the same.

Just tested again in Word 2024 on Windows 11. Includes variable TTF and static OTF fonts this time. The Variable fonts do not look right other than the Normal width. Letter spacing and/or kerning is not correct. So embedding a variable font in a PDF from Word 2024 is not working.

And oddly the line-height changed on the OTF statics - it is set at 1 line - and Use Typo Metrics is On in the fonts. So have to figure-out what is going on there.

EDIT: I just realized it exported the OTF statics from Word 2024. I had the OTF versions installed to test in Affinity and did not think about it. Have to see/confirm if Word 2024 can now embed OTFs in a PDF - appears it does here.

[psb1558]

Yeah, it's not looking good. But I've never seen an implementation of variable font support that didn't start out buggy. Variable fonts are hard!

Can I ask you both about your versions of Word and the systems they're running on? My understanding is that Word for Mac and Windows are very different pieces of programming. @kenmcd, if I guessed that you're running Windows in that VM, would that be right?

[kenmcd]

Yes. Example above is Windows 11 and Office 2024 Preview. Both have all current updates.

Got ahold of Office 2024 for Mac a few days ago. I will get that installed and see how it goes with this too.

Note: printing the variable fonts seems to work, but embedding in a PDF does not.

Regardless it looks like it would be good to do some more current testing.

The LO test I did above on 2024-06-10 was to check the current state of variable support in LO. Better than the last time a few months ago. (I did find one odd thing with Junicode VF when doing that test - need to take a closer look and will post).

So I will check this stuff over the next few days.

[kenmcd]

Hi Peter, I did check this last week in Office 2024 for Mac - and had some issues. Going to update Office 2024 for Mac to v16.87 (from v16.86) and check again. Then check out what is happening with the VF.

Just found out today that the different line-height issue in Word on Mac may be alleviated by including a STAT table in the static fonts (like GF is doing now). Just saw that fix for Word on Mac mentioned in another font repo so I need to find the source of the recommendation.