Re: [gtk-i18n-list] `.pcf' font not accessible from pango

[pottendo <pottendo utanet at>]

hi,

mpsuzuki hiroshima-u ac jp writes:
> Hi
> 
[...]
> Although the Subject of this thread includes PCF,
> we only tested BDF only.
> 
> Tracing the behaviour of fc-cache, I found there's
> another reason in FreeType, either. fontconfig gets
> infos of charset/encoding by FreeType's "face"
> structure. The "face" is originally designed for
> TrueType, the charset/encoding info of BDF/PCF are
> returned as if the font were TrueType. The variety
> of infos that can be passed by "face" is restriced
> to TrueType's "cmap" specification. On the other
> hand, the charset/encoding info of BDF/PCF is just
> string. There's no restriction. To "synthesize"
> charset/encoding info from given font, FreeType
> returns platform=Apple & charset/encoding=Roman
> (US-ASCII), if there's no way. This is why we cannot
> use non-ASCII PCF/BDF via fontconfig.

Is this a bug or a feature? ;-)

I haven't checked the `Symbol font' article yet so please forgive me
if the following questions are stupid... 

Do you think that it is possible to end up with the desired behaviour
(petsci mapping) by hacking fonts.cache-1 by hand? (entry charset and
maybe lang?).
Where can I find information about the semantics and syntax of
fonts.cache-1 (besides the source code).  

Would this be the case where one should write a special `petsci'
rendering backend for pango? I'm just curious.

Regards,
martin