- dev-context - NTG Mailing Lists

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

texshow-web rss feed added
by Patrick Gundlach 27 Oct '04

27 Oct '04

Hello, this is probably mainly for Taco: I've added a (yet simple) rss feed for the changes for texshow-web: http://texshow.contextgarden.net/rss-en.xml Patrick -- Context wiki: http://contextgarden.net

3 10

Latest version diff && website mirror
by Taco Hoekwater 21 Oct '04

21 Oct '04

Hi, The latest version diff is very minimal indeed: - texexec.pl: file existance checked before pdfopen call - textools.rb: format string for timestamp fixed - context.tex: version 2004.10.07 - type-cbg.tex: cbgreek name improved - type-xxx.tex: euler math package improvements - x-fe.tex: a typo fixed For the website mirror, I do not use wget.txt, but a 'full parse' of the website. This is intentional, because it helps debugging. Here are the 'not found' documents that were discovered last night: > http://www.pragma-ade.com/dir.pdf > http://www.pragma-ade.com/general/manuals/xcorresp.pdf > http://www.pragma-ade.com/general/manuals/ex-imple.pdf > http://www.pragma-ade.com/general/manuals/ex-ample.pdf > http://www.pragma-ade.com/general/manuals/xmlfoe.pdf > http://www.pragma-ade.com/general/manuals/foxet.pdf > http://www.pragma-ade.com/present/road/roadmap.pdf > http://www.pragma-ade.com/dir > http://www.pragma-ade.com/present/road/roadshow.pdf All of those files are linked to from somewhere within the HTML pages, but do not actually exist. And another question: would it be possible to stop using absolute paths in the internal html links? I am talking about things like: <a href="/about-1.htm" title="...">about</a> My website mirror is located in the directory /context/mirror, so "my" about-1.htm is actually available as "/context/mirror/about-1.htm", but not as "/about-1.html". The result is that almost all internal links in http://tex.aanhet.net/context/mirror are currently broken. If it this cannot be fixed easily, I will have to create http://context.aanhet.net but I'd rather not do that, if it is easy to fix on the generating end. -- groeten, Taco

3 5

Fw: [dev-context] Latest version diff && website mirror
by Taco Hoekwater 08 Oct '04

08 Oct '04

Begin forwarded message: Date: Fri, 8 Oct 2004 11:50:13 +0200 From: Taco Hoekwater <taco(a)elvenkind.com> To: Hans Hagen <pragma(a)wxs.nl> Subject: Re: [dev-context] Latest version diff && website mirror On Fri, 08 Oct 2004 11:23:21 +0200, Hans wrote: > Taco Hoekwater wrote: > > >>http://www.pragma-ade.com/dir.pdf > > that is no pdf file, but a directory view, i.e. /dir is a trigger for > the web server which you can best ignore It *is*l generating a 404 Error though, so something must be wrong (linked from overview.htm) > > And another question: would it be possible to stop using absolute > > paths in the internal html links? I am talking about things like: > > > > <a href="/about-1.htm" title="...">about</a> > > i have to play with that a bit; the problem is that i need the / because > sometimes they are called deep down a tree (the reverse of your problem) No problem. New location of my mirror: http://context.aanhet.net effective as of now. :-) -- groeten, Taco -- groeten, Taco

2 1

Alpha (now main) -> changes
by Taco Hoekwater 07 Oct '04

07 Oct '04

Hans and others, I really believe this is an error: - context.tex: contextversion is now 2004.06.10 (that would be june 10 !) Flowcharts: - What happened there? General stuff: - There are a lot of fixes to the inline documentation (dutch-> english), a number of commented out sections are finally removed, some minor ML fixes, and a few locations where \the\uccode should/could have been plain \uccode. And some XML (FO) things have changed yet again but I can't be bothered to list those. For the rest, here we go: - context.properties: adds xsl extension - texexec.pl: <context-directive> additional 'module' attribute, a bugfix in the interface chooser, and xetex support. - textools.rb: two new private actions: --touchcontextfile --downcasefilenames - xmltools.rb: file existance paranoia added (?) - switch.rb: recursive file globbing added - colo-hex.tex: support for xetex hex colors - context.tex: contextversion is now 2004.06.10 - cont-fil.tex: new file synonym 'exi-interface' - cont-new.tex: some XML tricks added - cont-usr.ori: support for catalan language - core-new.tex: eol magic in 'setups' - core-not.tex: footnote extension/bugfix - lang-ita.tex: catalan support - math-ini.tex: active characters bugfix - m-chart.tex: major cleanup, perhaps new functionality as well - page-mar.tex: "\vadjust pre" no longer used, Omega support removed - page-not.tex: footnote fix in columns - spec-fdf.tex : \flushFDFnames fixed - spec-xtx.tex: new specials, for xetex - x-mathml.tex: {\start,\stop}XMLinlinemath removed As usual, i may have missed and/or misinterpreted some. I will do a 'Release Notes' diff set eventually, but I'd rather wait for the version number to be corrected :-) -- groeten, Taco

2 1

Re: [dev-context] footnote/align spacing bug in dutch alpha
by Taco Hoekwater 07 Oct '04

07 Oct '04

Any chance of a quick fix? Hans wrote: > > the problem was introduced when first/last column footnotes were > implemented > -- groeten, Taco

2 1