<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 16, 2019 at 3:41 PM Marcel Fabian Krüger <<a href="mailto:tex@2krueger.de">tex@2krueger.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 20, 2019 at 08:26:22PM +0100, Marcel Krüger wrote:<br>
>  ---- On Wed, 20 Mar 2019 19:01:08 +0100 luigi scarso <<a href="mailto:luigi.scarso@gmail.com" target="_blank">luigi.scarso@gmail.com</a>> wrote ----<br>
>  > <br>
>  > <br>
>  > On Wed, Mar 20, 2019 at 6:54 PM Marcel Kr&uuml;ger <<a href="mailto:tex@2krueger.de" target="_blank">tex@2krueger.de</a>> wrote:<br>
>  > Thanks. There is one other thing, I do not really know if I would describe it as a backward compatibility bug or a feature request:<br>
>  > <br>
>  > For non-"scaled" numbersystems, code like<br>
>  > <br>
>  > filldraw stroke z1e--z2e;<br>
>  > (example taken from cmbase.mf, `left_bracket`)<br>
>  > <br>
>  > fail, because z1e-- is interpreted as z 1e- - instead of z1e --. So z1e--z2e is equal to z1-z2e, leading to lots of errors.<br>
>  > <br>
>  > I understand that the new numbersystems and the exponential syntax can lead to problems of this kind, but I think this could be avoided:<br>
>  > Maybe a `e+` / `e-` could only be interpreted as exponential notation if it is followed by a  digit? I do not think<br>
>  > anyone would write "1e-" or "3e+" for 1 or 3, so it should not lead to any breakage.<br>
>  > On the other hand it would catch almost all cases where this is invoked accidentially.<br>
>  > <br>
>  > A possible implementation of this change  is attached.<br>
>  > <br>
>  > <br>
>  > hm it looks like a serious bug, and I fear I will not able to fix it for next TL --- but I hope to put it into trunk immediately after the TL code is frozen.<br>
>  > <br>
> <br>
> Right, I am sorry for bringing this up so late in the TL cycle.<br>
> <br>
> One additional note on this: The behaviour described above (`1e-` being interpreted as `1`) seems to be specific to the `double` mode.<br>
> The `decimal` mode just fails because it is not able to parse the number, which further reduces the risk of breaking some code by changing the current<br>
> behaviour.<br>
> <br>
> Also I attached a fixed version of the earlier patch, there was a smaller error.<br>
> <br>
> Best regards,<br>
> Marcel Krüger<br>
> <br>
>  > <br>
>  > -- <br>
>  > luigi<br>
>  ><br>
<br>
Hi,<br>
<br>
are there still plans to fix this?<br>
<br>
Best regards,<br>
Marcel<br>
<br>
<br>
<br>
--<br>
<a href="http://tug.org/metapost/" rel="noreferrer" target="_blank">http://tug.org/metapost/</a><br>
</blockquote></div><div><br></div>Hm, have you mixed email ?<br clear="all"><div>Here Subject  says</div><div>Re: [metapost] Uninitialized variable sometimes causing malformed TFM files<br></div><div>the content is quite different .</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">luigi<br></div></div>