>
> > The issue is whether we want to draw all of UTF, and it's far too big
> > to be memorized glyph per glyph, or only latin characters, and the
> > single glyph texture approach becomes possible and preferable.
>
> Ah - but no text is really all that likely to use all the glyphs, so a
> mechanism to render glyphs that are used "on demand" and then cache them
> for re-use later (on the basis that a given bit of text is very likely
> to re-use the same glyphs...)

I would think this assumption holds for alphabetic scripts, but not
for Chinese and friends.


> I guess we'd need some sort of low-cost
> hash scheme for "searching" for the cached glyphs quickly, then...
>
> With that mechansim, we can probably cache just a few thousand glyphs
> and get pretty much everything we'd need, for any given text.
>
> Or, we can (as you have done) render complete strings and cache them.=20
> I guess that will make the rendering more consistent between the GL and
> FL views, as we will get kerning and so forth the same in both cases.
> (I assume that glyph-by-glyph rendering will not cope with kerning and
> so forth.)
>
>
> > I reasoned that FLTK-1.3 aimed at full UTF support.
>
> It does.
>
> > To draw UTF to textures, one needs to be able to draw them
> > to a bitmap in the first place, and that is still not possible
> > in 1.3+X11+xft.
>
> I don't understand what you are saying here. I often render utf8 text,
> with non-LGC glyhs, into bitmaps and so forth.
> I don't understand what you are telling me here.
>
> > So, the way I see this issue is that extending
> > xft support to full UTF needs be solved before deciding how to
> > transform xft output into GL textures.
>
> Sorry - you have lost me - what part of XFT rendering do we need to fix?
> --
> Ian

I don't succeed here in having FLTK-XFT to render CJK characters.
It works with Greek, Cyrillic, though. And I know I have the
font somewhere because my file manager displays chinese filenames
correctly. It seems that my FLTK does not know how to fish the fonts
that contain CJK characters. I assume the problem will be the
same if fl_draw() is directed to a bitmap.

This was my point.

Your reaction suggests that I may have missed something (may be in
FLTK + XFT compilation ?). I refer to a Debian 32-bit OS.

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

Reply via email to