Weight/spacing combo issues

[ischaap]

I'm finding that at medium weight and regular spacing, italic and boldface text isn't exporting correctly from MS Word to pdf. Italics produce gibberish, while boldface text appears unbolded.

Example text in Word:

Same text exported to pdf:

The result is the same whether exporting from within Word, converting within File Explorer, or converting within Adobe Acrobat.

Meanwhile things look fine exporting to pdf at, for example, light weight/regular spacing. Here's the pdf output:

What caught my eye is that, after installing all of the Junicode Two Beta fonts (38 plus the one italic with hinting = 39), some of the weight and spacing combinations seem to be missing in Word's font drop-down (and note that SemiExpanded is listed twice, once in roman and once in italics):

To try to understand which weight/spacing combinations are unavailable in the Word font drop-down, I made the little table below. Combinations that aren't accessible but that I presume should be are entered as 'n/a'. It also shows that the Regular-weight/Regular-spaced italic isn't working, and that using Word's bold local styling (Ctrl+B) only approximates (as shown in parentheses) what I imagine is the intended Bold-weight/Regular-spaced roman and italic, which don't seem to be available. I'm guessing this is why the medium-weight boldface didn't export to pdf in the example above but the light-weight boldface did (assuming that applying boldface local styling to the Light-weight/Regular-spacing in Word applies the Junicode Medium-weight/Regular-spacing, which is available, while applying boldface local styling to the Medium-weight/Regular-spacing applies the Junicode Bold-weight/Regular-spacing, which is not).

Another thing I think the table shows is that what's labelled in the drop-down as 'Junicode Two Beta Expanded' (which I take to mean Regular-weight/Expanded-spacing) appears actually to be applying an Expanded spacing in either Semibold or Bold, but I can't quite tell which. Finally, it also seems to me that what's labelled 'Junicode Two Beta SemiCondensed' in the font drop-down (ostensibly Regular-weight/Semicondensed-spacing) might actually be applying SemiCondensed Medium.

Sorry that this isn't very methodically tested or reported -- I would have liked to test in InDesign as well, where there's more control, but my sub is lapsed at the moment. It occurs to me too that some of these items might be known issues as this point in the beta -- but anyway, I hope reporting them is helpful nevertheless.

[psb1558]

Are you using the static ttf, static otf, or variable ttf version?

[ischaap]

I'm using the static ttf version.

[kenmcd]

You cannot have both the Italic and the Italic-hinted installed at the same time. They have the same names internally and will cause name conflicts - which can cause unexpected results.

Not all of the styles are available in the current static fonts.

3. Condensed - 6 styles - No Bold or SemiBold
4. SemiCondensed - 6 styles - No Bold or SemiBold
5. Normal - 10 styles
6. SemiExpanded - 8 styles - No Light
7. Expanded - 8 styles - No Light Same in the VF not all the expected instances are there.

Many of the names are too long and will not fit in the Word font list. This can cause fonts which do exist to not be listed. Example: Bahnschrift SemiLight SemiCondensed does not appear in the Word font menu - too long. IIRC three of the Bahnschrift instances do not appear for this reason (which is really dumb with one of their own fonts). And Bahnschrift does not even have to include "Italic" which would make it worse (as there are no italics).

Many of the names are also too long for the PostScript Name (which is used for embedding in the fonts in the PDF). This results in truncation which then may make the field the same for multiple fonts. This can lead to font cache corruption - which can result in garbage being embedded in the PDF. Like your example image above.

Once you remove "Two Beta " from the family name that will help. Stuff like SemiCondensed SemiBold is going to have to be shortened. All the styles name lenghts need to be reviewed,

Peter, you may want to consider separating them by widths so the font menu lists are more organized. InDesign sorts them for you using the OS/2 table width and weight settings, so it hides the mess. But in LibreOffice, Word, etc. it is kind of a mess.

So @ischaap you are correct this is definitely still beta, and a few things are going to need some attention before re-testing. Too much going on here to have a simple fix. The missing instances/styles need to be added. The names need to be shortened. Then re-evaluate in Word, LibreOffice, InDesign, etc.

[kenmcd]

@psb1558 Another thought... Are you planning submit Junicode v2 to Google Fonts? Because that has some other names, instances, etc., considerations.

[psb1558]

I was going to mention the name length issue in Windows apps. That will partly resolve itself once the name changes from "JunicodeTwoBeta" to simply "Junicode," but there will still be names that exceed the max length of 31 characters. It may be possible to condense some of the style names.

Investigating this, I did find one incredibly stupid bug--namely, that I had the wrong "width" values for all the SemiExpanded Italic styles. I have fixed this, and now it works fine in InDesign:

As I recall, questions about the order of instance names in font menus have come up more than once in the Glyphs forum, where the answer seems to be that font makers have no control over that at all: apps order instances in their menus in ways that seem good to them.

LibreOffice for the Mac has big problems with extended font families. I keep hoping for a fix (bug reports have been languishing for years), but there has been little improvement.

I have no access to MS Word, so I can't test there. Font handling in Word is notoriously brain dead, and I have long since stopped trying to provide workarounds for Word users.

[kenmcd]

LibreOffice on Windows and Linux do now work correctly if the style groups are all OK. Don't know about the Mac now; but the way it did apply its own weight sorting was totally bizarre (I remember the multiple missing Medium font bug posts). That was a Mac issue, so it may be gone now.

But making the style groups match the typographic family groups does make the families the same on all platforms. Which is another reason for the by-width groups/families. Makes it easier for users cross-platform. And the font menues sort better.

[psb1558]

It looks like "Style Groups" are a FontLab thing. I'll have to find out if it can be done without FontLab.

[kenmcd]

It looks like "Style Groups" are a FontLab thing. I'll have to find out if it can be done without FontLab.

No. Glyphs has the same thing. Just organized different. It is still NameID 1 and NameID 2. And a few check boxes for the flags. Just looked at this in Glyphs in a macOS Ventura VM for Inter. Kinda convoluted. It is a lot easier in FontLab. But the Google Fonts folks do it all the time in Glyphs.

[ischaap]

@psb1558 and @kenmcd, thank you both for your replies, and @kenmcd thanks for the tip about the two italic fonts. I'll make sure to remove one of them.

I can't pretend to understand all of the discussion but I gather that some of the issues I was describing in this thread are because of the way long font names impact functionality in Word and font embedding in pdfs, but that the names will eventually be shortened after beta -- though some may still be too long unless radically renamed. Makes sense!

I'm glad things are looking good in InDesign, since that is ultimately where I'll be using Junicode Two. As long as it's functional there and correctly exporting to/embedding in Acrobat, I'll be very happy. If I have to accept that test typesets in Word may always be a bit rough, that's understandable given Word's limitations.

[kenmcd]

I'm glad things are looking good in InDesign, since that is ultimately where I'll be using Junicode Two. As long as it's functional there and correctly exporting to/embedding in Acrobat, I'll be very happy.

That may not be the end of it. The limitations on the PostScript Name is for compatibility with PostScript printers - some of which still have very old software. So it may work exporting to PDF, but if someone wants to print the PDF on a PostScript printer, or send it to a service bureau for printing - it may not work properly.

[psb1558]

Adobe has recommended style name abbreviations: these are reported in the Glyphs naming tutorial.

• Bd = Bold
• Cn = Condensed
• Ex = Extended (could be used for Expanded, I guess)
• It = Italic
• Lt = Light
• Md = Medium
• Rg = Regular
• Sm = Semi-
• X = Extra

If I use these, it will certainly solve the Windows name length problem. The cost, of course, is less transparency for Mac and Linux users, who won't have problems related to longer names.

[psb1558]

Peeking into Inter, I see, e.g.

name 1: Inter Light
name 2: Regular

and Junicode:

name 1: Junicode Two Beta Light
name 2: Regular

or

name 1: Junicode Two Beta SemiExpanded Medium
name 2: Regular

What am I doing differently?

[kenmcd]

The structure of the style groups in the statics is working as is. So no need to be concerned about that. Just the names are too long. Once the names are shortened they should work fine in both LO and Word.

They are different in the VF, but again working as is.

Note: in the Inter statics the Display optical size was moved to a separate typographic family and the style group was matched to this. So users on Mac and Windows, and Linux, all see the fonts grouped the same way in the font lists. That is what I am suggesting for the widths here. Easy in FontLab; more difficult in Glyphs.

[kenmcd]

Regarding the abbreviations, usually you do not have to go so extreme as only two-characters. "Junicode" is not real long so you have some leeway to go a little more readable.

I think those Adobe two-character recommendations are from the Type 1 days - and basically for the PostScript Name. The visible names do not have to be the same as the PostScript Name. It can have more abbreviations to be shorter.

[psb1558]

Is the 31-char limit just for the postscript name?

[kenmcd]

Is the 31-char limit just for the postscript name?

No. That is for the Word font menu (and other MS apps). I have actually counted 32 showing, but I think that may be the extra space - the font menus supposedly show the Full Font Name (name ID 4) - so name ID 1+2 with a space. Have not looked at this in awhile. 31 is the recommended length (1+2 and 16+17).

When LibreOffice recently added variable font support for named instances, I immediately tested Bahnschrift and it did show all of the instances, but they did have some sort of abbreviation applied (which is not in the font). So not sure exactly what is being done there.

For compatibility with old PostScript printers/interpreters it is actually 29 characters (eek!). I think the source of that is a really old Adobe Technical report (5088, Font Names). "For compatibility with the earliest versions of PostScript interpreters and with the file systems in some operating systems, Adobe limits the number of characters in the FontName to 29 characters." A much later report (5902, Generating PostScript Names for Fonts Using OpenType Font Variations, 2016) talks about "not exceeding the 127 character limit." So Adobe itself may no longer be concerned about this. Dunno. Users may still run into these really old PostScript interpreters even in modern printers (according to Adam Twardoch).

The FontLab 7 Manual still recommends 31 and 29. https://help.fontlab.com/fontlab/7/manual/Font-Naming/

[psb1558]

<rant> Sheesh. Microsoft drives me absolutely up the wall. Microsoft Typography is totally brilliant, leading the way in the development of font technology and capably guiding the OpenType spec (even if I disagree with some decisions). And meanwhile, every one of their apps is a typographical disaster (I leave aside Edge, which seems to me very good). The 31-character limit is a case in point. We've had extended font families for a number of years now, and they need long descriptive names. Microsoft could fix this idiotic limitation (I don't say it would be easy—I think of it as like the Y2K problem of 24 years ago), but they seem not to care.

Honestly, I don't think Adobe is much better, though they are also major font technology leaders. I don't care about ancient PostScript interpreters: it's not Adobe's fault that they're still hanging around. But their rollout of VF support in the Creative Suite was very rocky. Also, Junicode has detailed descriptions of the cvNN features (parallel to the names of the ssNN features) ready to go, and it's all commented out because a bug in the Creative Suite disables all OpenType features if cvNN names are present. I've pointed this out to them, but they're too busy building AI into their apps (to enable little Johnny to better steal copyrighted material) to bother with fixing their broken font handling. </rant>

Oh well, I'll figure out how to compress the names. In the worst case, I think I only have to shorten by some seven characters.

[kenmcd]

Yeah, the MS font handling is pretty dismal. I was hoping the recent "new" font list interface would make things better, it did just a little. I think that so much of the font handling is woven throughout not just the user apps we see, but also in the all the programming stuff like .NET and all their other APIs, corp app, etc. Makes it hard to change.

One potential bright spot - apparently Word in Office for the Mac uses the STAT table for the font selection interface. The Google Fonts folks use it to test font STAT tables configurations, because AFAIK it is the only application with STAT table support.. I got it (Word/Office) installed in a macOS Ventura VM, and played with it briefly, but have not tested it much. Hopefully... that will lead to a better a font selection interface in the future... perhaps by around 2030, or so...

Maybe they will also bring the OpenType feature support into this century. We can dream...

Re: Adobe - it does kind of amaze me how much they do ####-up when it comes to typography stuff. As Rosanne-Rosannadana would say, "it's always somethin'."

[psb1558]

Thanks for reminding me of Roseanne Roseannadanna, one of the funniest characters ever created, by one of the funniest human beings who ever walked this sad old planet. I'm old enough to have seen her when she first joined the SNL cast, and to have mourned her when she passed.

I want to temper my rant with a shout-out to whatever divisions of MS run this brilliant site and supply the brilliant Visual Studio Code, which I use every day. The MS of today is not the MS of thirty years ago—maybe there's even hope for MS Office, some day in the distant future.

[ischaap]

I can give an update on this issue for MS Word for 365 in v. 2.000beta1. It looks like the current font names are overall a bit shorter, and Word seems to be much happier than it was before when it comes to the font dropdown (though I'm not sure why 'Junicode Two Beta' is still hanging around there at the bottom of the list as I've deleted the previous beta):

I can now achieve the following (composed in Word and exported to pdf):

But there are still issues with italics. While I get this in Word...

...I still get some italic gibberish once exported to pdf:

In the pdf output, it also kind of looks to me like the light italic and normal italic are identical at the condensed, semicondensed, and regular spacings. Could both issues be because the names of the italic fonts are still a bit too long for embedding in pdfs?

Finally, if I use Word to compose a sentence in Junicode Medium roman and then appy local bolding to a single word, the bold text doesn't export properly to pdf. The only way to get bold to export properly to pdf in a text otherwise set in Medium is to change the word to be bolded into plain Junicode (which I presume is Junicode Regular) and then apply the local bold. I realize there's no Junicode Medium Bold (as Bold and Medium are both weights and so mutually exclusive) but I would have thought that the way this kind of thing works in Word is that local bolding bumps selected text of any weight up one or two weights. If not, it's easy enough to handle with styles, as you'd do in InDesign, but at the same time I would've anticipated Junicode Bold to show up in the dropdown alongside the plain Junicode -- excluding the italics, Junicode Bold is, I think, the only one of the fonts that still doesn't show up. But maybe this is a Word issue and not a Junicode issue?

[psb1558]

Try out version 2.000beta2 (just posted), in which I have shortened several style name elements:

• Semi -> Sm
• Condensed -> Cond
• Expanded -> Exp

That makes the longest style name (I think) 29 characters (Junicode smCond smbold Italic), which should ease the Windows problems quite a bit.

Some of the file names are now different, so when you install, you must uninstall the old version first; otherwise you'll have old files hanging around and making your life difficult.

[ischaap]

Thanks for 2.000beta2. I tried this again, but unfortunately I'm getting the same results when exported to pdf. Again, everything looks good in Word (pdf results below).

I should also add that SemiExpanded Bold and Expanded Bold both apply italics as well, but the italics can then be removed in the usual way for local formatting in Word (Ctrl+i).

[psb1558]

I doubt that this will fix the problem, but do try version 2.000beta3, which fixes some style linking/name table issues, especially in the italic faces.

[ischaap]

Here's the output from Word (where everything looks good) to pdf for v. 2.000beta3. Looks like some movement! Semi-expanded Bold Italic and Expanded Bold Italic now both work in pdf. So now, interestingly, it's just all the medium italics that have issues.

[kenmcd]

@ischaap
Can you attach the above PDF? Like to see what is in there. And the Word docx? So I can test the same thing, and see if I get the same corruption. If you could please put both in a ZIP and attach it that would be great.

The scrambled text looks like font cache corruption, so I would like to see if I get the same output.

[ischaap]

No problem! -- here you are.

Quick brown fox.zip

[kenmcd]

No problem! -- here you are.

Quick brown fox.zip

Great. Thanks. Will save me some time.

[kenmcd]

The PDF output looks good to me. Exported to PDF from Word 2019 on Windows 10. Then exported to PNG from my PDF editor. This is v2.000beta3.(2023-08-02)

So you may have some font cache corruption and/or duplicate font files in your Fonts folders.

When font files are locked, and you update the fonts, you may end up with duplicate font files, because Windows installs the updated fonts by adding a number suffix to the file name. Example: Junicode-Regular_0.ttf When Windows does this it keeps track of the "correct" font file in the registry - and that can get messed-up. Scan your Fonts folders and see if any files have a number suffix. Some applications just scan the Font folders (like Affinity), so those duplicate files mess-up their font cache - and you see stuff like your image above.

Lots of applications may lock the font files, so shut down applications before updating the fonts (like Word, browsers, etc.). I always un-install the fonts, then check the Fonts folder to make sure those font files are gone, and then install the new versions.

Clean-up... Un-install all the fonts and then check both the main Windows Fonts folder and your User Fonts folder. Delete any leftovers that should not be there. Windows Font folder: C:\Windows\Fonts\ User Fonts folder: C:\Users\USERNAME\AppData\Local\Microsoft\Windows\Fonts\ Replace USERNAME with your User Name. You can get directly there by opening a Run dialog (WindowsKey+R) and pasting this: %userprofile%\AppData\Local\Microsoft\Windows\Fonts\ then click OK. That will open a Windows Explorer window for your User Fonts folder. When you install fonts with the Font Viewer Install button, they end up there. This was added in a Windows 10 update to enable users without admin rights to install fonts. Don't use this.

Always Install for all users Which puts the fonts in the main Windows Font folder. Select the font files, right-click, and select Install for all users (on Win11 you have to open the "more options").

Shut everything down, do the clean-up, and restart your computer (and it should clean-up the font cache itself), install the fonts, and check the PDF output again. Hopefully it will now work as expected.

[ischaap]

@kenmcd, thank you very much for your detailed instructions. I followed them and did discover some rogue fonts lurking in the user fonts folder, which I cleaned up. But I couldn't find any remaining Junicode files in either folder. I did make sure that hidden objects were visible just in case. Then I restarted in the hopes that clearing the font cache might help, but no luck. The pdf outut is the same for me, with the five lines of gibberish.

I did notice earlier on during the Junicode beta (after Dr Baker announced that the italic had caught up with the roman -- I think that was v. 1.063 or 1.064) that when I'd delete Junicode via the Windows font folder, it would seem to miss deleting some of the files, even though the entire family visually appeared to be deleted. But I could tell something was up because when I'd install the next build (always via 'intall for all users') I'd get a message asking to replace several of the Junicode files. After that, I realized the surest way for me to delete all Junicode files completely is not via the Windows font folder but via Settings > Personalization > Fonts, so that's what I've been doing ever since.

I'm holding onto hope that there's not something completely messed up with my system and that this will work itself out in a future build -- I feel it must be encouraging that in v. 2.000beta2 I had seven lines of gibberish, but in v. 2.000beta3 only five, hahaha! On the other hand maybe it doesn't bode well for me that you could get a clean pdf without gibberish.

Well, maybe something I've said here will suggest some other action I can take (?).

[kenmcd]

I did notice earlier on during the Junicode beta (after Dr Baker announced that the italic had caught up with the roman -- I think that was v. 1.063 or 1.064) that when I'd delete Junicode via the Windows font folder, it would seem to miss deleting some of the files, even though the entire family visually appeared to be deleted. But I could tell something was up because when I'd install the next build (always via 'intall for all users') I'd get a message asking to replace several of the Junicode files. After that, I realized the surest way for me to delete all Junicode files completely is not via the Windows font folder but via Settings > Personalization > Fonts, so that's what I've been doing ever since.

You need to be able to look at the actual files - not what Windows shows you through the Font Manager, etc. because that is showing you what is installed per the registry which is not the same as the files present on the folder.

I use a file management application called XYplorer and just leave one tab open to the Windows Fonts folder at all times. It shows the actual files. It is a commercial application.

The free open source 7-Zip application is also a file manager. And it also shows the actual files content of the Fonts folder. (and I also use it to manage protected system fonts)

As you mentioned above, the messages asking if you want to replace some font files definitely means you are not seeing all the files that are actually there. So give 7-Zip or XYplorer a try. 7-Zip is here: https://7-zip.org/download.html

[ischaap]

Update on this issue -- I resubbed to InDesign and when I export to pdf from InDesign, this is my pdf result:

So it would seem the gibberish italics must be a Word for 365 issue? Or something about the way Word for 365 is interacting with Adobe.

That said, @kenmcd, I am interested in your last post, but I'm not sure I understand what you're saying. I have 7-zip, but how can I use it to see the contents of the Windows Font folder or the User Font folder? Just zip the apparently empty folders? When I tried to zip C:\Windows\Fonts, I got this error message:

I was able to zip the User Fonts Folder, but the zip folder was empty.

[kenmcd]

Update on this issue -- I resubbed to InDesign and when I export to pdf from InDesign, this is my pdf result:

So it would seem the gibberish italics must be a Word for 365 issue? Or something about the way Word for 365 is interacting with Adobe.

Those do not look right. The weights are not correct. Look at the Expanded fonts, etc. The way to check it for sure is see what fonts are embedded in the PDF for the different text snippets. Simply pasting into InDesign may not work. Advanced graphics applications like InDesign and Affinity Publisher, etc. use the Typographic Family Name, and applications like Word and LibreOffice use the older Family Name (or style groups). So there has to be a bit of a translation between these two "naming systems" when moving between the different applications. You probably would need to go through and re-apply all the fonts/styles in InDesign (ID), and then it may be correct on PDF export. Placing the Word doc into InDesign (not simply pasting text) may work better because then ID processes the text it is importing, and that may have better results.

I plan on testing Junicode 2 in ID, but will probably not get to it today. Maybe tomorrow.

That said, @kenmcd, I am interested in your last post, but I'm not sure I understand what you're saying. I have 7-zip, but how can I use it to see the contents of the Windows Font folder or the User Font folder? Just zip the apparently empty folders? When I tried to zip C:\Windows\Fonts, I got this error message:

I was able to zip the User Fonts Folder, but the zip folder was empty.

Kinda surprised by this. Since you can see "Install for all users" I assumed you have administrator rights. You can see what kind of User account you are using by going to: Settings > Accounts > Your info For example mine says: Ken Local Account Administrator

If you do not have a Local Account, you can make one, and give it Administrator rights.

You can also try running 7-Zip as Administrator. Right-click on the 7-Zip icon or .exe, and select: Run as Administrator

I open 7-Zip and use its file browsing features to go to the Windows Fonts folder. And it looks like this:

Hmmm... I may have set my 7-Zip to automatically Run as Administrator. Yes, just checked, Run as Administrator is required to be able to rename font files, delete font files, etc.

We'll get you there yet. :-)

[psb1558]

@kenmcd: Have you tried the variable version in InDesign yet? I'm wondering if you'll have the same problems I'm having, i.e. things are fine if you pick an instance from the style menu, but problems start if you use the sliders.

[kenmcd]

@kenmcd: Have you tried the variable version in InDesign yet? I'm wondering if you'll have the same problems I'm having, i.e. things are fine if you pick an instance from the style menu, but problems start if you use the sliders.

No. I meant to get to it today. But it looks like it will be tomorrow. I may know what the issue is. Need to poke around a few tables to see.

What version of InDesign to you have on your Mac? I have v17.2.1.105 installed in a Win11 VM. And have v18.4.0.57 in-waiting but I did not want to mess with installing it yesterday when I was getting my AdopeyTests Win11 VM all up-to-date.

I installed the latest release of Office 2021/0219 in that VM yesterday trying to get the new font menu - but still not there. Apparently still only in O365. And I wanted to get my hands on the new Aptos fonts. But the same issue - only in O365 Insiders release for now.

[psb1558]

I have InDesign 18.2.1, running on Ventura 13.4.1 on M1. I have made further changes since 2.000beta4. Maybe I should build beta5 before tomorrow.

[ischaap]

Ah, now I get it, thanks @kenmcd. I followed your instructions and I did indeed find some Junicode files in C:\Windows\Fonts with numerical suffixes (none in the user fonts folder though). I cleaned up the ones in the Windows fonts folder as instructed, restarted and reinstalled, and this is what I've got now, which I think looks good:

But unfortunately, having done this, a new pdf export from Word still has a few lines of gibberish italics:

Re: the pdf output from InDesign I posted yesterday, do the weights really look wrong? Could it just be that I grouped the fonts by width instead of by weight? The differences in line-length are less dramatic that way, and maybe your eye was anticipating the more dramatic grouping by weight. Compare these two pdfs from InDesign below. Both were composed just now subsequently to cleaning up with 7-zip, and both were composed directly in InDesign to eliminate the MS Word factor.

This first one is grouped by width, same as the one I posted yesterday:

This second one is grouped by weight, and so looks more dramatic:

To my eye the weights and widths look right in both examples, the method of grouping in each being taken into account, but maybe you're seeing something I'm not! Please let me know what you think, but in any event, thank you @kenmcd for your continued help and patience.

[kenmcd]

To my eye the weights and widths look right in both examples, the method of grouping in each being taken into account, but maybe you're seeing something I'm not

Those images still do not look right to me. Best way to confirm is to check the PDFs. Please attach the PDFs you used to create the images.

But unfortunately, having done this, a new pdf export from Word still has a few lines of gibberish italics:

That is quite odd. Only thing I can think of now is to manually clear your Windows font cache. There are instructions online. On my phone ATM but if you cannot find it I can post some links tomorrow. Think I may also have script that does it (which is easier). The font cache files are locked by a couple services. So you have to shut-down the services, then delete the cache files, and then restart the services. The script does this for you.

The Windows registry font entries can also get messed-up, but I would not expect a corruption like this - that is usually a cache issue. But... it could be. There are two Windows font managers which have tools to clean-up the Windows registry font info - High-Logic MainType and Proxima FontExpert. Both have a 30-day trial which you could use to do the registry clean-up.

[kenmcd]

I have InDesign 18.2.1, running on Ventura 13.4.1 on M1. I have made further changes since 2.000beta4. Maybe I should build beta5 before tomorrow.

Sounds good to me.

[psb1558]

I've posted 2.000beta5. I'll be very interested in hearing how it behaves for you.

[psb1558]

My instance test in InDesign looks okay (static version: the variable font crashes ID). I attach PDF for comparison. Junicode_instance_test.pdf

[psb1558]

Found I was several versions of InDesign behind, updated to 18.5. It didn't change anything.

Discovered an anomaly, that the SemiBold instance was sometimes Smbold, sometimes SmBold. Corrected that, which was worth doing, but it didn't help the InDesign crashes.

I've opened an issue for InDesign crashes.

[ischaap]

Those images still do not look right to me. Best way to confirm is to check the PDFs. Please attach the PDFs you used to create the images.

Sure thing -- both images from yesterday were taken from the attached.

Quick brown fox 2.000b4 - InDesign.pdf

(Edited to add: looking at the instance test @psb1558 posted this morning, I do now see the problem with my samples from yesterday, especially in the semibold italics and the bold italics.)

That is quite odd. Only thing I can think of now is to manually clear your Windows font cache. There are instructions online. On my phone ATM but if you cannot find it I can post some links tomorrow.

Is what you had in mind something like the instructions here? I.e. stop font cache services, disable Windows Presentation Foundation Font Cache 3.0.0.0 etc., etc.? If so, I'll give it a try.

[kenmcd]

I've posted 2.000beta5. I'll be very interested in hearing how it behaves for you.

I do not see a beta5 tag: https://github.com/psb1558/Junicode-font/tags

So I will download the full repo. (note: ever since you reorganized the repo I cannot use Git or GitHub Desktop to access the repo and just download updates - we can discuss later when you have more time).

[kenmcd]

Sure thing -- both images from yesterday were taken from the attached.

Quick brown fox 2.000b4 - InDesign.pdf

All looks fine. Apparently this was just me not paying proper attention. Thanks for posting the PDF.

[kenmcd]

Is what you had in mind something like the instructions here? I.e. stop font cache services, disable Windows Presentation Foundation Font Cache 3.0.0.0 etc., etc.? If so, I'll give it a try.

Yes. Those instructions look OK.

And regarding their "Way 2" - I have not seen that tool before - have to play with that ... later.

[ischaap]

All looks fine. Apparently this was just me not paying proper attention. Thanks for posting the PDF.

Thanks very much for taking a look. I was starting to doubt myself!

To update further, I followed the procedure for manually clearing the font cache. My services only included Windows Font Cache and didn't have Windows Presentation Foundation Font Cache 3.0.0.0, but I followed the instructions otherwise and all seemed to go all right. Utimately no change in exporting from Word to pdf, though -- still some italic gibberish.

Could the absence of the Windows Presentation Foundation Font Cache 3.0.0.0 service -- and hence no FontCache3.0.0.0.dat file to delete -- be the ultimate problem?

At any rate, next I tried HighLogic MainType. It found one registry issue and a handful of corrupt fonts, which I fixed, but nothing specific to Junicode. This yielded no change in exporting from Word to pdf either.

So, current status in v. 2.000beta5:

• export from InDesign to pdf: looks fine
• export Word for 365 to pdf: all five medium italics are gibberish

[kenmcd]

• export Word for 365 to pdf: all five medium italics are gibberish

Very strange. I do have a version of O365 installed in a Windows 11 VM. It was installed with an MS developer program I was in for awhile which has since expired (so no more updates). I will give that a try with the static fonts in the next few days. Also going to test in LibreOffice, Affinity Publisher, etc... Trying to focus on the variable fonts today.

Could the absence of the Windows Presentation Foundation Font Cache 3.0.0.0 service -- and hence no FontCache3.0.0.0.dat file to delete -- be the ultimate problem?

That is kinda strange. Think that is WPF is part of .NET - and I cannot imagine that you do not have any version of .NET runtimes installed. So, yeah, very weird.