Re: ec encoding and tcaron

Re: ec encoding and tcaron

[Richard Gabriel]

[-- Attachment #1.1: Type: text/plain, Size: 2177 bytes --]

Hello Michal, 

I'm sure the EC encoding contains the 'tcaron' character (see the lm-ec.enc file for example).
I have ConTeXt on top of TeXLive 2005.
I can find:
texmf/fonts/enc/dvips/base/ec.enc
texmf/fonts/enc/dvips/lm/ec-lm.enc
texmf/fonts/enc/dvips/lm/lm-ec.enc

I use EC normally for typesetting Czech documents. So I would suggest to use EC ;-)

-Richard


  _____  

From: Michal Kvasnicka [mailto:quasar@econ.muni.cz]
To: mailing list for ConTeXt users [mailto:ntg-context@ntg.nl]
Sent: Fri, 09 Jun 2006 12:11:11 +0200
Subject: [NTG-context] ec encoding and tcaron

Dear friends,
  
  I apologize that I ask the same question that had been asked a year ago 
  but I can't find in the archive the definite solution.
  
  I want to use new fonts in the ConTeXt to typeset the Czech documents. 
  TeXFont seems to be the best way to prepare metrics. EC encoding seems 
  to be the standard ConTeXt encoding. But it doesn't include tcaron 
  (well, this is true at least for EC.enc on my teTeX 3.0 under the SuSE 
  Linux 10.0 with the latest ConTeXt from May 28). (In the Czech the lower 
  case of Tcaron looks like tqouteright but nowadays most AFM files call 
  it tcaron).  Other glyphs may miss as well (I might not notice since I 
  suspect that ConTeXt replaces missing letter with composites, e.g. 
  Ecaron with \v{E}).
  
  So, what is the standard way I should use? I can use ec-lm.enc but is it 
  the right way? (Moreover, it seems there is no information for 
  ligatures.) I could try to use il2, but is the right way? And I had some 
  problems with xl2.enc used formerly for il2-encoded fonts.
  
  So, what was decided to be the right encoding for the ConTeXt? (Is the 
  answer the same for the Czech typesetters?)
  And one more question: Does anybody have the enc file that would make 
  the TeXFont to generate metrics for il2-encoded fonts for the use with 
  csplain (the Czech version of plainTeX)?
  
  Sincerely yours
  Michal Kvasnicka
  
  _______________________________________________
  ntg-context mailing list
  ntg-context@ntg.nl
  http://www.ntg.nl/mailman/listinfo/ntg-context
    

[-- Attachment #1.2: Type: text/html, Size: 2808 bytes --]

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

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

Re: ec encoding and tcaron

[Michal Kvasnicka]

Hi Richard.
> I'm sure the EC encoding contains the 'tcaron' character (see the 
> lm-ec.enc file for example).
> I have ConTeXt on top of TeXLive 2005.
> I can find:
> texmf/fonts/enc/dvips/base/ec.enc
> texmf/fonts/enc/dvips/lm/ec-lm.enc
> texmf/fonts/enc/dvips/lm/lm-ec.enc
>
> I use EC normally for typesetting Czech documents. So I would suggest 
> to use EC ;-)
I'm sorry you're not right. The lm-ec.enc really includes tcaron, but 
neither ec.enc nor EC.enc does, at least at my teTeX 3.0. If you use 
only LatinModern, it works, because lm-ec.enc is used. But I doubt it 
works well for other fonts. Does it? I was unsuccessful. Can you send me 
your ec.enc file please?

Yours
Michal Kvasnicka

P.S. It's nice to hear that more Czech use the ConTeXt.

Re: ec encoding and tcaron

[Vit Zyka]

Michal Kvasnicka wrote:
> Hi Richard.
>> I'm sure the EC encoding contains the 'tcaron' character (see the 
>> lm-ec.enc file for example).
>> I have ConTeXt on top of TeXLive 2005.
>> I can find:
>> texmf/fonts/enc/dvips/base/ec.enc
>> texmf/fonts/enc/dvips/lm/ec-lm.enc
>> texmf/fonts/enc/dvips/lm/lm-ec.enc
>>
>> I use EC normally for typesetting Czech documents. So I would suggest 
>> to use EC ;-)
> I'm sorry you're not right. The lm-ec.enc really includes tcaron, but 
> neither ec.enc nor EC.enc does, at least at my teTeX 3.0. If you use 

I believe this bug was fixed more then a year ago. The names of ec-lm 
and lm-ec was changed during a time a year ago. teTeX 3.0 has not 
changed since last year since it is dead.

Vit

> only LatinModern, it works, because lm-ec.enc is used. But I doubt it 
> works well for other fonts. Does it? I was unsuccessful. Can you send me 
> your ec.enc file please?
> 
> Yours
> Michal Kvasnicka
> 
> P.S. It's nice to hear that more Czech use the ConTeXt.

Re: ec encoding and tcaron

[Mojca Miklavec]

On 6/9/06, Michal Kvasnicka wrote:
> Hi Richard.
> > I'm sure the EC encoding contains the 'tcaron' character (see the
> > lm-ec.enc file for example).
> > I have ConTeXt on top of TeXLive 2005.
> > I can find:
> > texmf/fonts/enc/dvips/base/ec.enc
> > texmf/fonts/enc/dvips/lm/ec-lm.enc
> > texmf/fonts/enc/dvips/lm/lm-ec.enc
> >
> > I use EC normally for typesetting Czech documents. So I would suggest
> > to use EC ;-)
> I'm sorry you're not right. The lm-ec.enc really includes tcaron, but
> neither ec.enc nor EC.enc does, at least at my teTeX 3.0. If you use
> only LatinModern, it works, because lm-ec.enc is used. But I doubt it
> works well for other fonts. Does it? I was unsuccessful. Can you send me
> your ec.enc file please?

Approximately a year ago there was a discussion on tex-fonts mailing
list about fixing ec.enc (for example there's a glyph called "dbar",
which is agains any standards: in Unicode it's called "d with stroke"
and according to Adobe standards it should be called "dcroat"; and
many more inconsistencies).

The result of the discussion was something like: "No, we may not
change this since it may break functionality of some fonts which used
that standard years ago. Googling for this and that reveales that some
fonts still use those old glyph names ..." (perhaps Google found 4
hits or so ...) The explanation/excuse was that everyone using modern
glyph names should create his own "ec.enc" (just as it was done for
Latin Modern).

I would recommend you to use lm-ec.enc or tex256.ec ("fixed" version
of ec.enc which should be present in the same folder as ec.enc). The
Polish guys did their best to follow the standards, so the ec file of
Latin Modern should be OK for most fonts. If some glyph is still
missing, you can manually change the encoding definition (and then
note that specific encoding in map file as well, in the same was as
it's done for LM).

You can test the resulting font with
    \showfont[yourfontname] % where yourfountname should preferrably
be ec-something
In that way you'll spot any missing glyphs pretty easily.

About xl2.enc: it is incomplete and neiter supported by ConTeXt (it
could be, but there's no real benefit) nor by most popular fonts (you
have to create metrics and everything by yourself, so your files might
be highly unportable). I dropped the idea about using it pretty soon.
It's not impossible to use it, but probably not worth it.

Mojca

ec encoding and tcaron

[Michal Kvasnicka]

Dear friends,

I apologize that I ask the same question that had been asked a year ago 
but I can't find in the archive the definite solution.

I want to use new fonts in the ConTeXt to typeset the Czech documents. 
TeXFont seems to be the best way to prepare metrics. EC encoding seems 
to be the standard ConTeXt encoding. But it doesn't include tcaron 
(well, this is true at least for EC.enc on my teTeX 3.0 under the SuSE 
Linux 10.0 with the latest ConTeXt from May 28). (In the Czech the lower 
case of Tcaron looks like tqouteright but nowadays most AFM files call 
it tcaron).  Other glyphs may miss as well (I might not notice since I 
suspect that ConTeXt replaces missing letter with composites, e.g. 
Ecaron with \v{E}).

So, what is the standard way I should use? I can use ec-lm.enc but is it 
the right way? (Moreover, it seems there is no information for 
ligatures.) I could try to use il2, but is the right way? And I had some 
problems with xl2.enc used formerly for il2-encoded fonts.

So, what was decided to be the right encoding for the ConTeXt? (Is the 
answer the same for the Czech typesetters?)
And one more question: Does anybody have the enc file that would make 
the TeXFont to generate metrics for il2-encoded fonts for the use with 
csplain (the Czech version of plainTeX)?

Sincerely yours
Michal Kvasnicka

ec encoding and tcaron

[Vit Zyka]

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{ťŤ}
\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.
vit

Re: ec encoding and tcaron

[Hans Hagen]

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 -)

>
> \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

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)

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.



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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Vit Zyka]

[-- 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

Re: ec encoding and tcaron

[Hans Hagen]

Vit Zyka wrote:

> 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...

(btw, magazines can be doen quite well with columnsets) 

Here is a patched WORD (core-fnt):

\chardef\uppercasemode\plusone % 0=ignore 1=normal 2=expand

\unexpanded\def\WORD#1%
  {\bgroup
   \the\everyuppercase
   \let\smallcapped\firstofoneargument
   \let\WORD\firstofoneargument
   \let\dochar\rawcharacter
   \ifcase\uppercasemode
     #1%
   \or % No expansion here, otherwise \getvalue problems! Default!!!
    %\edef\next{#1}% keep this to prevent roll back
    %\uppercase\expandafter{\next}% keep this to prevent roll back
     \uppercase{#1}%
   \or
     \expanded{\uppercase{#1}}% needed when in utf8
   \fi
   \egroup}

And here a patched \definecharacter (enco-ini)

\def\numcharacter#1{\char#1 }
\let\dochar\numcharacter

\def\definecharacter#1 #2 %
  {\ifundefined{#1}\setvalue{#1}{\dohandlecharacter{#1}}\fi
   \doifnumberelse{\string#2}
     {\setevalue{\characterprefix\characterencoding\string#1}%
        {\dochar{#2}}%
      \doautosetregime{#1}{#2}}
     {\setvalue{\characterprefix\characterencoding\string#1}{#2}}}

% goes on top of enco-utf 

\prependtoks
  \doif\currentregime{utf}{\chardef\uppercasemode\plustwo}%
\to\everyuppercase


% \input enco-ini-new.tex

% \startmapping [ec]
%   \defineuppercasecom \something \nothing 
% \stopmapping

\input enco-ec.tex % needed when no new format 

\starttext

\enableregime[utf] \usetypescript[modern][ec] \setupbodyfont[10pt,rm]

ť Ť \ccaron

\WORD{ť Ť \ccaron}

\stoptext

I didn't test this with latin input; the trick is to let the named glyphs expand to a raw character which then can be uppercased by tex. quite dirty. It is dangerous to do this always because in the case of written/reread data we cannot output raw characters since they would eb regimes again (this time in the wrong way). 

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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Vit Zyka]

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

Hans Hagen wrote:
> Vit Zyka wrote:
> 
>> 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...
> 
> 
> (btw, magazines can be doen quite well with columnsets)
> Here is a patched WORD (core-fnt):
> 
> \chardef\uppercasemode\plusone % 0=ignore 1=normal 2=expand
> 
> \unexpanded\def\WORD#1%
>  {\bgroup
>   \the\everyuppercase
>   \let\smallcapped\firstofoneargument
>   \let\WORD\firstofoneargument
>   \let\dochar\rawcharacter
>   \ifcase\uppercasemode
>     #1%
>   \or % No expansion here, otherwise \getvalue problems! Default!!!
>    %\edef\next{#1}% keep this to prevent roll back
>    %\uppercase\expandafter{\next}% keep this to prevent roll back
>     \uppercase{#1}%
>   \or
>     \expanded{\uppercase{#1}}% needed when in utf8
>   \fi
>   \egroup}
> 
> And here a patched \definecharacter (enco-ini)
> 
> \def\numcharacter#1{\char#1 }
> \let\dochar\numcharacter
> 
> \def\definecharacter#1 #2 %
>  {\ifundefined{#1}\setvalue{#1}{\dohandlecharacter{#1}}\fi
>   \doifnumberelse{\string#2}
>     {\setevalue{\characterprefix\characterencoding\string#1}%
>        {\dochar{#2}}%
>      \doautosetregime{#1}{#2}}
>     {\setvalue{\characterprefix\characterencoding\string#1}{#2}}}
> 
> % goes on top of enco-utf
> \prependtoks
>  \doif\currentregime{utf}{\chardef\uppercasemode\plustwo}%
> \to\everyuppercase
> 
> 
> % \input enco-ini-new.tex
> 
> % \startmapping [ec]
> %   \defineuppercasecom \something \nothing % \stopmapping
> 
> \input enco-ec.tex % needed when no new format
> \starttext
> 
> \enableregime[utf] \usetypescript[modern][ec] \setupbodyfont[10pt,rm]
> 
> ť Ť \ccaron
> 
> \WORD{ť Ť \ccaron}
> 
> \stoptext

Yes, Hans, it works in utf8. In case of il2 it works too if expansion is 
also done:

\prependtoks
  \doif\currentregime{utf}{\chardef\uppercasemode\plustwo}%
  \doif\currentregime{il2}{\chardef\uppercasemode\plustwo}%
\to\everyuppercase

---

Actually I discovered the source of the problem with \tcaron!
There exists enco-ecm.tex file with some exceptions. And there is

   \definecharacter tcaron     {\buildtextaccent\textcaron t}

If I comment this line, expansion is not needed. I suggest to omit it 
since \tcaron is now present in lm.

But \WORD I do not use (it was only product of my debugging) I use 
pseudo caps and there the problem preserves. Files attached and
   texfont --fontroot=X: --en=ec --ve=public --co=lm --source=auto 
--ca=0.8 lmbx10


> I didn't test this with latin input; the trick is to let the named 
> glyphs expand to a raw character which then can be uppercased by tex. 
> quite dirty. It is dangerous to do this always because in the case of 
> written/reread data we cannot output raw characters since they would eb 
> regimes again (this time in the wrong way).

Hans, did you think about Petr Olsak's enc-tex? I believe it is much 
straight-forward solution that solve input enco, output to files and 
output to log (utf8 works too). And it should be much quicker than 
macros. I am not sure, but perhaps there is no patch to aleph now...

vit

[-- Attachment #2: smallcaps.zip --]
[-- Type: application/zip, Size: 1863 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

Re: ec encoding and tcaron

[Mojca Miklavec]

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

Vit Zyka wrote:
> Actually I discovered the source of the problem with \tcaron!
> There exists enco-ecm.tex file with some exceptions. And there is
> 
>    \definecharacter tcaron     {\buildtextaccent\textcaron t}
> 
> If I comment this line, expansion is not needed. I suggest to omit it
> since \tcaron is now present in lm.

If and only if you work with lm & ec. Otherwise building of accents is
quite useful.
(How can I get ec in Antiqwa?)

> But \WORD I do not use (it was only product of my debugging) I use
> pseudo caps and there the problem preserves. Files attached and
>    texfont --fontroot=X: --en=ec --ve=public --co=lm --source=auto
> --ca=0.8 lmbx10

Another *extremely* strange observation.
In a document with ec encoding and some accented characters, searching
for 'č' simply doesn't work. I don't understand why. I know very
little about PDF, but in the resulting document there was this line
present:

/CharSet (/breve/one/D/U/Y/u/Ccaron/Scaron/Tcaron/Zcaron/ccaron/tcaron)

with more or less only the characters I used. The line seems to be OK,
ccaron seems to be present. Searching for 'š' works as expected (even
lower/uppercase is recognised), but at the place of 'č' only c is
recognised (if I copy-pase, only c remains at that place).
I thought that it was only Acrobat's fault, but searching for the same
letter in another document worked OK (documentation for Antiqwa for
example).

Minimal example:

\usetypescript[modern][ec]
\setupbodyfont[10pt,rm]
\starttext
\ccaron\scaron
\stoptext

and then either searching or converting to plain text.

Mojca

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

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

Re: ec encoding and tcaron

[Vit Zyka]

Mojca Miklavec wrote:
> Vit Zyka wrote:
> 
>>Actually I discovered the source of the problem with \tcaron!
>>There exists enco-ecm.tex file with some exceptions. And there is
>>
>>   \definecharacter tcaron     {\buildtextaccent\textcaron t}
>>
>>If I comment this line, expansion is not needed. I suggest to omit it
>>since \tcaron is now present in lm.
> 
> 
> If and only if you work with lm & ec. Otherwise building of accents is
> quite useful.
> (How can I get ec in Antiqwa?)
> 
> 
>>But \WORD I do not use (it was only product of my debugging) I use
>>pseudo caps and there the problem preserves. Files attached and
>>   texfont --fontroot=X: --en=ec --ve=public --co=lm --source=auto
>>--ca=0.8 lmbx10
> 
> 
> Another *extremely* strange observation.
> In a document with ec encoding and some accented characters, searching
> for 'č' simply doesn't work. I don't understand why. I know very
> little about PDF, but in the resulting document there was this line
> present:
> 
> /CharSet (/breve/one/D/U/Y/u/Ccaron/Scaron/Tcaron/Zcaron/ccaron/tcaron)
> 
> with more or less only the characters I used. The line seems to be OK,
> ccaron seems to be present. Searching for 'š' works as expected (even
> lower/uppercase is recognised), but at the place of 'č' only c is
> recognised (if I copy-pase, only c remains at that place).
> I thought that it was only Acrobat's fault, but searching for the same
> letter in another document worked OK (documentation for Antiqwa for
> example).
> 
> Minimal example:
> 
> \usetypescript[modern][ec]
> \setupbodyfont[10pt,rm]
> \starttext
> \ccaron\scaron
> \stoptext

Just comment:

There should be CMAP resouce in the PDF for that maps font encoding to 
unicode. Then search and copying works. ConTeXt supports CMAP but IFAIK 
only il2 encoding! CMAP resources for the rest encoding are missing. 
Just see enco-pfr.tex

vit

Re: ec encoding and tcaron

[Taco Hoekwater]

Vit Zyka wrote:
> 
> 
> Just comment:
> 
> There should be CMAP resouce in the PDF for that maps font encoding to 
> unicode. Then search and copying works. ConTeXt supports CMAP but IFAIK 
> only il2 encoding! CMAP resources for the rest encoding are missing. 
> Just see enco-pfr.tex

 From the Release notes:

  Context 2005.07.27

  This version of ConTeXt was uploaded on July 28, 2005.

     * .....
     * optionally make ec-encoded pdfs better searchable in Acrobat5 and 
lower

See also this thread, only a few weeks ago:

  http://archive.contextgarden.net/message/20050727.073731.41799d96.html

Cheers, Taco

Re: ec encoding and tcaron

[Mojca Miklavec]

Taco Hoekwater wrote:
> Vit Zyka wrote:
> 
>> Just comment:
>>
>> There should be CMAP resouce in the PDF for that maps font encoding to 
>> unicode. Then search and copying works. ConTeXt supports CMAP but 
>> IFAIK only il2 encoding! CMAP resources for the rest encoding are 
>> missing. Just see enco-pfr.tex
> 
> 
>  From the Release notes:
> 
>  Context 2005.07.27
> 
>  This version of ConTeXt was uploaded on July 28, 2005.
> 
>     * .....
>     * optionally make ec-encoded pdfs better searchable in Acrobat5 and 
> lower
> 
> See also this thread, only a few weeks ago:
> 
>  http://archive.contextgarden.net/message/20050727.073731.41799d96.html
> 
> Cheers, Taco

Thank you both! I remember the thread, but at that time searching for 
letters in ligatures worked for me and I have never noticed that 
anything was wrong with texnansi until a week ago :) as Hans's tricks 
made the letters look all-right.
So I didn't understand the point of that hack.

I added the comment about pfr to the Wiki (encodings and regimes).

(Would it be very expensive to add this feature to the ec encoding 
automatically?)

Thanks,
	Mojca

Re: ec encoding and tcaron

[Hans Hagen]

Mojca Miklavec wrote:

>
>
> (Would it be very expensive to add this feature to the ec encoding 
> automatically?)

no, quite cheap; i'll cut you a deal ... make me the texnansi and qx variants and i'll enable all of it automatically 

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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Hans Hagen]

Mojca Miklavec wrote:

>
> (Would it be very expensive to add this feature to the ec encoding 
> automatically?)

there is a problem

(1) loading needs to be carefully synchronized 
(2) we don't want dummy vectors when we have a no-text document 
  
so we may end up with manual activation 

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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Hans Hagen]

Vit Zyka wrote:

> Hans, did you think about Petr Olsak's enc-tex? I believe it is much 
> straight-forward solution that solve input enco, output to files and 
> output to log (utf8 works too). And it should be much quicker than 
> macros. I am not sure, but perhaps there is no patch to aleph now...

i took a look at it when it came around but it's not flexible enough; it deals with the input and part of the output; i asked the author to consider some extensions that would it make possible to deal with multiple output variants (keep in mind that some input data may need to be fed into pdf specific data structures, in different encodings, with different kind of escapes etc) and that in for instance buffers, verbatim, multi-pass data and other situations one may need the original input; it all depends on how a macro package is build and deals with data and also with the complexity of the applications. Live is simply not simple. What works for latex or plain tex may not work for context and vise versa. 

So, when i noticed the 'just use it and don't ask' attitude i gave up on enctex or at least decided to postpone support till i ran into a 

Of course anyone is free to overload the relevant pieces of the regime handler. I suppose that putting some enctex mapper in front of it works ok (i.e. as long as one either expands to raw characters in the current encoding or to named glyphs. 

now back to the issue: 

I uploaded a new version (while crossing my fingers); the problem with this uppercasing is that handling (font) characters is one thing, handling inputs another oif not to speak of commands, and other things that can end up inside WORD and then be subjected to uppercasing 

\def\Vit{Vit} \WORD{\Vit} -> VIT 

\def\Vit{whatever} \WORD{\Vit} -> WHATEVER

\startencoding[ec]
  \defineuppercasecom \Vit {nothing}
\stopencoding

\def\Vit{whatever} \WORD{\Vit} -> nothing 

so, there is much more involved; i change a few things (i fear that taco is the only one who now understand what's going on but you may give it a try -) 

(\chardef\uppercasemode\plusone gives the old behaviour)

The problem with this kind of things is that it will not become esier to solve when we have a different tex or so ... there are simply too many variants / usages / ...) 


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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Vit Zyka]

Hans Hagen wrote:
> Vit Zyka wrote:
> 
>> Hans, did you think about Petr Olsak's enc-tex? I believe it is much 
>> straight-forward solution that solve input enco, output to files and 
>> output to log (utf8 works too). And it should be much quicker than 
>> macros. I am not sure, but perhaps there is no patch to aleph now...
> 
> 
> i took a look at it when it came around but it's not flexible enough; it 
> deals with the input and part of the output; i asked the author to 
> consider some extensions that would it make possible to deal with 
> multiple output variants (keep in mind that some input data may need to 
> be fed into pdf specific data structures, in different encodings, with 
> different kind of escapes etc) and that in for instance buffers, 
> verbatim, multi-pass data and other situations one may need the original 
> input; it all depends on how a macro package is build and deals with 
> data and also with the complexity of the applications. Live is simply 
> not simple. What works for latex or plain tex may not work for context 
> and vise versa.
> So, when i noticed the 'just use it and don't ask' attitude i gave up on 

I think I undestand...

> enctex or at least decided to postpone support till i ran into a
> Of course anyone is free to overload the relevant pieces of the regime 
> handler. I suppose that putting some enctex mapper in front of it works 
> ok (i.e. as long as one either expands to raw characters in the current 
> encoding or to named glyphs.
> now back to the issue:
> I uploaded a new version (while crossing my fingers); the problem with 
> this uppercasing is that handling (font) characters is one thing, 
> handling inputs another oif not to speak of commands, and other things 
> that can end up inside WORD and then be subjected to uppercasing
> \def\Vit{Vit} \WORD{\Vit} -> VIT
> \def\Vit{whatever} \WORD{\Vit} -> WHATEVER
> 
> \startencoding[ec]
>  \defineuppercasecom \Vit {nothing}
> \stopencoding
> 
> \def\Vit{whatever} \WORD{\Vit} -> nothing
> so, there is much more involved; i change a few things (i fear that taco 
> is the only one who now understand what's going on but you may give it a 
> try -)
> (\chardef\uppercasemode\plusone gives the old behaviour)
> 
> The problem with this kind of things is that it will not become esier to 
> solve when we have a different tex or so ... there are simply too many 
> variants / usages / ...)

All right, thanks Hans, I will try new alpha, but what about 
texfont-pseudocaps-problem? Is it relevat to this one? I turn to thing 
it is different and much simpler problem...

vit

Re: ec encoding and tcaron

[Hans Hagen]

Vit Zyka wrote:

>
> All right, thanks Hans, I will try new alpha, but what about 
> texfont-pseudocaps-problem? Is it relevat to this one? I turn to thing 
> it is different and much simpler problem...

i think that they are not loaded at all, adam may know (in a few weeks 
i'll pick up a thread about this var stuff since we have some ideas on 
how to make in more convenient)

anyhow, there is no need to redefine all mappings, sinc ethe existing 
typescripts will be taken as well, so:

\starttypescript [all] [latin-modern] [texnansi,ec,qx,pl0,il2,t5]
    \definefontsynonym [cmcsci10]   [\typescriptthree-lmri10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscbx10]  [\typescriptthree-lmbx10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscbxi10] [\typescriptthree-lmbxi10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcscro10]  [\typescriptthree-lmro10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcsctti10] [\typescriptthree-lmtti10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcsctto10] [\typescriptthree-lmtto10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcscss10]  [\typescriptthree-lmss10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscssbx10][\typescriptthree-lmssbx10-capitalized-800][encoding=\typescriptthree]
    \definefontsynonym [cmcscssi10] [\typescriptthree-lmsso10-capitalized-800] [encoding=\typescriptthree]
\stoptypescript

\starttypescript [serif] [latin-modern] [default]
    \definefontsynonym [SerifSmallCaps]          [ComputerModern-Caps]
    \definefontsynonym [SerifItalicSmallCaps]    [cmcsci10]
    \definefontsynonym [SerifBoldSmallCaps]      [cmcscbx10]
    \definefontsynonym [SerifBoldItalicSmallCaps][cmcscbxi10]
    \definefontsynonym [SerifSlantedSmallCaps]   [cmcscro10]
\stoptypescript

\starttypescript [sans] [latin-modern] [default]
    \definefontsynonym [SansSmallCaps]       [cmcscss10]
    \definefontsynonym [SansItalicSmallCaps] [cmcscssi10]
    \definefontsynonym [SansBoldSmallCaps]   [cmcscssbx10]
    \definefontsynonym [SansSlantedSmallCaps][cmcscssi10]
\stoptypescript

\starttypescript [mono] [latin-modern] [default]
    \definefontsynonym [MonoSmallCaps]      [ComputerModernMono-Caps]
    \definefontsynonym [MonoItalicSmallCaps][cmcsctti10]
\stoptypescript 

(you can now add these typescripts to the main file, no need for a separate typescript file) 

another approach is: 

\starttypescript [all] [latin-modern-sc] [texnansi,ec,qx,pl0,il2,t5]
    \definefontsynonym [cmcsci10]   [\typescriptthree-lmri10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscbx10]  [\typescriptthree-lmbx10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscbxi10] [\typescriptthree-lmbxi10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcscro10]  [\typescriptthree-lmro10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcsctti10] [\typescriptthree-lmtti10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcsctto10] [\typescriptthree-lmtto10-capitalized-800] [encoding=\typescriptthree]
    \definefontsynonym [cmcscss10]  [\typescriptthree-lmss10-capitalized-800]  [encoding=\typescriptthree]
    \definefontsynonym [cmcscssbx10][\typescriptthree-lmssbx10-capitalized-800][encoding=\typescriptthree]
    \definefontsynonym [cmcscssi10] [\typescriptthree-lmsso10-capitalized-800] [encoding=\typescriptthree]
\stoptypescript

\starttypescript [serif] [latin-modern-sc] [name]
    \definefontsynonym [Serif]          [ComputerModern-Caps]
    \definefontsynonym [SerifItalic]    [cmcsci10]
    \definefontsynonym [SerifBold]      [cmcscbx10]
    \definefontsynonym [SerifBoldItalic][cmcscbxi10]
    \definefontsynonym [SerifSlanted]   [cmcscro10]
\stoptypescript

\starttypescript [sans] [latin-modern-sc] [name]
    \definefontsynonym [Sans]       [cmcscss10]
    \definefontsynonym [SansItalic] [cmcscssi10]
    \definefontsynonym [SansBold]   [cmcscssbx10]
    \definefontsynonym [SansSlanted][cmcscssi10]
\stoptypescript

\starttypescript [mono] [latin-modern-sc] [name]
    \definefontsynonym [Mono]       [ComputerModernMono-Caps]
    \definefontsynonym [MonoItalic] [cmcsctti10]
\stoptypescript

\starttypescript[map][latin-modern-sc][all]
 ...
\stoptypescript

\definetypeface[modernsc][rm][serif][latin-modern-sc][default]
..... 

{\modernsc test}


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

Re: ec encoding and tcaron

[Vit Zyka]

Hans Hagen wrote:
> Vit Zyka wrote:
> 
>>
>> All right, thanks Hans, I will try new alpha, but what about 
>> texfont-pseudocaps-problem? Is it relevat to this one? I turn to thing 
>> it is different and much simpler problem...
> 
> 
> i think that they are not loaded at all, adam may know (in a few weeks 
> i'll pick up a thread about this var stuff since we have some ideas on 
> how to make in more convenient)
> 
> anyhow, there is no need to redefine all mappings, sinc ethe existing 
> typescripts will be taken as well, so:

Dear Hans,

I do not know if my descriptions is so fuzzy or we are both a bit 
overworked ;-)

I send to the conference zipped minimal example and typescripts for 
pseudo-small caps yesterday. They are based on font variants and work 
perfectly. The ONLY PROBLEM (demonstrated in the minimal example) is 
that texfont ignore tcaron when creating virtual font. Every other 
similar accented letters (e.g. \dcaron) is OK.

And since I can not find it in the texfont source I ask again: WHERE/HOW 
texfont gives info about corresponding (lower->uppercase) char pairs?

vit

> \starttypescript [all] [latin-modern] [texnansi,ec,qx,pl0,il2,t5]
>    \definefontsynonym [cmcsci10]   
> [\typescriptthree-lmri10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcscbx10]  
> [\typescriptthree-lmbx10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcscbxi10] 
> [\typescriptthree-lmbxi10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcscro10]  
> [\typescriptthree-lmro10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcsctti10] 
> [\typescriptthree-lmtti10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcsctto10] 
> [\typescriptthree-lmtto10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcscss10]  
> [\typescriptthree-lmss10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym 
> [cmcscssbx10][\typescriptthree-lmssbx10-capitalized-800][encoding=\typescriptthree] 
> 
>    \definefontsynonym [cmcscssi10] 
> [\typescriptthree-lmsso10-capitalized-800] [encoding=\typescriptthree]
> \stoptypescript
> 
> \starttypescript [serif] [latin-modern] [default]
>    \definefontsynonym [SerifSmallCaps]          [ComputerModern-Caps]
>    \definefontsynonym [SerifItalicSmallCaps]    [cmcsci10]
>    \definefontsynonym [SerifBoldSmallCaps]      [cmcscbx10]
>    \definefontsynonym [SerifBoldItalicSmallCaps][cmcscbxi10]
>    \definefontsynonym [SerifSlantedSmallCaps]   [cmcscro10]
> \stoptypescript
> 
> \starttypescript [sans] [latin-modern] [default]
>    \definefontsynonym [SansSmallCaps]       [cmcscss10]
>    \definefontsynonym [SansItalicSmallCaps] [cmcscssi10]
>    \definefontsynonym [SansBoldSmallCaps]   [cmcscssbx10]
>    \definefontsynonym [SansSlantedSmallCaps][cmcscssi10]
> \stoptypescript
> 
> \starttypescript [mono] [latin-modern] [default]
>    \definefontsynonym [MonoSmallCaps]      [ComputerModernMono-Caps]
>    \definefontsynonym [MonoItalicSmallCaps][cmcsctti10]
> \stoptypescript
> (you can now add these typescripts to the main file, no need for a 
> separate typescript file)
> another approach is:
> \starttypescript [all] [latin-modern-sc] [texnansi,ec,qx,pl0,il2,t5]
>    \definefontsynonym [cmcsci10]   
> [\typescriptthree-lmri10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcscbx10]  
> [\typescriptthree-lmbx10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcscbxi10] 
> [\typescriptthree-lmbxi10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcscro10]  
> [\typescriptthree-lmro10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym [cmcsctti10] 
> [\typescriptthree-lmtti10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcsctto10] 
> [\typescriptthree-lmtto10-capitalized-800] [encoding=\typescriptthree]
>    \definefontsynonym [cmcscss10]  
> [\typescriptthree-lmss10-capitalized-800]  [encoding=\typescriptthree]
>    \definefontsynonym 
> [cmcscssbx10][\typescriptthree-lmssbx10-capitalized-800][encoding=\typescriptthree] 
> 
>    \definefontsynonym [cmcscssi10] 
> [\typescriptthree-lmsso10-capitalized-800] [encoding=\typescriptthree]
> \stoptypescript
> 
> \starttypescript [serif] [latin-modern-sc] [name]
>    \definefontsynonym [Serif]          [ComputerModern-Caps]
>    \definefontsynonym [SerifItalic]    [cmcsci10]
>    \definefontsynonym [SerifBold]      [cmcscbx10]
>    \definefontsynonym [SerifBoldItalic][cmcscbxi10]
>    \definefontsynonym [SerifSlanted]   [cmcscro10]
> \stoptypescript
> 
> \starttypescript [sans] [latin-modern-sc] [name]
>    \definefontsynonym [Sans]       [cmcscss10]
>    \definefontsynonym [SansItalic] [cmcscssi10]
>    \definefontsynonym [SansBold]   [cmcscssbx10]
>    \definefontsynonym [SansSlanted][cmcscssi10]
> \stoptypescript
> 
> \starttypescript [mono] [latin-modern-sc] [name]
>    \definefontsynonym [Mono]       [ComputerModernMono-Caps]
>    \definefontsynonym [MonoItalic] [cmcsctti10]
> \stoptypescript
> 
> \starttypescript[map][latin-modern-sc][all]
> ...
> \stoptypescript
> 
> \definetypeface[modernsc][rm][serif][latin-modern-sc][default]
> .....
> {\modernsc test}
> 
> 
> -----------------------------------------------------------------
>                                          Hans Hagen | PRAGMA ADE
>              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
>                                             | www.pragma-pod.nl
> -----------------------------------------------------------------
> 
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
> 

-- 
=======================================================
Ing. Vít Zýka, Ph.D.                         TYPOkvítek

database publishing              databazove publikovani
data maintaining and typesetting in typographic quality
priprava dat a jejich sazba v typograficke kvalite

tel.: (+420) 777 198 189     www: http://typokvitek.com
=======================================================

Re: ec encoding and tcaron

[Hans Hagen]

Vit Zyka wrote:

>
>
> And since I can not find it in the texfont source I ask again: 
> WHERE/HOW texfont gives info about corresponding (lower->uppercase) 
> char pairs?

this not done by texfont, but by afmtotfm and i guess that it's kind of hard coded in there (taco or patrick may know) 

an alternative is to copy for instance ec.enc to ec-cap.enc and change the lowercase entries to uppercase ones (we can add such files to the distribution); then you use texfont with that encoding so you get ec-cap-whatever kind of font files 

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.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

Re: ec encoding and tcaron

[Patrick Gundlach]

>
> \usetypescript[modern][ec]
> \setupbodyfont[10pt,rm]
>
> \starttext
> ťŤ          % \tcaron\Tcaron
> \WORD{ťŤ}

In ec encoding there is no tcaron, Only tquoteright, which I guess
should be the lowercase Tcaron. When faking smallcaps, afm2tfm uses
the tolower() c function, that will fail the way afm2tfm uses it. So
it assumes that the lowercase of Tcaron is tcaron, which is not
present in ec enc and therefore does not get in the fontencoding. 

Did this help? I am just stepping into this thread, so I might have
missed the whole point.


Patrick
-- 
ConTeXt wiki and more: http://contextgarden.net

Re: Re: ec encoding and tcaron

[Vit Zyka]

Patrick Gundlach wrote:
> 
>>\usetypescript[modern][ec]
>>\setupbodyfont[10pt,rm]
>>
>>\starttext
>>ťŤ          % \tcaron\Tcaron
>>\WORD{ťŤ}
> 
> 
> In ec encoding there is no tcaron, Only tquoteright, which I guess
> should be the lowercase Tcaron. When faking smallcaps, afm2tfm uses
> the tolower() c function, that will fail the way afm2tfm uses it. So
> it assumes that the lowercase of Tcaron is tcaron, which is not
> present in ec enc and therefore does not get in the fontencoding. 
> 
> Did this help? I am just stepping into this thread, so I might have
> missed the whole point.

No, Patrick, you hit the goal! But, after Hans last note, it was easy 
even for me ;-)

It is some kind of inconsistency/bug in the ec encoding: if there is 
equivalent /dcaron present, then trere should be /tcaron too instead 
/trightquote.

My problem is solved now, thanks to Moica, Hans, and Patrick.

vit

Re: ec encoding and tcaron

[Patrick Gundlach]

Hi Vit,

> It is some kind of inconsistency/bug in the ec encoding: if there is
> equivalent /dcaron present, then trere should be /tcaron too instead
> /trightquote.

So, how do the fonts name the glyph? You can use tex256 encoding. See

http://fun.contextgarden.net/encodingtable/enctable.rb?ec,tex256

Patrick
-- 
ConTeXt wiki and more: http://contextgarden.net

Re: Re: ec encoding and tcaron

[Vit Zyka]

Patrick Gundlach wrote:
> Hi Vit,
> 
> 
>>It is some kind of inconsistency/bug in the ec encoding: if there is
>>equivalent /dcaron present, then trere should be /tcaron too instead
>>/trightquote.
> 
> 
> So, how do the fonts name the glyph?

looking to my font/afm directory:

afm>grep -S -l "tcaron" *.afm |
    perl -n -e "$i=0;while(<>){$i++;}print\"$i\n\""
761

afm>grep -S -l "tquoteright" *.afm |
    perl -n -e "$i=0;while(<>){$i++;}print\"$i\n\""
69

but from these 69, 53 are from lm, and in lm these glyph is dubdled 
(both tcaron and tquoteright):
lmr10.afm: C -1 ; WX 388.88889 ; N tquoteright ; B 19 -11 332 699 ;
lmr10.afm: C -1 ; WX 388.88889 ; N tcaron ; B 19 -11 332 699 ;

the rest 16 files are:
   8x .\ibm\courier\*.afm
and
   8x .\ibm\times\*.afm
even there are both glyphs but with different metrics
   grep -S "tcaron" cour.afm
     C -1 ; WX 600 ; N tcaron ; B 94 -14 538 720 ;
     CC tcaron 2 ; PCC t 0 0 ; PCC caron -77 92 ;
   grep -S "tquoteright" cour.afm
     C -1 ; WX 600 ; N tquoteright ; B 73 -14 646 563 ;

So it seems that fonts are using /tcaron; lm use /tquoteright only for sure.

Does anybody know who is responsibility/background for ec encoding?

vit

Re: ec encoding and tcaron

[Patrick Gundlach]

[trightquote/tcaron]

> So it seems that fonts are using /tcaron; lm use /tquoteright only for sure.

ok, thanks

> Does anybody know who is responsibility/background for ec encoding?

Last time I asked about the encodings (xt2.enc in particular) I got
the following answer from Thomas Esser:

> That file comes from the fontname distribution (CTAN:info/fontname).
> If you request for a change in that file, please write either to the
> tex-fonts list or to Karl Berry.

Patrick
-- 
ConTeXt wiki and more: http://contextgarden.net