Re: [ft] Missing glyphs vs. invisible glyphs for certain characters

[Adam Twardoch (List)]

Ps. It's similar to the division between HTML and CSS. CSS is used in HTML but 
can be used in other XML dialects as well (SVG). CSS has no knowledge in which 
elements or pseudoselectors are valid in HTML5, and should not differentiate 
between "valid" and "invalid" HTML tags, or presume some special behavior of 
certain HTML tags. 

In a browser, it's a task for the HTML interpreter to decide for which elements 
to apply the defined CSS styling, which nesting and which order of elements is 
valid. 

The CSS styler should make assumptions there, because an element valid in some 
current version HTML may be in invalid in another HTML version or in SVG. 

FreeType operates on the same level as CSS. Earlier-level modules such as ICU 
and Harfbuzz are like HTML. They have the notion of what Unicode in a given 
version is. FreeType does not have it and should not have it. 

(In reality, for internal hinting purposes, FreeType does have some notion of 
Unicode via its integration with Harfbuzz, but that's very "private" notion 
which is used to classify functionally related glyphs in a font together in 
order to make their appearance in small sizes more consistent.)

Best,
Adam

Sent from my mobile phone.

> On 04.12.2015, at 15:51, Adam Twardoch (List) <address@hidden> wrote:
> 
> FreeType is correct. Its purpose is to display the characters associated with 
> character codes in a given font. 
> 
> Note that the character codes passed to FT_Get_Char_Index are not necessarily 
> Unicode: they can be any FT_Charmap object defined in the font. There is 
> still a number of encoding systems in use which are not Unicode (esp. in 
> Asia, but also in some specialty applications). 
> 
> While FreeType defaults to the font's Unicode charmap, it does not interpret 
> the character codes in any special way, and is indifferent to the various 
> special meanings of certain character codes in various encoding standards. 
> The same character code can stand for a control character in Unicode but for 
> a renderable text character in another encoding. Also, the Unicode standard 
> grows constantly. 
> 
> Semantic handling of non-renderable character codes according to some 
> dncoding standard is outside of scope for FreeType. 
> 
> Apps should not use FreeType to perform straight Unicode text rendering. In 
> fact, FT_Get_Char_Index should not be used for text rendering at all, unless 
> you really know what you’re doing. 
> 
> FreeType is really a library to interact with fonts and render their glyphs, 
> *not* a library to render text. 
> 
> For Unicode text layout, apps should use a Unicode text processing library 
> such as ICU, and a glyph layout library such as Harfbuzz before querying 
> FreeType for glyph images. 
> 
> Best,
> Adam
> 
> Sent from my mobile phone.
> 
>> On 04.12.2015, at 14:48, Preet <address@hidden> wrote:
>> 
>> Hi all
>> 
>> I've tried a few fonts out and I seem to be getting the same behaviour: The 
>> zero index is returned for a few glyphs that I thought would be 'invisible' 
>> such as line feed or tab when I call FT_Get_Char_Index(...). After 
>> rendering, the zero index glyph shows up as the visible 'missing glyph' 
>> symbol.
>> 
>> Is this expected behavior? When rendering is it normal to go through the 
>> text and get rid of these characters before getting glyphs from FreeType? 
>> I'm aware FreeType isn't laying out the text, but I guess I thought the 
>> layout characters would have invisible glyphs.
>> 
>> 
>> Preet
>> _______________________________________________
>> Freetype mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/freetype