Address second round of cubic-dev-ai review feedback:
P1: detectCJKFont only scans raw file bytes for CJK characters, which
misses CJK content inside compressed/binary formats (docx, epub, odt,
pptx). For these formats, always pass a CJK font to avoid missing glyphs.
Text formats still use content-based detection.
P3: Test assertions only checked that CJKmainfont value exists in args
array but did not verify -V flag precedes it. Added assertCJKFontArg
helper that checks -V adjacency for all CJK font tests.
Changes:
- Add binaryFormats set for docx/epub/odt/pptx
- Binary formats always get Noto Sans CJK SC (cannot detect language
from raw bytes, SC is the safest default covering all CJK characters)
- Text formats continue using detectCJKFont for locale-aware detection
- Add assertCJKFontArg helper verifying -V precedes CJKmainfont value
- Add 3 new tests for binary formats (docx, epub, odt) with -V check
- 14 tests total, all passing
Address code review feedback from cubic-dev-ai:
P1: Unconditionally passing CJKmainfont broke non-CJK conversions in
environments without CJK fonts. Now the source file is scanned for CJK
characters and the font argument is only added when CJK content is
detected.
P2: Hardcoded Noto Sans CJK SC only covers Simplified Chinese. Now
detects the specific CJK language (Japanese Kana, Korean Hangul, or
Chinese Hanzi) and selects the appropriate font variant (JP/KR/SC).
Changes:
- Add detectCJKFont() that reads the source file and returns the
correct Noto Sans CJK variant, or null for non-CJK content
- CJK font argument is only added when detectCJKFont returns non-null
- Detection order: Japanese (Kana) > Korean (Hangul) > Chinese (Hanzi)
since Japanese also uses Kanji shared with Chinese
- Graceful fallback: if file can't be read, no CJK font is added
- Update tests to use temp files with real CJK content (11 tests total)
When converting documents containing Chinese, Japanese, or Korean
characters to PDF via pandoc/xelatex, the output was blank or missing
glyphs because no CJK-capable font was installed or configured.
Changes:
- Dockerfile: Add fonts-noto-cjk and texlive-lang-chinese packages
- pandoc.ts: Pass -V CJKmainfont=Noto Sans CJK SC to pandoc when
converting to pdf/latex, so xelatex uses a CJK-capable font
- pandoc.test.ts: Add 3 tests verifying CJK font argument is present
for pdf/latex output and absent for other formats
Fixes#547
* fix(assimp): pass -f<format> so non-extension targets work
The assimp converter invokes `assimp export <in> <out>` and relies on
assimp's extension-based format inference to pick the output format.
That works for targets whose id happens to match a real file extension
(glb, gltf, obj, stl, ply, etc.) but silently fails for every target
whose assimp id is not a conventional filename extension:
glb2, gltf2, objnomtl, stlb, plyb, fbxa, assbin, assxml, pbrt, assjson
Picking any of those in the UI aborts the job with:
assimp export: no output format specified and I failed to guess it
assimp_cmd's `-f<h>` flag overrides extension inference, and the values
in `properties.to.object` already correspond 1:1 to assimp's format ids
(verified against `assimp listexport`). Passing `-f${convertTo}` makes
every advertised target work without changing anything else.
Reproduction: upload any .stl, convert to glb2. Before: ENOENT on the
nonexistent output file. After: valid binary glTF 2.0.
* fix(assimp): write real file extensions for non-extension format ids
Follow-up to the previous commit. With `-f<format>` now passed to
assimp, every advertised target exports successfully — but seven of
them still produce files with assimp's internal format id as the
extension, which no third-party viewer recognises:
glb2 → .glb2 (really binary glTF 2.0, should be .glb)
gltf2 → .gltf2 (text glTF 2.0, should be .gltf)
objnomtl → .objnomtl (OBJ without .mtl, should be .obj)
stlb → .stlb (binary STL, should be .stl)
plyb → .plyb (binary PLY, should be .ply)
fbxa → .fbxa (ASCII FBX, should be .fbx)
assjson → .assjson (JSON dump, should be .json)
Map these in `normalizeOutputFiletype`, the same helper that already
handles jpeg→jpg, latex→tex, markdown→md. The format id on `convertTo`
is untouched, so `assimp -f<id>` still selects the correct
encoding/variant — only the output filename changes.
assbin, assxml, and pbrt are both the format id and the canonical
extension, so they need no mapping.
* style(assimp): fix prettier formatting
