========== HOWTO Lines:	Generated by
				perl convex.pl draw >o1b.tex

Produces pictures for different line-approximated (or not) almost-lines.

By giving various draw* arguments one can filter out those approximable by 1 line, etc.  Filter out intersecting ones???

When one goes 1 step after the end of a known non-extendable line, then extends back maximally, then extends forward
maximally, then one get a complete list of non-extendable lines.   Then there seems to always be an intersection of consecutives.

  The key question is to find the radial offset of the “true” line w.r.t. the guessed straight segments.  They one would be able to
  use fontforge’s interpolator (spiro one, or otherwise)!

======================= TODO-Algo

In convex arcs, consider best-fit straight lines.  They form the “tightest” broken line, and make triangles adjacent to edges of
this line.  It seems that shortest edges correspond to “tight gate” for our curve to pass through (i.e., the curve passes at a very
oblique angle); and the “opposite” vertex of this adjacent triangle seems to be a the good position for the curve to ass through.
But how to find good positions for longer edges???

When the start/end best-fit straight lines passe through such a “gate” near its far-from-the-curve-ends end AND it is long enough,
one should also consider a shorter segment reaching not-up-to-the-gate.  (Otherwise underestimates the curvature near the ends???)

    Then one can assume that this short segment gives an approximation to the “end run ending at 0 curvature” ???  

    Does not seem to be beneficial for the arc of circle [[1], 1,2, [-1], -1,1,-1,2,-1,5,2,1,[-1],-1,2,-1,1] ???

       If not long enough, one could try to “interpolate” introducing a ”not exactly 0 curvature at end”???

======================= Defects

Basing the start/end xyIntercept at centers seems to ruin the algorithm.  Replace to where the line hits the midline of □???

5 2 gives wrong slope.
				(Cannot find such examples???

For the line between two convex bodies, if there is no x-overlap, try to find y-overlap as well ???

Only multiples of 4 in (flavors of) rot16.

Calculations with slopes, SL, SLint (these 3 used only in the slopes report) ignore $inv inside @$L.

After abs($ang) <= $PI/4: We assume that $ang and $Ang[$i] are somewhat related; but they are not!

Shift by $eps is not very meaningful for vertical stacks of tiles!

TEMPORARILY “correct”
  $othO->[$lst_idx+$last_eq][0]-0.5

Intersection code does not allow inversion yet.
				DONE — partially

@$L contains $S,$E: x-coordinates of the left and right ends of the run of square tiles.

@xIntercept starts/ends at a center of a square???

================================ Allowing rot16: in longest…pieces

was
    push @atS, [$hulls, $a, $b, $doneS, $cnt, $x, $X, $Y, $pre, $post];
new:
    push @atS, [$hulls, $a, $b, $inv, $doneS, $idx, $pre, $post, $ROT16];

================================

generate-img-tikz-a.pdf
	Contains examples of possible rasterizations of circles.  It seems that the purple tiles either form 2×2 or 2×3 rectangles,
	or removing them leaves a chess king path.

Need extra arguments to longest_line: ROT, and which of B/T is concave.  We return the last idx instead of a count, and do not
return dX,dY.  Debugging output is not corrected to match the snake format!

How to draw pre/post if they go around the 180°-dirs-bounded range???

Store lines as (a,b,inv), with x=ay+b if inv.  Functionality not implemente and the second call to intervals_intersect() is not
appropriately corrected .	16 cases?!!!  If inv’s are different, consider the composition ina a suitable order???

longest_linearizable_pieces() needs to take bounds as arguments.  Obsolete way to convert a vertical line to a slopped one — with
$y, $D placeholders.  (We do not even do the conversion on the backwards scan!)

        In which color should we draw point-pairs which are used with different $flip in differrent sub-arcs of the stroke?

To allow backwards search with absolute coordinates, allow a rudimental rotate-by-dir (via multiplication by $centSym???)
  my $prevDir16 = $snake->[max(0,$i-1)][2];	# Only if $step>0

  my $prevDir16 = $snake->[max(0,$i-1)][2];	# Only if $step>0 ??? XXXX
    my $dir32 = $dir16 +$prevDir16;
    $dir32 = ($dir32+16) % 32 if abs($dir16 - $prevDir16) > 16/2;	# move the smaller one by 16 up!
    $prevDir16 = $dir16;
    my() = dir32ToOffset $dir32;	# If incrementing $y, left midside is above, right is below the curve:

Warn on when the ratio of angles is too large and rejected???

A column should give a vertical line (unsupported!) such as in [1], 5, 1 (due to rotation of segments-to-intersect).

Apparently, the code to draw a line through a corridor is very sparsely tested.

Currently, the algorithm is quadratic, since on any step we walk through the tail of the other array (in our case, though!, short)

If we exchange HORIZ direction, it cannot find lines???

Any amount of curvature can create a 90 degrees angle between two diagonal directions. This corner may disappear after we find the
fitting lines.  In the opposite direction, given a join between a horizontal line and a diagonal line at angle 45 degrees, there is
a section of three tiles where the fitted lines intersect. Do we want to special case these when the lines are long enough, to
interpret it as a sharp angle, or do we smooth this intersection? 

Essentially, analizing a standalone junction, we need to:
  • Detect which part of the junction to remove to find the “proper” directions of the parts (“Just go up to midpoint=meetpoint”?)
  • Check whether their maximal fitting-in extensions actually meet.  If so, there is no need to smooth.
  • Add these “edge” parts to the list of straight pieces when we look for the centers of curvature.
  • Given (the medial of) curvature on the junction and the angle of rotation, estimate the length of the joining arc.
  • ???

=================== TODO for snakes

Special-case snakes with 5×3 tiles connectors as in

 xx      x
   x      xxx
    xx       x

and the long coming-in lines ending at the center tile.  In both cases, shorten the incoming lines by 1.  (Since not extendable, it
would be surrounded as

          •
  •xx      x
     x      xxx
      xx•      x
                •	Why on both sides???  If only on one side, it seems that it is better not to linearize this connected.)

=================== Bugs:

using intervals_intersect(): $prev and $next should go to the next point, not +-0.5.  $maxDx is silly!

We special-case >10000.

In snake_line(), we optimize the line near the bottleneck of the gap between two convex bodies.  Should not we pay more attention
to what happens near the ends???

============== (essentially — see ???) DONE below this line

What is the meaning of the dotted extensions (as on the 4th picture ( [7,9], 1, 1 ) )???
		DONE (they show how the conditions breaks)
			But this assumes that every "step" changes x by 1 ???

