<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 January 2016 at 05:08, Reinhard Kotucha <span dir="ltr"><<a href="mailto:reinhard.kotucha@web.de" target="_blank">reinhard.kotucha@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 2016-01-19 at 23:50:13 +0000, Karl Berry wrote:<br>
<br>
> Hi David,<br>
><br>
> Currently pdftexconfig.tex sets \pdfdecimaldigits=3<br>
> In other words was there a particular reason to choose 3....<br>
><br>
> Not that I know of, but then I probably wouldn't know. (Ross, Thanh?)<br>
><br>
> However, in any case ... changing it at this late date would mean, I<br>
> think, that most PDF output from pdftex would be gratuitiously different<br>
> from what was produced before. That doesn't sound like a good outcome.<br>
> On the badness scale, I'd say that's rather worse than not being able to<br>
> share settings ... -k<br>
<br>
</div></div>AFAIR Hartmut Henkel investigated a decade ago and came to the<br>
conclusion that more than 3 decimal digits don't make sense.<br>
<br>
As far as the backend is concerned, it sounds reasonable. PDF's unit<br>
is a "big point", and with <div class="gmail_default" style="font-size:small;display:inline"></div>\pdfdecimaldigits=3 the resolution in the<br>
PDF file is about 0.3µm. This should be sufficient in most cases.<br>
If it's not sufficient in a particular case, the configuragtion can be<br>
changed.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="display:inline"></div>\pdfdecimaldigits=3 was a decision that makes sense for most cases. A larger value</div><div class="gmail_default" style="font-size:small">results in bigger pdf output without visible change to human eyes.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Hans said that many transformations are involved. Sure, if too many<br>
"cm" ("concat" in PostScript) operations are written to the PDF file,<br>
rounding errors add up.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">yes, this is a valid case where it makes sense </div><div class="gmail_default" style="display:inline"> to have </div> <div class="gmail_default" style="display:inline">larger \</div>pdfdecimaldigits<div class="gmail_default" style="display:inline"></div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Hans distinguishes between LuaTeX internals and the (PDF) backend.<br>
<br>
So what does \pdfdecimaldigits actually control? Since LuaTeX is<br>
written in C I would expect that numbers are either floats, doubles,<br>
or integers internally and numbers are represented with a reasonable<br>
resolution.<br>
<br>
Does \<div class="gmail_default" style="font-size:small;display:inline"></div>pdfdecimaldigits really control how numbers are processed in the<br>
innards of LuaTeX? That would be strange.<br>
<br>
If<div class="gmail_default" style="font-size:small;display:inline"></div> \pdfdecimaldigits only controls how numbers are represented in a<br>
PDF file,</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">When outputting a dimen to PDF, pdftex rounds the value represented in scaled</div><div class="gmail_default" style="font-size:small">point by tex to a real number in PDF, and <div class="gmail_default" style="display:inline"></div> \pdfdecimaldigits says how </div><div class="gmail_default" style="font-size:small">many digits can be after the the decimal point. The differences between the </div><div class="gmail_default" style="font-size:small">outputted value in PDF and the desired value (in scaled point) are tracked, in order </div><div class="gmail_default" style="font-size:small">to minimize the accumulation of rounding errors.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Example (roughly):</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- pdftex needs to move the pen to the right by 123456 sp</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- convert to bp: 123456 sp = (123456/65536)*(7200/7227) = 1.87675124533001245328</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- \pdfdecimaldigits=3 => outputted value: 1.877 </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- pdftex takes into account that the pen was moved to the right by </div><div class="gmail_default" style="font-size:small"> 1.877bp = 1.877*(7227/7200)*65536 = 123472.36352 = 123472 sp </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- the difference (123456 - 123472) will be considered when the next pen movement comes</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Thanh</div></div></div></div></div>