Re: Marking glyphs as deliberately blank, per font

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas, all that talk makes sense, but unless a concrete proposal for how to 
change fontconfig comes in, I don't know what to do about it.

behdad

On 11/26/2009 04:35 AM, Nicolas Mailhot wrote:
>
>
> Le Mer 25 novembre 2009 23:54, Behdad Esfahbod a écrit :
>>
>> On 11/25/2009 07:01 AM, Paul Flo Williams wrote:
>
>>> 2. The fonts.conf page says that 'fonts often include "broken" glyphs which
>>>      appear in the encoding but are drawn as blanks on the screen.' A trawl
>>> of
>>>      the mailing list suggests that this configuration option is ancient --
>>> at
>>>      least I can't find any discussion of its introduction -- so is this form
>>>      of breakage common in fonts we use today?
>>
>> Donno.
>
> I don't know if it's common, but it definitely exists today. We've seen it
> just a few months ago in Fedora (in smc fonts IIRC). In their case it was not
> even a blank but a buggy glyph meant to indicate 'reserved'
>
> IMHO now there are efforts in big apps such as Firefox to do more CSS3,
> including the CSS3 "select unicode subrange in font" operator, it is becoming
> even more urgent for fontconfig to stop considering a font is a basic atomic
> unit, and allow fontconfig users to write rules that only apply to part of a
> font. It is a huge problem if the font selection model used by fontconfig does
> not permit direct mapping from the font selection model used by web-oriented
> apps (which can be basically any app now more and more GUI toolkits move to
> use of CSS to specify styling)
>
> http://people.mozilla.org/~jdaggett/AdvancingWebTypography.pdf page 42
>
> The "fonts should only include one script with consistent quality so
> fontconfig does not need to split them" is a lost cause now, the font
> community chose, and not the way fontconfig authors wished.
>
> All the conflicts between scripts and weird inverted logic overrides almost no
> one really understands are caused by the "font is an atomic fontconfig unit"
> postulate. All past attempts to mitigate those problems without changing the
> "font is an atomic fontconfig unit" postulate have failed miserably. Humans
> just do not think fonts are an atomic unit, and can not wrap their minds
> around a system where they are forced to think this way.
>
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig


[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux