April 2007 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 04 Apr '07

04 Apr '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: Accepted Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-04-04 19:42 Message: Logged In: YES user_id=421 The default might be reasonable, but even setting the fontflags as 4 (symbol) doesn't work, as this is interpreted as being the default and changed to 34. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 04 Apr '07

04 Apr '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

[ pdftex-Bugs-762 ] symbolic font gets /Flags as nonsymbolic
by noreply＠sarovar.org 04 Apr '07

04 Apr '07

Bugs item #762, was opened at 2007-04-04 19:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 7 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: symbolic font gets /Flags as nonsymbolic Initial Comment: The input file \pdfcompresslevel=0 \pdfmapline{psyr Symbol} \nopagenumbers \font\sy=psyr \sy a \end results in a pdf with a Font Descriptor with /Flags 34 for the Symbol font, which is wrong; it should be 4. The flags are initialized as 4 in mapfile.c and writefont.c sees this as the default value and writes 34 to the pdf. Reported by TeX Guy <pdftexlist(a)gmail.com> and analyzed by George N. White III <gnwiii(a)gmail.com>; see the thread starting at http://tug.org/pipermail/pdftex/2007-April/007133.html ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=762&group_id=106

1 0

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

04 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: Closed Resolution: Fixed 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. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-04-04 12:44 Message: Logged In: YES user_id=421 Accepted (with minor documentation corrections). ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 09:30 Message: Logged In: NO Here is a patch for the last comment. Index: luatex.web =================================================================== --- luatex.web (revision 383) +++ luatex.web (working copy) @@ -11534,7 +11534,7 @@ end @ The necessary conversion factors can all be specified exactly as -fractions whose numerator and denominator are 65535 or less. +fractions whose numerator and denominator add to 32768 or less. According to the definitions here, $\rm2660\,dd\approx1000.33297\,mm$; this agrees well with the value $\rm1000.333\,mm$ cited by Bosshard @^Bosshard, Hans Rudolf@> @@ -11542,8 +11542,12 @@ The Didot point has been newly standardized in 1978; it's now exactly $\rm 1\,nd=0.375\,mm$. Conversion uses the equation $0.375=21681/20320/72.27\cdot25.4$. -The new Cicero follows the new Didot point; $\rm 1\,nc=12\,nd$. - +The new Cicero follows the new Didot point; $\rm 1\,nc=12\,nd$. These +would lead to the ratios $21681/20320$ and $65043/5080$, respectively. +The closest approximations supported by the algorithm would be +$11183/10481$ and $1370/107$. In order to maintain the +relation $\rm 1\,nc=12\nd$, we pick the ratio $685/642$ for $\rm nc$, +however. @d set_conversion_end(#)== denom:=#; end @d set_conversion(#)==@+begin num:=#; set_conversion_end @@ -11562,9 +11566,9 @@ @.dd@> else if scan_keyword("cc") then set_conversion(14856)(1157) @.cc@> -else if scan_keyword("nd") then set_conversion(21681)(20320) +else if scan_keyword("nd") then set_conversion(685)(642) @.nd@> -else if scan_keyword("nc") then set_conversion(65043)(5080) +else if scan_keyword("nc") then set_conversion(1370)(107) @.nc@> else if scan_keyword("sp") then goto done @.sp@> ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 09:28 Message: Logged In: NO Here is a patch for the last comment. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 08:37 Message: Logged In: NO Unfortunately, Knuth's original comment is _also_ wrong. The _sum_ of numerator and denominator must not exceed 32768. So the conversion ratio for nd is _also_ incorrect, as can be witnessed by checking the value 9.99998nd. Changing the ratio to 685:642 would reconstitute the relation 12nd=1nc. The closest approximation for nd that works with the code would be 11183:10481. However, we are talking about differences in the order of 1e-7, so the ratio with the simpler relation to nc might be preferable. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-03 11:43 Message: Logged In: YES user_id=421 A patch is attached; this will be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0

Proposed patch for the nc/nd problem
by David Kastrup 04 Apr '07

04 Apr '07

Seems like I can't get a patch attached to a bug report in the PDFTeX system, and Martin has closed the bug after fixing the first half. Here is a proposed patch to deal with the rest (note that 9.99998nd gets a wrong value, too, with the current code even though it adheres to Knuth's original description of the constraints). It also fixes Knuth's comment, and puts the nd ratio in shortest terms. The patch is based on LuaTeX, but it should be possible to apply it to pdfTeX. -- David Kastrup

1 0

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

04 Apr '07

Bugs item #752, was opened at 2007-04-03 14:50 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: Closed Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 13:00 Message: Logged In: NO Here is a patch for the last comment. Index: luatex.web =================================================================== --- luatex.web (revision 383) +++ luatex.web (working copy) @@ -11534,7 +11534,7 @@ end @ The necessary conversion factors can all be specified exactly as -fractions whose numerator and denominator are 65535 or less. +fractions whose numerator and denominator add to 32768 or less. According to the definitions here, $\rm2660\,dd\approx1000.33297\,mm$; this agrees well with the value $\rm1000.333\,mm$ cited by Bosshard @^Bosshard, Hans Rudolf@> @@ -11542,8 +11542,12 @@ The Didot point has been newly standardized in 1978; it's now exactly $\rm 1\,nd=0.375\,mm$. Conversion uses the equation $0.375=21681/20320/72.27\cdot25.4$. -The new Cicero follows the new Didot point; $\rm 1\,nc=12\,nd$. - +The new Cicero follows the new Didot point; $\rm 1\,nc=12\,nd$. These +would lead to the ratios $21681/20320$ and $65043/5080$, respectively. +The closest approximations supported by the algorithm would be +$11183/10481$ and $1370/107$. In order to maintain the +relation $\rm 1\,nc=12\nd$, we pick the ratio $685/642$ for $\rm nc$, +however. @d set_conversion_end(#)== denom:=#; end @d set_conversion(#)==@+begin num:=#; set_conversion_end @@ -11562,9 +11566,9 @@ @.dd@> else if scan_keyword("cc") then set_conversion(14856)(1157) @.cc@> -else if scan_keyword("nd") then set_conversion(21681)(20320) +else if scan_keyword("nd") then set_conversion(685)(642) @.nd@> -else if scan_keyword("nc") then set_conversion(65043)(5080) +else if scan_keyword("nc") then set_conversion(1370)(107) @.nc@> else if scan_keyword("sp") then goto done @.sp@> ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 12:58 Message: Logged In: NO Here is a patch for the last comment. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 12:07 Message: Logged In: NO Unfortunately, Knuth's original comment is _also_ wrong. The _sum_ of numerator and denominator must not exceed 32768. So the conversion ratio for nd is _also_ incorrect, as can be witnessed by checking the value 9.99998nd. Changing the ratio to 685:642 would reconstitute the relation 12nd=1nc. The closest approximation for nd that works with the code would be 11183:10481. However, we are talking about differences in the order of 1e-7, so the ratio with the simpler relation to nc might be preferable. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-03 15:13 Message: Logged In: YES user_id=421 A patch is attached; this will be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0

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

04 Apr '07

Bugs item #752, was opened at 2007-04-03 14:50 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: Closed Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 12:58 Message: Logged In: NO Here is a patch for the last comment. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 12:07 Message: Logged In: NO Unfortunately, Knuth's original comment is _also_ wrong. The _sum_ of numerator and denominator must not exceed 32768. So the conversion ratio for nd is _also_ incorrect, as can be witnessed by checking the value 9.99998nd. Changing the ratio to 685:642 would reconstitute the relation 12nd=1nc. The closest approximation for nd that works with the code would be 11183:10481. However, we are talking about differences in the order of 1e-7, so the ratio with the simpler relation to nc might be preferable. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-03 15:13 Message: Logged In: YES user_id=421 A patch is attached; this will be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0

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

04 Apr '07

Bugs item #752, was opened at 2007-04-03 14:50 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: Closed Resolution: Fixed 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. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-04-04 12:07 Message: Logged In: NO Unfortunately, Knuth's original comment is _also_ wrong. The _sum_ of numerator and denominator must not exceed 32768. So the conversion ratio for nd is _also_ incorrect, as can be witnessed by checking the value 9.99998nd. Changing the ratio to 685:642 would reconstitute the relation 12nd=1nc. The closest approximation for nd that works with the code would be 11183:10481. However, we are talking about differences in the order of 1e-7, so the ratio with the simpler relation to nc might be preferable. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-04-03 15:13 Message: Logged In: YES user_id=421 A patch is attached; this will be included in the next release. ---------------------------------------------------------------------- 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 Taco Hoekwater 03 Apr '07

03 Apr '07

David Kastrup wrote: > But I consider it more likely that nc should be changed to 1370:107 And also, I applied this change to luatex.web (and fixed the documentation sting back). TeX's conversions are approximations anyway, I see little point in changing the conversion arithmetic. Taco

4 7

[ 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: Closed >Resolution: Fixed 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. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-04-03 11:43 Message: Logged In: YES user_id=421 A patch is attached; this will be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=752&group_id=106

1 0