Unknown Script 33

David Massara

Hello Guys!

I am working on a typeface and encountering an issue when exporting the font files. I receive the error code "Unknown Script 33" in Adobe InDesign when selecting the font. The typeface consists of two files: plain and italic. The problem appears to be related to the PostScript name. Depending on how I rename it in FontLab. If I activate only the plain or only the italic file, it works fine individually on Indesign. The error may seem to be tied to some TrueType metadata when I see the "(OTF)" on the InDesign panel.

Interestingly, if I include the word "trial" in the name, the issue arises, but removing it resolves it. Any insights would be appreciated. 

Thomas Phinney

This seems like a really interesting InDesign bug. Sure sounds like their font-handling engine is tripping on something in the font name, which is getting processed in some way it should not!

As a workaround, you could come up with some synonym for “Trial” and probably avoid triggering the problem. I can’t instantly think of anything better than “Test” but surely there are other options.

Also, I would definitely report this to the Adobe InDesign team, at: https://indesign.uservoice.com/

Johannes Neumeier

If you are familiar with fonttool's ttx command it would be interesting to see the generated name tables for the upright and italic that are causing the issue: ttx -t name path/to/font.otf (or drop it here and see the "Naming table" section)

Inspecting specifically the post script name (name table record with id 6) you could check if they indeed have unique (different from one another) names.

What is odd is that the error message mentions "Script" — name tables records have platform, encoding and language, but not script.

David Massara

Thank you for your comments. This is more than disturbing. I recomposed the font in its entirety step by step. It worked for a while, but after re-exporting the same file a few hours later, the problem returned. This is beyond my understanding. It was the same file with no modifications made.

Here is a preview of the naming table on opentype.js. Everything seems to be in order. I tried several times to clear the font caches from the terminal and to uninstall InDesign.

The issue also happens in Photoshop as well, It splits the file in two.
As recommended I sent the issue on https://indesign.uservoice.com/

John Hudson

To confirm, the error is now occurring even if the word ‘Trial’ does not occur in the name strings?

The fact that the error occurs in the InDesign font family menu suggests one of two things: either the font name includes a character that InDesign cannot parse, or the font contains metadata elsewhere relating to script coverage that InDesign does not recognise.

Check all your name strings for invisible characters. These might be trailing spaces, for example, or could be zero-width. I suggest copying and pasting each name string from the compiled fonts into the Unicode Text Analyzer and check to confirm that the name strings are as expected.

Check the codepage and Unicode range data stored in the OS/2 table. In FontLab, you can preview this in the Font Info Codepages and Unicode Ranges panels, but of course what matters is what is actually being written to the compiled fonts. It is possible that you have somehow set an undefined bit. InDesign sorts the font family menu by script, in part determined by the OS/2 table settings (although I think a more complicated algorithm is involved), so this error message might be flagging that it does not recognise something it encounters in this process.

David Massara

Hello John,

Yes, I recompiled the entire file into a new one by copying and pasting each glyph with the copy layer (option+cmd+c), but the issue is still present. The most surprising thing is that the issue now does not appear on my computer but can occur on my associate's computer.

I checked with the Unicode Text Analyzer and everything seems to be in order. When the problem occurs, InDesign displays the characters "#$%&" instead of "sample". I don't know if this could indicate a particular issue.

Kent Lew

I think you misinterpreted the Terminal instructions. Your command should be

ttx /Users/David/Library/Fonts/SCMozart/SCMozart-Bold.otf

David Massara

Thank you, Kent! I'm only familiar with FontMake, and I have never used FontTools before. Thank you for the command; I have generated the different name tables in a .ttx file.

If anyone is interested in telling me if they find any anomalies in it that might explain this problem, I would appreciate it.

John Hudson

See my previous comments regarding OS/2 table codepage and Unicode range bit settings. The #$%& string showing up in the font preview suggests something like a character encoding error or incorrect data in those bit settings. It looks like InDesign doesn’t recognise what writing system the font supports, so cannot determine what sample string to display.

John Hudson

I checked one of your TTX dumps (I would not recommend posting whole TTX files on a public forum, since they are reversable to a font), and took a look at the OS/2 codepage and Unicode range bits.

Unicode Ranges:

<ulUnicodeRange1 value="10000000 00000000 00000000 00000011"/>

Those bits look fine, and are typical for a basic Latin typeface.

<ulUnicodeRange2 value="00010000 00000000 00000000 00000000"/>

That bit might be an error. It is the bit for CJK Compatibility Ideographs in the F900-FAFF.

<ulUnicodeRange3 value="00000000 00000000 00000000 00000000"/>

<ulUnicodeRange4 value="00000000 00000000 00000000 00000000"/>

This looks fine: I would expect all these to be unset in a basic Latin font.

Codepages:
<ulCodePageRange1 value="00100000 00000000 00000000 00000001"/>
The first bit (at the right) is correct (Windows Codepage 1252 Latin 1), but the other bit is for the Microsoft Symbol character set, which should only be set for a specific kind of symbol font.

<ulCodePageRange2 value="00000000 00000000 00000000 00000000"/>
That looks fine.

So, I suggest going into the FontLab Font Info panels and unchecking the CJK Compatibility Ideographs range in the Unicode Ranges panel, and removing the Symbol Character Set from the selected codepages in the Codepages panel. Then regenerate the fonts and re-test.

[Code formatting in TypeDrawers is a mess!]

David Massara

Thank you John for checking the .ttx files. As recommended, I have removed them from the forum. I tend to prefer trust and not think about ill-intentioned people on this forum.

What is curious is that these parameters were not implemented in the Unicode range nor the Codepages panel in Fontlab. Even after removing them entirely and re-exporting them, I still encounter the same issue. But what bothers me is that if I activate only the plain or only the italic file, it works fine individually in InDesign..

John Hudson

So you should definitely have some Unicode range and codepages selected in your source. It is possible that some generic bits are being set automatically during font export because your settings are empty.

I took a look at the cmap coverage in your TTX dump, and see that your font seems to be missing a lot of standard accented characters. So FontLab’s auto settings for the OS/2 bits might be confused.

I suggest selecting the 1252 Latin 1 codepage in the FL Codepages panel (i.e. use the rightward button to move it to the selected codepages box), even though your font does not yet include all the characters in that codepage. My guess is that alone might solve your problem, but you could also run the auto function (jewel button) in the Unicode Ranges panel and see which ranges get selected.

I strongly recommend covering at least one complete codepage in your character set, but presume that perhaps you are just wanting to test incomplete fonts during development. For that purpose, ‘lying’ in the Codepages panel is sometimes necessary.

David Massara

Thank you, John, for taking the time to look into this issue. Yes, I noticed this problem during the early production phases of this project. For now, the font only includes a custom character set called "trial," covering just 127 glyphs.

The Unicode ranges and code pages were still generated using the jewel button before. I tried covering the "1251 Latin" character set as you recommended, also including it in the Unicode range and codepage panel, but nothing seems to work even after exporting it.

What is problematic is that it seems to have worked on my computer for a few steps, but not on my colleagues' computers, even after removing the caches or reinstalling the applications (Indesign).

John Hudson

Try deleting the fonts, clearing the system and Adobe font caches. Restart system. Reinstall the fonts.

Instructions for clearing system font cache.

Instructions for clearing Adone font cache (take care to only delete AdobeFnt*.lst entries).

David Massara

Hello guys!

First of all, I'd like to thank everyone for their help in resolving this issue. I’m finally back with the solution. I contacted Alphabet Type in Berlin, and Andreas Eigendorf helped me understand the problem!

The upright and italic font files had a reduced character set, smaller than Latin-1. This information is important because, in the upright version, two symbols (U+263A and U+263B) were temporarily included. Because of these two symbols, InDesign thought the upright version was a symbol font, rather than the italic version which didn’t include these two emojis. This was the cause of the bug. To fix it, there were two options: either include the two emojis in the italic version so that the font would be recognized as a symbol font, or remove the two emojis from the upright version.

This bug was quite particular. The issue wouldn't have occurred if the character set had been complete. This peculiarity was quite interesting, and I’m grateful to Andreas for finding the solution. I would like to point out to those who may be affected by this bug that it's important to clear the caches from the terminal even after the bug has been resolved.

I hope this article will be helpful to anyone experiencing the same issue!
Thank you all for your help!