![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Thu, Nov 22, 2018 at 2:13 PM Ulrike Fischer
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