Re: ec encoding and tcaron

[Vit Zyka <vit.zyka@seznam.cz>]

[-- Attachment #1: Type: text/plain, Size: 4822 bytes --]

Hans Hagen wrote:
> Vit Zyka wrote:
> 
>> Hi all,
>>
>> let allowed me some pessimism. I am working on our 
>> 40-years-scout-group-bulletin intensively for more then a month. I 
>> have to solve many many technical problems instead on focusing on the 
>> design. The Bulletin is rather complex but many problems are 'simple'. 
>> I start to doubt if ConTeXt (and that is why TeX generally) is good 
>> tool for such typsetting. Detective debugging is good fun but if time 
>> is going, no results, and the list of todo technical unwanted features 
>> is increasing...
>>
>> Only some of these 'bugs' I presented in this list. Even such number 
>> would be looking as making only troubles. Never mind, here is another 
>> problem I am puzzled by for 4 hours...
>>
>> Please imagine a simple code in ISO-8859-2:
>> --------------------------------------
>> \enableregime[il2]
>> %\enableregime[latin2]
>>
>> \usetypescript[modern][ec]
>> \setupbodyfont[10pt,rm]
>>
>> \starttext
>> ťŤ          % \tcaron\Tcaron
>> \WORD{ťŤ}
> 
> 
> 
> i see utf8 here -)

Yes, my e-mail client work in utf8. For reading good solution, next I 
attach zip for testing.

>> \stoptext
>> ---------------------------------------
>> It produces an error
>>   ! Undefined control sequence.
>>   <to be read again> ¢
>> It comes from the first letter inside \WORD{...}. The same letters 
>> outside \WORD are typeset OK. So ť is not defined. But where it should 
>> be defined? \tcacon def is OK. Other diacritics chars e.g. \dcaron, 
>> \rcaron are OK.
>>
>> I was looking to enco-ec, enco-il2, regi-lat. Upper/lower mapping and 
>> char codes seems to be OK. But more I looking into I less understand 
>> it. There is no regi-il2 file, so I expect that appropriate info goes 
>> from enco-il2. But any other (perhaps more appropriate) combination like
>>   \enableregime[latin2]
>>   \usetypescript[modern][ec]
>> or
>>   \usetypescript[modern][il2]
>> gives totaly wrong glyphs.
>>
>> I believe that ť uppecase bug also relates with ignoring making 
>> pseudo-caps for this letter by
>>   texfont --fontroot=X: --en=ec --ve=public --co=lm --source=auto 
>> --ca=0.8 lmbx10
>> So problem is somewhere in ec encoding.
>>
>> Can somebody help please? Thanks and sorry for my embittering - it 
>> aims to my own head.
> 
> 
> firts of all, i need zipped test files, since mailes mess around with 
> encodings.
> 
> next, can you try the alpha release, since it has some fixes (much of 
> the encodings were not complete in the sense of lc/uc mappings); also 
> mojca made teh latin encodings more complete

I am using latest greatest alpha with new formats with newtexexec...
(I got it in the beginning of the week for testing sorting.)

> don't worry, it should work ok,
> 
> part of the problem is that il2 encoding (font encoding) is rather 
> useless and incomplete but it happened to be the prefered one for czech 
> cum suis (mostly computer modern related) and crossing language borders 
> was not part of the game; (the same is true for pl0 encoding for polish 
> and the polish computer modern; but qx encoding is supposed to handle 
> both polisg and czech etc ok)

I am using ec font encoding, il2 only as input encoding (regime). I can 
use any other in xemacs, but il2 is from historical reason.

Never mind, problem is the same with utf8 input encoding, see 
attachment. I beleive the problem is not in il2 but somewhere in ec.

Clue: Where texfont gives info about appercase letters for -ca switch 
(pseudo small caps)???

> it's actually even more messy when one looks into hyphenation, since 
> most patterns are ec bases (czech patterns also can handle il2), which 
> is why context now ships with generic patterns that can be used in other 
> font encodings as well;
> 
> regimes are just part of the input game, the active chars expand to 
> names glyphs that themselves expand to characters; so, if something does 
> not work as you expect, well we should make it work.

This theory is clear for me. Until this weekend I though it is clear 
even practically. But now my char code travelling mechanism is broken :-(

Moment, the idea that comes from Moica's example .... yes!
Line
   \enableregime[utf]
is enough, but in case of il2 you shoud type
   \input regi-lat
   \enableregime[latin2]
How people recognize that some regimes are preloaded and some not? What 
about some error/warning message if using not loaded regime?

So regime starts to be clear again. The only question is:
   Where ConTeXt gives il2 mapping info if one types
   \enableregime[il2]???
(There is no 'il2' string in regi-*.tex; is it from enco-il2.tex?)

---

Please look in the attachment for the \tcaron problem.
vit


[-- Attachment #2: uppercase.zip --]
[-- Type: application/zip, Size: 1739 bytes --]

[-- Attachment #3: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context