UlCodePageRange and OpenType feature inaccessibility in InDesign CS

Primary tabs

5 posts / 0 new
Last post
Anonymous's picture
Offline
Joined: 6 Mar 2002 - 1:06pm
UlCodePageRange and OpenType feature inaccessibility in InDesign CS
0

or Where is the bug?

Let’s assume that a particular font supports _only_ codepage Windows-1251 (Cyrillic), i.e. has glyphs that cover only this codepage. Then, in the process of .otf compilation, the MakeOTF heuristics properly set the bits of ulCodePageRange1 to 0000……0100 (bit 2 = Cyrillic), leaving ulCodePageRange2 zeroed.

On an XP system (atmfd.dll and atmlib.dll — version 5.1.2.225), however, such a font is only partially functional in InDesign CS, because all the OpenType features (including the kern one) are completely inaccessible.

Nevertheless, should bit 1 (= Latin 2: Eastern Europe) in ulCodePageRange1 be set to 1, the font works like a charm, regardless of whether bit 2 (= Cyrillic) is set or not. (i.e. 0000……0110 and 0000……0010 are both OK)

Since it’s rather improbable that this is the intended implementation, where is the bug — in the CoolType engine, in XP’s font driver or

Hrant H Papazian's picture
Joined: 3 May 2000 - 11:00am
0

So what’s your real name?

hhp

Anonymous's picture
Offline
Joined: 6 Mar 2002 - 1:06pm
0

What does it matter. If this is a valid bug we can all benefit from anyone who can shed some light on this.

Nigel

Anonymous's picture
Offline
Joined: 6 Mar 2002 - 1:06pm
0

The problem may either be in the CoolType engine or in the module responsible for handling OpenType feature data (if different).

I. At InDesign initialization time, CoolType checks whether the fonts available on the system are present in its

Anonymous's picture
Offline
Joined: 6 Mar 2002 - 1:06pm
0

The problem may either be in the CoolType engine or in the module responsible for handling OpenType feature data (if different).

I. At InDesign initialization time, CoolType checks whether the fonts available on the system are present in its

Topic locked