[metapost] luamplib fails to process string with "char 0"
Hans Hagen
j.hagen at xs4all.nl
Thu Jul 29 17:36:17 CEST 2021
On 7/29/2021 4:23 PM, Toby Thurston wrote:
>
>> On 29 Jul 2021, at 13:24, Hans Hagen <j.hagen at xs4all.nl
>> <mailto:j.hagen at xs4all.nl>> wrote:
>>
>> On 7/29/2021 1:16 PM, Toby Thurston wrote:
>>> consider the following MP program, which is trying to print the Greek
>>> alphabet in the default font using the default TeX encoding, which
>>> puts Gamma at position zero
>>> prologues := 3;
>>> outputtemplate := "%j%c.eps";
>>> beginfig(1);
>>> string AB;
>>> AB = ("AB" & char 0 & char 1 & "EZH" & char 2 & "IK"
>>> & char 3 & "MNO" & char 4 & char 5 & "P"
>>> & char 6 & "T" & char 7 & char 8 & "X"
>>> & char 9 & char 10);
>>> draw AB infont "cmmi10" shifted 10 up;
>>> draw AB infont "eurm10" shifted 10 down;
>>> draw bbox currentpicture;
>>> endfig;
>>> end.
>>> if I run this through `mpost` (MetaPost 2.00 (TeX Live 2021)
>>> (kpathsea version 6.3.3)) I get two lines with the expected 24 Greek
>>> characters in each, with a box around them.
>>> But if I change the program to wrap it up with luamplib like this:
>>> \documentclass{standalone}
>>> \usepackage{luamplib}
>>> \begin{document}
>>> \begin{mplibcode}
>>> beginfig(1);
>>> string AB;
>>> AB = ("AB" & char 0 & char 1 & "EZH" & char 2 & "IK"
>>> & char 3 & "MNO" & char 4 & char 5 & "P"
>>> & char 6 & "T" & char 7 & char 8 & "X"
>>> & char 9 & char 10);
>>> draw AB infont "cmmi10" shifted 10 up;
>>> draw AB infont "eurm10" shifted 10 down;
>>> draw bbox currentpicture;
>>> endfig;
>>> \end{mplibcode}
>>> \end{document}
>>> and run it through `lualatex` (This is LuaHBTeX, Version 1.13.0 (TeX
>>> Live 2021) then all I get are the first two characters in each
>>> string. In other words it stops at char 0 (Gamma).
>>> Oddly the bbox is still large enough for the whole string…
>>> any thoughts?
>> just avoid 0 chars (\nul) in a luatex related workflow ... data gets
>> passed through c string handling so it can indicate an end of string;
>> using "infont' is anyway worse that btex ... etex where you can use
>> \char 0
>>
>> Hans
>
> That’s not really the point. Sure there are plenty of work-arounds and
> clearly c string handling is the likely culprit, but the point is that
> the current support of “infont” is very good apart from this bug and it
> is still useful, and still widely used in existing code, and since `char
> 0` is a valid MP string, I think this should be fixed. Or at least
> documented as a limitation of `luamplib` compared to plain `mpost`.
char 0 in meytapost is also known as EOF and is therefore also in for
instance reading from and writing to file seen as terminator and going
via a lua path is kind of via file;
btw, internally the zero is there (as length)AB) shows, so in principle
we can pass the length but that doesn't guarantee that it will fail
upstream (i'll look into the mp part but won't touch the rest)
probably the best option is to specify that the lua interfacing doesn't
like zero's
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
More information about the metapost
mailing list.