reader

309 Commits 16 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
hectorqin	0551f21e4e	fix(web,server): 段落不再合成一块，插图重新画出来，工具栏对齐	2026-09-19 09:09:12 +08:00
hectorqin	1c2d07ba4c	fix(web,server): 让服务端只交章节，并去掉成对的 sync 请求服务端仍在做排版：`chapter-html:<n>` 自己断段、自己提升标题、自己吐 `<p>`。于是 reader 设置里的缩进和段间距只能作用于服务端已经渲染好的那一份，流式那条路（`chapter:<n>`）拿不到段落，同一本书因为走哪条传输而看起来不一样。客户端的 `retypePlainText` 于是把服务端断好的段落再拆一遍——同一个判断被两个地方执行，两次的结果就会分歧。 `POST /api/v1/sync` 的响应本来就是合并后的状态（服务端在两个接口上返回同一份 `pull`），但客户端把它丢掉，然后又为同一份数据发一个 `GET`。读者每翻一页都发一个 POST 加一个 GET，网络面板里成对出现。另外 `setState` 每次调用都广播，而阅读页的状态监听会重绘整棵 chrome 树，一个同步循环通知三次。现在服务端只把整章字符交出来（`text/plain`，`chapter-html:` 不截断），断段、去段前空格、提升标题全部由 `web/src/formats/segments.ts` 一处决定；push 的返回值直接喂给 `applyPulled`，空闲轮询才真的发 GET；`setState` 值未变就不广播。「这一章是不是纯文本」改由 manifest 声明（item 的 `format: 'html'` → `Section.plainText` → `isPlainText()`），不再靠 `.txt-body` 嗅探：服务端现在发裸字符，嗅探对一章节全是纯文本的章节会答「不是」，读者会看到一本没有段落、没有缩进、样式表也没挂上的小说。`.txt-body` 标记降级为旧服务端／旧缓存的兜底。放弃的方案：保留服务端渲染、只在客户端覆盖样式。缩进和段间距是阅读偏好，服务端渲染就等于把每次调整变成一次往返，而这个往返正是问题本身。也考虑过让 `chapter-html:` 直接返回服务端渲染的裸 `<p>`（不带 wrapper），但那仍然有两个地方在判断「一段是什么」。 Ref: #34	2026-09-18 23:39:55 +08:00
hectorqin	7b9c786c83	feat(web): 纯文本排版改在客户端，并让顶栏底栏一起收放现状问题。TXT 的段落和缩进原本由服务端决定：`chapter-html:<n>` 把章节渲染成带 `<p>` 的片段，客户端只是把它塞进 shadow root。于是三件事同时不对。一是缩进设定只对服务端已经渲染好的那份生效，windowed 路径拿到的 `chapter:<n>` 是纯字符没有段落，同一个读者同一本书会因为走哪条传输而长得不一样。二是抓取来的文件里用来当缩进的段前空格被原样留下，和读者的缩进叠加，恰好在最需要这个设定的文件上看起来像没生效。三是这些设定是每台设备各自的阅读偏好，烧进响应就等于把每次调整变成一次往返。另一件事是顶栏和底栏可以各自隐藏，读者收起导航后底栏仍压着每一页的最后两行。方案依据。把「一段是什么」收敛到客户端的唯一定义（`formats/segments.ts`），本地加载、windowed、流式三条路都走它，服务端的职责缩小为交出完整章节和在原文上断段。`ReaderView` 在渲染前对纯文本章节再过一遍这个拆分（按块读回、拼回空行再拆，所以服务端断得对不对不影响观感），缩进、段间距、去掉段前空格因此无需请求即可作用于两条路径。顶栏与前底栏由 `.reader-screen` 上的一个 `data-chrome` 统一开关，收起时两条栏一起归零高度并滑出、正文长满整屏，同时右侧浮出一列快捷按钮，否则收起工具栏会变成「必须离开才能操作」的状态。放弃方案。把服务端的 `chapter-html` 直接删掉：`href` 同时是阅读位置的标识，且 `format: 'html'` 字段已是既有契约，删掉会让旧客户端与旧位置一起失效，所以保留作为传输，只去掉它承担的排版职责。让缩进靠服务端属性（`data-indent`）继续驱动：那正是「设定是响应的属性」这一问题的根源。收起态用两个独立开关：写法上就能只藏一半，而这恰是读者报的那个 bug。改动点。新增 `web/src/formats/segments.ts`（分段、去段前空格、HTML/节点两种形式、跨 chunk 的 carry 判定）；`reader-view.ts` 增加 `retypePlainText` 并去掉旧排版表里读服务端属性的规则；`render/text.ts` 按 `carry` 拼接跨块段落；服务端 `text-html.ts` 去掉 `indent` 选项、不再截断；`reader-chrome.tsx` 增加侧边快捷列与设置面板顶部的「快捷」一行；`reader.css` 增加两条栏的收放与按钮列样式；图标集新增 `text-indent` / `text-type` / `spacing`；`docs/ui.md` 补 §3.7 的边界说明与 §3.8 沉浸式阅读。验证方式。`cd web && npm test`（369 条）、`cd server && npm test`（205 条）全绿； `npm run build` 通过；`npm run ui:review` 全绿，并新增「收起工具栏: 顶栏与底栏一起走 / 都不\|不可见 / 正文占满整屏 / 右侧仍有快捷按钮」四条尺寸断言（截图见 `docs/ui-review/03-reader-no-chrome.png`），评审夹具改用全角空格缩进，使「段前空格被去掉」在截图上可见。 Ref: #34	2026-09-18 19:09:51 +08:00

Author

SHA1

Message

Date

hectorqin

0551f21e4e

fix(web,server): 段落不再合成一块，插图重新画出来，工具栏对齐

2026-09-19 09:09:12 +08:00

hectorqin

1c2d07ba4c

fix(web,server): 让服务端只交章节，并去掉成对的 sync 请求

服务端仍在做排版：`chapter-html:<n>` 自己断段、自己提升标题、自己吐
`<p>`。于是 reader 设置里的缩进和段间距只能作用于服务端已经渲染好的那一份，
流式那条路（`chapter:<n>`）拿不到段落，同一本书因为走哪条传输而看起来不一样。
客户端的 `retypePlainText` 于是把服务端断好的段落再拆一遍——同一个判断被两个
地方执行，两次的结果就会分歧。

`POST /api/v1/sync` 的响应本来就是合并后的状态（服务端在两个接口上返回同一份
`pull`），但客户端把它丢掉，然后又为同一份数据发一个 `GET`。读者每翻一页都发
一个 POST 加一个 GET，网络面板里成对出现。另外 `setState` 每次调用都广播，而
阅读页的状态监听会重绘整棵 chrome 树，一个同步循环通知三次。

现在服务端只把整章字符交出来（`text/plain`，`chapter-html:` 不截断），断段、
去段前空格、提升标题全部由 `web/src/formats/segments.ts` 一处决定；push 的返回
值直接喂给 `applyPulled`，空闲轮询才真的发 GET；`setState` 值未变就不广播。

「这一章是不是纯文本」改由 manifest 声明（item 的 `format: 'html'` →
`Section.plainText` → `isPlainText()`），不再靠 `.txt-body` 嗅探：服务端现在发
裸字符，嗅探对一章节全是纯文本的章节会答「不是」，读者会看到一本没有段落、
没有缩进、样式表也没挂上的小说。`.txt-body` 标记降级为旧服务端／旧缓存的兜底。

放弃的方案：保留服务端渲染、只在客户端覆盖样式。缩进和段间距是阅读偏好，服务端
渲染就等于把每次调整变成一次往返，而这个往返正是问题本身。也考虑过让
`chapter-html:` 直接返回服务端渲染的裸 `<p>`（不带 wrapper），但那仍然有两个
地方在判断「一段是什么」。

Ref: #34

2026-09-18 23:39:55 +08:00

hectorqin

7b9c786c83

feat(web): 纯文本排版改在客户端，并让顶栏底栏一起收放

现状问题。TXT 的段落和缩进原本由服务端决定：`chapter-html:<n>` 把章节渲染成
带 `<p>` 的片段，客户端只是把它塞进 shadow root。于是三件事同时不对。一是缩进
设定只对服务端已经渲染好的那份生效，windowed 路径拿到的 `chapter:<n>` 是纯字符
没有段落，同一个读者同一本书会因为走哪条传输而长得不一样。二是抓取来的文件里
用来当缩进的段前空格被原样留下，和读者的缩进叠加，恰好在最需要这个设定的文件
上看起来像没生效。三是这些设定是每台设备各自的阅读偏好，烧进响应就等于把每次
调整变成一次往返。另一件事是顶栏和底栏可以各自隐藏，读者收起导航后底栏仍压着
每一页的最后两行。

方案依据。把「一段是什么」收敛到客户端的唯一定义（`formats/segments.ts`），
本地加载、windowed、流式三条路都走它，服务端的职责缩小为交出完整章节和在原文
上断段。`ReaderView` 在渲染前对纯文本章节再过一遍这个拆分（按块读回、拼回空行
再拆，所以服务端断得对不对不影响观感），缩进、段间距、去掉段前空格因此无需请求
即可作用于两条路径。顶栏与前底栏由 `.reader-screen` 上的一个 `data-chrome` 统一
开关，收起时两条栏一起归零高度并滑出、正文长满整屏，同时右侧浮出一列快捷按钮，
否则收起工具栏会变成「必须离开才能操作」的状态。

放弃方案。把服务端的 `chapter-html` 直接删掉：`href` 同时是阅读位置的标识，且
`format: 'html'` 字段已是既有契约，删掉会让旧客户端与旧位置一起失效，所以保留
作为传输，只去掉它承担的排版职责。让缩进靠服务端属性（`data-indent`）继续驱动：
那正是「设定是响应的属性」这一问题的根源。收起态用两个独立开关：写法上就能只藏
一半，而这恰是读者报的那个 bug。

改动点。新增 `web/src/formats/segments.ts`（分段、去段前空格、HTML/节点两种形
式、跨 chunk 的 carry 判定）；`reader-view.ts` 增加 `retypePlainText` 并去掉旧
排版表里读服务端属性的规则；`render/text.ts` 按 `carry` 拼接跨块段落；服务端
`text-html.ts` 去掉 `indent` 选项、不再截断；`reader-chrome.tsx` 增加侧边快捷列
与设置面板顶部的「快捷」一行；`reader.css` 增加两条栏的收放与按钮列样式；图标
集新增 `text-indent` / `text-type` / `spacing`；`docs/ui.md` 补 §3.7 的边界说明
与 §3.8 沉浸式阅读。

验证方式。`cd web && npm test`（369 条）、`cd server && npm test`（205 条）全绿；
`npm run build` 通过；`npm run ui:review` 全绿，并新增「收起工具栏: 顶栏与底栏一
起走 / 都不|不可见 / 正文占满整屏 / 右侧仍有快捷按钮」四条尺寸断言（截图见
`docs/ui-review/03-reader-no-chrome.png`），评审夹具改用全角空格缩进，使「段前
空格被去掉」在截图上可见。

Ref: #34

2026-09-18 19:09:51 +08:00