UlCodePageRange and OpenType feature inaccessibility in InDesign CS

anonymous's picture

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

anonymous's picture

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

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

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

hrant's picture

So what's your real name?

hhp

Syndicate content Syndicate content