view release on metacpan or  search on metacpan

lib/Image/Bitmap2Paths.pm  view on Meta::CPAN

=item C<minibitmap>

Likewise, but without blank borders (they will be added when the field 'bitmap' is calculated).

=back

The fields to get are

=over 12

=item C<strokes>

The most important output field.

Array with elements like C<[is_loop, is_blob, [@segments], [@runs], [@breaks]]>, with each C<segment> of the form
C<[dir, x0, y0, x1, y2]> (optionally followed by C<'tip'> if this segment comes from C<Tail/MFork> spur).  Here C<dir> is 
one of 8 compass direction in C<0..7> (with step 45°; see C<offs> below), or is C<-20> for "diagonal of a rhombus" strokes.  The
last two elements (C<runs> and C<breaks>) are optional (and do not appear for stroks of one segment???).  C<is_loop> is negative if
the loop is “smooth”: has no corners with angles sharper than 135° (if a loop has such “sharp corners”, the start and the end of the
loop are at such a corner).

The arrays C<runs> and C<breaks> are artefacts of the current (primitive) algorithm.  The meaning is subject to change.

They contain information about how a stroke is subdivided into “smooth” parts.  Currently, the parts are
either straight segments (currently of length ≥3), or convex runs of “edges”, or non-convex runs which cannot be converted to 
straight segments.  The array C<breaks> gives (???) indices of edges in a stroke which start a new “smooth” substroke (without
angles smaller than 135°).  (It always contains C<0>; even for smooth closed loops.)

=item width height

… Of the minibitmap.  In other words, 2 less than for bitmap.

=item C<Lb Rb>

Left and right bearings.  Offsets in the extended bitmap: last blank column at start; likewise, first at end.

=item C<stageOne>

Combines: C<offs cnt cntmin near nearmin doublerays>.

=item C<offs>

At C<[$y][$x]> contains the list of 8 possible directions (in 0..7, with step 45°) where it has a neighbor.  Directions are
consecutive, 0 decreases $y, 2 is to the right,  (This is clockwise from top if C<y> increases going down.)

=item C<cnt>=C<cntmin>

The length of the corresponding list.

=item C<near>=C<nearmin>

Like off, but an array of length 8 with 1 or 0 at each direction 0..7.

=item C<doublerays>

At C<[$y][$x]>, the count of directions in which a ray goes for length >=2.

=item C<stage10>

Combines: C<rays> C<longedges10> C<seenlong10> C<inLong10> C<midLong10> (done in two long iterations of DO_RAYS + a minor
massage)

=item C<rays>

For each C<[$y][$x][$dir]> which corresponds to a known neighbor, contains the (preliminary) result of the deep inspection of the
narrow sector going “about” the direction $dir.  The result is an array; its 0th element is the string describing “the type” of
this sector.  The rest may contain extra info specific to the type.  (Usually, the 1st element is “rotation”: the main “branch” of
how one should “correct” C<dir> when one goes one step “further inside the sector”.)

(Types are indicated on the 3x-magnified debugging output, near each vertex.)  Dictionary of ray candidates: Dense (>=7 neighbors
at dist 1 or 2); otherwise as below (dot denotes an empty place; d is a dependency: rays there “must be good”).  Below C<*> denotes
the vertex C<($x,$y)>; the lines indicate how a vertex in this position “is connected” to the C<*>.  The direction of the sector
startubg at C<*> is not ambiguous in these pictures:

                        . .        . /   |.              d .                  .               \                          .... ..
  doubleray: *-- curve: *-.  Fork: *d.  ./-  fake-curve: *-.  d/-    rhombus: *d.  tail: --*-  *- ish;  serif --*  notch:.-* ..*
            .|/          .\   |    . \  *.       \         \  *.       d * d  .|\        .|.  /   .|/           |        ./. ./|.
     fork4: *d.  Near-corner: *.         m-joint: ||       elses-ray: *|  /      3fork3: *d.      *d.      Sharp: *---   /.  ..|
            .|\              .d--                 *d                   d d               .|\   .  ..\     \..      \-       \
   Note that dependent is not a neighbor for diagonal elses-ray (and is not unique)            -          .d-     ...\       \
      fork4 and one flavor of fork3 are particular cases of fork!		Corner-curve: *.\ 3fork3: *|    bend-sharp: --*
    Later may put: ignore, Ignore, Tail, 2fork3, Enforced, Arrow/(x-)arrow,     Probable-curve:    *|    Joint???: d*-.
      1Spur, MFork; Rhombus-force, Zh/K-fake-curve is intended to be ½-of-segment                  .|-
      Btail, 4fork, xFork, °.     (Also allow longer shaft on Sharp)                                |.

In these docs, the only dependent type which is mentioned corresponds to opposite-direction pair C<tail>/C<doubleray>; it is
converted to C<Tail>/C<MFork> if C<tail> has C<cnt==3> (as on top of the glyph for “M”).  Likewise for a symmetrized case (as at
bottom of “V”): if it is C<fake-curve>/C<Fork> with C<cnt!=1> and the opposite is C<1Spur>/C<Probable-curve>, or unrecognized
(instead of C<doubleray>); here C<rot=0>.  Here C<Tail> is the spur direction going from the branch point, and C<MFork> is the
direction of the spur going into the branch point.

Essentially, the type C<MFork> indicates that a short spur on a very sharp fork (=the handle) is presumed to be the artifact due to
a very sharp angle on a broken line.  The joint of two (long) joining lines should be actually moved to the end of the spur.  (See
also C<tailEdge>.)

    Do we support such a sharp angle “sideways” to another line???  Can two such guys appear on opposite sides when we “punch a
    curve through” a joint???

  Removal of certain points during ray-detection (between two passes) not explained???

=item C<longedges10>

Lists candidates for edges of length √5 going “in between” our 8 compass directions.  This long edge should not be “made” of two
shorter edges since it is “intersected” by another (long) path.  The list element contain 2 coodinates of the start, 2 of the end,
offset in the list, “the approximate” C<$dir> and C<$rot> ≟ ±1. ???

(This corresponds to the ray type C<2fork3>.  There must be a neighbor in the direction $dir.  These are only candidates: we list
them since we do not know which of two ways “around a 45° rhomus” is preferable; in the following stages the answer may become more
clear, and then such candidates are going be removed from the corresponding updated lists.)

=item C<seenlong10>

Hash with the same elements indexed by C<{$x,$y,$x1,$y1}> I<and> by C<{$x1,$y1,$x,$y}>.

=item C<inLong10>

Hash indexed by C<{$X,$Y}>, true of this point is one of the ends of a longedge.

=item C<midLong10>