tamakyi
310f85156a
perf(share): 单题卡二维码同样提到 5px/模块
...
单题卡右侧卡片只有 210×255，二维码最大只能到 148px（37 模块 = 4px/模块），
缩到 480 宽照样解不出。
- QQRCardW 210 → 236、QQRCardH 255 → 300、QQRSize 150 → 190（37 模块 → 185px）
卡片仍居中对齐（x 679、y 120），左侧文字区随 QQRCardX 派生，自动收窄 26px
- 二维码卡片绘制抽成 drawQuestionQRCard，可在测试里直接调用出图
- 新增 TestQuestionQRCardLayout：二维码必须正方形、模块 ≥5px、四边留白 ≥20px、
居中偏差 ≤1px，TEST_PREVIEW=1 输出整卡 PNG；把 QQRSize 改回 150 立刻 FAIL
实测：二维码 185px（5px/模块）、居中偏差 0.5px、上下留白 34px；
gozxing 在 960 / 720 / 480 / 320 宽下都能解出正确链接。
2026-10-23 00:27:07 +08:00
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
0181fc5c66
fix templates v3
2026-10-22 18:26:30 +08:00
tamakyi
b939d26ff0
fix templates v2
2026-10-22 17:49:25 +08:00
tamakyi
bd02eb7ed2
fix templates v1
2026-10-22 17:04:10 +08:00
tamakyi
38cd41afde
theme v3
2026-10-19 16:46:42 +08:00
tamakyi
3202ef9821
theme v2
2026-10-19 16:16:07 +08:00
tamakyi
e9fba8b9ed
theme v1
2026-10-19 15:23:11 +08:00
tamakyi
12a37e726f
fix v14
2026-10-19 02:25:19 +08:00
tamakyi
4592b6ef24
fix v13
2026-10-19 01:58:00 +08:00
tamakyi
bd613a6f5a
fix v12
2026-10-19 01:11:28 +08:00
tamakyi
7a6417c33d
restrict v8
2026-10-18 23:32:38 +08:00
tamakyi
317c96ca17
restrict v7
2026-10-18 23:04:50 +08:00
tamakyi
bd81398a06
restrict v6
2026-10-18 22:18:21 +08:00
tamakyi
d14d26df17
restrict v5
2026-10-18 21:59:12 +08:00
tamakyi
52f0712eda
restrict v4
2026-10-18 21:50:58 +08:00
tamakyi
efb19606a7
restrict v3
2026-10-18 21:36:03 +08:00
tamakyi
6bd90779f8
restrict v1
2026-10-18 21:14:59 +08:00
tamakyi
da7e76a7db
webp fix v2
2026-10-16 09:39:30 +08:00
tamakyi
e4457e3da4
webp fix v1
2026-10-15 11:41:19 +08:00
tamakyi
5ee2dc1540
fix login error
2026-09-15 13:10:57 +08:00
tamakyi
0e0c16f786
fix deactivate
2026-09-15 12:10:42 +08:00
tamakyi
adcc42cc8c
fix anwser token and database issus
2026-09-15 11:06:09 +08:00
tamakyi
e683e798aa
fix typo error
2026-09-10 19:27:21 +08:00
tamakyi
8e2325eda5
aliyun sensor server
2026-09-10 18:04:19 +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