gPdf
Use cases · Logistics & shipping

PDF สำหรับฉลากการจัดส่งในสเกลระดับ carrier

เรนเดอร์ฉลากการจัดส่ง thermal ขนาด 4×6 พร้อมบาร์โค้ด GS1-128 แบบเวกเตอร์, ITF-14 carton codes และ SSCC-18 pallet IDs การเรนเดอร์บน Edge ช่วยให้ p99 ต่ำกว่า 15 ms แม้มี spike ช่วง Black Friday

Job to be done

เรนเดอร์ฉลากการจัดส่ง thermal ขนาด 4×6 ที่พร้อมใช้กับ carrier รวมถึงบาร์โค้ด GS1-128, ITF-14 และ SSCC-18 แบบเวกเตอร์ จาก order JSON โดยตรง ไม่ต้องเปิด headless browser ต่อ request output ต้องสแกนได้เชื่อถือได้ที่ 203 dpi บน printer Zebra/SATO/Honeywell และยังต่ำกว่า 15 ms p99 ระหว่าง peak retail spikes

Why gPdf for this

  • Vector Code 128, QR, DataMatrix, PDF417 และ GS1-128 / ITF-14 / SSCC-18 — แม่นระดับ sub-pixel ที่ 203 dpi, 300 dpi และ 600 dpi
  • ความแม่นยำพิกัด 0.1 มม. — ตรงกับ tolerance ความยาวรวมของ carrier สำหรับ human-readable interpretation lines
  • Page size `label_4_6_in` รวมถึง `label_4_8_in`, `label_a6` ถูกเตรียมไว้สำหรับ thermal-printer formats หลัก
  • Determinism — order JSON เดิมเรนเดอร์เป็น PDF byte-identical ดังนั้น reprint ในคลังสินค้าจะไม่สร้างฉลากที่ “ต่างออกไป”
  • Edge rendering — p50 3 ms, p99 8 ms แม้พิมพ์ฉลาก 50K ใบในนาทีเดียวกันช่วง carrier pickup
  • Stateless: ฉลากอยู่ใน memory ประมาณ 4 ms ใน Cloudflare Worker isolate แล้วถูกปล่อย ไม่มี document store และไม่มีพื้นผิวรั่วไหลของ carrier-data

Sample request

POST /api/v1/pdf/render — ฉลาก thermal 4×6 ขั้นต่ำพร้อมบาร์โค้ด carrier tracking แบบ Code 128

{
  "pages": [{
    "size": "label_4_6_in",
    "elements": [
      {
        "type": "text",
        "x": 4, "y": 6,
        "content": "SHIP TO",
        "style": { "font_size": 8, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "text",
        "x": 4, "y": 12,
        "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116",
        "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "barcode",
        "format": "code128",
        "content": "1Z999AA10123456784",
        "x": 4, "y": 60,
        "width": 92, "height": 22,
        "barcode_text": { "enabled": true, "position": "bottom" }
      }
    ]
  }]
}

Compliance and conformance

  • GS1 General Specifications — module width (X-dimension), quiet zone และ overall length ตรงกับ tolerance ของ GS1 Section 5.4 ที่ 203 dpi
  • Carrier mandates — UPS, FedEx, DHL และ USPS ยอมรับ rendered output ว่าสแกนได้ โดยไม่ต้อง post-processing ต่อ carrier
  • PDF/A-2b ใช้ได้สำหรับ archival ผ่าน `settings.profile = "pdfa-2b"` หากคุณต้องเก็บ label PDF ด้วยเหตุผลด้าน tax/audit

workload ของ shipping-label ในหนึ่งย่อหน้า

ทุก order สร้าง PDF หนึ่งไฟล์ ทุก PDF ถูกพิมพ์หนึ่งครั้งบน thermal printer และ failure mode ถ้าคุณช้าไม่ใช่ “หน้าโหลดช้า” แต่คือ “จุดรับสินค้าของคลังสินค้าต้องรอ API เรนเดอร์ฉลากของคุณ” Shipping เป็นงานที่ p99 latency คือ product metric สำคัญที่สุด output ต้อง deterministic เพราะ reprint เป็นเรื่องปกติ และคุณภาพบาร์โค้ด — วัดด้วย tolerance ของ GS1 X-dimension ไม่ใช่ pixels — เป็นตัวตัดสินว่า scanner อ่านฉลากได้ตั้งแต่ครั้งแรกหรือไม่

PDF stack ที่ใช้ headless browser มักรับมือสามเรื่องนี้พร้อมกันได้ยาก: cold-start cost ทบกันตอน spike, raster barcodes เสื่อมคุณภาพบนฉลาก thermal ขนาดเล็ก และ font rasterisation drift ระหว่าง Chromium versions ทำให้ “byte-identical reprint” เป็นไปไม่ได้

ทำไม gPdf ถึงเหมาะ

ฉลาก thermal 4×6 มีขนาดเล็ก (576 × 864 pixels ที่ 203 dpi), จำนวนองค์ประกอบไม่มาก (text blocks + บาร์โค้ด 1-2 ตัว + optional carrier logo) และปริมาณสูง (3PL ขนาดกลางเรนเดอร์ 50K-500K ใบต่อวัน) นี่คือ workload ที่ gPdf ถูกสร้างมาเพื่อรองรับ renderer:

  1. Compile layout ครั้งเดียว — page coordinates, font cascades และ barcode geometry ถูก resolve ตอน request ไม่ผ่าน browser layout engine
  2. Vectorise ทุกบาร์โค้ด — modules ถูกวาดตรงลงใน PDF stream ทำให้ GS1-128 กว้าง 30 มม. อ่านได้ชัดที่ 203 dpi หรือ 600 dpi โดยไม่ต้องมี DPI-aware rasterisation logic ในฝั่งคุณ
  3. ฝัง NotoSans CJK + Latin — payload เดียวกันเรนเดอร์ชื่อ carrier ภาษาจีนได้ถูกต้องโดยไม่ต้อง provision fonts ใน render container

p99 คงที่ที่ 8 ms ใน reference workload ของเรา (1K invocations ของตัวอย่างด้านบนบน EU-WEST) ไม่ว่าจะเป็น isolate ที่เรนเดอร์ฉลากใบเดียวหรือ 10K ใบแล้วก็ตาม

คำนวณ volume + cost

3PL ขนาดกลางทั่วไปทำงานประมาณ 50K labels/day = ~1.5M/month บน Basic plan (5/month สำหรับ 100K pages, 0.00005 per page overage) จะเป็น:

1.5M pages × $0.00005       = $75.00 in overage
+ Basic plan base            =   $5.00
─────────────────────────────────────
total                         = $80.00 / month

workload เดียวกันบน Puppeteer-on-Lambda มักอยู่ในช่วง $200-400/month ตามค่า concurrency ของ Lambda ทั่วไป ก่อนรวม cold-start tax ช่วง peak

Black Friday: ตัวอย่างคำนวณจริง

Peak spike คือ workload ที่ทำให้ edge rendering แสดงคุณค่าชัดที่สุด ลูกค้า retail ที่มี label volume สูงกว่าปกติ 200% ในชั่วโมงแรกของ Black Friday เช่น 100K labels ใน 60 นาที เฉลี่ย 1.7K labels/minute และ peak burst 5K/minute สามารถจบภายใน Cloudflare Workers region pool เดียวโดยไม่มี cold-start tax ส่วน workload เดียวกันบน Puppeteer warm pool ที่ sizing ตาม traffic เฉลี่ยจะเกิด cold-start 1.5-2.5 s บน containers ที่ถูก spawn ตอน burst และจุดรับสินค้าคลังสินค้าจะรู้สึกถึงทุกครั้ง

ควรอ่านต่อที่ไหน

Keep reading