- dev-context - NTG Mailing Lists

\rm in pmod, bmod, etc
by Aditya Mahajan 20 Feb '07

20 Feb '07

Hi Hans and Taco, Do you think it makes sense to replace {\rm mod} in the definition of bmod and pmod (in math-pln.tex) by \mfunction{mod}? Aditya

3 13

how to \obeyMPlines?
by Mojca Miklavec 15 Feb '07

15 Feb '07

Hello, It took me way too much time to trace the source of the problem, but now I've finally found it, although I don't know how to solve it. It's not crytical, but for some longer graphics metapost complains about too long lines. Assume the existance of the following file, say, a.tex: \startMYgraphic[1] draw fullcircle scaled 3cm; draw fullcircle scaled 3cm shifted (2cm,0); \stopMYgraphic The main file contains: \def\processMYfile[#1][#2]{% \def\startMYgraphic {\obeyMPlines % <- problem \dosingleargument\dostartMYgraphic} \long\def\dostartMYgraphic[##1]##2\stopMYgraphic {\startreusableMPgraphic{#1 ##1}##2\stopreusableMPgraphic} \readlocfile{#2}{}{} } \processMYfile[X][a.tex] \reuseMPgraphic{X 1} If I leave the \obeyMPlines there, I get spurious characters (probably because TeX adds some character codes which correspond to \r or \n). If I comment out the \obeyMPlines it works OK, but longer graphics fail. Thanks a lot, Mojca This is another, only partially related question, and still only of theoretical nature: Also, sometimes it fails because of TeX memory limit exceeded. (If gnuplot wants to draw a 100x100 grid, it needs 10.000 lines of code times three - one for color, one for shape, one for actually drawing/filling it, that makes it some 31.000 lines of code, and TeX cannot handle that. Will there be any possibility for a solution to it any time in the future except fixing gnuplot itself? It's not that important, but I would just like to know if that issue is solvable at all from within TeX or not.) Otherwise, the speed of gnuplot doesn't cause any problems any more. I don't know what has changed, but I bet that ConTeXt now works at least five times faster with graphics than it worked two years ago for plain text only ;)

2 4

[Fwd: [tex-live] wrong shebang in ConTeXt scripts break RPM packaging]
by Taco Hoekwater 13 Feb '07

13 Feb '07

just in case .. -------- Original Message -------- Subject: [tex-live] wrong shebang in ConTeXt scripts break RPM packaging Date: Tue, 13 Feb 2007 12:31:01 +0100 From: Jindrich Novy <jindranovy(a)gmail.com> To: tex-live(a)tug.org Hi all, I was bitten by a bug in ConTeXt while packaging the TeXLive 2007 texmf tree. RPM's find-requires script added a bogus dependency to /usr/env which prevented me to actually install the packages. I tracked it down to the ConTeXt package ruby scripts, where incorrect shebang is present in the wwwserver.rb. The cause might be that the ctxtools.rb script, which contains the add_shebang function, which is used to write a shebang to newly created scripts, contains a typo, when it refers to /usr/env, but should refer to /usr/bin/env as usual. Attaching patch that fixes it. Jindrich

2 1

[Fwd: CTAN Update: fonts iwona and kurier]
by Taco Hoekwater 13 Feb '07

13 Feb '07

-------- Original Message -------- Subject: CTAN Update: fonts iwona and kurier Date: Tue, 13 Feb 2007 15:39:56 +0100 (CET) From: CTAN Announcements <ctan-ann(a)dante.de> Organization: UNI-C To: ctan-ann(a)dante.de Newsgroups: comp.text.tex References: <Pine.LNX.4.44.0702131509310.2466-100000(a)fam82.internetdsl.tpnet.pl> On Tue, 13 Feb 2007, Staszek Wawrykiewicz submitted updates for the iwona and kurier packages. > ------ > Package: iwona > Version: 0.991 > Author: Janusz Marian Nowacki > License: GFNL (GUST-FONT-NOSOURCE-LICENSE based on LPPL) > Location on CTAN: fonts/iwona/ > > The current version (0.991) contains negationslash glyph corrected. > > ------ > Package: kurier > Version: 0.991 > Author: Janusz Marian Nowacki > License: GFNL (GUST-FONT-NOSOURCE-LICENSE based on LPPL) > Location on CTAN: fonts/kurier/ > > The current version (0.991) contains corrected negationslash glyph. Thanks for the upload. For the CTAN Team Rainer Schöpf

1 0

[contexttest-Feature Requests][73] Unbreakable space after labels in floats
by contexttest-featurerequests＠foundry.supelec.fr 13 Feb '07

13 Feb '07

Feature Requests item #73, was opened at 2007-02-05 01:13 You can respond by visiting: http://foundry.supelec.fr/tracker/?func=detail&atid=164&aid=73&group_id=21 Or by replying to this e-mail entering your response between the following markers: #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ (enter your response here) #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ Status: Open Priority: 3 Submitted By: Mojca Miklavec (mojca) Assigned to: Nobody (None) Summary: Unbreakable space after labels in floats Version: None Category: None Initial Comment: (from contextgarden.net) Unbreakable space after labels such as \setuplabeltext[de][figure=Abbildung~] in default configuration HH: But the word needs to be hyphenatable, so it would be something ...|~| or, i must think of it ---------------------------------------------------------------------- Comment By: Peter Münster (peter) Date: 2007-02-13 11:28 Message: I don't understand: "Abbildung " is as hyphenatable as "Abbildung~". Here is a test file: \starttext Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~% Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~% Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung~Abbildung \stoptext Peter ---------------------------------------------------------------------- You can respond by visiting: http://foundry.supelec.fr/tracker/?func=detail&atid=164&aid=73&group_id=21

1 0

[Fwd: Re: [OS X TeX] More New MacTeX Packages]
by Taco Hoekwater 12 Feb '07

12 Feb '07

Hi guys, See below. Does anybody have a chance to investigate? There is nothing I can do on my non-mac,non-texlive system, I am afraid. Taco -------- Original Message -------- Subject: Re: [dev-context] [OS X TeX] More New MacTeX Packages Date: Mon, 12 Feb 2007 12:54:25 +0000 From: Charles Doherty <charles.doherty(a)ntlworld.ie> To: Taco Hoekwater <taco(a)elvenkind.com> References: <9BAE31F9-2597-4DB4-92D6-764B7474D74B(a)math.uoregon.edu> <B5C315F8-AB5B-4271-B381-44E4D293144D(a)ntlworld.ie> <C6581A45-F555-4D73-924E-04AC4E57A766(a)rna.nl> <45D0305A.8050206(a)elvenkind.com> <20070212111945.GD9341(a)gamma.logic.tuwien.ac.at> <45D05107.6010603(a)elvenkind.com> <45D05162.60903(a)elvenkind.com> <06C14C4B-F82F-409F-9369-B1902CE8399C(a)ntlworld.ie> <45D05EDA.5000101(a)elvenkind.com> On 12 Feb 2007, at 12:34, Taco Hoekwater wrote: > Charles Doherty wrote: >> That works perfectly. At first run though I had random errors on >> accents and dashes but I trashed all auxiliary files and >> everything was correct on the fresh run. By the way it works with >> both the lines above Marvosym and MarVoSym > > Great. Ok, I'll add this to the context wiki as soon as texlive is > officially 'out'. > > Taco Taco, Just to be sure I tested a few more times. It works fine in gwTeX . I tried it on TeXLive-2007, the other package from Dick Kock's site. The euro symbol comes out right but the pound sterling £ is randomly changed to a dollar sign $. Also some accented words are garbled as well as some dashes. I trashed all auxiliary files to make sure no corruption was carried to a new run but these problems persisted. So the gwTeX distribution deals with it properly but not TeXLive-2007. Apologies for not testing a bit more before sending off the e-mail. I hope this is of some help. Charlie

1 0

Re: [dev-context] [Fwd: Re: Debian Context Font problems]
by Boguslaw Jackowski 12 Feb '07

12 Feb '07

NP> Mark mentioned it several times, it seems to be the freetype renderer. NP> xpdf per default uses t1lib and with t1lib rasterizer it does work NP> without problems. Sorry, I'm not on the list dev-context(a)ntg.nl, I received only the letter from you and (one) from Mike Bird <mgb-debian(a)yosemite.net>, who wrote: > Looks like lmodern and freetype don't get along. I like this formulation: at the moment I cannot swear, that LMs are flawless (in this respect; I'm sure they are not in many others... ;-) Therefore I tested the programs from commercial vendors, as there was no mention so far about them (or I just overlooked it), just to have more experimental data in hand. The only thing we can do -- at this stage -- is to experiment with global hints (I hope it is not an urgent matter...). Or maybe freetype team will earlier spot the reason? Has anybody informed them? Thank you very much for the efficient collaboration. Cheers -- Jacko -- BOP s. c. ul. Bora-Komorowskiego 24, 80-377 Gdansk, Poland tel. (+48 58) 553 46 59, fax (+48 58) 511 03 81 bop(a)bop.com.pl, http://www.bop.com.pl

2 1

Re: [dev-context] [Fwd: Re: Debian Context Font problems]
by Boguslaw Jackowski 12 Feb '07

12 Feb '07

HH> strange these par signs Strange, indeed. HH> esp 9/10 pt looks like the wrong glyphs are taken There are no fonts in question from which the incriminated (tall and thin) section glyphs may originate. Which program could intervene on the way? Enclosed you'll find the screen shots of the previews from Acrobat Readers 5.0 and 6.0 for (for the same magnifications and the same plain TeX example processed by dvips --> PS and GS 8.53 --> PDF). AR 6.0 is a little bit better (and it apparently renders the PDF with a higher resolution), but NO weird shapes can be observed. Cheers -- Jacko -- BOP s. c. ul. Bora-Komorowskiego 24, 80-377 Gdansk, Poland tel. (+48 58) 553 46 59, fax (+48 58) 511 03 81 bop(a)bop.com.pl, http://www.bop.com.pl

3 2

Re: [dev-context] [Fwd: Re: Debian Context Font problems]
by Boguslaw Jackowski 12 Feb '07

12 Feb '07

Hi, > Ok, I tried the following: > \setupbodyfont[17pt] [...] > \stoptext Thanks! Interesting... And what about trying a trivial plain script: \nopagenumbers \font\A=lmsy5 \font\a=ec-lmr5 \font\B=lmsy6 \font\b=ec-lmr6 \font\C=lmsy7 \font\c=ec-lmr7 \font\D=lmsy8 \font\d=ec-lmr8 \font\E=lmsy9 \font\e=ec-lmr9 \font\F=lmsy10 \font\f=ec-lmr10 \A \char120 \a 5\par \B \char120 \b 6\par \C \char120 \c 7\par \D \char120 \d 8\par \E \char120 \e 9\par \F \char120 \f 10\par \end You can also check various magnifications adding as the first line of the script \magnification=1200 or \magnification=800 or something else. All the best -- Jacko Ps. The only guess that comes to my mind is that there may be something wrong with the global hinting (so called blue zones). But in order to check it thoroughly I need a better controlled example. -- BOP s. c. ul. Bora-Komorowskiego 24, 80-377 Gdansk, Poland tel. (+48 58) 553 46 59, fax (+48 58) 511 03 81 bop(a)bop.com.pl, http://www.bop.com.pl

3 2

Re: [dev-context] [OS X TeX] More New MacTeX Packages
by Taco Hoekwater 12 Feb '07

12 Feb '07

Gerben Wierda wrote: > Hans & Taco, > > There is a potental problem with ConTeXt on TL2007 and the € symbol > havig to do with changes in marvosym. > > Charles, > > could you make a non gtamacfonts test file and see if that works? > Because I do not kow how ConTeXt works. If you have such a file and it > does not work, probably Has & Taco would like to kow the exact details. No need for a test file, the problem is staightforward enough. The UTF euro sign maps to the macro \texteuro, that then tries to find the best suited glyph. Since EC encoding doesn't have a euro symbol, context falls back to the marvosym font to provide one. But the metric file ConTeXt knows that font by (fmvr8x) was deleted from TeXLive, because the package (marvosym) that it belongs to has been updated, and it switched to a new name for the metric file. It is very likely they did not change *just* the name, but updated the base font file as well, so simple name remapping probably will not work anyway. We probably have to update the support macros for marvosym as well (cc the dev-context list). It is bad luck that the last-minute update to marvosym in texlive breaks the marvosym support in context, but there is no way to fix that any more. Meanwhile, if you need a euro sign, it looks like you have to use texnansi encoding. Greetings, Taco

2 3