一键制作图片词典 MdxSourceBuilder

喬治兄

wjl 发表于 2020-8-16 11:23
你这个定位边算法不是已经有词头了吗？在每页加个左右分界标记，然后不就能够区分左侧单词、右侧单词以及 ...

9 Y2 i) c8 n' J& s( N兄弟，那也得人工去挑出來呀！，怎麼顯示都不是困難點，重點是如何挑出左右邊，人工那不如多花點精神弄精確定位，反正也差不了幾步，所有的動作不就只是想輕鬆點，然後效果又不要差太多，不是嗎？甚至是沒字表，隨便亂匹配也能知道大概位置，或甚至多配或沒匹配到也能找到位置，也能去那估出的位置看一下，辭典到底是否有收錄這個單字與否
3 V; ~9 }3 H" x! n/ J  D1 ?8 t

wjl

喬治兄 发表于 2020-8-16 11:34
兄弟，那也得人工去挑出來呀！，怎麼顯示都不是困難點，重點是如何挑出左右邊，人工那不如多花點精神弄精 ...

好吧，不过我不是很理解那种词头不精确、大词表、乱定位的词典有何意义。正规词典上的少数错误都会被各种专家、看客吐槽呀。

wht1979

喬治兄 发表于 2020-8-16 11:34
兄弟，那也得人工去挑出來呀！，怎麼顯示都不是困難點，重點是如何挑出左右邊，人工那不如多花點精神弄精 ...

这样用ps批处理左右加上不同的符号再用FineReader  ocr出来应该问题不大。你可以试验下或我可以给你实验个30-50张。（FineReader带格式的保留很全，就是慢）
( t! C: f5 d7 Z- l  x

4 }& Y5 v* O$ a, O
( M4 Y- g5 D) V/ g) D

喬治兄

wjl 发表于 2020-8-16 12:07
' Z( U9 q$ V" _- e" {, F好吧，不过我不是很理解那种词头不精确、大词表、乱定位的词典有何意义。正规词典上的少数错误都会被各种 ...

6 L/ _& }; O% N/ j$ wwjl 兄，在下也不建議您用粗略匹配的辭典，本來就不是很好用，最好是弄一次到位的文字辭典，然后文字辭典最好也是沒你所說的OCR錯誤，何必屈就圖片辭典呢，時間，效益，和用途，本來就要拿捏不是嗎？

喬治兄

0 M8 Y# ?6 y2 {0 G) d

wjl 发表于 2020-8-16 12:07
9 \# Q& U% E! c2 L  t! b& X$ e好吧，不过我不是很理解那种词头不精确、大词表、乱定位的词典有何意义。正规词典上的少数错误都会被各种 ...

在下從來不怕人家吐槽，也不說空話，畢竟空話一堆是生不出辭典，這話有點毒辣，除非有更好的實現方法或作為，粗配的缺點不用你說，大家都知道，所用的方法更不是什麼好方法，粗略定位呢，和粗配一樣缺點定不準而且還很難找，這是已知的問題呀，有沒有改善的空間呀，有的，花更多的時間去人工處理呀，若按您的標準，精確定位的處理法，你怎能忍受呢，若是碰到有音節的單詞或內縮的詞頭，請問閣下是OCR校對呢, 還是一個個點擊單詞列表呢.....以上所言並非為粗配護航也無意護航，而是閣下應對事物的本質有所了解再去決策實現的方法, 粗配也是一個笨方法...哪有可能包山包海的全解
# V5 T3 @+ V3 q+ M: l' L% P: |

VimVim

真实词典案例：
- U2 N* i& U8 w- ]
國語日報辭典 - 使用MdxSourceBuilder重制导航
https://www.pdawiki.com/forum/thread-41323-1-1.html
" O8 C' \5 K2 Z' A$ i  k, {(出处: 掌上百科 - PDAWIKI)
; m8 C- E/ e# e) L' y

* [8 P6 {7 @  O5 D  M在这个案例中，还增加了一个功能：可以添加现成的mdx源文件。其妙用：特别适合于类似案例这种港澳台等表达习惯不同的情形，要添加额外@@@LINK到已有词条的内容。

VimVim

Update：增加了防错机制，对词条、info等文件的编码都不做要求，无论gbk或utf-8，还是bomb或nobomb，系统均会自动处理。

VimVim

我在 MdxSourceBuilder 标准版的基础上，定制了一个能够兼容多层次词条（主词条+多个相关词条）的版本，用于制作《汉字源流字典-谷衍奎》，大家可以前往观摩，体会开源的好处及程序的灵活性（开源就是这个好处，想怎么改就怎么改）：
7 E: `1 F0 u+ _' q) K# y6 K" l) h
【汉字源流字典-谷衍奎】最实用的字源字典
https://www.pdawiki.com/forum/thread-41393-1-1.html
(出处: 掌上百科 - PDAWIKI)

starmars

建议作者不要搞VIM这么专业的东西，不要用什么命令行，即使您感觉再简单也会令大部分初级人员望而生畏。最好使用C#编程用WPF或者更加原始的winform创建标准的Windows桌面应用软件，一切使用拖拽式傻瓜处理，加一些窗口菜单界面上可选择的微调设置。软件开发结束之后，不要浪费时间写这么多使用说明。写一千个字都不如制作三分钟视频演示教学管用，不要无声的视频要带音频讲解的。这正是我现在正在做的。
# W" p+ z$ ^1 J

VimVim

. {5 o3 ^7 `: {

starmars 发表于 2020-8-26 11:44
7 Y; R( T/ y% f: J建议作者不要搞VIM这么专业的东西，不要用什么命令行，即使您感觉再简单也会令大部分初级人员望而生畏。最 ...

期待您的大作！若能超越，那是最好的了，皆大欢喜！
  u' I. i6 A# G- a8 V
% Q+ \' J! U! Y; I9 @# M" a( {不过你对MdxSourceBuilder的理解有误 —— 它不用任何命令就可以使用（讨论可参见21楼）：打开Vim，单击 工具栏按钮 “运行vim脚本” ，找到MdxSourceBuilder.vim，确定，结束。

, U3 ^+ r4 X6 i5 c4 G9 j2 g* D此外，MdxSourceBuilder 的初衷是开源而且跨平台（不能局限于Windows，毕竟很多人使用Mac、Linux），人人都能按需修改。我水平有限，能想到的就是要用脚本语言，否则编程门槛太高就失去了意义。我的目标不是傻瓜化，而是足够优秀（无论是成品体验，还是制作过程），同时又没有后顾之忧（开源，不要受制于原作者，想怎么修改就怎么修改）。至于傻瓜化只是必要的组成部分（属于产品需求分析与设计的范畴）。当然如果能用Python之类的流行语言编写更好。怎奈我更熟悉Vim，且使用Vim可以让我实现编辑到输出完全都只用一个工具。期待高人能够编写一个更好的Python版本。
# ~: h* G. b" s5 Z' Z2 p* |* S0 J
4 _# P' Q) _' J; D
至于教程，其实就一句话：打开Vim，单击“运行vim脚本”按钮或输入命令 :bro so，找到MdxSourceBuilder.vim，打开，结束。

8 A6 `; {5 D& m) l
3 B' u  U! _8 |. L1 P7 Q2 P对于普通用户来说，其他的文字都是可以不看，完全属于多余的内容。。。之所以写那么多，甚至GIF无声动画，那是为了协助高级用户了解来龙去脉，以便深度定制或开发新程序，或者纯粹为了让帖子好看一点，有图有真相，吸引更多的用户而已。


; v: }( u6 n9 s) |1 b  ?' ]6 a

VimVim

starmars 发表于 2020-8-26 11:44
建议作者不要搞VIM这么专业的东西，不要用什么命令行，即使您感觉再简单也会令大部分初级人员望而生畏。最 ...

0 w* r5 f' Y. e0 r: ~建议您搞个可开放下载的切图软件更有意义（开源不开源无所谓，但要有反馈的机制，比如Github）。目前流传的切图软件在友站可是讨论的热火朝天（至少说明用户很感兴趣），只是有很多问题得不到原作者的反馈或参与，甚是可惜。
3 @* _: I4 ~8 }
MdxSourceBuilder 从提出想法到已经实现，甚至都出了好几个案例了，也没几个人感兴趣，您若只是重复造这个轮子，感觉有点浪费您的技术水平了。
: y1 e2 T  R) K5 L1 Q+ ?
若说 MdxSourceBuilder 有任何闪光点的话，我觉得也仅仅是其中的 “一键制作（面向制作者）” 和 “基本导航（面向词典终端用户）” 思想。MdxSourceBuilder 程序本身纯粹是玩具，编程高手看了不笑话就不错了，因为我根本就不会编程。为了实现 MdxSourceBuilder，我还是临时学习的Python，借鉴着相关概念用熟悉的Vim脚本来编写的，你说的那两个技术术语（WPF、winform）我都没听说过，期待我去编写什么C#程序那是不现实的。

MdxSourceBuilder 更多是解决我自己的需求：在目前还没有任何其他替代品的情况下，搞了个粗糙的小脚本满足自己个性化的想法。

wjl

VimVim 发表于 2020-8-12 17:12
! k+ {$ W; ^$ a/ Q) S) e! [9 s; i0 u# P# MdxSourceBuilder
% C, D" g; c. Z. X( U* y
5 R+ R& `! k4 {一键制作图片词典：原始词条==> 标准化词条==> mdx源文件 ==> mdx词典文件

请问一下正文前和正文后部分的页码如何写？图片文件如何命名？假设正文前和正文后的页码如下所示
/ {/ b7 ?7 ?7 f) [) D
/ b" Y- l9 p+ s+ I& o1 C, R6 c正文前部分：
" I. W% q( W4 t0 B, v6 E0001
封面
( d, c+ A# \+ t* ?" [1 B0002
0003
# |! U1 B1 V, x- V3 b4 \0004
0005
1 G" d6 o( h# ]. v编写人员名单
0006
目录
, o; _! A6 S: E' G7 g7 M0007
5 s/ c5 Z6 V: a$ f( l6 S序
0008
0009
* s0 S3 a4 ?7 B. ?& Z* f前言
2 Y4 F6 P2 e) Z( V# F7 [! z0010
体例说明
0011
8 V/ z+ B3 Q8 Z' q; {/ i0012
* R: ~) ~; Y3 F7 o) ?3 `% K略语表
- Y* x0 h& e& k" N  C+ f9 o& K* G% H$ M0013
) e' T) p2 ]8 F7 ~( g# t, t8 W0014
0015
4 {4 u- L3 i7 l, T0 b6 E主要参考书目

正文后部分：
0001
& ]% n; q: U2 S图书在版编目(CIP)数据
0002
3 F: F/ j( t6 M0 D0 k0003
0004
/ S; ~4 t! [4 x+ C/ P5 K封底
: _) r% e4 s4 N' D$ n
* d' P, a! v( {2 w- F: o

VimVim

9 C& a0 X! }& n5 Z  E! _1 p, G

wjl 发表于 2020-8-31 18:54
  D. d+ n' n! Y请问一下正文前和正文后部分的页码如何写？图片文件如何命名？假设正文前和正文后的页码如下所示
# H* @0 i) {' Z+ z  w1 L+ _
正文前 ...

页码其实可以随便怎么写都可以，默认只要是四位数字都支持（3位或5位等需要更改core程序），但按顺序写（从1开始，或接续正文页码），用起来也符合逻辑不是吗？否则跳着页码来或突然来个第7856页，也很奇怪啊。
. a& w- g3 \% a! y5 u; G
0 e$ g( f, @6 G4 ?2 G图片名称是由配置文件MdxSourceBuilder.vim的g:dictionaryParts 决定的：前缀（第2个参数）+四位数字页码（在词条文件中）+后缀（第3个参数），比如：        
let g:dictionaryParts = [
7 `) H  H: n* {% b        \["火星词典.Cover.txt", "MarsDictCover_", ".png", 0, 1],
        \]
7 c" ]( v& Z- C+ o
6 _* i% ^* o+ v1 m3 p' ?% G/ R
那么这个图片名称就是 MarsDictCover_1234.png

% m1 }1 n& i7 j3 U你在案例中可以看到，我给每个部分的前缀名定义都不一样，就是为了避免不同部分的图片名称冲突了。

+ D- U8 m9 n3 P9 S( x& ]

wjl

不支持以下格式吗？
' V& E$ c  s0 R1 z  x
0001        A
1 v: u; _$ X' I$ ^% M0001        Al/A-one
. G2 e7 A8 J% i  z9 f+ T" T9 n: D9 d# |0001        Al at Lloyd's
0001        d coups de baton
  B' A& C0 S; K* F# U" d) b* A0 D5 g0001        d haute voix
& t$ q$ e9 q7 O0001        d Mervielle
3 Q) z) _- O9 S8 o, D; a0001        A to Z of, the
$ v! @. l: N9 k& q4 y0001        A/advanced level
  U8 U- \6 `$ T2 u% y, c' ^0001        Aaron's beard
0001        Aaron*s rod
9 z+ B0 O4 v% [# b. t$ f3 E0001        Aaron's serpent

VimVim

1 R( Q0 H0 w, V- J; A

wjl 发表于 2020-8-31 22:53
不支持以下格式吗？
2 T) e' P" i1 l" x$ n. l
0 V1 H* I7 Y9 B9 T- }( h0001        A

支持啊，格式2。
配置文件中都有说明文档啊，不用这样一点一点问答吧。
3 z& O& I; U, p; }/ \9 n" y8 v* ^

wjl

VimVim 发表于 2020-8-31 23:16
! H+ n$ x0 F7 n, X- h9 m支持啊，格式2。
* c1 T  G( Q, f8 ?配置文件中都有说明文档啊，不用这样一点一点问答吧。
4 k' V. |; F4 E) n ...

! ?; T6 c( |! ~; Q) @- d5 o程序使用的分隔符是什么呀？我用制表符分割，生成的mdx只有页码，没有关键字词条

VimVim

9 n- ^( j* t" M) |' j- x1 c

wjl 发表于 2020-8-31 23:21
! O) {9 J9 K2 b9 y6 o程序使用的分隔符是什么呀？我用制表符分割，生成的mdx只有页码，没有关键字词条 ...

2 w. m$ D- Q9 h词条格式的配置参数对了吗？PageKeywordStyle：2
支持tab或4个及4个以上空格
2 I* H( {- r( O" a5 N
% N* |! F) G0 q7 c7 l

wjl

VimVim 发表于 2020-8-31 23:24
9 r6 m+ Q8 Y" Y; e9 V词条格式的配置参数对了吗？PageKeywordStyle：2
支持tab或4个及4个以上空格

4 K7 u# t3 ~* U9 t& @" p3 J我这里实测用emeditor的tab不行，换成四个空格就正常了

VimVim

wjl 发表于 2020-8-31 23:38
# p1 a8 a3 M4 O4 j5 S我这里实测用emeditor的tab不行，换成四个空格就正常了

% p  C2 w2 N8 ~9 U9 ^- a* @你是下载的最新版本吗？中间升级过。

wjl

! g* x2 a! O6 H% g

VimVim 发表于 2020-8-31 23:42
9 m, t+ p- G' m3 S! K8 e你是下载的最新版本吗？中间升级过。

对，我今天刚下载的最新版本。另外，转换的条数也不全，五万多条，只转了四五百条

VimVim

0 _9 }) q, b2 c

wjl 发表于 2020-8-31 23:47
$ ^8 l% ^' c5 Q# V对，我今天刚下载的最新版本

我估计你肯定哪里出错了，只是你还没发现。

! U7 h5 L0 N9 G2 t- W6 o6 G/ R% L1 T方便的话，私信我一个案例文件吧，我具体看一下。
, A0 r" r& G5 G( k/ w% A0 f

VimVim

VimVim 发表于 2020-8-31 23:49
) M/ {4 l+ e2 ]7 U我估计你肯定哪里出错了，只是你还没发现。
. w$ i* s1 }( f* a, l+ W& b* u9 ]5 i
% R& D, T, h+ Q, G# M方便的话，私信我一个案例文件吧，我具体看一下。

  ]/ b3 X$ [: ?9 S8 Y找到问题所在了——你的词条文件有问题：
9 G* q& z$ s/ k! k. ]# L
如果你使用词条格式2，其分隔符采用的是tab或4个及4个以上空格，因此，你的关键词中不应该出现与分隔符一样的字符，否则就会造成错乱。经排查，你的关键词中有大量的tab分隔符，错误就在这里了，你把这些tab都替换掉，就不会出错了。
如果你不想更改这些关键词的tab键，那么建议你想办法将这个词条格式2，转换位词条格式0，这样，不管其中的内容是什么，都是可以正常处理的。

也可以这么理解，词条格式0的兼容性是最强的，因为它对词条关键词没有任何禁忌。而其他词条格式都会多出一步——将其转换位词条格式0，这个步骤可能会有不少潜在的风险，除非你知道如何排查或避免。
; g' m4 m/ a4 {" [4 z4 ]' U1 Z3 m* l- d

wjl

0 d- V, p/ y* b3 Y% A' O1 ^4 p7 O% b

VimVim 发表于 2020-9-1 01:17
2 J* z& ]* B* s: M! U# T5 g1 H( m找到问题所在了——你的词条文件有问题：

2 K/ M6 F! ?3 A如果你使用词条格式2，其分隔符采用的是tab或4个及4个以上空格 ...

8 h& B* X0 W1 _分隔符如果能支持自定义就好了。我原来使用分号和tab键做分隔符就是因为单个分隔符容易在词条中出现

VimVim

wjl 发表于 2020-9-1 08:27
分隔符如果能支持自定义就好了。我原来使用分号和tab键做分隔符就是因为单个分隔符容易在词条中出现 ...

9 Z; r$ t% {4 i你可以自定义。看core.vim文件，随便你怎么折腾。

wjl

既然程序内部也是先转换为词条格式0，我还是先自己转换词条格式0再使用MdxSourceBuilder吧，以免出现无法预料的问题