On Mon, Jul 10, 2000 at 10:43:26AM +0200, Asger K. Alstrup Nielsen wrote:
> > As for 1., Kawakami-ChangGil's patch implements all the required stuffs in
> > (IMHO) a clean and elegant way. I think this part can be integrated into
> > LyX without problems.
>
> Could you factor out this part of the patch?
> Then we can look at it, and if it looks good, apply it to cvs.
We need to change the internal text storage from 8-bit to 16/32-bit,
before we can use such a patch.
However, I think that we should implement the CJK input within LyX, as
we already do it for all the other language (and it does let you to input CJK
on any machine).
> That should at least make the CJK patch smaller, and thus closer to
> real integration.
>
> > 3. is clearly addressed in Dekel's patch. However, the approach is rather
> > problematic from the point of view of CJK-support. My main concern is
> > the availability of ISO 10646 fonts. Although it shouldn't be a problem
> > on systems where truetype font renderers (e.g. XFree86 ver4.0 server/xfs)
> > are running, this is not always the case. The traditional approach on X
> > window system, which is portable, is to combine several font files to
> > make a single logical font. XFontSet is a facility offered by Xlib for
You don't need xfree 4.0. It works fine with xfree 3.3.x and fairly recent xfs.
Furthermore, we can add support for TTF fonts using the freetype library
directly which will give more portability, better performance, and perhaps
support for anti-aliasing.
> > such purpose. The essential idea is that a user requests a XLFD >>WITHOUT<<
> > a font norm and Xlib appends font norms according to the locale:
> > For example, if I aliase Japanese gothic(which is in fact a sans serif) to
> > helvetica and requests
> > oc = XCreateOC(om, XNBaseFontName,
> > "-*-helvetica-medium-r-normal-*-14-*-*-*-*-*", NULL);
> > under LC_CTYPE=ja_JP, then
> > -*-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1
> > -*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0201.1976-0
> > -*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0208.1983-0
> > -*-helvetica-medium-r-normal-*-14-*-*-*-*-*-jisx0212.1990-0
> > will be loaded and I can access the XFontStructs via
> > XFontsOfFontSet(oc, &FS, &charlist);
> > and
> > XmbDrawString(dpy, win, oc, gc, x, y, mb_string, num_bytes);
> > will draw a multibyte string automatically switching the real fonts used.
>
> So the font selection is based on the global LC_CTYPE?
>
> Hmm, that seems a bit restrictive. Is it not possible to specifically
> ask for the font norms for a given locale without setting LC_CTYPE?
>
> That would probably be the best solution, since we would like to
> support writing Japanese on a system where the LC_CTYPE might be
> set up for Danish.
We also want to be able to render simultaneously Japanese, Hebrew, Russian,
etc. Is it supported by Xlib? (i.e. does the XCreateOC call also load
iso8859-n font if they are available?)
> If we assume that it is possible to specify our own LC_CTYPE without
> really doing it (you know what I mean), how would this fit in with
> Dekel's approach? Dekel, can the two approaches be integrated in
> some way?
As I've written above, I don't know if the Xlib multi-font support gives up
what we need.
