RE: language specifics

RE: language specifics

[Berend de Boer]

> The main problem is in the weird ones. I have no problem with
> the "e and alike ones, but using them for compound words and
> quotes is a bad idea, since context has dedicated
> alternatives for those, which also have options.

For me "e and such is good enough. For the others, I'm quite used to the
alternatives.

Groetjes,

Berend. (-:

Re: language specifics

[Hans Hagen]

On 7-5-2010 9:25, Peter Münster wrote:
> On Thu, May 06 2010, Hans Hagen wrote:
>
>> in mkiv we don't have (want) language specifics ... why do yoi need them?
>
> Hello Hans,
>
> What is now the right mechanism, to trigger some setting when a specific
> language is activated and cancel this same setting, when this language is
> deactivated?
>
> Example: when entering French language, I want to execute
> "\setcharacterspacing[frenchpunctuation]" and when leaving French I want to
> execute "\setcharacterspacing[reset]".
>
> (today the file
> http://dl.contextgarden.net/modules/t-french/tex/context/third/french/t-french.tex
> is broken, because I don't know how to do it right... :(

you can then probably just enable it as i cannot imagine a document 
which uses mixed typographical habits that still looks right

anyway, there will be some mechanism but probably more at the level of 
the features itself (i.e. as part of setcharacterspacing) as there have 
to be ways to turn on/off specific language bound features. The mkii 
language specifics were mostly meant for encoding issues and those 
trigger points have disappeared as encodings are gone now.

Hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: language specifics

[Hans Hagen]

At 09:20 PM 11/16/99 +0100, Tobias Burnus wrote:

>> a) Do we still have to account for 7-bit ascii?
>YES! Using our local computer network (physics department), all DEC computers
>don't have umlauts on their keybord (the FreeBSD ones, have but they usually
>don't work). Using accented letters on Telnet connections does sometimes, but
>not always work, etc.

When you take a look at up to date 001 you will see that keying in 
\"u in a text field indeed gives an u-umlaut (javascript) -) I can make a german JS, converting "u into uumlaut too. 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: language specifics

[Tobias Burnus]

Hi all,

> > The main problem is in the weird ones. I have no problem with the "e
> > and alike ones, but using them for compound words and quotes is a bad
> > idea, since context has dedicated alternatives for those, which also
> > have options. To what extend do we need to satisfy habits and features
> > from for instance latex?
The use of "a, "s etc is very important not only because of backward
compatiblity, but also
a) the \ss doesn't bring you a "s = \SS = ß
b) thinks like "ck only get be used when they are simple to type in.

> It is a sensible argument that many of the abbreviations I've been
> discussing to you in the last few days may be kind of complicated crap,
> let alone of no use to a lot of languages.
Well the complication and number of languages shouldn't be the problem,
but I don't see the necessarity for "` "' (I recently tried them on a lecture
evaluation form (LaTeX powered) and got instancely the wrong ones ("...,,), so I
prefer \quote and \quotation.

> The german package for that instance has evolved for the last twelve
> years, so that I expect the basics to having been settled. On the other
I don't need them, but I think you can add them to cont-sys.tex as your personal
setup. (maybe also a using \writestring{DON'T FORGET ME TO ADD, WHEN DISTIBUTING
THIS TEX FILE})

> Thus, if context has even more powerful tools that can cope in all
> necessary cases, maybe this is the time to consider turning to a more
> reasonable source encoding. In this case, my questions are:

> a) Do we still have to account for 7-bit ascii?
YES! Using our local computer network (physics department), all DEC computers
don't have umlauts on their keybord (the FreeBSD ones, have but they usually
don't work). Using accented letters on Telnet connections does sometimes, but
not always work, etc.

Regards,

Tobias

RE: language specifics

[Berend de Boer]

> a) Do we still have to account for 7-bit ascii?

I think the answer is yes. 7-bit or else unicode. 7-bit is readable even
through the most basic telnet package or weird ms-dos code page.

Groetjes,

Berend. (-:

Re: language specifics

[Karsten Tinnefeld]

> The main problem is in the weird ones. I have no problem with the "e
> and alike ones, but using them for compound words and quotes is a bad
> idea, since context has dedicated alternatives for those, which also
> have options. To what extend do we need to satisfy habits and features
> from for instance latex?

It is a sensible argument that many of the abbreviations I've been 
discussing to you in the last few days may be kind of complicated crap, 
let alone of no use to a lot of languages.

However, the functionality provided appears to me to be quite important 
- at least as long as we still build on 7- or 8-bit input code sets. 
The german package for that instance has evolved for the last twelve 
years, so that I expect the basics to having been settled. On the other 
hand, all but the very simplest ligatures are defined more or less 
arbitrarily, and explaining plain paragraph source to a wysiayg user is 
a nontrivial task.

Thus, if context has even more powerful tools that can cope in all 
necessary cases, maybe this is the time to consider turning to a more 
reasonable source encoding. In this case, my questions are:

a) Do we still have to account for 7-bit ascii?
b) How do we encode the various ways of hyphening and dash-ing in a most 
   non-ideosyncratic way?

Karsten
-- 
Karsten Tinnefeld                       tinnefeld@ls2.cs.uni-dortmund.de
Fachbereich Informatik, Lehrstuhl 2                   T +49 231 755-4737
Universität Dortmund, D-44221 Dortmund, Deutschland   F +49 231 755-2047

language specifics

[Hans Hagen]

Hi all, 

There have been some mails on language specifics in dutch, but in croation they also seem to apply. I wonder if we always want those specifics to be the default, since there is no real way to turn them off. So, an option is to add a key to each \setuplanguage, which can be set by the user in cont-sys.tex or in the file itself. On the other hand, this would mean breaking downward compatibility for german and polish, since they default to specifics. The complication is that I probably have to group them (more convenient). 

The main problem is in the weird ones. I have no problem with the "e and alike ones, but using them for compound words and quotes is a bad idea, since context has dedicated alternatives for those, which also have options. To what extend do we need to satisfy habits and features from for instance latex? 

Hans      

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------