Y.A.P.T.R. — Yet Another PaperS3 Text Reader
BTW. 知道Y.A.S.D这个梗的人应该都有点年龄了吧……
出于个人兴趣开发的轻量级阅读固件，针对 PaperS3 平台的文本阅读体验进行了优化，最主要的初心其实只是好奇。
如果说最基础的操作，无非就是下面几条
- 双击解锁
- 左右翻页
- 点击中心区域显示菜单
更详细的介绍和说明，参见WIKI的细节
后续版本陆陆续续添加了诸如：
- 自定义字体
- 竖排
- 繁简转换
- 深色模式
- 自动旋转
- 目录支持
- 自动翻页
- 更多锁屏和式样支持
- 等等
而V1.3之后，把原本依赖Python的支持性工具用浏览器扩展支持。
总体来说各方面都是按照自己的阅读习惯和倾向做了些定制化设计，一方面满足了自己的好奇心，另一方面也确实因为符合自己的（哪怕拙劣）的审美和使用习惯——不过正如我习惯性劝退的，从完备性、优化各方面，对PaperS3来说EDCBook无疑是我本人之外的用户的优选；
与其谈为什么开源，不如先说说为什么以前一直闭源；原因很简单，拿不出手而已。
这个项目最开始纯粹只是从写个demo调试定位下自己的SD卡是不是坏了开始，我既没有经验、也缺乏精力和动力（在有了EDCBook这个选项之后），从来也没有想象过会一直几个月陆陆续续写下来写到现在。
而且，一切的起点其实是EDCBook的字体工具的python源码的启发，所以代码充分展现出一种由点到线，从线到面，从底向上的“生长的美感”。换句话说，就是架构混乱；
其次，如果不是AI，不是CoPilot，已经把C代码丢下十几年的我，恐怕连续的100行代码都写不利索，所以，高度依赖AI的编码就造成了很多代码、函数可读性不够优秀（更不用提有些关键文件能被AI肆意堆到三四千行额程度），拿出来实在有些汗颜；
最后，一直以来，我受益于开源社区的无私甚多，也深知真正有效的开源，如果没有良好的文档和Support，根本无从谈起，而本项目的文档……能被称作是笔记就已经很不错了，更多的还是在我自己脑子里罢了。
可是为什么忽然又改主意了呢？因为, “我想通了”
代码混乱、文档缺乏，既然很多时候是因为能力有限借助AI导致，那么比我更聪明的人，借助AI原汤化原食当然就有解了。
至于前面提到的那点“汗颜”——其实， 谁看啊……Who cares?
IDE： VSCode + Platformio：这个部分其实参考M5Stack的官方推荐和相关配置，当然platformio.ini之类的都在，如果有兼容性问题，对照比较看看；然后理论上是可以直接编译，除了tinyusb这部分有点特殊需要点本地hack，参见/docs/TINYUSB.md做点处理；
Python: 目前实际上大部分的工具支撑都在JS的webapp（即扩展实现），原tool下的python基本上只是作为参考和对照；除非字体部分关于繁简转换和GBK转换的文件需要重新生成（但是这部分其实改动的可能性不大）还需要借助tools下的py工具，那么此时，请使用setup.bat来构建基于virtualenv的环境之后再继续；
浏览器： 调试扩展开发自然离不开，那就不赘述了，无非Chrome/Edge/Firefox浏览器就行了；
- data： SPIFFS的预置内容
- design：一些素材和图片原件
- docs：文档（少数而有限...）
- include：比较重要，特别是
readpaper.h和papers3.h定义了一些全局性质的宏决定了很多系统级的表现（PS. 有点特例，/src/globa.cpp/src/global.h还有小部分全局定义） - src：主要代码部分,内部子目录就不详述，大多看名字就有数；
- tools：主要是Python相关的工具目录
- webapp：浏览器扩展代码
- 顶层架构：
/docs/ARCHITECTURE.md, 概述和状态机相关 - 字体处理：
/docs/FONTS.md,字体生成，实现相关； - TINYUSB：
/docs/TINYUSB.md，记录了混合框架下Tinyusb的一些使用注意； - WIFI API:
/docs/WIFI_HTTP_API.md, 热点模式下WEB API的接口定义，用来和WebApp的扩展互通