next version

next version

[Hans Hagen]

Hi,

The next release will -apart from bug fixes and a few new things as well as the 
bib module- also miss a few things: the interface setup files, we now definitely 
move to the xml variants; as a result, texshow has been swapped for taco's 
texshow which handles the xml files directly; this is all part of a cleanup. The 
alpha relese already has these changes.

Expect also cleanup in the font area:

- csr/plr/aer/vnr will be dropped in favor of lmr (also makes minimals smaller)
- i consider run time map entries instead of file based ones
- some unused macros will be removed

btw, there is a new 'manual': tiptrick.pdf; will be extended over time

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: next version

[Nikolai Weibull]

* Hans Hagen <pragma@wxs.nl> [Jan 06, 2005 17:50]:
> - csr/plr/aer/vnr will be dropped in favor of lmr (also makes minimals
> smaller)

What will this entail, exactly?
	nikolai

-- 
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: next version

[Hans Hagen]

Nikolai Weibull wrote:
> * Hans Hagen <pragma@wxs.nl> [Jan 06, 2005 17:50]:
> 
>>- csr/plr/aer/vnr will be dropped in favor of lmr (also makes minimals
>>smaller)
> 
> 
> What will this entail, exactly?

less font files because latin modern has all those glyphs in it (once vietnamese 
is in there some 600 glyphs per font); for speed and consistency i may add a 
bunch of <encoding>-lmr*.tfm files but users will not notice it;

latin modern support is already present in context

another advantage is that once we default to latin modern, we have the glyoh sin 
the proper ascii slots, which means less hassle with xml

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: next version

[Adam Lindsay]

Hans Hagen said this at Thu, 6 Jan 2005 18:32:27 +0100:

>>>- csr/plr/aer/vnr will be dropped in favor of lmr (also makes minimals
>>>smaller)
>> 
>> 
>> What will this entail, exactly?
>
>less font files because latin modern has all those glyphs in it (once
>vietnamese 
>is in there some 600 glyphs per font); for speed and consistency i may add a 
>bunch of <encoding>-lmr*.tfm files but users will not notice it;

Okay, here's a question: what's the plan for ec-lmr*.tfm files?

Your latin-modern typescripts accept ec, but the tfm files are called cork.
(I'm only wondering about this now for antt support.)

I know of two approaches. Which would you recommend?

\starttypescript [serif] [antykwa-torunska] [texnansi,qx,ec]
  \definefontsynonym [AntykwaTorunska-Bold]
          [\typescriptthree-anttb]     [encoding=\typescriptthree]
\stoptypescript

\starttypescript [serif] [antykwa-torunska] [ec]
  \definefontsynonym [ec-anttb] [cork-anttb]
\stoptypescript

% or...

\starttypescript [serif] [antykwa-torunska] [texnansi,qx]
  \definefontsynonym [AntykwaTorunska-Bold]
          [\typescriptthree-anttb]     [encoding=\typescriptthree]
\stoptypescript

\starttypescript [serif] [antykwa-torunska] [ec]
  \definefontsynonym [AntykwaTorunska-Bold][cork-anttb][encoding=ec]
\stoptypescript

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: next version

[h h extern]

Adam Lindsay wrote:

> Okay, here's a question: what's the plan for ec-lmr*.tfm files?

indeed a problem, i will provide an extra a typescript that maps the ec-lm* 
files onto cork-lm-*; in addition to that i will ship copies of ec-lm* as well 
as il2-lm* and pl0-lm* [or maybe polish can move to qx-lm*]; given that context 
is the only system using the encoding-name scheme, and since i have lots of ec-* 
files around, i see no reason to change ec-* to cork-*

[an option is to have something \ec that expands to ec or cork but i dislike that]

> Your latin-modern typescripts accept ec, but the tfm files are called cork.
> (I'm only wondering about this now for antt support.)

for the ant, use ec- since that's what texfont provides

> I know of two approaches. Which would you recommend?
> 
> \starttypescript [serif] [antykwa-torunska] [texnansi,qx,ec]
>   \definefontsynonym [AntykwaTorunska-Bold]
>           [\typescriptthree-anttb]     [encoding=\typescriptthree]
> \stoptypescript

easier and faster

> \starttypescript [serif] [antykwa-torunska] [ec]
>   \definefontsynonym [ec-anttb] [cork-anttb]
> \stoptypescript
> 
> % or...
> 
> \starttypescript [serif] [antykwa-torunska] [texnansi,qx]
>   \definefontsynonym [AntykwaTorunska-Bold]
>           [\typescriptthree-anttb]     [encoding=\typescriptthree]
> \stoptypescript
> 
> \starttypescript [serif] [antykwa-torunska] [ec]
>   \definefontsynonym [AntykwaTorunska-Bold][cork-anttb][encoding=ec]
> \stoptypescript

slower, the less typescripts we have ... same for lm fonts, the less the better

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: next version

[Adam Lindsay]

h h extern said this at Sun, 9 Jan 2005 21:19:10 +0100:

>> Your latin-modern typescripts accept ec, but the tfm files are called cork.
>> (I'm only wondering about this now for antt support.)
>
>for the ant, use ec- since that's what texfont provides

Ah, I invoked Latin Modern because (since Jacko seems to have been behind
helping out with the release) the TeX release of Antykwa Torunska
provides the same sort of cork-* files as lm.

Anyway, I started in with some test typescripts that treat [ec/cork]
separately. (sent under separate cover)
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: next version

[Adam Lindsay]

Hans Hagen said this at Thu, 6 Jan 2005 17:44:21 +0100:

>Expect also cleanup in the font area:
>
>- csr/plr/aer/vnr will be dropped in favor of lmr (also makes minimals
>smaller)

Cool.
Not directly relevant, but if you're considering the minimals, the antt
font got a stunning update somewhere at the end of the year:
<http://www.ctan.org/tex-archive/fonts/antt/doc/fonts/antt/
AntykwaTorunska-doc-en-2_01.pdf>
<http://www.ctan.org/tex-archive/fonts/antt/>

(And I'm sure you know about Utopia being updated as well.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: next version

[Hans van der Meer]

On Jan 6, 2005, at 17:44, Hans Hagen wrote:

>
> btw, there is a new 'manual': tiptrick.pdf; will be extended over time
>

Where can I find it? I did look for it on the pragma site but could not 
find a link to it in any of the subtrees.

May I also make a suggestion? I think it will be useful when the 
versiondate of the documents, especially the manuals, can be put along 
the download link. Like is done for the context zipped updates in the 
download page. It will make spotting updates much easier en prevents 
downloads that afterwards turn out to be duplicates. Thanks if it can 
be implemented.

Hans van der Meer

Re: next version

[Tobias Burnus]

Hi,

Hans van der Meer wrote:
> On Jan 6, 2005, at 17:44, Hans Hagen wrote:
>> btw, there is a new 'manual': tiptrick.pdf; will be extended over time
> Where can I find it? I did look for it on the pragma site but could 
> not find a link to it in any of the subtrees.
http://www.pragma-ade.com/general/manuals/tiptrick.pdf

Tobias

Re: next version

[Peter Münster]

On Fri, 7 Jan 2005, Hans van der Meer wrote:

> May I also make a suggestion? I think it will be useful when the 
> versiondate of the documents, especially the manuals, can be put along 
> the download link.

You are probably looking for this link:
http://www.pragma-ade.com/dir/general/manuals/?M=D
Cheers, Peter

-- 
http://pmrb.free.fr/contact/
_____________________________________
FilmSearch engine: http://f-s.sf.net/

m-letter.tex (first page, input file)

[Rob Ermers]

Dear friends,

My attempts to customize my letter have yielded some results.
I still have two problems and questions that keep troubling me.

- If I use the following method to include an external document, it does 
place the desired text:
\startsetups[letter:content]
\input brieftekst
\stopsetups

However, any backslash, such as (in Dutch) ge\"interesseerd and 
effici\"ent, is converted into something else, e.g. ge“”interesseerde, 
e\x0eci“”–e˝nt.

If I use the construction with startbuffer, as presented in the 
correspondence manual, the external document is not included at all, the 
backslash in \input being converted to “ immediately.
(\startbuffer[texletter] \input brieftekst \stopbuffer
yields
“input brieftekst)

I am really puzzled by this.

- My second question is how to make a second page that is different from 
the first, by means of pdf graphics. There are several possibilities:

1. page 1 contains graphic A + B, page 2-... contains graphic A
2. page 1 contains graphic A, page 2-... contains graphic C.

The module contains the items letternext, lettermain, that may be 
related to this problem, but I cannot figure out how they are used.

Any suggestions are welcomed!

Kind regards,

Robert Ermers

Re: next version

[h h extern]

Hans van der Meer wrote:

> May I also make a suggestion? I think it will be useful when the 
> versiondate of the documents, especially the manuals, can be put along 
> the download link. Like is done for the context zipped updates in the 
> download page. It will make spotting updates much easier en prevents 
> downloads that afterwards turn out to be duplicates. Thanks if it can be 
> implemented.

maybe some day i will add some versioning to that, but currently i don't have 
that (manuals don't change that often, mostly new files are added)

you can use texsync to sync the documentation tree [uses rsync] and then you 
only update the changes [quite efficient]

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

can I upgrade yet?

[Gary]

Some months ago I stopped upgrading ConTeXt.  Here and there I saw 
references to new file hierarchies, and something about installation 
scripts ... if I remember correctly.   I didn't want to break my system, 
so I just stopped upgrading, and stopped reading those messages (which I 
didn't understand, anyway).

I'm currently using MikTeX.

1.)  Concerning file hierarchy:  did something monumental indeed ocurr 
that I ignored?

2.) If so, is it safe to upgrade? 

3.) Is there some other way besides my traditional method of unzipping 
cont-tmf.zip file into /localtexmf ?  Do I need to rebuild the file system?

4.) Have I misinterpreted, and nothing much has changed?

Sorry about this.  I really want to avoid getting my system into some 
strange state, and spending hours unraveling the mystery.  Done that too 
many times in my life.

-gary

Re: can I upgrade yet?

[Hans Hagen]

Gary wrote:
> Some months ago I stopped upgrading ConTeXt.  Here and there I saw 
> references to new file hierarchies, and something about installation 
> scripts ... if I remember correctly.   I didn't want to break my system, 
> so I just stopped upgrading, and stopped reading those messages (which I 
> didn't understand, anyway).
> 
> I'm currently using MikTeX.
> 
> 1.)  Concerning file hierarchy:  did something monumental indeed ocurr 
> that I ignored?

enc and map files as well as scripts are now in new locations, i assume that 
miktex has been adapted to that

> 2.) If so, is it safe to upgrade?

miktex has a good reputation or upgrading

> 3.) Is there some other way besides my traditional method of unzipping 
> cont-tmf.zip file into /localtexmf ?  Do I need to rebuild the file system?

no, you can unzip, run "textools --fixtexmf --force", regenerate the database, 
and cross your fingers

> 4.) Have I misinterpreted, and nothing much has changed?

thing shave changed, e,g, the pdftex cfg file is gone now; no real problem for 
context since it never depended on that; the danger is in partially upgrading: a 
new pdftex will not work in an old tree

> Sorry about this.  I really want to avoid getting my system into some 
> strange state, and spending hours unraveling the mystery.  Done that too 
> many times in my life.

i do my best to avoid problem sfo rusers, but some things are out of my control

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: can I upgrade yet?

[Gary]

Hans Hagen wrote:

> Gary wrote: 


[...]

>> Sorry about this.  I really want to avoid getting my system into some 
>> strange state, and spending hours unraveling the mystery.  Done that 
>> too many times in my life.
>
>
> i do my best to avoid problem sfo rusers, but some things are out of 
> my control
>
> Hans
>
Understood and appreciated.   I am *not* annoyed, and I apologize if I 
sounded annoyed.
Thanks for the upgrade tips.
-gary

Re: can I upgrade yet?

[Hans Hagen]

Gary wrote:

> Understood and appreciated.   I am *not* annoyed, and I apologize if I 
> sounded annoyed.

i was not annoyed at all -)

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: can I upgrade yet?

[Gary]

Hans Hagen wrote:

> Gary wrote:

[...]

>> 3.) Is there some other way besides my traditional method of 
>> unzipping cont-tmf.zip file into /localtexmf ?  Do I need to rebuild 
>> the file system?
>
>
> no, you can unzip, run "textools --fixtexmf --force", regenerate the 
> database, and cross your fingers

ok, here's what I did:

1. Upgraded MikTeX
2. Unzipped the latest cont-tmf.zip (from pragma-ade.com)  into 
c:\tex\localtexmf
3. ran "textools --fixtexmf --force"  (what does that do?)
4. checked c:\tex\localtex\context\config.  texexec.ini is newer than 
texexec.rme, so I left it alone.
5. ran "texexec --make en nl"  (do I need "nl"? I'm exclusively 
English.  I guess it can't hurt.)
6.  noticed that cont-en.efmt was automatically relocated to 
c:\tex\localtex\miktex\fmt but cont-nl was not.
7. moved cont-nl.efmt to c:\tex\localtex\miktex\fmt
8.  renamed them both to *.fmt  (per a note in the contextgarden wiki.   
Is this necessary?)
9.  ran "texexec --make metafun"
10.  moved metefun.mem to c:\tex\localtex\miktex\mem
11. ran "mktexlsr"

So far, everything seems to be fine. 
Are all of these steps necessary?  or advisable? Did I forget anything?  
Is there an shorter method that I've missed?  (not that this is long or 
difficult)

Thanks again,
-gary

Re: can I upgrade yet?

[Hans Hagen]

Gary wrote:
> Hans Hagen wrote:
> 
>> Gary wrote:
> 
> 
> [...]
> 
>>> 3.) Is there some other way besides my traditional method of 
>>> unzipping cont-tmf.zip file into /localtexmf ?  Do I need to rebuild 
>>> the file system?
>>
>>
>>
>> no, you can unzip, run "textools --fixtexmf --force", regenerate the 
>> database, and cross your fingers
> 
> 
> ok, here's what I did:
> 
> 1. Upgraded MikTeX
> 2. Unzipped the latest cont-tmf.zip (from pragma-ade.com)  into 
> c:\tex\localtexmf
> 3. ran "textools --fixtexmf --force"  (what does that do?)

if needed it moves you rlocal enc/map files to their new locations, not needed 
if you have no commercial fonts

> 4. checked c:\tex\localtex\context\config.  texexec.ini is newer than 
> texexec.rme, so I left it alone.
> 5. ran "texexec --make en nl"  (do I need "nl"? I'm exclusively 
> English.  I guess it can't hurt.)
> 6.  noticed that cont-en.efmt was automatically relocated to 
> c:\tex\localtex\miktex\fmt but cont-nl was not.
> 7. moved cont-nl.efmt to c:\tex\localtex\miktex\fmt
> 8.  renamed them both to *.fmt  (per a note in the contextgarden wiki.   
> Is this necessary?)
> 9.  ran "texexec --make metafun"
> 10.  moved metefun.mem to c:\tex\localtex\miktex\mem
> 11. ran "mktexlsr"

texexec --make  (--all if you want all patterns)

is normally enough, apart from moving the fmt and mem files (aren't those put at 
the right spot by miktex?)

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: can I upgrade yet?

[Gary]

Hans Hagen wrote:

> Gary wrote:
>
>> Hans Hagen wrote:
>>
>>> Gary wrote:
>>
>>
>>
>> [...]
>>
>>>> 3.) Is there some other way besides my traditional method of 
>>>> unzipping cont-tmf.zip file into /localtexmf ?  Do I need to 
>>>> rebuild the file system?
>>>
>>>
>>>
>>>
>>> no, you can unzip, run "textools --fixtexmf --force", regenerate the 
>>> database, and cross your fingers
>>
>>
>>
>> ok, here's what I did:
>>
>> 1. Upgraded MikTeX
>> 2. Unzipped the latest cont-tmf.zip (from pragma-ade.com)  into 
>> c:\tex\localtexmf
>> 3. ran "textools --fixtexmf --force"  (what does that do?)
>
>
> if needed it moves you rlocal enc/map files to their new locations, 
> not needed if you have no commercial fonts
>
>> 4. checked c:\tex\localtex\context\config.  texexec.ini is newer than 
>> texexec.rme, so I left it alone.
>> 5. ran "texexec --make en nl"  (do I need "nl"? I'm exclusively 
>> English.  I guess it can't hurt.)
>> 6.  noticed that cont-en.efmt was automatically relocated to 
>> c:\tex\localtex\miktex\fmt but cont-nl was not.
>> 7. moved cont-nl.efmt to c:\tex\localtex\miktex\fmt
>> 8.  renamed them both to *.fmt  (per a note in the contextgarden 
>> wiki.   Is this necessary?)
>> 9.  ran "texexec --make metafun"
>> 10.  moved metefun.mem to c:\tex\localtex\miktex\mem
>> 11. ran "mktexlsr"
>
>
> texexec --make  (--all if you want all patterns)
>
> is normally enough, apart from moving the fmt and mem files (aren't 
> those put at the right spot by miktex?)
>
> Hans
>
Hmm.   I normally open a command line window, and execute

texexec --make en nl

 in some random directory.  The result appears to be cont-en.efmt in the 
"correct" place, and cont-nl.efmt in the current directory.  It's 
possible that I did not look closely enough, and something entirely 
different happened.

I can't see why MikTeX would have any say in the matter of what texexec 
does.

Anyway, thanks for commenting.  I wasn't sure I was doing the right thing.

-g

Re: m-letter backslash codes in xml database

[Rob Ermers]

Contexers,

That the best way for coding diacritics in the xml database which you 
wish to use for your mailing is by using the appropriate iso-latin1 or 
unicode number:

      <contact num="3" regio="z3" label=`num3'>
      <address>
           <p>J. Sch&#246;ttelndreher</p>
           <p>J. Sch&#xF6;ttelndreher</p>
           <p>Laan der Drie&#235;enheid</p>
           <p>Laan der Drie&#xEB;enheid</p>
....
      </address>
               </contact>

The unicode number (&#x..) gives a slightly better result in my pdf.

Output:

J. Schöttelndreher
J. Schöttelndreher
Laan der Drieëenheid
Laan der Drieëenheid
1234 AB Beginhoven

The code is known, of course, but find nevertheless a useful link here: 
http://www.i18nguy.com/markup/ncrs.html

If you should want to copy your text back from the pdf, the diacritic 
character falls apart: Laan der Drie¨eenheid, but who would?

I suppose other codes can be used as well.

Regards,

Robert Ermers

Re: m-letter backslash codes in xml database

[h h extern]

Rob Ermers wrote:
> Contexers,
> 
> That the best way for coding diacritics in the xml database which you 
> wish to use for your mailing is by using the appropriate iso-latin1 or 
> unicode number:
> 
>      <contact num="3" regio="z3" label=`num3'>
>      <address>
>           <p>J. Sch&#246;ttelndreher</p>
>           <p>J. Sch&#xF6;ttelndreher</p>
>           <p>Laan der Drie&#235;enheid</p>
>           <p>Laan der Drie&#xEB;enheid</p>
> ....
>      </address>
>               </contact>
> 
> The unicode number (&#x..) gives a slightly better result in my pdf.

if you want to move things around in an encoding neutral way:

\defineXMLsingular
   [c]
   [n=unknowncharacter]
   {\executeifdefined {\XMLop{id}} \unknowncharacter}

<c n='eacute'/>

sometimes it's handier to move elements around than entities

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: m-letter backslash codes in xml database

[Rob Ermers]

h h extern wrote:
> if you want to move things around in an encoding neutral way:
> 
> \defineXMLsingular
>   [c]
>   [n=unknowncharacter]
>   {\executeifdefined {\XMLop{id}} \unknowncharacter}
> 
> <c n='eacute'/>

Thanks, Hans, for the example. I do agree, but I'm sorry I don't quite 
understand how to apply this code. Could you be more specific?

Do I still have to use the unicode number, or is this a method to use 
\"e again in the database?

Should I code each diacritic in this way, such as ouml (ö) in my 
example: <p>J. Sch&#246;ttelndreher</p>)?

My solution by the way does not work with, e.g., a Turkish scedil 
(U0015F) in my database, while Tex excells in all kinds of diacritics.

Kind regards,

Robert

Re: m-letter backslash codes in xml database

[Adam Lindsay]

Rob Ermers said this at Sat, 15 Jan 2005 02:31:32 +0100:

>h h extern wrote:
>> if you want to move things around in an encoding neutral way:
>>
>> \defineXMLsingular
>>   [c]
>>   [n=unknowncharacter]
>>   {\executeifdefined {\XMLop{id}} \unknowncharacter}
>>
>> <c n='eacute'/>

Um, I'm not sure, but I think Hans mixed two different attribute names:
the code won't work as is. It should probably be:

\defineXMLsingular
   [c]
   [n=unknowncharacter]
   {\executeifdefined {\XMLop{n}} \unknowncharacter}


>Thanks, Hans, for the example. I do agree, but I'm sorry I don't quite
>understand how to apply this code. Could you be more specific?

It should be in a .tex file that is loaded during processing. You can do
this manually in your style file, or in (for example) a cont-loc.tex file
that's in your path (e.g., the project directory or your tex/context/user ).

>Do I still have to use the unicode number, or is this a method to use
>\"e again in the database?

This is so that you can substitute elements for entities in your
database. This is an XML database, so it's a lot more useful if you don't
restrict it to TeX-specific character entry. Entities (or elements) are a
much better option, long-term.

>Should I code each diacritic in this way, such as ouml (ö) in my
>example: <p>J. Sch&#246;ttelndreher</p>)?

<p>J. Sch&#246;ttelndreher</p>     or, if you \useXMLfilter[ent] :
<p>J. Sch&#ouml;ttelndreher</p>    or, with Hans's definition:
<p>J. Sch<c n='odiaeresis'/>ttelndreher</p>

>My solution by the way does not work with, e.g., a Turkish scedil
>(U0015F) in my database, while Tex excells in all kinds of diacritics.

This is a slightly different issue. It's fairly easily fixed with a
couple additions to the style file/cont-loc file:

% You can use &scedil; with:
\defineXMLentity [Scedil]   {\Scedilla}
\defineXMLentity [scedil]   {\scedilla}

% You can use &#351; or other unicode (decimal) numbers with:
\def\executeXMLdeccharacter#1\relax %
  {\utfunifontglyph{#1}}

(I was unable to come up with a satisfactory way of handling the hex
version thereof. I also haven't really tested the above function
overload--I'm sure someone can improve on this.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: (resolved) m-letter backslash codes in xml database

[Rob Ermers]

Thanks Adam,

Now Hans' suggestions work. They are a bit lengthy, but I don't really 
care for now. They are preferred to a number. For searching purposes in 
the database, it is possible to introduce separate labels without 
diacritics.

Introducing scedilla in the file, as you suggested, seems not necessary:
Ba<c n='scedilla'/> soka<c n='gbreve'/><c n='dotlessi'/>.

Then it took me a while, but the Turkish Idot also works. This sign has 
several names (Idotabove, Iabovedot), and in Context it appears to be 
called Idotaccent. Therefore <c n='Idotaccent'/> produces the desired 
result:

<contact label=`num297'>
      <address>
           <p><c n='Idotaccent'/>brahim G<c n='udiaeresis'/>ng<c 
n='odiaeresis'/>rm<c n='udiaeresis'/><c n='scedilla'/></p>
           <p><c n='Idotaccent'/><c n='Idotabove'/>n<c 
n='odiaeresis'/>n<c n='udiaeresis'/> Soka<c n='gbreve'/><c 
n='dotlessi'/></p>
           <p>A<c n='Gbreve'/>RI</p>
      </address>
</contact>


Thanks again!

Kind regards,

Robert

Adam Lindsay wrote:
> Rob Ermers said this at Sat, 15 Jan 2005 02:31:32 +0100:
> 
> 
>>h h extern wrote:
>>
>>>if you want to move things around in an encoding neutral way:
>>>
>>>\defineXMLsingular
>>>  [c]
>>>  [n=unknowncharacter]
>>>  {\executeifdefined {\XMLop{id}} \unknowncharacter}
>>>
>>><c n='eacute'/>
> 
> 
> Um, I'm not sure, but I think Hans mixed two different attribute names:
> the code won't work as is. It should probably be:
> 
> \defineXMLsingular
>    [c]
>    [n=unknowncharacter]
>    {\executeifdefined {\XMLop{n}} \unknowncharacter}
> 
> 
> 
>>Thanks, Hans, for the example. I do agree, but I'm sorry I don't quite 
>>understand how to apply this code. Could you be more specific?
> 
> 
> It should be in a .tex file that is loaded during processing. You can do
> this manually in your style file, or in (for example) a cont-loc.tex file
> that's in your path (e.g., the project directory or your tex/context/user ).
> 
> 
>>Do I still have to use the unicode number, or is this a method to use 
>>\"e again in the database?
> 
> 
> This is so that you can substitute elements for entities in your
> database. This is an XML database, so it's a lot more useful if you don't
> restrict it to TeX-specific character entry. Entities (or elements) are a
> much better option, long-term.
> 
> 
>>Should I code each diacritic in this way, such as ouml (ö) in my 
>>example: <p>J. Sch&#246;ttelndreher</p>)?
> 
> 
> <p>J. Sch&#246;ttelndreher</p>     or, if you \useXMLfilter[ent] :
> <p>J. Sch&#ouml;ttelndreher</p>    or, with Hans's definition:
> <p>J. Sch<c n='odiaeresis'/>ttelndreher</p>
> 
>>My solution by the way does not work with, e.g., a Turkish scedil 
>>(U0015F) in my database, while Tex excells in all kinds of diacritics.
> 
> 
> This is a slightly different issue. It's fairly easily fixed with a
> couple additions to the style file/cont-loc file:
> 
> % You can use &scedil; with:
> \defineXMLentity [Scedil]   {\Scedilla}
> \defineXMLentity [scedil]   {\scedilla}
> 
> % You can use &#351; or other unicode (decimal) numbers with:
> \def\executeXMLdeccharacter#1\relax % 
>   {\utfunifontglyph{#1}}
> 
> (I was unable to come up with a satisfactory way of handling the hex
> version thereof. I also haven't really tested the above function
> overload--I'm sure someone can improve on this.)

Re: (resolved) m-letter backslash codes in xml database

[Adam Lindsay]

Rob Ermers said this at Sun, 16 Jan 2005 11:12:24 +0100:

>Introducing scedilla in the file, as you suggested, seems not necessary:
>Ba<c n='scedilla'/> soka<c n='gbreve'/><c n='dotlessi'/>.

Right. You've figured this out, but in case anyone else was following
along, Hans's element-based solution used ConTeXt's internal glyph names
(very extensive) instead of the more limited and must-roll-your-own list
of XML character entities.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: (resolved) m-letter backslash codes in xml database

[Hans Hagen]

Adam Lindsay wrote:
> Rob Ermers said this at Sun, 16 Jan 2005 11:12:24 +0100:
> 
> 
>>Introducing scedilla in the file, as you suggested, seems not necessary:
>>Ba<c n='scedilla'/> soka<c n='gbreve'/><c n='dotlessi'/>.
> 
> 
> Right. You've figured this out, but in case anyone else was following
> along, Hans's element-based solution used ConTeXt's internal glyph names
> (very extensive) instead of the more limited and must-roll-your-own list
> of XML character entities.

Remark:

a thord alternative, the &scedilla; approach, has as disadvantage that xml 
processors (xslt, parsers, databases) like to resolve entities; this is why i 
sometimes use the <c n='...'/> approach;

numbered entities should work ok, but some vectors may not yet be defined

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: can I upgrade yet?

[Matthew Huggett]

> Is there some other way besides my traditional method of unzipping 
> cont-tmf.zip file into /localtexmf ?

I'm on MikTeX as well.  I've kept my system up to date via the
MikTeX Update Wizard.  But just to see if unzipping cont-tmf.zip over
my \texmf would break anything, I just tried it.  No problem.
That said, I updated my installation via the wizard only a few weeks
ago....