Re: TeX output for UML diagrams [path]

[Cyrille Chepelov <cyrille chepelov org>]

Le mer, jan 09, 2002, à 09:57:25 +0200, Ruslan Shevchenko a écrit:

> TeX itself - no.

Has DK decided that this "no" is final ?

> omegaTeX (distributed with near all TeX distributions)
> can handle utf16, will be handle utf8 and utf32 in near future.

OK.  (assuming utf16 ~= UCS-2 and utf32 ~= UCS-4)

> So, ideal solution is:
> 
> - insert dialog form for TeX pstricks export parameters.
>   (Can I do this from plugin ? If yes - how ?)
>    where ask output TeX encoding.

I don't think there is any architecture for that at the moment. Perhaps it's
easier for the TeX pstricks plug-in to register two or three variants, and
derive the option (local/utf8/ucs-2) from the variant ? Hmmm. I really don't
know.

What I think, however, is that the plug-in should *not* invoke a dialog in
its export routine (this'll be another PITA when someone wants to finish
diaconv, the command-line tool). It is very possible that we need to expand
the plug-in structure to add room for "export properties" (a structure
option, opaque and allocated by the plug-in, which is filled by a new
plug-in operation "set properties", etc.). In the short term, several
variants seems good enough.

> - transform Utf8 to Utf16 for omegaTex or to some 8-bit
>   encoding for normal TeX.
>     \footnote{
>        encoding of text is usially
>        setted by \inputenc command in document preambule.
>      }


>   Extra questions:
>   (what is the name of type for utf16 char and utf16 string ?
>    are exists built-in in support libraries transform functions
>    (utf8 -> utf16), or I

raw types defined by <unicode.h> is unicode_char_t. 
Unfortunately, we don't always HAVE_UNICODE, and haven't yet decided to make
it mandatory (I'm for it, but we can't do that if win32 doesn't have it).

lib/charconv.h makes some loops to define "unichar" as gchar or unicode_char_t
and wraps unicode.h in general into something that is supposed to work
everywhere. uni_get_utf8() will allow you to get each character of an UTF-8
string into (unichar* result).

Re-reading the code, it looks like lib/charconv.h should be amended thusly:

(in the #ifndef UNICODE_WORK_IN_PROGRESS case):
#ifdef HAVE_UNICODE
typedef unicode_char_t unichar;
#else
typedef gchar unichar;
#endif


>    can use code from unicode consorcium. ?
In theory, you could, if it was GPL-compatible.

>    are exists built-in in support libraries transform functions
>    (utf8 -> encoding Name).

see lib/charconv.h, in particular charconv_local8_to_utf8 (and back).
This'll work only between UTF-8 and the local 8-bit charset (or UTF-8 if the
locale is UTF-8).

>   - in terms of 'soft-localization' code is Ok.
>    (i. e. current code will work with utf8, but TeX will not be
> able to interpet it correctly. )

> So, I think current patch [ with TODO record ] will ok as
> short-term solution (it does not make thing worse), then when we
> will learn, how to do first approach, we will write extra code for
> handling of different TeX input encodings.

OK.

	-- Cyrille

-- 
Grumpf.