- dev-context - NTG Mailing Lists

Re: [NTG-context] ec encoding and tcaron
by Mojca Miklavec 25 Aug '05

25 Aug '05

Adam Lindsay wrote: > Am I right in thinking the > main array in pdfr-ec maps from slots in the encoding to the unicode > code point? Is there anything else I need to be mindful of? According to the Adobe specification <http://partners.adobe.com/public/developer/en/acrobat/5411.ToUnicode.pdf> both existing pdfr-* files already violate at least one of the following two requirements: /CMapType 2 def ... 1 begincodespacerange <0000> <FFFF> endcodespacerange You can either define a range (for example for A-Z, 0-9, ...) or single characters. Mojca

2 2

Euro-letter encoding (was: Dense Encoding)
by Adam Lindsay 23 Aug '05

23 Aug '05

Hans Hagen said this at Sun, 21 Aug 2005 18:36:21 +0200: >so the advised font encodings will be: texnansi, qx, t5, dense Okay, thinking about it, dense isn't a great name, either. Just about all the 8-bit encodings are dense--they're just dense with different stuff. So with that in mind, I present euro-letters: <http://homepage.mac.com/atl/tex/euro-letter.pdf> <http://homepage.mac.com/atl/tex/euro-letter.zip> In the course of things, I found that for whatever reason, the unic-030 (VN) vector was off by two slots. I added [ST]commaaccent to enco-uc (should be in enco-def, too) and unic-002. The key files, however, are enco-el.tex and eurolett.enc. The tester file was brought to life simply by installing: texfont --ma --in --ve=public --co=lm --so=auto --en=eurolett \ --pat="lmvtt*" Please run with normal text--anything you can get your hands on. I am nearly a monoglot, and don't have a lot of stuff lying around that would actually put this stuff to the test. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl(a)comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

4 8

Re: [NTG-context] Re: Dense Encoding - Comments wanted
by Adam Lindsay 21 Aug '05

21 Aug '05

Patrick Gundlach said this at Fri, 19 Aug 2005 12:34:11 +0200: >> On Hans's suggestion, I've been working on a "dense" character encoding >> that does away with combining accents and extraneous symbol-like >> characters in favor of fully accented characters. > >> <http://homepage.mac.com/atl/tex/dense.pdf> > >do you have an enc file to play with? Sure. (didn't send to main list 'cos it's rough, still) I notice in the context of this latest discussion that I use Eth as a stand-in for Dcroat, mostly because I know slightly more about Icelandic than I do about Croatian. Although these slots are precious, perhaps I shouldn't do that. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl(a)comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

5 39

Re: [tex-fonts] error in ec encoding
by Hans Hagen 21 Aug '05

21 Aug '05

Adam Lindsay wrote: >Patrick Gundlach said this at Fri, 19 Aug 2005 16:03:31 +0200: > > > >>[...] >> >> >> >>>encodings, and of course that raises an entirely different matter. Even >>>though cork.enc, EC.enc, tex256.enc, etc. are all distinct >>>_encoding_vectors_, they still seek to implement the same _font_encoding_ >>>as far as TeX is concerned. >>> >>> >>What is a _font_encoding_ here? >> >> > >Well, from the context, I'd conclude that it's the logical, abstract >selection of characters that is independent of a given font's specifics. >I welcome the concept, as it's a powerful one when dealing with modern fonts. > > > >>Sounds like a LaTeX terminology. >> >> > >I have no idea where it comes from. Is there a place where this is used/ >defined? > > font encoding is usaually used when we talk about what tex is dealing with, i.e. some input (regime in context) is mapped onto the slots read in from the tfm file, but no names are involved, just numbers/slots; and then tex uses that (font) encoding when it hyphenates; so the hyphenation patterns should be loaded under a specific font encoding; btw, it's for this reason that context has a language-encoding relationship (patterns are loaded multiple times, for different font encodings) and that i use generic patterns so, in the end we may will have - adobe-dense.enc (will be mostly used in afm2tfm cum suis) - unicode-dense.enc (for the record) and this is relatively independent of context (that does not read the files) but it is important for the map file; Hans 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 -----------------------------------------------------------------

1 0

[Fwd: Re: [tex-fonts] error in ec encoding]
by Hans Hagen 21 Aug '05

21 Aug '05

Hi, so, according to walters mail, we have actually two files: dense.enc dense-<whatever names the type 1 font uses>.enc (used in map files) my impression is that we can assume that commercial fonts use the adobe scheme, but i'm not that sure how well tex fonts behave 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 -----------------------------------------------------------------

1 0

encodings
by Hans Hagen 19 Aug '05

19 Aug '05

Hi, This encoding mess ... somehow i got the feeling that we should start shipping proper tfm files, i.e. texnansi ec qx char (adam's new one) ecx (mojcs's fixed ec) I can probably convince te polish font guys and we need a similar named set (generated of copied) for the abotu 15 free fonts on tex live. There is no point is keeping in tune with old stuff and latex-needs-it-this-way-so-we-cannot-fix-it situation. It's taking too much time. (Comparable with the patterns mess, i now just ship them). In the end we can set up a project that maintains these sets. 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 -----------------------------------------------------------------

4 6

Garden server moving
by Patrick Gundlach 19 Aug '05

19 Aug '05

Hi, I'll move the garden server to a slightly faster and bigger machine. I have found out that a 5 gig disk is just not enough for all the fine ConTeXt thingies out there. I guess that I do the work on monday/tuesday. Just in case someone wants to store things on the machine (museum etc...), this can be done soon. Patrick (I'll write to the main list when I start moving) -- ConTeXt wiki and more: http://contextgarden.net

2 1

kpse
by Hans Hagen 16 Aug '05

16 Aug '05

Hi, The latest distribution has an experimental ruby kpse class in kpsefast.rb (expects updates -). As far as i can measure it's not slower than native kpse and once loaded in a ruby prog it's faster of than reinvoking kpse each time; it can (optionaly) dump the database in a home/temp path which halves loading time. I will probably use this mechanism in the coming texexec/texutil (maybe also in texmfstart). The associated variant of kpsewhich is 'tmftools' (no help yet). Apart from basic kpsewhich functionality it will harbor more tree tools. texmfstart tfmtools --analyze --root=/whatever/tex texmfstart tfmtools --analyze --root=/whatever/tex --trees=texmf,texmf-local can be very instructive on duplicate files on your machine and point you to problems. It has a --delete option which can be used as follows texmfstart tfmtools --analyze --root=/whatever/tex --delete "texmf-local/fonts/.*/lm" this will remove dups in texmf-local (to be sure, one needs to pass --force as well) 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 -----------------------------------------------------------------

1 0

lua
by Hans Hagen 09 Aug '05

09 Aug '05

Hi Hartmut, think of this: rewrite the map file mess in lua -) pseudo coded: \lua { <open file> <while not eof> <read and interpret line> pdftex.mapline(...) <end> <close file> } 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 -----------------------------------------------------------------

2 2

lua
by Hans Hagen 09 Aug '05

09 Aug '05

Hi, Recently i've started looking into Lua, a language meant for embedding in programs. It has a small footprint, and by reading themanukl i get the impression that it's a pretty well designed and clever language. So (after playing with lua and scite, which has it embedded) i started wondering about including lua in pdftex. Of course i'm dependent on others but i'm curious abotu wat members of this list think of it. It has quite a clever function model. Especially because it has a small footprint (some 100-150 k) it would add a lot to pdftex but at little cost. think of on the one hand: \dimen0=\lua{tex.todimen(tex.thedimen(0)+tex.thedimen(2)} kind of things, or \setbox2=\hbox to \lua{tex.todimen(somevar)} {\lua{tex.text("abcde")}} and alike. Of course the interface is to be determined, but a startingpoint can be access to box dimensions and registers and the ability to pipe text (strings) back into teh tex inpt stream. whatdoyouthink ... 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 -----------------------------------------------------------------

3 6