Re: [NTG-context] German ß

Wolfgang Zillig wrote:

Hello,

I tried following things: 1. \enableregime[win] äöü is working; ß is shown as SS

Strange. If you take a look at enco-def.tex, you'll notice that \Ssharp will expand into SS, but I have no idea why this would happen with \ssharp. Where did I miss the definition?

2. \enableregime \[il1] öäü and ß comes wrong 3. \enableregime[win] \definecharacter ssharp 255 äöü is working; ß is shown as SS \ssharp results in ß 4. \enableregime[il1] \definecharacter ssharp 255 äöü are wrong; ß is shown as ß

When I take a look to regi-win.tex and regi-il1.tex, both definitions for the character 223 appear to be OK (\defineactivetoken 223 {\ssharp}). I have no idea where the difference comes from. You have to write \definecharacter ssharp 25, not 225. If you look at the .enc or .afm files of your font, there's a "germandbls" located on the 25th slot. But I can't really track down your examples. They are too confusing.

5. and completely strage: using \ss in the text changes from there on to the font LMSans12! And there ß and öäü is working.

\ss stands for "sans" in ConTeXt (just as if someone would try to switch the language to Slovenian with \sl). I'm not sure about which meaning of "\ss" would have the priority here, but I'm almost sure that it won't be changed. You can use \ssharp or the proper regime.

I really have to state that I don't understand the font font handling completely but I think some things changed here in the last time.

I hope that anybody can give me a hint how to use fonts (especially that ones from the latex-hfbright package)

I have absolutely no idea about the fonts (I'm unable to install one), but I can explain you a bit about the mechanism behind. It's not a very clear way of explaining - I hope that you'll catch at least a little bit of it. There are (at least) two layers of "encodings" The first one, called "regime" in ConTeXt (and inputenc in LaTeX) takes care that the bytes in your input file transform into something meaningful for TeX and the second layer, "encoding" in ConTeXt (fontenc in LaTeX) takes care that this "something meaningful" chooses the proper glyph from the font you provided. Examples of regimes are il1 (iso latin 1), win (cp1252), utf (utf-8), ... They are pretty standard and if there's a mistake in the regi-*.tex file, it should be removed right away. Examples of encodings (font encodings) are OT1 (standard in TeX), ec/cork/T1, texnansi, ... They are supposed to be standard, but it may be that some glyphs in your font are missing, that font comes in some obscure font encoding, that encodings themselves are buggy and nonstandard (ec contains some glyphs with strange names and some duplucates), that there is no standard at all (Arabic, symbol fonts) ... TeXnansi is supposed to be somehow recommended for the usage with ConTeXt for Western European. It may also be that it is the default (instead of the default OT1 in TeX) and that there's no "undo texnansi" except if you delete a couple of lines in ConTeXt source or if you write your own enco-ot1.tex file. OT1 is needed for your font (you could recode the font as well, but this requires some additional skills and you would have to do that on every computer where you want to compile your document then). When you define a regime (such as il1 or win), the bytes in your input file will turn into "named glyphs". If there's a char 223 in your file (which is defined to be ß in iso latin 1, but may be just any other character in another regime), you'll see the definition \defineactivetoken 223 {\ssharp} in regi-win.tex. Now that you have this \ssharp you have to tell TeX which glyph from the chosen font to use. Fonts have only 256 slots and ß is located at position 25 in OT1 (default) encoding. But you have to tell ConTeXt about that. This happens in enco-xxx.tex when you choose an encoding. If you had a font in ec encoding, the definition \definecharacter ssharp 255 in enco-ec.tex would do that for you. ConTeXt processes the enco-def.tex file first. Strange letters that are not present in your font, but could be faked, are defined there. \Ssharp expands into SS there, \ssharp goes into the character 25, some accents are built there, ... When you tell ConTeXt that you would like to use ec font encoding, some of the definitions are replaced. \definecharacter Thorn 222 in enco-ec.tex will explain to ConTeXt that character 222 can be used when someone types in \Thorn or "Þ" in the proper encoding. In any other encoding \Thorn would be ignored. I don't know how you prepared your typescript file (and I guess that I wouldn't understand it anyway), but the problem may be that you are instructing ConTeXt to use the wrong encoding. Perhaps even if you don't define any encoding explicitly, it perhaps defaults to texnansi. (sorry for philosophising) Mojca

Mojca Miklavec schrieb:

...

Wolfgang Zillig wrote:

...

Hello,

i have some problems with an selfcreated typescriptfile. Until one of the last context-updates everythin works fine. The font I use is from the hfbright package (the hfbright package is a free version of the cmbright font) but when I created that typescript I did't relalize that a full font package was available and I renamed the fonts (therefore I will not provide that ugly typescript file here). I don't know what has changed but the german Я is not working any more. I use as font encoding ec and as regime win.

I'm a bit confused where exactly my problem lies: either the encoding is wrong, but I do't know which one is right because in the latex package hfbright the encoding is called OT1. Has anyone an idea how to fix this problem or can anyone help me to set up a context module like the hfbright-module?

Many thanks

Wolfgang

Out of curiosity: what happens if you add the following line somewhere after the definition of encoding and after font switching?

\definecharacter ssharp 25

Also try to test a word like "bi\ssharp chen" (this should prevent problems with input regime).

If this works, it's necessary to add support for OT1 (if this is not already default), see http://source.contextgarden.net/enco-ec.tex for example.

Ec is not supposed to work properly (in LaTeX it's known under the name T1), texnansi also has other character positions, but ssharp could work there.

Mojca