@feedmepos/mf-menu 0.32.71 → 0.32.72-dev.1

package/dist/{app-CMjz-bvL.js → app-D6CmNX90.js}

@@ -1,5 +1,5 @@
 import { defineStore as r } from "pinia";
-import { J as a, K as s, L as l } from "./index.vue_vue_type_script_setup_true_lang-BCZZq6zJ.js";
+import { K as a, L as s, M as l } from "./index.vue_vue_type_script_setup_true_lang-DILo07iQ.js";
 const u = {
   async read() {
     return a(await s().get("/public-setting"));

package/dist/app.js

@@ -1,4 +1,4 @@
-import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-2VeaJE9t.js";
+import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-D1p44Rbf.js";
 export {
   e as FmApp,
   r as i18nMessages,

package/dist/apps/mf-menu/src/app.d.ts

@@ -1601,6 +1601,10 @@ export declare const i18nMessages: {
             };
             productInternalTools: {
                 title: string;
+                unreadable_images: {
+                    title: string;
+                    message: string;
+                };
             };
             publish: {
                 title: string;
@@ -3661,6 +3665,10 @@ export declare const i18nMessages: {
             };
             productInternalTools: {
                 title: string;
+                unreadable_images: {
+                    title: string;
+                    message: string;
+                };
             };
             publish: {
                 title: string;
@@ -5719,6 +5727,10 @@ export declare const i18nMessages: {
             };
             productInternalTools: {
                 title: string;
+                unreadable_images: {
+                    title: string;
+                    message: string;
+                };
             };
             publish: {
                 title: string;
@@ -7778,6 +7790,10 @@ export declare const i18nMessages: {
             };
             productInternalTools: {
                 title: string;
+                unreadable_images: {
+                    title: string;
+                    message: string;
+                };
             };
             publish: {
                 title: string;
@@ -9825,6 +9841,10 @@ export declare const i18nMessages: {
             };
             productInternalTools: {
                 title: string;
+                unreadable_images: {
+                    title: string;
+                    message: string;
+                };
             };
             publish: {
                 title: string;

package/dist/apps/mf-menu/src/components/feature/TreeEditor/composable/productImages.d.ts

@@ -63,6 +63,22 @@ export declare function validateImageType(file: File): string | null;
  * the images already in the wild.
  */
 export declare const MAX_IMAGE_EDGE = 2000;
+/**
+ * What an upload is aimed at, as opposed to what the service will still accept.
+ *
+ * Exported because it is a contract, not a tuning knob: POS cannot render a large image —
+ * it crashes — so "did these bytes go through compression" is a question callers have to be
+ * able to ask (`meetsUploadBudget`), not just something this module does on the way past.
+ *
+ * `MAX_IMAGE_BYTES` is a 413 boundary, not a target, and using it as one is what merchants
+ * saw as "compression that does nothing": a heavy original re-encoded at `OUTPUT_QUALITY`
+ * landed at 8 MB, sat under the limit, and no further round ran. A 2000px JPEG of a real
+ * photo is a few hundred KB, so this sits just above where photography lands and below
+ * anything that would be heavy on a POS tile or a QR menu card. Enforced by the loop in
+ * `canvasToFile`, which spends quality to get here — a full-frame 2000x2000 photo does
+ * cross it and comes back one quality step down, which is the intended trade.
+ */
+export declare const TARGET_UPLOAD_BYTES: number;
 /**
  * Encodes an edited canvas as a file guaranteed to be uploadable.
  *
@@ -72,8 +88,10 @@ export declare const MAX_IMAGE_EDGE = 2000;
  * the dead end this feature exists to remove. Quality is spent first and pixels second,
  * because a slightly softer photo beats a smaller one.
  *
- * PNG is kept only when the caller asks for it (a source with transparency); it has no
- * quality lever, so it is shrunk by size alone.
+ * Callers ask for JPEG (see `compressImageForUpload`); `mime` still honours a deliberate
+ * PNG, which has no quality lever and is shrunk by size alone. Lossy output is flattened
+ * onto white first, in place — every canvas reaching here is minted for this encode (a
+ * cropper result or `fileToCanvas` output), never one a caller keeps using.
  */
 export declare function canvasToFile(canvas: HTMLCanvasElement, options: {
     fileName: string;
@@ -82,20 +100,51 @@ export declare function canvasToFile(canvas: HTMLCanvasElement, options: {
     maxBytes?: number;
 }): Promise<File>;
 /**
- * Re-encodes a picked file to `MAX_IMAGE_EDGE` / `OUTPUT_QUALITY` before it is uploaded.
- *
- * Unconditional by design. The single-thumbnail flow this feature replaced compressed
- * every image on the way out (4:3, 2000px, JPEG q0.75); the multi-image rewrite dropped
- * that for a plain size check, which let a full-resolution phone photo reach
- * media-service verbatim as long as it happened to sit under `MAX_IMAGE_BYTES`. So the
- * trigger is the edge cap now, not the byte limit — an 8 MB 12MP original is compressed
- * exactly like a 12 MB one.
- *
- * The one file handed back untouched is the one re-encoding would only make worse: canvas
- * has no quality lever for PNG and re-encodes an already-optimised one bigger, and a JPEG
- * already saved below `OUTPUT_QUALITY` grows too. When the source is inside the edge cap, already
- * uploadable, in the very format the encoder would have written, and smaller than what
- * came back, the original wins — "compressed" has to mean smaller.
+ * Whether a file already satisfies everything an upload guarantees, so re-encoding it would
+ * only cost a generation of JPEG loss.
+ *
+ * Deliberately strict on all three axes, because the consumer is unforgiving: POS crashes on
+ * a large image, so anything that cannot be proven compressed has to be compressed. JPEG is
+ * required rather than preferred — a PNG in budget today is still a format whose weight does
+ * not track its pixel count, and it is the format that produced the 8 MB "compressed" upload
+ * in the first place.
+ *
+ * `dimensions` is optional only because a caller that has not decoded the image yet cannot
+ * supply it; omitting it makes this answer the question for bytes and format alone, so a
+ * caller that can decode should pass it.
+ */
+export declare function meetsUploadBudget(file: File, dimensions?: {
+    width: number;
+    height: number;
+} | null): boolean;
+/**
+ * Re-encodes a picked file as a `MAX_IMAGE_EDGE` / `OUTPUT_QUALITY` JPEG before upload.
+ *
+ * Unconditional, and unconditionally JPEG — both learned the hard way. The multi-image
+ * rewrite replaced the single-thumbnail flow's always-compress (4:3, 2000px, JPEG q0.75)
+ * with a plain size check, so a full-resolution phone photo reached media-service verbatim
+ * whenever it sat under `MAX_IMAGE_BYTES`; putting the edge cap back still kept a PNG
+ * source as PNG, and canvas PNG is lossless, so a 10 MB photo saved as PNG came back ~8 MB
+ * and counted as compressed. Product photos gain nothing from an alpha channel, so
+ * transparency is flattened onto white and everything leaves as JPEG. (The backfill script
+ * still keeps a genuinely transparent PNG as PNG: it rewrites production originals
+ * irreversibly, so changing what an already-approved image shows is a line it does not
+ * cross. A new upload is previewed in the editor before the merchant confirms it.)
+ *
+ * The only file handed back untouched is a JPEG that is already leaner than the encode —
+ * one saved below `OUTPUT_QUALITY` grows if re-encoded, and skipping that spares it a
+ * second generation of loss for nothing. Restricted to JPEG sources on purpose, rather
+ * than "whatever is smaller": product images have no use for an alpha channel, so no
+ * upload path may leave a PNG or WebP in storage, and a JPEG source cannot carry
+ * transparency in the first place. The trade is known and accepted — a lean PNG of flat
+ * colour (a logo, a screenshot of a menu) re-encodes bigger, because JPEG spends bits on
+ * exactly the hard edges PNG stores for free. Every stored original being one format is
+ * worth that.
+ *
+ * Note what the passthrough cannot wave through: the encode it is compared against is
+ * bounded by `TARGET_UPLOAD_BYTES`, so a heavy original has nothing lean to tie with. The
+ * comparison used to be against a same-format encode, which is how a 10 MB PNG kept its
+ * own bytes.
  */
 export declare function compressImageForUpload(file: File, unreadableMessage?: string): Promise<File>;
 /**