Werner LEMBERG wrote: >> - Werner: it has crossed my mind a few times all these years - CJK >> is a bit too generic/confusing - do you have an official logo >> (like the abuse that TeX does with raising/lowering letters...)? > > No, I haven't. Never thought about that :-)
Argh - I sometimes do CJK/Latex to mean the package rather than the collection of large-fontset languages. I am adding a \CJK macro to the notes as is the custom (currently just small cap'ed CJK\LaTeX) but you could think of something. That said - does the package currently defines such a macro/command? That would be confusing. :-) >> - I suppose either of you might want to look at how XeTeX does thai >> line-breaking? > > XeTeX uses ICU's line breaking algorithm for Thai which is the same as > with cttex, I think. Looking into polyglossia's Thai support, > however, the central command > > \XeTeXlinebreaklocale="th" > is commented out.[...] The first time I did chinese with XeTeX a few weeks ago I was also surprised I needed 'zh'! It is an FAQ on XeTeX's web site. Maybe polyglossia is following a convention? > BTW, you write in your attached PDF file: > > TeXLive 2011 does not bundle the emacs lisp scripts. > > This is not correct. You can find them in > > $TEXMF/source/latex/cjk/utils/lisp/ Argh, Fedora's texlive 2011 is not shipping it anywhere. In any case, how do you envision it being used on multi-user systems? It isn't ready to be hooked into /usr/share/emacs/site-lisp. Theppitak wrote: > On Wed, Dec 07, 2011 at 03:52:55AM +0000, Hin-Tak Leung wrote: > >> Here is my notes on Thai with LaTex - I am okay with either of you >> shipping it (and the source of it) with CJK or ThaiLaTeX, but I just >> like to fix a few things first: > > My problem with it is that thailatex installation as described there > is over-complicated. I think it is clearer (for those who want to understand how it works). I could replace all the 6 environment variables with just one (HOMETEXMF , which defaults to $HOME/texmf ), and a tree-layout. Also, I don't use /usr/local, nor install non-packaged software on my system. i.e. software not tracked by apt(or rpm or yum or yast) are in /home or not all all. So installing a small library (datrie) just to build a small tool swath, just doesn't do for me. I think you should consider needs of people who don't have admin access to their little unix boxes. > In brief, you just need libdatrie, from here: > > ftp://linux.thai.net/pub/thailinux/software/libthai/ > > Historically, swath used to bundle an outdated and unmaintained version > of libdatrie. And that had caused maintenance problem as its word break > dictionary couldn't be modified any more, due to incompatibility with > newer command-line tools. Meanwhile, libdatrie was rewritten for use in > the libthai project. So, swath was later migrated to the new one instead. > That's the benefit of code sharing over bundling. libdatrie does not seem to have libthai dependency currently? There is the problem with over-dividing as well, when one only wants to build one small tool that depends on another small library which few others needs. Anyyway, here is the receipe to build swath without needing libdatrie afterwards - and that *is* complicated for trying to build a small command-line tool. ==================== # unpack the two sources in parallel: cd libdatrie-0.2.5/ # --disable-shared, so swath does not need it afterwards ./configure --enable-static --disable-shared make # cd ../swath-0.4.1/ # swath build needs one of the datrie-tools export PATH=`pwd`/../libdatrie-0.2.5/tools/:$PATH # The /.libs/ below is a libtool quirk: DATRIE_LIBS="-L`pwd`/../libdatrie-0.2.5/datrie/.libs/ -ldatrie" \ PKG_CONFIG_PATH=`pwd`/../libdatrie-0.2.5/ \ DATRIE_CFLAGS=-I`pwd`/../libdatrie-0.2.5/ ./configure make ================= I think you have completely lose context with your potential users - to try out something which may or may not work well to my purpose (or somebody's purpose), I do not want to pollute my /usr/local just to try something out. So if something is this difficult to *try out* without system-wide install, it does not get installed system-wide . > Treat thailatex like a "shared library". It's no longer an end-user > package. The fonts are, just like lmodern et al. That's where your mentality doesn't work for some users - thailatex is a small add-on package I like to try out, which may or may not suit my use, overall. I don't want to install it system-wide as a shared resources, until I have estalished its general usefulness. > The designed way: ... > sudo make install ... > sudo make install > 2. Install thailatex > make > [sudo] make install > 3. Install fonts > [sudo] make install You will find it hard to persuade potential users to 'sudo make install' a piece of software of unknown usefulness, just to try it out. You are asking for a lot of trust from your *potential* users that you do not do make a mess in their /usr/local or the TEXMF tree. _______________________________________________ Cjk maillist - Cjk@ffii.org https://lists.ffii.org/mailman/listinfo/cjk
