- dev-context - NTG Mailing Lists

confused with keys-xx.xml files
by Patrick Gundlach 07 Dec '04

07 Dec '04

Hi, in cont-en.xml: reservefloat: <cd:parameter name="frame"> <cd:constant type="on"/> <cd:constant type="off"/> in keys-de.xml: <cd:constant name="frame" value="rahmen"/> <cd:variable name="on" value="an"/> Why is "on" a constant in cont-en and a variable in keys-de.xml? What is a variable and what is a constant? In my understanding, "frame" here should be a variable, because it can be either "on" or "off". Patrick -- ConTeXt wiki: http://contextgarden.net

1 0

cont-xx.xml constant = type / name
by Patrick Gundlach 07 Dec '04

07 Dec '04

Hi, in cont-en.xml we have <cd:constant type="middle"/> <cd:constant type="..."/> <cd:constant type="12pt"/> <cd:constant type="default"/> as well as <cd:constant type="cd:dimension"/> IMO this should be something like <cd:constant name="middle"/> <cd:constant name="..."/> <cd:constant name="12pt"/> <cd:constant name="default"/> and keep <cd:constant type="cd:dimension"/> Which would be semantically more sensible. dimension is a "type" but middle is more a "name". But I don't know if its worth any trouble. Patrick -- ConTeXt wiki: http://contextgarden.net

1 0

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

06 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 11 Nov '04

11 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 11 Nov '04

11 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