R CMD check WARNs on non-ASCII in R/fly_mask.R — clear it before #52 adds the workflow

[NewGraphEnvironment]

What changes if we do it

R CMD check goes to 0 errors, 0 warnings, 0 notes, so #52 can land an R-CMD-check
workflow that is green on day one.

What happens if we never do

#52 lands and the new workflow is red on its first run, for a reason unrelated to whatever
PR triggers it. The likely outcome is that the workflow gets error_on: "error" to quieten it,
which is exactly the setting that would let a real WARNING through later.

The finding

Measured 2026-09-20 while releasing v0.13.0. devtools::check() on a clean tree:

0 errors ✔ | 1 warning ✖ | 0 notes ✔

❯ checking code files for non-ASCII characters ... WARNING
  Found the following file with non-ASCII characters:
    R/fly_mask.R

It is pre-existing — present on origin/main before #59 — and fly_mask.R is the only
file affected. The characters are em-dashes in the roxygen block:

#' Scanned airphotos carry a black collar <e2><80><94> film holder edges, fiducial marks ...

R CMD check tolerates non-ASCII in comments "except perhaps in comments", but is reporting
it here anyway, so the escape is required.

Why it has not bitten

The repo runs pkgdown only (.github/workflows/pkgdown.yaml is the sole workflow), so
nothing currently executes R CMD check. That is #52.

Fix

tools::showNonASCIIfile("R/fly_mask.R") lists the lines; replace each em-dash with —
or a plain ASCII dash. Worth doing before #52 rather than inside it, so the workflow's
first run is a clean signal about the workflow rather than about this.

Blocks #52.

[NewGraphEnvironment]

Done in #67 (merged as 3d403c1, released as v0.14.1), which is the #52 workflow this issue was filed to clear the way for. Closing by hand rather than by trailer because the commits landed without one — #67 was written without knowing this issue existed, which is my miss, not a disagreement about scope.

The outcome is what this issue asked for, and it went one better than the plan: rather than clearing the WARNING first and landing a workflow that is green on arrival, #67 landed the workflow first so the gate could be seen rejecting something. Run 35680424973 is red on exactly this WARNING across all three platforms; 35681274310 is green after the one-character fix. The gate is at the r-lib default error-on: "warning" — the outcome this issue argued for, with the error_on: "error" escape it warned about explicitly declined.

One correction, because the diagnosis here is wrong and the reason is worth keeping

This issue says:

The characters are em-dashes in the roxygen block … R CMD check tolerates non-ASCII in comments "except perhaps in comments", but is reporting it here anyway, so the escape is required.

It does not report comments, and it was not reporting the roxygen. What the check runs is tools:::.check_package_ASCII_code(dir, FALSE), which is line-based over the raw file and skips comments. Of the 30 non-ASCII lines in R/fly_mask.R, 29 are comments and are correctly ignored. The one offender was a string literal — a raw em dash inside the runaway-guard warning() at line 293. That is why the escape was required, and it is why R/fly_footprint.R (97 non-ASCII lines) and R/fly_georef.R (52) are clean: their em dashes are either in comments or already written —.

Worth keeping because the probe that gets this wrong is the obvious one. Parsing each file and running deparse() over the parse tree looks like the rigorous approach and is not: deparse() renders — back as a literal em dash, so it reports the existing fix as the defect. That probe named three files where the check names one. Use tools:::.check_package_ASCII_code(dir, FALSE), which agrees with the check by construction.