其实无论你们怎么选，我都会再重写一遍，不好意思 😂
我只是想摸下鱼。

我不是很喜欢最后那个算 padLeft 和 padUp 的
大致就是
lineW = (cfg.font_size + sp_h) * scale
lineH = (cfg.font_size + sp_v) * scale
cols = int(image.width / lineW)
rows = int(image.height / lineH)
padLeft = (image.width - (cols*lineW) + sp_h) /2
padTop = (image.height - (rows*lineH) + sp_v) /2
🤔 很生的布局边界计算，难怪当时我想用一个 LayoutPlanner ，原来是这么算的 真的有预先算布局再区间迭代啊……
（啊不对，不是 line，应该是 item……）

差别大致在于预先算好了的项目布局不依赖执行顺序（这样就相对容易优化），看来我有必要把 TintedDrawable 给细化一点了……
class TintedDrawable:
def drawOn(self, img, rect, color): pass
这样的话既可以保证项目的灵活性，也能保证算法尽可能抽象。

这一段设计实在是太赞，爱了爱了（虽然现阶段解耦合的设计可能带来额外开销）

#GUI 🤔 谁会画这种单元格？……
class Boxes: QWidget {
public:
Boxes();
~Boxes();
int width, height;
int n_rows, n_cols;
void setColor(QPoint p, QColor color);
QColor getColor(QPoint p);
}

数据都迁移完了
目前发现损失的有
文化周的视频（可以重新编码出来）
PS安装包（可以重新下，反正到时也要换2020版的了）
红米3刷机包（重新解压的事）
Windows 8.1镜像（重新下）
腾讯会议安装包（这个其实也没啥留着的必要）

综合看来损失不算特别大，但万一以后损失的是其他东西呢

好想学 Java swing/awt 和 Qt GUI 开发啊

Python 就有一点好，就是 pip ipython 什么的都很简单，想要什么依赖几乎都可以立等可取不需要折腾什么构建管理啊包管理啊（甚至还得提供“repositories”）
而且又有带语义缩排，不像其他语言要么 {} 要么写一大堆 end

所以虽然 Python 有很多缺点，但还是会被包括学者在内的许多人喜爱
Kotlin 现在是没 boilerplate code 了，但我可以不开 IDE 直接就在 Kate 文本编辑器里想到啥写啥，虽然可怜 Python 没有静态检查而且很不严格就是了……

但好好考虑一下，Python 新建一个文件，写上一个 shell-bang line 再 import 几个必要库就可以开整，但 Kotlin 还要按照 Java 的那一套去配置半天…… 就为了个很牵强的“可复现的构建环境” 也是怪难受的了

其实 extract-subtitles 完全可以移植到 Java，关键依赖只不过…… 是 OpenCV, Tesseract, 和一个从信号取得所有峰值索引的 peak estimation 算法
不知道 Python 用 ctypes 绑定一些简单的 C function 还是用 JNI 简单（
不过也必须有 Iterator 并且能实现 chuncked 方法，要不然处理点高清视频 JVM 上照样卡死。（ java.util.stream.Stream 里面已经有了 reduce 方法，不过那个是新的 Java API，Android 里也木有…… ）

不过现在 Kotlin 也有 Kotlin Script 了，不知道依赖库全局共享能不能做
Python 作为“脚本语言”可以用来处理很多偶尔需要运行的任务，但作为常见的应用的话还是不如用静态强类型的语言，单单用“编译语言”或“脚本语言”都是不可以的（非正式名词）

#Learn #law 如果做动漫剧情解说，会涉及侵权吗，例如 b 站的 Lexburner 会有这方面的风险吗? - Sithferia的回答 - 知乎
https://www.zhihu.com/question/380126301/answer/1084812506

🤔 来说说吃饭路上想的两个设计啊。 #Learn

1. ParserKt 依然是 PWOC(Pattern/PatternWrapper, OptionalPattern, ConstantPattern)
SDRIES(Seq, Decide, Repeat, item, elementIn, satisfy)
CCDPAC(Convert, Contextual, Deferred, Piped, AlsoDo, Clam)
SJIT(SourroundBy, JoinBy, InfixPattern, TriePattern)
NLL(NumUnitPattern, LayoutPattern, LexicalScopedPattern)
此外还有 GreedyPattern, TextPattern, LexerFeed
TriePattern 也有特别的 PairedTriePattern 和 DictPattern
将来 ParserKt，我会争取让人能“完全理解”这个框架。（在我的眼睛里，这个问题本应该非常简单）

2. 当然是 MontagePY 了，我整理出了一个参数表，以及提供了一个基于 Fold 以同时实现 count diff pixel & color average 功能的方法（Fold 真是一个“宝藏架构”……），下面我会叙述自己的设计思路。
先说说 Fold 吧（它不过就是把 create, loop-modify state 的模板代码给解耦成 constructor, accept, finish 了而已，同时这也可能增大 GC 压力但 Java/JS 不就是这么用的么）
我觉得 Fold 对 ParserKt 真是超赞啊，之前没有在工程系 parser tool 里见过能直接把输入变成 Int 而无需弄什么 parseInt 啊 toInt 啦的流程（其实这个东西在比较学术的 parser comb. 实现里也很常见，比如 Haskell 有 lazy list 的情况下，只不过那些语言复用性都太弱）
其实许多东西都是原来早就存在了的（解析组合子不就是那几个东西嘛），只不过 ParserKt 把它们融入自己的灵魂、强调强调再强调、带到了工程实践中来而已。其他方法也很好，只不过总结方法没有 ParserKt 这么直白而已。
Fold 的两个操作 accept 和 finish 的字符数目竟然都是一样的，我非常喜欢（不像 Observer 那 onNext onFinish，虽然我也没更好方法(onDone 太 trivial) ），最近有点强迫症……

整理的参数包含三类：
字体| font, font-size, font-color
图像| mode, scale, spacing
微调| draw-color-code
当然还有
输入| image, seq

🤔其实蒙太奇图可 hack 性是比较大的，比如 draw 的也不一定是 text 什么的（做了接口抽象出来了）
比如可以弄很多 icon，给它们加能调颜色的 filter 而拼成一幅图画，不过现在暂时没法给安排成（整体就一 Callable[[List[String]], Iterator[TintedDrawable]] 的问题，关于 cycle-ing chars 呢…… 也可以给放在绘制函数的外面不必强求无限循环，更加灵活）

整个弄完后我觉得可以搞成 GIMP 插件的形式，不过不知道如果提交到预置里会不会不能弄自定义代码了，emmm。


……啊，漏掉了关于 Fold 的设计。
原来 draw-color-code 的要求很简单，就是要么画（求一个 color）要么不画
（题外话，原来我给它叫成 draw-unless 了，脑子里当时想的是 draw-unless = hide-if = 最直白(而且能强调它是否定)的肯定形式…… 很糊涂别试理解，后来我给改成 draw-color-unless 的时候我想的是要么返回原有 bool 要么是 Color ，结果就没发现实际返回只能是 (Color|False) 应该换成 (Color|None) ……这都是动态类型的锅 ||@_@| ）

可是这个过程…… 如果按照原项目参考，我一下子合并了三个参数：
+ keyColor: 生成图的背景色，同时也用作原图“背景”的参照色
+ keyThres: 如果所有通道的 distance 求和大于这个值，视为不同色 （颜色模糊匹配）
+ keyRatio: 某块的同色达到这个比率即为背景块，不作绘制

如你们所见，我把整个参照合并为了一个函数： Callable[[Image], Nullable[Color]]
但是我仍然要移植原算法，就需要解决一个数据依赖问题：
—如果我 lambda it: colorAverage(it) if ... else None
……等等，我们哪里求了要靠 keyColor/keyThres 算出的 n_difference ？ 条件是 n_difference / it.width*it.height > keyRatio 或者说 n_difference > it.width*it.height*keyRatio 才可以啊？
如果专门为此定义一个函数（这还不谈到底把一个色块遍历了几遍），则灵活性又下降了不少……

就是这样，一个子程序要遍历一遍，求出两个数据以供判断。
（关于 lambda 里不能定义局部变量怎么解构的看下面）
lambda it: let(lambda *ac_p: ac_p[0] if ac_p[1] > it.width*it.height*keyRatio, AllFold(imagePixels(it), MapFold(Averager, 3), colorDistanceCount(rgbColorFrom("#FFFFFF"), 10) ))

所以 class Fold 这种模式不仅有利于循环逻辑的解偶，还可以提升代码的灵活性（ 1个fold 对应 N组数据(MapFold) 还是 N个fold 对应 1组数据(AllFold) 都OK ）
突然觉得这个 lambda 写得好…… 烂。好了就说这么多。

迫真重构小讲堂（草

(h_sp, v_sp) = spacing
(w_item, h_item) = (d+sp for d, sp in zip((font_size, font_size), (h_sp, v_sp)) )
(m, n) = (int(full/d) for full, d in zip((width, height), (w_item, h_item)) )
padLeft = (width - (m*w_item) + sp) /2
padTop = (height - (n*h_item) + sp) /2
🤔 两点。 (0) 即便 width - (m*w_item) aka. width - (int(width/w_item) *w_item) 可以用 width % w_item 替换（并且甚至可以上 Python 的 divmod）我也没用（因为我没发现不止可以用 divmod，哈哈）
(1) (a/2+b/2) 不是永远都可以合并去 (a+b)/2 的，比如浮点高精度，但这里可以。
(2) 即便可以把 padLeft, padTop 写成 value destruct 的形式，我也没那么写，这都是为了可读性。

下文直接上骚操作：
(width, height) = imageBounds(image)
global font_size

(h_sp, v_sp) = spacing
(w_item, h_item) = (font_size+sp for sp in (h_sp, v_sp) )
(m, n) = (int(full / item) for (full, item) in zip((width, height), (w_item, h_item)) )
(padLeft, padTop) = (int( (full % item + sp) /2) for (full, item, sp) in zip((width, height), (w_item, h_item), (h_sp, v_sp)) )
*最后一条 zip(a, b, c) 真心不推荐，这条是真闹着玩的。