On Thu, Nov 22, 2018 at 2:13 PM Ulrike Fischer <news3@nililand.de> wrote:

Am Thu, 22 Nov 2018 13:50:08 +0100 schrieb Hans Hagen:

>> When I use this definitions I still get partly blue glyphs with this
>> preamble. Don't you get them?

> well, i don't know what to expect

Khaled mentioned this link which shows how (harfbuzz-based) browsers
like firefox interpret the font
https://www.amirifont.org/fatiha-colored.html

Also the spec
https://docs.microsoft.com/en-us/typography/opentype/spec/colr#layer-record
says

====
A palette entry index value of 0xFFFF is a special case indicating
that the text foreground color (defined by a higher-level client)
should be used and shall not be treated as actual index into CPAL
ColorRecord array.
====

sure, in font-dsp.lua

2953 -- The special value 0xFFFF is foreground (but we index from 1). It

2954 -- more looks like indices into a palette so 'class' is a better name

2955 -- than 'palette'.

" the text foreground color (defined by a higher-level client) should be used"

doesn't mean "you MUST take the current color text" or even "you MUST use black"

In fact "defined by a higher-level client" means

that I could define a palette such that each glyph marked with 0xFFFF has its own color based on my palette --- not necessarily the *same* color.

(this is the meaning in font-ocl.lua of

247 local default = colorvalues[#colorvalues] -- or 1 or ... maybe make it an option

)

So..in this situation black makes sense as blue -- I guess that 0xFFFF is mapped as "cuirrent text color" in harfbuzz-browsers,

so, sure, it has a bit more functionality.

luigi