>> 2. Incorrect assumption that all [non-control] characters occupy just
>>    one column. sparkaround's CJK characters occupy 2 characters.


> Note that fontconfig (and I think XFT and freetype) actually identify
> three base font width types:
>
> FC_MONO - all glyphs in the font are the same width
>
> FC_DUAL - where the font has glyphs in precisely two widths, one
> twice as wide as the other
>
> FC_PROPORTIONAL - glyphs are whatever width they like
>
> Now, I think the FC_DUAL case is common in CJK fonts that also
> (usually) have fairly complete Latin (or even LGC) pages. This is
> probably the case the sparkaround has?
> And if so, can we leverage that to our advantage and simplify the
> code by assuming the widths have this 1:2 relationship...?
>
> Though, if this is FC/XFT specific, how does that help us with OSX
> and win32?


In http://www.fltk.org/str.php?L2158 I already raised the question
about native wcwidth() implementations and Markus Kuhn's mk_wcwidth().
For Linux, the locale comes into play, and they give different results
on my box. I don't know whether native OSX and Win32 wcwidth() work
in a similar way to the Linux implementation, or whether they are
closer to mk_wcwidth(). Apart from issues of cut'n'paste from a
native application to an FLTK application with mk_wcwidth() I could
not see any problem with simply using mk_wcwidth() as is.

I haven't looked at fontconfig, XFT or freetype, and as I say, I'm a
Linux person trying to learn by doing, but that does mean that I'm woefully 
ignorant of OSX and Win32 possibilities.

And the more I get into the Unicode stuff, the more ignorant I feel.

But that's how you learn, no?

Cheers
D.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to