November 2004 - dev-context - NTG Mailing Lists

Re: symb-uni.tex (was: degree sign)
by Duncan Hothersall 13 Dec '04

13 Dec '04

Maybe the dev list is a better place for this follow-up. I'm trying to understand (a) what exactly the task is to create the maths vectors, and (b) what is really going on with the degree sign. Taking (b) first... Looking in unic-000.tex (the degree sign is #00B0 = char 176 in vector 0) I see two vector definitions. Does the second supersede the first or are both needed? Looking at the second vector definition, it starts at char 159 and so looking down to position 176 there appears to be the correct code - namely \textdegree. This presumably explains why it appears correctly in running text in my sample posted to the ConTeXt list. But why does it not work in the XMLdata section? Is it the case that there is another unicode processing system for data being processed as XML? Is this where the fix is required? As to question (a) - for example what exactly should I put into, say unic-034.tex to denote #222A (character 42 in vector 34) as \cup? Do I need two \startunicodevector commands? Or do i just do \startunicodevector 34 \unknownchar \or ... [repeat 41 times] ... \cup \or ... \stopunicodevector ? Sorry if this betrays a lack of understanding. Look forward to clarification. Duncan Adam Lindsay (23/11/2004 13:42) said: >>Duncan Hothersall wrote: >> >> >>>I have been searching in the base files but can't see the hook. Can >>>anyone point me in the right direction to fix this? Thanks. >> >>we (you -) need to define unic-*.tex vectors for the math ranges, > > > The attached symbol file might be a place to start. > (didn't bother with list, cos file's to big)

3 6

interface xml files / ctxtools
by Patrick Gundlach 07 Dec '04

07 Dec '04

Hello Hans, it looks as if texmfstart/ctxtools is not trying kpsewhich and alike. For texshow-web I'd like to rely on cont-en.xml in the current dir only and texmfstart/ctxtools should take the keys-xx.xml from the distribution: pg$ texmfstart ctxtools.rb --translate ro CtxTools | generating keys-ro.xml CtxTools | no keys-ro.xml generated right, I have no keys-ro.xml in my dir: pg$ ls keys-ro.xml ls: keys-ro.xml: No such file or directory but texmfstart should be able to find it: pg$ kpsewhich keys-ro.xml /opt/context/latest/texmf/tex/context/interface/keys-ro.xml Would it be possible to use the kpathse stuff as fallback? Patrick -- ConTeXt wiki: http://contextgarden.net

4 8

key files
by Patrick Gundlach 02 Dec '04

02 Dec '04

Hi, the keys-??.xml should have another namespace. Now: <cd:interface xmlns:cd="http://www.pragma-ade.com/commands" name="context" language="de" version="2004.11.16"> future: <cd:keys xmlns:cd="http://www.pragma-ade.com/keys" name="context" language="de" version="2004.11.16"> (or something like this, what is this name="context" for?) Patrick -- ConTeXt wiki: http://contextgarden.net

2 2

translations of xml files
by Patrick Gundlach 17 Nov '04

17 Nov '04

Hello Hans, Taco and others, we now have in cont-en.xml: <cd:command name="showlayout"> <cd:sequence> <cd:string value="showlayout"/> </cd:sequence> </cd:command> and in cont-de.xml <cd:command name="zeigelayout"> <cd:sequence> <cd:string value="zeigelayout"/> </cd:sequence> </cd:command> what about making the german (....) translation to something like: <cd:command name="showlayout" lang="de"> <cd:sequence> <cd:string value="zeigelayout"/> </cd:sequence> </cd:command> so we can easily see what showlayout is in different languages/interfaces. P. Atrick -- ConTeXt wiki: http://contextgarden.net

3 3

Re: fontdimen trickery
by Taco Hoekwater 17 Nov '04

17 Nov '04

(Switched to dev. list) Hans Hagen wrote: > \setupbodyfont[new] > > {\csname*new12ptmmmi*\endcsname \fontdimen7\font=1pt} What about: \fontdimen7\csname*new12ptmmmi*:\endcsname=0pt (with the appended colon) is that too low-level?

4 8

BiDi in ConTeXt
by Adam Lindsay 12 Nov '04

12 Nov '04

Hi folks. I just started thinking about further language support within ConTeXt now that the XeTeX-ConTeXt "basics" are done. XeTeX doesn't have the same character/line directionality control that is apparently in Omega, but it does control Right/Left typesetting fairly well. In particular, it makes a fairly big deal of its implementation of the eTeX beginR/beginL extensions. They seem to work fairly well in demos I've seen and simplistic tests I've done. I was wondering about the bigger issues in terms of BiDi support, though. Do people want an interface that mimics Omega's \pardir command? Or is there a more simple/focussed/specific way? (I imagine I don't see a single \beginR in ConTeXt's source code because it relies heavily on proper font support, probably beyond what the TFM system usually offers.) Anyway, I cooked up a quick simulation of the Omega \pardir command as used in m-gamma. It only supports \pardir TRT and \pardir TLT, but is it a way people want to progress? \def\pardir#1#2#3{%TRT,TLT \ifnum\TeXXeTstate=1\else \TeXXeTstate=1\fi % check or blindly set? \doifinsetelse{#2}{R,L} {\EveryPar{\setbox0=\lastbox % \csname begin#2\endcsname\box0}} {\message{Paragraph direction must be right or left}} \doifnot{#1#3}{TT} {\message{Typesetting lines from top to bottom only}}} Also, is dev-context the right place for a discussion like this? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

3 8

Fwd: Re: BiDi in ConTeXt
by Adam Lindsay 12 Nov '04

12 Nov '04

[Idris couldn't reply to the list, so I'm forwarding it.] ---------------- Begin Forwarded Message ---------------- Subject: Re: BiDi in ConTeXt Date Sent: Thursday, 11 November 2004 14:37 From: Idris Samawi Hamid <ishamid(a)colostate.edu> To: Adam Lindsay <atl(a)comp.lancs.ac.uk> , Dev Context <dev-context(a)ntg.nl> [Please forward to dev-context(a)ntg.nl] On Thu, 11 Nov 2004 14:53:25 +0000, Adam Lindsay <atl(a)comp.lancs.ac.uk> wrote: > Hi folks. Hi Adam, & thnx for cc'ing me. > I just started thinking about further language support within ConTeXt now > that the XeTeX-ConTeXt "basics" are done. XeTeX doesn't have the same > character/line directionality control that is apparently in Omega, but it > does control Right/Left typesetting fairly well. I've been out of the loop on all things TeX for a while now (demands of my profession and other matters). I have a couple of general questions: 1. What exactly is the aim and purpose of XeTeX? 2. Since its apparently based on eTeX, and since bidi seems to be of interest, why not integrate it with the Aleph project, also eTeX-based (with an eye towards ConTeXt), and which already has the bidi stuff implemented rather well? > In particular, it makes a fairly big deal of its implementation of the > eTeX beginR/beginL extensions. They seem to work fairly well in demos > I've seen and simplistic tests I've done. > > I was wondering about the bigger issues in terms of BiDi support, though. > Do people want an interface that mimics Omega's \pardir command? Or is > there a more simple/focussed/specific way? If the idea is a kind of BiDi-Light (just paragraph and text), then implementing a subset of Aleph's functionality (such as \pardir and textdir) seems like a good way to go. > (I imagine I don't see a single \beginR in ConTeXt's source code because > it relies heavily on proper font support, probably beyond what the TFM > system usually offers.) which is where we will need Aleph and Bidi-Full > Also, is dev-context the right place for a discussion like this? Please also cc the Aleph list (and forward this thread) because others there may find your project interesting or useful. If things get off-topic ConTeXt-wise then the Aleph list would be a good place to continue. Is Giuseppe aware of all of this (I assume he's on dev-context)? Best Idris -- Professor Idris Samawi Hamid Department of Philosophy Colorado State University Fort Collins, CO 80523 ----------------- End Forwarded Message ----------------- -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

XeTeX specials in ConTeXt
by Adam Lindsay 08 Nov '04

08 Nov '04

[resent. stripped big pdf attachment. Get PDF at: http://homepage.mac.com/atl/tex/figuretext.pdf ] Hi all, I've been working away at the XeTeX special drivers in ConTeXt, and I still keep running up against the problem where an \externalfigure gets found and framed correctly, but the graphic itself ends up on the lower left corner of the page. I've tried countless variations on the specials, but something in core- fig has me completely stymied. I'm now officially in over my head. I hope there's someone out there who might be able to give me a further clue. Some notes: The specials have undergone all sorts of silly variations. As a result, what you see in the file doesn't reflect the cleanest code. Quoted from the XeTeX manual: "The final result of a \XeTeXpicfile command is an object which can be included in the text being typeset just like a character, albeit usually a rather large one. It could be thought of as a box, though it cannot be unboxed. It can, however, be put inside a normal TEX box register, and in fact this is often desirable." This unboxing thing sounds potentially critical, but AFAIK, no such thing happens in core-fig. Near as I can tell, the \foundexternalfigure box is obtained and measured from my \dogetXTXfiguresize. In the macros as they currently stand, my \handlepdfimage isn't actually called, because core-fig thinks it has the box. [Jonathan, I don't expect you to follow what happens with ConTeXt's giant core-fig file. I'm just writing to see if the output triggers anything that you might recognise.] [Hans, the spec-xtx file is ready to replace what's currently in the ConTeXt distro, which works even less than what's here.] So, does anyone have any words of wisdom? Thanks, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

3 3

XeTeX specials in ConTeXt
by Adam Lindsay 07 Nov '04

07 Nov '04

Hi all, I've been working away at the XeTeX special drivers in ConTeXt, and I still keep running up against the problem where an \externalfigure gets found and framed correctly, but the graphic itself ends up on the lower left corner of the page. I've tried countless variations on the specials, but something in core- fig has me completely stymied. I'm now officially in over my head. I hope there's someone out there who might be able to give me a further clue. Some notes: The specials have undergone all sorts of silly variations. As a result, what you see in the file doesn't reflect the cleanest code. Quoted from the XeTeX manual: "The final result of a \XeTeXpicfile command is an object which can be included in the text being typeset just like a character, albeit usually a rather large one. It could be thought of as a box, though it cannot be unboxed. It can, however, be put inside a normal TEX box register, and in fact this is often desirable." This unboxing thing sounds potentially critical, but AFAIK, no such thing happens in core-fig. Near as I can tell, the \foundexternalfigure box is obtained and measured from my \dogetXTXfiguresize. In the macros as they currently stand, my \handlepdfimage isn't actually called, because core-fig thinks it has the box. [Jonathan, I don't expect you to follow what happens with ConTeXt's giant core-fig file. I'm just writing to see if the output triggers anything that you might recognise.] [Hans, the spec-xtx file is ready to replace what's currently in the ConTeXt distro, which works even less than what's here.] So, does anyone have any words of wisdom? Thanks, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: [NTG-context] Bug in math accents (analyzed)
by Taco Hoekwater 01 Nov '04

01 Nov '04

Hans, The problem is that your code does not set \skewchar for the \scriptfont and \scriptscriptfont of the relevant math families. You need to make sure you set all three of \textfont X, \scriptfont X and \scriptscriptfont X. This requires some minor rewriting of a few macros in font-ini.tex. I could do that for you, but my coding style is not even remotely similar to yours so I wager you'd rather do it yourself. ;-) Attached is a plain/context 'dual mode' test file. Greetings, Taco Taco Hoekwater wrote: > On Thu, 28 Oct 2004 13:14:46 +0200 > Hans Hagen <pragma(a)wxs.nl> wrote: > > >>Maybe some italic correction is needed here; or a tilde from an italic >>font : question for Taco, btw, in contex, \tilde in this case expands to >> >>\mathaccent "0\purefamilyhex {mr}7E >> >>which is the plain definition, so i wonder what goes wrong there. > > > My initial feeling is that the relevant font parameters are perhaps wrong or > even non-existant. (this would not show up in the expansion debug info, of > course). I cannot investigate a.t.m., but if nobody else is able and willing, > I look into it next week. > > Greetings, Taco > _______________________________________________ > ntg-context mailing list > ntg-context(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-context

2 1