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

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

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/

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

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

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

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

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: <address> <p>J. Schöttelndreher</p> <p>J. Schöttelndreher</p> <p>Laan der Drieëenheid</p> <p>Laan der Drieë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

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

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: <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öttelndreher</p>)?

<p>J. Schö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 ş with: \defineXMLentity [Scedil] {\Scedilla} \defineXMLentity [scedil] {\scedilla}

% You can use ş 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 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 -----------------------------------------------------------------