. "$BST_LIB"

# BST-TIMEOUT: 900   # measured elapsed=47s (76 cases) on the local build host,
#                    # 2026-09-23, against elapsed=22s (38 cases) before zbarimg.
#                    # So doubling the case count and adding 20 launches of a
#                    # 34 MB binary that calls InitializeMagick() before it reads
#                    # anything cost 25s, and 900 keeps ~19x headroom -- which
#                    # this suite wants because the scan entry point is held at
#                    # -O0 (see below). The per-fixture loop keeps its output so
#                    # the 13 zbar/img-sym-* cases read it back rather than
#                    # launching again; without that it would be 33 launches.
#                    # The ==BST-SUITE== line reports what it actually spent --
#                    # take the number off a run, not from here.

# zbar 0.23.1+git (meta-oe recipes-support/zbar, SRCREV 89e7900d) -- the ZBar
# bar-code reader: a scanner and decoder for EAN-13/UPC-A, UPC-E, EAN-8,
# Code 128/93/39, Codabar, Interleaved 2 of 5, QR and SQ Code.
#
# WHAT SHIPS, AND WHY IT IS STILL DRIVEN BY A PROBE AS WELL AS BY zbarimg.
# This port installs libzbar.a, zbar.h, zbar.pc -- and, since BRINTOS-1078,
# /usr/bin/zbarimg. It did not always: zbarimg reads every image through
# ImageMagick's MagickWand and has no other loader, so upstream builds it only
# `if HAVE_MAGICK', and BRINTOS-1043 shipped the library alone because
# ImageMagick was not on the image yet. The zbarimg half of this suite is at the
# foot of the file and the `zbar/img-*' cases are all of it.
#
# The probe did not become redundant when the program arrived, and the reason is
# the reason both halves are here: zbarimg reaches the decoders through
# MagickReadImage() and MagickGetImagePixels(), so a red from it cannot say
# whether the image loader or a decoder moved. The probe wraps the fixture as
# Y800 itself and calls zbar_scan_image() directly, which is the half that can.
# It is also the only thing that covers the library for a consumer that never
# touches ImageMagick -- which is what -dev and -staticdev exist for. Without a
# cross-linked consumer this suite could assert only that some files exist --
# which passes just as happily against an archive whose every decoder answers
# WRONGLY, and answering wrongly, not crashing, is exactly how a bar-code reader
# fails. /usr/libexec/zbar-tests/zbar-probe is
# recipes-support/zbar/zbar/zbar_probe.c linked in-recipe against the very
# libzbar.a that ships.
#
# THE ORACLE IS A NATIVE x86-64 BUILD OF THE IDENTICAL SRCREV, and unlike its
# neighbours in the 57- range this port had no reason to hesitate about that.
# 57-libvorbis.test and 57-speexdsp.test refuse a stored cross-machine digest
# and 57-libopus.test pins one observed on target, because all three decode
# through floating-point synthesis whose last ulp moves with the FPU. Bar-code
# decoding is not that: the scanner thresholds integer sample runs and the
# decoders are table lookups over run-length ratios, so there is no accumulation
# for an FMA or a libm difference to move. The QR and SQ readers do use floats
# for the perspective transform, which is why those two fixtures are in the
# byte-exact comparison rather than exempted from it -- if anything here is
# going to drift it is them, and the suite should be what says so.
#
# THE COMPARISON IS LAYERED, so a red says WHICH WAY it moved:
#
#   zbar/native-identical    the whole transcript byte for byte -- the bar the
#                            ticket asks for, and what this port achieves
#   zbar/native-structural   the decoded symbols alone (type and payload), with
#                            image geometry and the version line dropped. A red
#                            HERE is a real decode defect and cannot be blamed
#                            on a fixture regeneration
#   zbar/sym-<symbology>     one case per symbology, with the expected payload
#                            written out HERE rather than read from the
#                            reference, so a regenerated reference cannot move
#                            the meaning of the test in silence
#
# READING A RED. native-structural red => the decoder is wrong on this arm and
# nothing excuses it. native-identical red with structural green => the geometry
# or version line moved, which is a recipe or fixture change, not a decode
# defect. A single sym-* red with the rest green localises the failure to one
# decoder, which is the whole reason they are enumerated.
#
# FIVE CASES ARE EXPECTED RED, ON ONE CAUSE, AND THEY ARE ATTRIBUTED RATHER
# THAN SKIPPED. zbar/qr-binary-len and zbar/qr-binary-head fail on this arm
# because zbar_scan_image finds NO symbol in upstream's examples/qr-code-
# binary.png -- silently, nsym=0, no trap -- while x86-64 (at -O2 AND -O0,
# byte-identical transcripts) and i386 both decode its 298-byte payload. That is
# https://brintos.io/brintos/hwjs-cc/issues/75. zbar/native-identical and
# zbar/native-structural go red with them, since the missing line is part of the
# transcript they compare, and zbar/img-qr-binary-pgm goes red for the same
# reason on the zbarimg side -- the program finds nothing and exits 4 where the
# x86-64 oracle prints 298 bytes and exits 0. The plain QR fixture decodes
# correctly, so the QR locator and decoder work in general; the two fixtures
# differ in BOTH payload mode and symbol version, and which of those matters is
# not established.
#
# They are left FAILING on purpose. A skip would make the suite green and throw
# away the regression signal: these four flip green on their own the day #75
# lands, which is the whole reason the suite exists.
#
# SEPARATELY, img_scanner.c ALONE IS HELD AT -O0 by a source pragma the bbappend
# patches in (BRINTOS-WORKAROUND: hwjs-cc#74); the rest of the library builds at
# the distro's -O2. Optimised, _zbar_scan_image traps on every image and this
# entire suite is red below zbar/probe-rc. If that is what you are looking at,
# the workaround has been dropped rather than the port having regressed.
#
# THE FIXTURES ARE MOSTLY UPSTREAM'S OWN. examples/*.png, converted to binary
# PGM (P5 -- Y800 with a text header) on x86-64 by src/zbar_mkfixtures.py,
# because this port builds no PNG reader. Three are not upstream's, and each
# exists because the corpus could not otherwise cover something:
#
#   zbar-upc-e.pgm    upstream ships no UPC-E sample at all
#   zbar-ean-13p.pgm  upstream's ean-13.png carries a 978 prefix, so zbar's ISBN
#                     add-on claims it and reports ISBN-13 -- correct, and it
#                     leaves the EAN-13 type name asserted by nothing
#   zbar-blank.pgm    a uniform white field: the negative control. A corpus of
#                     readable barcodes cannot pin the not-found path, and
#                     not-found is a result this library has to get right
#
# and zbar-ean-13.jpg is the same EAN-13 raster as JPEG. It is driven down BOTH
# paths and they are different code: through the probe it reaches zbar/jpeg.c,
# the library's own JPEG->Y800 conversion behind zbar_image_convert(), which is
# what --with-jpeg actually buys; through zbarimg it reaches ImageMagick's JPEG
# coder instead, because MagickWand hands libzbar a raster that is already grey.
# BRINTOS-1043's ticket asked for --with-jpeg so that zbarimg could read
# samples, and that was never what it did.

R=${BST_ZBAR_ROOT:-}
tmp=${TMPDIR:-/tmp}
TESTDIR=${BST_ZBAR_TESTDIR:-$R/usr/libexec/zbar-tests}
LIBDIR=$R/usr/lib
INCDIR=$R/usr/include
PROBE=$TESTDIR/zbar-probe
NATIVE=$BST_DATA/zbar-native.txt

# --- what ships -------------------------------------------------------------

if [ -f "$LIBDIR/libzbar.a" ]; then
  bst_ok zbar/staticlib
else
  bst_notok zbar/staticlib "no $LIBDIR/libzbar.a"
fi

if [ -f "$INCDIR/zbar.h" ]; then
  bst_ok zbar/header
else
  bst_notok zbar/header "no $INCDIR/zbar.h"
fi

if [ -f "$LIBDIR/pkgconfig/zbar.pc" ]; then
  bst_ok zbar/pkgconfig
else
  bst_notok zbar/pkgconfig "no $LIBDIR/pkgconfig/zbar.pc"
fi

# Shape, not absence: this arm converts to shared libraries per recipe
# (BRINTOS-1740), so a .so here is a conversion, not a policy breach.
bst_lib_shape zbar/no-shared "$LIBDIR/libzbar.so*"

# THE PROGRAM THAT MUST SHIP AND THE ONE THAT MUST NOT. Both are assertions
# about PACKAGECONFIG rather than tidiness, and they moved in opposite
# directions under BRINTOS-1078.
#
# zbarimg is present only under HAVE_MAGICK, so its ABSENCE means `imagemagick'
# fell out of PACKAGECONFIG or configure stopped finding MagickWand -- the
# library would still build and every case above would stay green, which is
# exactly why this is asserted rather than assumed. This case read
# `zbar/no-zbarimg' until 1078 and was correct then: ImageMagick was not on the
# image, so the program could not be built. Inverted, not deleted, so the
# regression signal survives the change of direction.
#
# zbarcam is gated on HAVE_VIDEO. If it appears, the `video' weak default has
# won again and this image has grown a v4l dependency for a camera a browser
# guest does not have.
if [ -x "$R/usr/bin/zbarimg" ]; then
  bst_ok zbar/zbarimg
else
  bst_notok zbar/zbarimg "no executable $R/usr/bin/zbarimg -- PACKAGECONFIG lost 'imagemagick', or configure stopped finding MagickWand"
fi

if [ ! -e "$R/usr/bin/zbarcam" ]; then
  bst_ok zbar/no-zbarcam
else
  bst_notok zbar/no-zbarcam "zbarcam shipped -- the 'video' PACKAGECONFIG default won again"
fi

if [ -f "$NATIVE" ]; then
  bst_ok zbar/native-ref-present
else
  bst_notok zbar/native-ref-present "no $NATIVE -- every comparison below would be vacuous"
fi

# --- stage the probe --------------------------------------------------------
# do_install ships it 0755, but the rootfs is read-only at browser runtime and
# the /tmp tmpfs is mounted without noexec, so it is copied and re-marked there.

probe=$tmp/bst-zbar-probe.$$
if [ -f "$PROBE" ] && cp "$PROBE" "$probe" 2>/dev/null && chmod +x "$probe" 2>/dev/null; then
  bst_ok zbar/probe-stage
else
  bst_notok zbar/probe-stage "cannot stage $PROBE"
  rm -f "$probe"
  return 0 2>/dev/null || exit 0
fi

out=$tmp/bst-zbar-out.$$
err=$tmp/bst-zbar-err.$$
"$probe" "$BST_DATA" > "$out" 2>"$err"; prc=$?

# The probe's last `probe-begin' breadcrumb names the fixture it was scanning
# when it stopped, which is the one thing a reader of a red run needs and the
# one thing a lost stdout buffer cannot supply.
if [ "$prc" -eq 0 ]; then
  bst_ok zbar/probe-rc
else
  bst_notok zbar/probe-rc "probe exited $prc, last: $(_bst_1line "$(tail -n 1 "$err" 2>/dev/null)")"
fi
rm -f "$err"

# A transcript that stopped early would otherwise let every extraction below
# compare an empty string to an empty string and report green.
if [ -s "$out" ] && grep -q '^ZBAR-PROBE-END$' "$out"; then
  bst_ok zbar/probe-complete
else
  bst_notok zbar/probe-complete "transcript has no ZBAR-PROBE-END: $(_bst_1line "$(tail -n 2 "$out" 2>/dev/null)")"
fi

# --- the fixtures and the walk arithmetic, without entering the scanner ------
# These are what separate "the port is miscompiled" from "the payload never
# arrived". --dump reads a fixture, walks the raster linearly, and then re-runs
# img_scanner.c's OWN movedelta walk -- row and column, character for character
# -- in the probe's translation unit. Three sums that agree with each other and
# with x86-64 say the fixture shipped intact and the walk arithmetic is right on
# this arm, which is exactly the control hwjs-cc#74 rests on. They stay green
# while the scan is broken, and that is the point: without them a reader of a
# red run cannot tell a codegen fault from a missing data file.
d=$("$probe" --dump "$BST_DATA/zbar-ean-13.pgm" 2>/dev/null); drc=$?
check_eq zbar/dump-rc 0 "$drc"
check_eq zbar/dump-geom  "dump geom w=226 h=100 len=22600" \
         "$(printf '%s\n' "$d" | grep '^dump geom ')"
check_eq zbar/walk-linear "dump linear-sum=3630867"  "$(printf '%s\n' "$d" | grep '^dump linear-sum=')"
check_eq zbar/walk-row    "dump rowwalk-sum=3630867" "$(printf '%s\n' "$d" | grep '^dump rowwalk-sum=')"
check_eq zbar/walk-col    "dump colwalk-sum=3630867" "$(printf '%s\n' "$d" | grep '^dump colwalk-sum=')"

# --- the whole transcript, byte for byte ------------------------------------

if cmp -s "$out" "$NATIVE"; then
  bst_ok zbar/native-identical
else
  d=$(diff "$out" "$NATIVE" 2>/dev/null | grep -c '^<')
  bst_notok zbar/native-identical "$d transcript lines differ from the x86-64 control"
fi

# The decoded symbols alone: geometry and the version line dropped, so this
# survives a fixture regenerated at a different size and fails only on a decode
# that actually changed.
grep '^sym ' "$out"    > "$tmp/bst-zbar-s1.$$" 2>/dev/null
grep '^sym ' "$NATIVE" > "$tmp/bst-zbar-s2.$$" 2>/dev/null
if [ -s "$tmp/bst-zbar-s1.$$" ] && cmp -s "$tmp/bst-zbar-s1.$$" "$tmp/bst-zbar-s2.$$"; then
  bst_ok zbar/native-structural
else
  bst_notok zbar/native-structural "$(_bst_1line "$(diff "$tmp/bst-zbar-s1.$$" "$tmp/bst-zbar-s2.$$" 2>/dev/null | head -n 4)")"
fi
rm -f "$tmp/bst-zbar-s1.$$" "$tmp/bst-zbar-s2.$$"

# --- one case per symbology -------------------------------------------------
# The expected values are written out here rather than read from the reference,
# so regenerating the reference cannot silently change what this suite means.
# _zbar_sym prints "<type> <data>" for a fixture's first symbol.

_zbar_sym() {
  awk -v f="$1" '$1=="sym" && $2==f && $3=="0" {
      t=""; d="";
      for (i = 4; i <= NF; i++) {
        if (substr($i,1,5) == "type=") t = substr($i,6);
        if (substr($i,1,5) == "data=") { d = substr($0, index($0,"data=") + 5); break }
      }
      print t " " d; exit
  }' "$out"
}

check_eq zbar/sym-isbn-13  "ISBN-13 9789876543217"                 "$(_zbar_sym zbar-ean-13.pgm)"
check_eq zbar/sym-ean-13   "EAN-13 1234567890128"                  "$(_zbar_sym zbar-ean-13p.pgm)"
check_eq zbar/sym-ean-8    "EAN-8 98765430"                        "$(_zbar_sym zbar-ean-8.pgm)"
check_eq zbar/sym-upc-a    "UPC-A 987654321012"                    "$(_zbar_sym zbar-upc-a.pgm)"
check_eq zbar/sym-upc-e    "UPC-E 01234565"                        "$(_zbar_sym zbar-upc-e.pgm)"
check_eq zbar/sym-code-128 "CODE-128 https://github.com/mchehab/zbar" "$(_zbar_sym zbar-code-128.pgm)"
check_eq zbar/sym-code-93  "CODE-93 ZBAR-9876543210"               "$(_zbar_sym zbar-code-93.pgm)"
check_eq zbar/sym-code-39  "CODE-39 ZBAR-9876543210"               "$(_zbar_sym zbar-code-39.pgm)"
check_eq zbar/sym-codabar  "Codabar A9876543210B"                  "$(_zbar_sym zbar-codabar.pgm)"
check_eq zbar/sym-i2-5     "I2/5 9876543210"                       "$(_zbar_sym zbar-i2-5.pgm)"
check_eq zbar/sym-qrcode   "QR-Code https://github.com/mchehab/zbar" "$(_zbar_sym zbar-qr-code.pgm)"
check_eq zbar/sym-databar  "DataBar 0198765432109879"              "$(_zbar_sym zbar-databar.pgm)"

# THE JPEG ARM. Same raster as zbar-ean-13.pgm, so an identical payload here is
# the statement that zbar/jpeg.c reproduced the image the decoder needs -- which
# is the whole of what --with-jpeg buys this port.
check_eq zbar/sym-jpeg     "ISBN-13 9789876543217"                 "$(_zbar_sym zbar-ean-13.jpg)"

# The two 2-D payloads are long (298 escaped bytes and 6144) and are covered in
# full by native-identical above; here they are pinned by length and head, which
# is enough to localise a red to the symbology without a 6 kB literal.
_zbar_len() { awk -v f="$1" '$1=="sym" && $2==f {for(i=4;i<=NF;i++) if(substr($i,1,4)=="len=") {print substr($i,5); exit}}' "$out"; }

check_eq zbar/qr-binary-len  298  "$(_zbar_len zbar-qr-binary.pgm)"
check_eq zbar/sqcode-len     6144 "$(_zbar_len zbar-sqcode.pgm)"
check_eq zbar/qr-binary-head "QR-Code \\xc2\\x89PNG" "$(_zbar_sym zbar-qr-binary.pgm | cut -c1-19)"

# --- the not-found path -----------------------------------------------------
# A corpus of readable barcodes says nothing about the result this library has
# to get right when there is no symbol. --scan-one mirrors zbarimg's own status
# convention (zbarimg.c: num_images && notfound -> exit 4).

nsym=$(awk '$1=="scan" && $2=="zbar-blank.pgm" {for(i=3;i<=NF;i++) if(substr($i,1,5)=="nsym=") {print substr($i,6); exit}}' "$out")
check_eq zbar/blank-nsym 0 "$nsym"

"$probe" --scan-one "$BST_DATA/zbar-ean-13.pgm" >/dev/null 2>&1
check_eq zbar/rc-found 0 "$?"

"$probe" --scan-one "$BST_DATA/zbar-blank.pgm" >/dev/null 2>&1
check_eq zbar/rc-notfound 4 "$?"

# An unreadable fixture must be distinguishable from a clean not-found, or a
# missing payload would read as "there was no barcode in it".
"$probe" --scan-one "$BST_DATA/zbar-no-such-fixture.pgm" >/dev/null 2>&1
check_eq zbar/rc-unreadable 2 "$?"

# --- version ----------------------------------------------------------------

check_eq zbar/version "version 0.23.1" "$(grep '^version ' "$out" | head -n 1)"

rm -f "$probe" "$out" "$err"

# --- zbarimg: the same decoders, reached through ImageMagick ----------------
# Everything above drives libzbar directly -- the probe wraps a fixture as Y800
# itself and calls zbar_scan_image(). zbarimg is the other half of this port and
# it gets to the same decoders through a front end none of the above touches:
# MagickReadImage() parses the file, MagickGetImagePixels(..., "I", CharPixel)
# reduces it to intensity, and only that raster is handed to
# zbar_process_image(). So a red here with the probe green localises to
# ImageMagick and not to a decoder, and that split is the whole reason both run.
# It is also why zbar-ean-13.jpg appears in both corpora: through the probe it
# exercises zbar/jpeg.c, through zbarimg it exercises ImageMagick's JPEG coder,
# and the two are different code with the same expected answer.
#
# THE TRANSCRIPT CARRIES A DIGEST RATHER THAN THE PAYLOAD. `--raw' prints the
# symbol data and nothing else, and two of the sixteen payloads are not text --
# zbar-qr-binary.pgm decodes to 298 bytes of PNG and zbar-sqcode.pgm to 6144 of
# a PKCS#7 blob. A reference file holding those verbatim would be unreadable and
# its diffs useless, so each fixture contributes one line of rc, byte count and
# sha256, which is byte-exactness by another route. The payloads a human needs
# to read are asserted as LITERALS below instead -- the same reason the probe's
# zbar/sym-* cases are written out here rather than read from the reference.
#
# data/zbar-zbarimg-native.txt is produced by src/zbar_zbarimg_mkref.sh from
# zbar-NATIVE linked against imagemagick-NATIVE: same recipes, same SRCREVs,
# same bbappends, same patches as the target build -- the shape
# src/imagemagick_mkfixtures.sh already uses for its own oracle.
#
# GRADED PER FIXTURE, unlike the probe's whole-transcript compare, and
# deliberately: hwjs-cc#75 costs exactly one fixture and there is no reason for
# it to drag the other fifteen red with it. zbar/img-corpus is what notices a
# fixture that fell out of one list and not the other, which is the failure a
# per-fixture grading would otherwise hide.
#
# EXPECTED RED: zbar/img-qr-binary-pgm and zbar/img-sym-qr-binary, for the same
# hwjs-cc#75 as zbar/qr-binary-len above -- zbar finds no symbol in that fixture
# on this arm, so zbarimg prints nothing and exits 4 where x86-64 prints 298
# bytes and exits 0. They flip green on their own the day #75 lands.

ZBARIMG=$R/usr/bin/zbarimg
ZREF=$BST_DATA/zbar-zbarimg-native.txt

# The order is data/zbar-native.txt's, so the two transcripts read side by side,
# and it is duplicated in src/zbar_zbarimg_mkref.sh rather than derived, so the
# two cannot drift silently -- zbar/img-corpus is the guard on that.
ZFIX="zbar-ean-13.pgm zbar-ean-13p.pgm zbar-ean-8.pgm zbar-upc-a.pgm \
zbar-upc-e.pgm zbar-code-128.pgm zbar-code-93.pgm zbar-code-39.pgm \
zbar-codabar.pgm zbar-i2-5.pgm zbar-qr-code.pgm zbar-qr-binary.pgm \
zbar-databar.pgm zbar-sqcode.pgm zbar-blank.pgm zbar-ean-13.jpg"

if [ -f "$ZREF" ]; then
  bst_ok zbar/img-ref-present
else
  bst_notok zbar/img-ref-present "no $ZREF -- every zbarimg comparison below would be vacuous"
fi

if [ ! -x "$ZBARIMG" ]; then
  # Without the program there is nothing below to run, and thirty-odd
  # case-by-case reds would say "zbarimg is wrong" about one missing file. One
  # named red, so the cases that did not run are visible as an absence with a
  # cause rather than as a shorter total nobody reads.
  bst_notok zbar/img-run "no $ZBARIMG -- the zbarimg cases below did not run; see zbar/zbarimg"
  return 0 2>/dev/null || exit 0
fi

# The reference's version and the target's, in that order. If the two arms are
# not the same zbar then every comparison below is measuring something else,
# and this is the cheapest place to notice it.
check_eq zbar/img-version "0.23.1 0.23.1" \
  "$(sed -n 's/^version //p' "$ZREF" 2>/dev/null | head -n 1) $("$ZBARIMG" --version 2>/dev/null)"

check_eq zbar/img-corpus "16 16" \
  "$(printf '%s\n' $ZFIX | wc -l | tr -d ' ') $(grep -c '^zbarimg ' "$ZREF" 2>/dev/null)"

zimgdir=$tmp/bst-zbarimg.$$
mkdir -p "$zimgdir" 2>/dev/null

# ONE LAUNCH PER FIXTURE AND NO MORE. rc is per-image, so the aggregate a single
# multi-argument run reports could not distinguish "one fixture found nothing"
# from "none of them did" -- but each launch also pays for a binary carrying a
# statically linked libMagickCore and an InitializeMagick() before it reads
# anything, so the output is KEPT and the per-symbology cases below read it back
# instead of running the program a second time. -q drops the "scanned N barcode
# symbols" summary, which carries a CPU time and would never reproduce.
for f in $ZFIX; do
  "$ZBARIMG" -q --raw "$BST_DATA/$f" > "$zimgdir/$f" 2>/dev/null; zrc=$?
  line="zbarimg $f rc=$zrc len=$(wc -c < "$zimgdir/$f" | tr -d ' ') sha256=$(sha256sum < "$zimgdir/$f" | cut -d' ' -f1)"
  check_eq "zbar/img-$(printf '%s' "${f#zbar-}" | tr . -)" \
           "$(grep "^zbarimg $f " "$ZREF" 2>/dev/null)" "$line"
done

# One case per symbology again, expected values written out HERE rather than
# read from the reference -- same reason as the probe's zbar/sym-* block.
#
# THREE OF THESE DO NOT MATCH THE PROBE'S ANSWER, AND THAT IS CORRECT. The two
# front ends ask the decoder different questions:
#
#   fixture            probe               zbarimg
#   zbar-ean-13.pgm    ISBN-13 978...217   9789876543217   (EAN-13)
#   zbar-upc-a.pgm     UPC-A   987...012   0987654321012   (EAN-13)
#   zbar-upc-e.pgm     UPC-E   01234565    0012345000065   (EAN-13, expanded)
#
# UPC-A, UPC-E, ISBN-10 and ISBN-13 are narrowings of EAN-13 that zbar reports
# only when each is INDIVIDUALLY enabled -- decoder/ean.c, ean_decode():
#
#     if(!ean->buf[0] && TEST_CFG(ean->upca_config, ZBAR_CFG_ENABLE))
#         part = ZBAR_UPCA;
#     else if(... TEST_CFG(ean->isbn13_config, ZBAR_CFG_ENABLE))
#         part = ZBAR_ISBN13;
#
# zbar_probe.c turns all of them on in one call (`set_config(s, 0,
# ZBAR_CFG_ENABLE, 1)' -- symbol 0 is every symbology), and zbarimg leaves the
# processor at the library's defaults, where they are off and the EAN-13
# superset is what comes out. The payloads are the same barcode either way: a
# UPC-A is an EAN-13 with a leading zero, and a UPC-E is the compressed form of
# one. Neither answer is wrong and neither tool is misconfigured.
#
# The zbar/img-set-* cases below are what turn that from an assertion into a
# measurement: driven with the probe's question, the SAME zbarimg binary gives
# the probe's answer. That is what separates "a configuration default" from "the
# front ends decode differently", which is the reading a reviewer would
# otherwise have to take on trust.
_zbar_img() { cat "$zimgdir/$1" 2>/dev/null; }

check_eq zbar/img-sym-ean-13   "9789876543217"                 "$(_zbar_img zbar-ean-13.pgm)"
check_eq zbar/img-sym-ean-13p  "1234567890128"                 "$(_zbar_img zbar-ean-13p.pgm)"
check_eq zbar/img-sym-ean-8    "98765430"                      "$(_zbar_img zbar-ean-8.pgm)"
check_eq zbar/img-sym-upc-a    "0987654321012"                 "$(_zbar_img zbar-upc-a.pgm)"
check_eq zbar/img-sym-upc-e    "0012345000065"                 "$(_zbar_img zbar-upc-e.pgm)"
check_eq zbar/img-sym-code-128 "https://github.com/mchehab/zbar" "$(_zbar_img zbar-code-128.pgm)"
check_eq zbar/img-sym-code-93  "ZBAR-9876543210"               "$(_zbar_img zbar-code-93.pgm)"
check_eq zbar/img-sym-code-39  "ZBAR-9876543210"               "$(_zbar_img zbar-code-39.pgm)"
check_eq zbar/img-sym-codabar  "A9876543210B"                  "$(_zbar_img zbar-codabar.pgm)"
check_eq zbar/img-sym-i2-5     "9876543210"                    "$(_zbar_img zbar-i2-5.pgm)"
check_eq zbar/img-sym-qrcode   "https://github.com/mchehab/zbar" "$(_zbar_img zbar-qr-code.pgm)"
check_eq zbar/img-sym-databar  "0198765432109879"              "$(_zbar_img zbar-databar.pgm)"

# THE JPEG ARM, through ImageMagick this time rather than zbar/jpeg.c. Same
# raster and therefore the same payload as zbar-ean-13.pgm above -- and the
# oracle records the same sha256 for both, which is the sharper statement. A red
# here with img-sym-ean-13 green is ImageMagick's JPEG coder and nothing else.
check_eq zbar/img-sym-jpeg     "9789876543217"                 "$(_zbar_img zbar-ean-13.jpg)"

# --set is zbarimg's own option parsing as well as the control above, so a red
# here is either the narrowing or the option handling, and the type prefix (no
# --raw) is what says which: a wrong TYPE is the narrowing, a wrong PAYLOAD is
# the decoder, and no output at all is --set not having been understood.
check_eq zbar/img-set-upca   "UPC-A:987654321012" \
  "$("$ZBARIMG" -q --set upca.enable=1 "$BST_DATA/zbar-upc-a.pgm" 2>/dev/null)"
check_eq zbar/img-set-upce   "UPC-E:01234565" \
  "$("$ZBARIMG" -q --set upce.enable=1 "$BST_DATA/zbar-upc-e.pgm" 2>/dev/null)"
check_eq zbar/img-set-isbn13 "ISBN-13:9789876543217" \
  "$("$ZBARIMG" -q --set isbn13.enable=1 "$BST_DATA/zbar-ean-13.pgm" 2>/dev/null)"

# The two 2-D payloads get no literal here. Their lengths are already pinned
# from libzbar's side by zbar/qr-binary-len and zbar/sqcode-len above, and what
# zbarimg adds over the probe is the MagickWand front end, which the per-fixture
# digest covers byte for byte. A second length literal would buy nothing and
# would cost hwjs-cc#75 a second red on one cause.

# --- zbarimg exit statuses --------------------------------------------------
# zbarimg.c: exit_code is 0 when a symbol was found, 4 when `num_images &&
# notfound && !exit_code', and dump_error() sets 1 for an ImageMagick
# ErrorException -- which is what an unopenable file raises. A file that cannot
# be read must be distinguishable from one that simply holds no barcode, or a
# missing fixture would read as "there was no barcode in it" and every case
# above it would still be green.

# These three are launches of their own rather than fields read off the
# transcript, because the transcript's own rc values are compared against the
# reference -- so a reference regenerated against a zbarimg whose statuses had
# changed would carry the change and agree with itself. Written out here, the
# convention is pinned by this file.
"$ZBARIMG" -q --raw "$BST_DATA/zbar-ean-13.pgm" >/dev/null 2>&1
check_eq zbar/img-rc-found 0 "$?"

"$ZBARIMG" -q --raw "$BST_DATA/zbar-blank.pgm" >/dev/null 2>&1
check_eq zbar/img-rc-notfound 4 "$?"

"$ZBARIMG" -q --raw "$BST_DATA/zbar-no-such-fixture.pgm" >/dev/null 2>&1
check_eq zbar/img-rc-unreadable 1 "$?"

rm -rf "$zimgdir"