Re: [NTG-context] naming and distribution of typescripts
On Wed, 27 Aug 2003 21:12:09 +0200 Henning Hraban Ramm [EMAIL PROTECTED] wrote: Am Dienstag, 26.08.03, um 22:13 Uhr (Europe/Zurich) schrieb Jens-Uwe Morawski: Is there some standard how to name typescripts and locate them in a texmf-tree, so that distribution of typescripts is possible in a controled way? I always name them type-vendor-collection.tex (e.g. type-adobe-palatino.tex) and put them into mytexmf/tex/context/user IMO, the problem is that an official external package should not put something in user/. Therefore i would prefer something like TEXMF/tex/context/type/, but here Hans has to agree so that future versions of ConTeXt do not use this directory too. Typescripts are simply TeX files -- you could put the commands even in your environment file or like that -- so they should stay with tex instead of inventing something new that nobody (and noproggy) understands. ok, on the other hand LaTeXs fd-files are only TeX files too. Jens ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] \dosetupsystem ????!
At 11:55 28/08/2003 +0900, you wrote:
Hans
it seems that something is happening in the top file (the option file
writtemn by texexec); did you change something in texexec.ini? is there
some magic in your local cont-sys.tex? can you grep you system for
{\setupsystem ?
Hans,
Is texexec in any way influenced by OS environment variables? The warning
Don't change language in unprotected mode in my log file caught my
attention because a few days ago I added an environment variable LANG =en
to my system (my OS not TeX).When I deleted this variable, texexec
went back to running without any trouble. The error can't have been
caused by any customizations in my texexec.ini or cont-sys.tex because
even when I re-installed TexLive from scratch and didn't setup those
files, texexec still ran into trouble in the top file with \setupsystem.
Don't change ... is generated when an \unprotect has no matching \protect
which can be dabgerous for esp french (active : and so).
Texexec is not influenced by env vars; how does your jobname.tmp (afte a
texexec run) looks (this is the saved options file).
Hans
-
Hans Hagen | PRAGMA ADE | [EMAIL PROTECTED]
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-
information: http://www.pragma-ade.com/roadmap.pdf
documentation: http://www.pragma-ade.com/showcase.pdf
-
___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context
Re[3]: [NTG-context] parameter mechanism
At 19:22 27/08/2003 +0200, you wrote:
Wednesday, August 27, 2003 Giuseppe Bilotta wrote:
GB Wednesday, August 27, 2003 Hans Hagen wrote:
HH At 16:56 27/08/2003 +0200, you wrote:
The trick is in mult-ini.tex, which redefines dosetvalue co
to support the multilingual interface; this is a problem when
you want to get raw (unconverted) keyword/value sets, which is
why it fails. ConTeXt used to have raw version of the
do..value commands, but they disappeared at one point. Yes,
they should be re-introduced.
HH i dunno what grep you have but mine gives:
HH syst-new.tex:\def\getrawparameters
HH {\dogetparameters\dosetrawvalue }
HH syst-new.tex:\def\getraweparameters
HH {\dogetparameters\dosetrawevalue}
HH syst-new.tex:\def\getrawgparameters
HH {\dogetparameters\dosetrawgvalue}
HH syst-new.tex:\def\getrawxparameters
HH {\dogetparameters\dosetrawxvalue}
GB I can't believe I missed them! What was I looking for?
BTW is there any difference between this and the variables
system?
the difference is that an undefined variable gives an empty string instead
of \relax
Hans
-
Hans Hagen | PRAGMA ADE | [EMAIL PROTECTED]
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-
information: http://www.pragma-ade.com/roadmap.pdf
documentation: http://www.pragma-ade.com/showcase.pdf
-
___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] parameter mechanism
First of all thank you to all of you who aswered. My test command works now, so the days of stuff like \def\mymacro#1#2#3... are counted :) I still have problems changing from \xdescgetparameters to the \rawgetparameters command (I'll try to fix this later). Regards, Peter P.S.: my grep version is 2.4.2 ;) Cmd.tex Description: TeX document
[NTG-context] Re: \dosetupsystem ????!
Hans Hagen [EMAIL PROTECTED] writes: Texexec is not influenced by env vars But TeX is. I once had trouble with 8bit characters; TeX was looking for the locale setting. But that is the only thing I know about. Patrick -- Silent is the goldfish in its bowl ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] CJK support in ConTeXt
It's time to discuss the topic CJK support in ConTeXt in a more public place. Agree! The currently ConTeXt release support UTF-8, CJKV locales can all be represented in UTF-8, so the mechanism is already done. IMHO, the real one work to do is to make the sets of typesetting conventions (typesetting rules) for each locale of CJKV (like the Chinese package did), that would varies quite much from locale to locale, all all of them are based on the same underlayed mechanism. Best, Hong _ Do You Yahoo!? []+ http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.messenger.yahoo.com ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
RE: [NTG-context] CJK support in ConTeXt
Hong Feng wrote: The currently ConTeXt release support UTF-8, CJKV locales can all be represented in UTF-8, so the mechanism is already done. IMHO, the real one work to do is to make the sets of typesetting conventions (typesetting rules) for each locale of CJKV (like the Chinese package did), that would varies quite much from locale to locale, all all of them are based on the same underlayed mechanism. My very first experiment with trying to use Japanese with ConTeXt made use of ConTeXt's built-in support for UTF-8. I soon found out that there is no line breaking present when UTF-8 support is used. So that has to be implemented. I'm not sure, but I remember that Hans once told me that that the typesetting mechanism and line breaking algorithm as used in the Chinese module cannot be directly used for UTF-8 support. Therefore I'm not sure if we can simply say that the 'mechanism is already done'. Maybe Hans can tell how difficult it is to add a line breaking mechanism to the UTF-8 support? It would be really handy if we could use ConTeXt's UTF-8 support so that some work for a CJK module is already done. But on the other hand, by using e-Omega, a lot of work is also already done. We have to make sure that adapting the UTF-8 mechanism doesn't take more time and effort than creating a module based on e-Omega. A CJK module based on e-Omega is maybe easier to write and more flexible. For example, not everyone can write documents in UTF-8. e-Omega will allow almost any kind of file encoding as long as there is an OTP available to convert it to Unicode. So I think the questions we have to ask ourselves are: Do we make line breaking and typesetting algorithms for ConTeXt's UTF-8 support or for e-Omega? What is the time and effort needed in creating a CJK module for each solution? And what solution gives the most powerful typesetting options? Personally, I would go for the e-Omega option, but I wouldn't mind seeing a module based on ConTeXt's UTF-8 support. As long as there is support for CJK, I'll be happy! :) My best, Tim ___ ntg-context mailing list [EMAIL PROTECTED] http://www.ntg.nl/mailman/listinfo/ntg-context
