[metapost] luamplib fails to process string with "char 0"

[Toby Thurston]

> On 29 Jul 2021, at 13:24, Hans Hagen <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`.

Toby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/metapost/attachments/20210729/0503dfb2/attachment.html>