April 2007 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-752 ] nc/nd broken
by noreply＠sarovar.org 03 Apr '07

03 Apr '07

Bugs item #752, was opened at 2007-04-03 11:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106 Category: Primitives Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: nc/nd broken Initial Comment: David Kastrup reports this: ------------------------ **\dimen0=1nc *\showthe\dimen0 > 12.80373pt. <*> \showthe\dimen0 ? *\dimen0=0.99998nc *\showthe\dimen0 > -0.09723pt. <*> \showthe\dimen0 ? This does not cut it at all. The section in tex.web starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 32768 or less. In LuaTeX, the section brazenly starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 65535 or less. Who does things like that without actually checking that they work? It is possible to rework the arithmetic to get along with 65535, but it is certainly not a matter of merely changing the _documentation_ and not the code. I have no idea whether this is an eTeX, a PDFTeX, an Aleph or a LuaTeX invention (did I forget anything?), but it certainly can't stay like that. Sorry if I sound like a whiner here. If you think it worth the trouble, I can rework the arithmetic (but there is a reason that Knuth kept to 15 bit factors, so it is going to become more complicated). But I consider it more likely that nc should be changed to 1370:107 which is the closest 15 bit fraction to 12nd (it is smaller than 12nd, but the next larger suitable fraction 32163:2512 is slightly further from 12nd). Please remember that in TeX, 2in is not equal to 1in+1in anyway. I think we can afford this. Certainly better than the current behavior. ------------------------ He tested it with luaTeX, but the bug is already in pdftex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0

Re: [NTG-pdftex] [Dev-luatex] What is the unit "nc" supposed to be?
by Martin Schröder 03 Apr '07

03 Apr '07

2007/4/3, David Kastrup <dak(a)gnu.org>: > New Cicero or what? >From the pdftex NEWS for 1.30: - pdftex knows two new units: - new Didot (1nd=0.375mm) - new Cicero (1nc=12nd) But it's broken in pdftex as well. :-( > Who does things like that without actually checking that they work? > It is possible to rework the arithmetic to get along with 65535, but > it is certainly not a matter of merely changing the _documentation_ > and not the code. Me. I got a patch and didn't check it. :-( Best Martin

1 0

[Fwd: [Dev-luatex] What is the unit "nc" supposed to be?]
by Taco Hoekwater 03 Apr '07

03 Apr '07

The following is forwarded from the LuaTeX list. -------- Original Message -------- Subject: [Dev-luatex] What is the unit "nc" supposed to be? Date: Tue, 03 Apr 2007 11:25:34 +0200 From: David Kastrup <dak(a)gnu.org> To: dev-luatex(a)ntg.nl New Cicero or what? Please consider the following: This is luaTeX, Version 3.141592-snapshot-2007040210 (Web2C 7.5.6) **\dimen0=1nc *\showthe\dimen0 > 12.80373pt. <*> \showthe\dimen0 ? *\dimen0=0.99998nc *\showthe\dimen0 > -0.09723pt. <*> \showthe\dimen0 ? * This does not cut it at all. The section in tex.web starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 32768 or less. In LuaTeX, the section brazenly starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 65535 or less. Who does things like that without actually checking that they work? It is possible to rework the arithmetic to get along with 65535, but it is certainly not a matter of merely changing the _documentation_ and not the code. I have no idea whether this is an eTeX, a PDFTeX, an Aleph or a LuaTeX invention (did I forget anything?), but it certainly can't stay like that. Sorry if I sound like a whiner here. If you think it worth the trouble, I can rework the arithmetic (but there is a reason that Knuth kept to 15 bit factors, so it is going to become more complicated). But I consider it more likely that nc should be changed to 1370:107 which is the closest 15 bit fraction to 12nd (it is smaller than 12nd, but the next larger suitable fraction 32163:2512 is slightly further from 12nd). Please remember that in TeX, 2in is not equal to 1in+1in anyway. I think we can afford this. Certainly better than the current behavior. -- David Kastrup _______________________________________________ dev-luatex mailing list dev-luatex(a)ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex

1 0

[ pdftex-Bugs-752 ] nc/nd broken
by noreply＠sarovar.org 03 Apr '07

03 Apr '07

Bugs item #752, was opened at 2007-04-03 11:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106 Category: Primitives Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: nc/nd broken Initial Comment: David Kastrup reports this: ------------------------ **\dimen0=1nc *\showthe\dimen0 > 12.80373pt. <*> \showthe\dimen0 ? *\dimen0=0.99998nc *\showthe\dimen0 > -0.09723pt. <*> \showthe\dimen0 ? This does not cut it at all. The section in tex.web starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 32768 or less. In LuaTeX, the section brazenly starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 65535 or less. Who does things like that without actually checking that they work? It is possible to rework the arithmetic to get along with 65535, but it is certainly not a matter of merely changing the _documentation_ and not the code. I have no idea whether this is an eTeX, a PDFTeX, an Aleph or a LuaTeX invention (did I forget anything?), but it certainly can't stay like that. Sorry if I sound like a whiner here. If you think it worth the trouble, I can rework the arithmetic (but there is a reason that Knuth kept to 15 bit factors, so it is going to become more complicated). But I consider it more likely that nc should be changed to 1370:107 which is the closest 15 bit fraction to 12nd (it is smaller than 12nd, but the next larger suitable fraction 32163:2512 is slightly further from 12nd). Please remember that in TeX, 2in is not equal to 1in+1in anyway. I think we can afford this. Certainly better than the current behavior. ------------------------ He tested it with luaTeX, but the bug is already in pdftex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0

Re: [NTG-pdftex] [tex-live] Debian TeX -- new packages
by Taco Hoekwater 02 Apr '07

02 Apr '07

Hi, From a discussion on TeX-Live with regard to the debian texlive packages for texlive and the complications raised by libpoppler: Sanjoy Mahajan wrote: > [What I describe below is not a Debian problem, but the proposed > change would make the packages easier for Ubuntu users to use. > > I added dev-context to the CC: list since the pkg deps affect Ubuntu > users -- e.g. me -- who use your excellent ConTeXt packages.] > > I'm using Ubuntu 6.10 (edgy) with all your tug.org stanzas. An > "apt-get install texlive-base-bin" or "apt-get install context" fails > when going from the TL2005 packages to the 2007 ones. The blocking > package is texlive-base-bin: > > # apt-get install texlive-base-bin > texlive-base-bin: > Depends: libpng12-0 (>= 1.2.13-4) but 1.2.8rel-5.1ubuntu0.1 is to be installed > Depends: libpoppler0c2 (>= 0.4.2) but it is not installable > E: Broken packages > > I'll upgrade to the Ubuntu 7.04 beta, which will solve the libpng12-0 > problem because Ubuntu 7.04 uses libpng 1.2.15. But libpoppler0c2 > would still be missing. Here are the libpoppler pkgs in versions of If I understand that thread correctly, the use of poppler instead of xpdf is now really a requirement on both debian and ubuntu? And you cannot share the binary packages between the various linuxes because there are packaging differences that cannot be resolved, at all? And that there are different versions of (dynamic) libpoppler that are mutually exclusive, even at compile-time? But at the same time, static binaries with xpdf linked in are not usable or 'not done' for some reason? If this is a sign of things to come, I may have to reconsider switching to MacOSX or freebsd. Taco

6 12

[Fwd: Re: [tex-live] buf-size]
by Hans Hagen 01 Apr '07

01 Apr '07

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 01 Apr '07

01 Apr '07

Bugs item #747, was opened at 2007-03-09 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2007-04-01 00:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 09:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 11:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 20:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 19:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 17:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0