Re: Problem with showing paths

It would also be nice if it were possible to suppress writing a newline with every call to "write", especially if it were possible to add newlines where desired using something equivalent to TeX's \newlinechar.

> Gesendet: Freitag, 21. Januar 2022 um 08:42 Uhr
> Von: "Laurence Finston" <[email protected]>
> An: [email protected]
> Betreff: Problem with showing paths
>
> For a particular application, I'm calling MP from within a program via a pipe and I want to read the output and use it for setting variables in my application.  The intention is to use "point x of <path>" to take a path of length n and convert it into an equivalent path of length n*m where m is some whole number > 1 (within reason).
>
> The problem is the way the lines in the output of "show" are broken:  The lines are fairly short (max. 80 characters, including the newline) and the x- and y-coordinates of the points can be broken across two lines, which makes parsing unnecessarily difficult.
>
> This is how I'm calling MP:
>
> mpost -interaction=nonstopmode -numbersystem "double" ftemp.mp
>
> This is the contents of ftemp.mp:
>
> tracingonline := 1;
> path q;
> q = (0cm, 0cm) ..  (1cm, -1cm) ..  (2cm, -2cm) ..  (1cm, -2cm) ..  (0cm, -2cm) ..  cycle;
>
> path r;
>
> n = (length q) / 10;
>
> r = point 0 of q;
>
> pair m;
>
> for i = n step n until length q:
>   m := point i of q;
>   r := r .. m;
> endfor;
>
> r := r .. cycle;
>
> show r;
>
> end
>
> This is the output of `show r':
>
> >> Path at line 22:
> (0,0)..controls (5.1033274754586504,-4.02658918875927) and (10.206654950917301,
> -8.0531783775185382)
>  ..(15.309982426375951,-12.079767566277809)..controls (20.836084424375677,-16.4
> 39931139579933) and (25.294686318678266,-22.003298723890239)
>  ..(28.346450000000001,-28.346450000000001)..controls (32.480291212340902,-36.9
> 3872086349576) and (41.608988021726468,-41.963264226932786)
>  ..(51.079824151240217,-40.859169680064937)..controls (60.177536433158913,-39.7
> 98573299547179) and (64.427271503927471,-51.786503064755529)
>  ..(56.692900000000002,-56.692900000000002)..controls (52.969536959567222,-59.0
> 54862701313922) and (48.735413750965591,-60.492376958047501)
>  ..(44.343636589685651,-60.885560755932076)..controls (38.685824079616481,-61.3
> 92089236029079) and (33.028509373892845,-59.909378434497384)
>  ..(28.346450000000001,-56.692900000000002)..controls (24.097340827760725,-53.7
> 73849444054306) and (18.504358165205602,-53.716232375214233)
>  ..(14.196014949203713,-56.547126869699198)..controls (9.9003101788908374,-59.3
> 69716987182123) and (4.3527609114952526,-59.426682524700915)
>  ..(0,-56.692900000000002)..controls (-12.410724714480779,-48.898255857308889)
> and (-22.071879582360939,-37.416127407829819)
>  ..(-27.62972345019935,-23.855414418073572)..controls (-34.633713352935132,-6.7
> 662159604187089) and (-15.885082241839086,9.4212918781208899)
>  ..(0,0)..controls (0,0) and (0,0)
>  ..cycle
>
> Is there anyway to fix this?  It would also be nice to limit the number of decimal places for the coordinates, by rounding or even by truncating.
>
> As a workaround, I've written a macro to write the data I need to a file (see attachment), but it would be nicer if "show" could be used instead.
>
> Thanks,
>
> Laurence
>

--
http://tug.org/metapost/