tamakyi
72f08cd7c9
perf(share): 用「同画布放大二维码」替代 2x 渲染，模块 4px → 5px
...
960×540 的卡被聊天软件缩到 480 宽时，二维码每模块只剩 2px，解码器读不出。
2x 渲染能解决，但实测成本不低（见下），先用零代价的办法把模块做大。
实测矩阵（go-qrcode 纠错 Q / 真实 55 字符链接 / 37 模块，含内嵌头像）：
尺寸 148px = 4.0px/模块 -> 960 o 720 o 480 x 320 x
尺寸 190px = 5.0px/模块 -> 960 o 720 o 480 o 320 o 240 x
纠错降到 M（33 模块）只省 11% 模块数，容错却从 25% 掉到 15%，不划算；
PNG 只能保住原图，缩到 480 一样解不出，体积还是 JPEG 的 5 倍。
- QRCodeSize 165 → 190（37 模块取整为 5px/模块；生产短域名 33 模块为 165px）
- QRCardH 315 → 335 容纳变高的二维码，卡片整体仍垂直居中
- 新增 TestGenerateQRModuleSizeAtLeast5：三种常见链接长度下模块必须 ≥5px，
把 QRCodeSize 改回 165 立刻 FAIL
渲染成本基准（1x vs 2x）：JPEG 编码 12 → 48ms、背景 Lanczos 缩放 25 → 41ms、
画布分配 3 → 13ms，二维码生成本身 0.8ms —— 2x 的代价主要在编码与缩放，
与二维码尺寸无关，所以放大二维码不增加任何 CPU。
2026-10-22 23:36:02 +08:00
tamakyi
b35c2a8f45
fix(share): 二维码不再被静默区吃掉三分之一尺寸；卡内间距收到 4px 栅格
...
上一版改成按模块整数倍出图时，静默区仍然画在图像里：49 个模块（41 + 4×2）
挤进 165px 只剩 3px/模块、符号 111px，比改造前的 135px 还小 —— 这是自己引入的
回归。测试卡上验证时才发现：二维码在 960 宽的卡里只占 111px，微信/QQ 二次
压缩到 480 宽后模块不足 1.5px，gozxing 直接解不出来。
- generateQR 改 qr.DisableBorder：图像只输出符号，静默区交给承载它的白色卡片
（四周留白 30px 以上，远超 4 模块）。符号尺寸按 size/modules 取整，最多
浪费一个模块宽度
- 调用方按实际符号尺寸居中与排版，不再假设等于目标尺寸
- 单题卡 QQRSize 128 → 150：37 模块的题目链接因此拿到 4px/模块（原 3px）
- 卡内垂直间距 26/21/21/15 → 24/20/20/16，落在 4px 栅格上
验证：profile 卡二维码 111px → 148px（37 模块 × 4px，用满 90%），单题卡
111px → 148px；gozxing 解码 960 原图、75% 缩放图均能读出正确 URL（含内嵌
头像）。守门测试加了两条：符号宽度必须等于 modules×perModule 且吃掉目标尺寸
≥80%（变异成「含静默区」立刻 FAIL），头像测试改判四角必须是定位图案而非
白色（防止符号被裁切）。
2026-10-22 23:22:34 +08:00
tamakyi
d51629ef2f
fix(share): 字体缺失不再永久失败；二维码按模块整数倍绘制
...
测试环境部署后分享卡整站 500「字体文件未配置或无法加载」。根因不是代码
回退，而是字体从来就不在仓库里：static/fonts/ 既没有入库（git 历史为空），
也没有 embed，凡是按仓库新建的环境都缺这个文件，只有手工补过字体的老环境
才正常。
- getFont 不再用 sync.Once 永久缓存失败：补上字体文件即生效，无需重启；
失败时错误信息带上「已尝试的路径」，排障不用再猜是配置还是文件
- 候选路径：font_path → static/fonts/*.{otf,ttf,ttc} → 常见系统 CJK 字体，
换过字体文件名也能用
- app.sample.ini 注明字体必须自备、缺失的后果
顺带做 P1 的第一项：generateQR 改为按模块整数倍出图（41 模块 @165px →
每模块 4px、符号 164px 居中）。原先是 256px 生成后最近邻缩到 165px，
每模块 4.02px，模块宽窄相差 1px，小尺寸二次压缩后更容易扫不动。
内嵌头像改为按目标尺寸等比（size*48/256）+ 2px 白边，静默区不受影响。
守门测试新增两条：TestGenerateQRIsModuleAligned（扫描线游程必须是模块
宽度的整数倍，变异成等比缩放后立刻 FAIL）、TestGenerateQRWithLogo
（中心是头像、四角静默区纯白）。
2026-10-22 22:33:22 +08:00
tamakyi
0054e508b7
fix(share): 分享卡链接按真实字宽居中，长链接按 host/path 收敛
...
原实现用字符宽度系数估算文本宽度，把标点/符号一律按 1em 计，
而 URL 里的 : / . _ - 实际只有 0.25~0.35em，整句高估 55%：
15px 的 box.shiroko.one/_/tamakyi 估算 352.5px、真实 227.9px，
越过卡片可用宽 230px 后触发等比缩字号，最终只画到 9.6px 且左偏 40px；
链接越长字号越小（长域名实测 5.3px），整段挤在卡片左侧。
- measureTextWidth 改为逐字累加 HMetric.AdvanceWidth + Kern，
scale = fontSize*64 与 freetype 在 72 DPI 下的换算一致，测量结果与
DrawString 返回笔位逐位相等；字体不可用时回退估算
- drawTextCentered 随之修正，底部水印原本偏 9.8px 一并归位
- 新增 displayURL（去协议前缀）/ layoutLink / ellipsizeMiddle：
单行 15→13px；放不下按 host/path 拆两行 13→11px；host 超宽才中间省略；
字号下限 11px，行长恒定不超过 QRCardW-40
- 卡片内容高度按链接行数计算，两行时整体重新居中
守门测试见 route/question/share_layout_test.go（测量=笔位、限宽、按着墨
边界判定居中 ±3px、TEST_PREVIEW=1 出图）。
2026-10-22 21:42:50 +08:00
tamakyi
4592b6ef24
fix v13
2026-10-19 01:58:00 +08:00
tamakyi
6bd90779f8
restrict v1
2026-10-18 21:14:59 +08:00
tamakyi
e3e59e7c69
chore: baseline snapshot before moderation-strictness feature
...
Repo .git was damaged (refs/ missing, index truncated, object store near-empty).
Repaired via git init (rebuilt refs), stale index preserved as .git/index.corrupt-20260910.bak,
then full worktree committed as a rollback baseline.
2026-09-10 10:56:27 +08:00
tamakyi