抠图太费时间,不如虚拟词表图片词典实用

哈哈,坚决等楼主的EXE,坚决不看楼主的PPT。
楼主加油,哈哈

之前想的一個不太完整的模型,沒有實際套用過,或許對 IBHI 兄可能有用吧

https://www.pdawiki.com/forum/forum.php?mod=viewthread&tid=42901&extra=

請賜教 css & html - 词库制作交流区 - Dictionary-Making - 掌上百科 - PDAWIKI - Powered by Discuz!

此處 B 為擺圖的地方
<div style="background-color:lightblue;width:93vw;">B</div>

B ==><img class="pic" src="xxx.png">

<div style="background-color:lightblue;width:93vw;"><img class="pic" src="xxx.png"></div>

本想套用於此帖的詞典…一直沒空再做更多套用實驗

此帖有大至上的解釋,在此標題後
粗略定位 以下可能並不實用僅是一個想法

基本概念上是先獲得匹配單詞的%,再以幾個特定位置的百分比求得平均值,和標準異差,借由標準異差去估出一個空間,此空間因是用標準異差去算的,因此會有機率的比較可能的區域的可能性,然后再去得到一個線性擬合的公式,然后求解其每個單字的跨越區域
您若對 excel 和統計有些許概念應該就不難理解,道理不難,略為繁鎖
作用只是把百分比再轉換成區域而以,或許是模型本身也粗糙,精度差很大,感覺不是很滿意,也就純試驗玩的

洋和尚,都猜到是仁兄!哈哈!见谅,因太忙你那个东西我有时间再弄。
你问我懂不懂EXCEL脚本编程,遗憾我一窍不通。但要问概率统计,以前连随机过程都学过的哈。不过搞不清这和粗略匹配有半毛钱关系?

啥叫“粗略匹配”?也许你和我的理解是不一样的?

我所说的粗略匹配,是说首先搞出每一页的首尾词条索引,然后从虚拟词表中一次取一个词出来看它落在哪个页面的首尾词之间,则那个页面被认为是收录了该词条,于是将该页面写到该词条的MDX中!如果取出来的词不落在任何一个页面首尾词区间中(按字母顺序排序的话,它是某页尾词和相邻下一页首词之间的一个词),则认为该词未被词典收录而丢弃它。
想想,这不就是我们人工查阅纸版词典的过程吗?
显然,这样做能确保的仅仅是:如果该词真的被词典收录了,那么它一定在该页面上而不会在其他页面上。但,显然,若该词典根本未收录此词条,该词条将被错误加入,未收录该词条的页面将被展示。但是,只要你查的词是比较常用的词(我研究过GRE水平也就13000左右词汇量,大部分词典都收得比这个多),而该词典有极大概率(99%)收录了该词,那么这样处理仍旧有非常现实的意义,这远比花九牛二虎之力几十小时甚至上百小时去折腾精确词条匹配甚至抠图的图片版词典有意义的多。

绝大部分词典都在每页页眉上提供了该页单词索引,有索引的词典里面,大约一半是每页都提供首尾词;另一半是偶数页提供首词奇数页提供尾词,这种的需要人工补录索引。但如果要求不高,不补直接拿来用也可以,只不过同时显示两页出来,人工在两页里找所查词条。

做这种粗略匹配词典,先OCR出来这些索引,再选用适当虚拟词表,然后用我的工具软件,真的是很快,即使2000页词典也应该不会超过一个小时。想想这是一种多高的产出比,我相信一旦退出这种实用工具,图片词典会大规模出品的!

图片词典的春天就要来到了!

4 个赞

lbhl 兄,那只是當時想個粗略定位,模型很粗糙,只是參考,在下會再想想比較可行簡單點,容易計算點的方法來定位
有關粗略匹配,你的想法沒錯,哪個單詞將會座落於哪一頁是跑不掉的,就是如此而以,仁兄完全理解無誤
粗略定位的想法只是再延伸而以,因模型粗糙不佳,也不太好解釋…,待後續在下再想個簡單點的模型來套看看

不“切图”的话,用单页 PDF,比用图片(位图)要好。一些 PDF 经得起缩放,可以查找、复制文本;扫描件 OCR 之后,也可以查找文本。

Adobe 有给网页嵌入 PDF 文件的 API:

1 个赞

Lurker 兄,所言及是呀!但似乎也可以切完圖後再轉成 PDF 後 OCR ,製作的選項和方法層出不窮,但若單字有音節,OCR後依然是繞不過的問題,除非校對中去除音節,否則查找也是會有困難的,在 PDF 上是如此,網頁崁入也一樣

如果此PDF词典原本就是文本版的那都可以制作出文字版的MDX了,怎么也比图片版或者你说的将词典软件当PDF浏览器用强;
我的即将竣工的图片MDX制作工具本来就支持在词典软件中让用户实时调整缩放图片大小(而不是退出词典软件先去修改CSS)。
至于OCR成双层PDF之后在词典软件里打开可以查找复制文本倒是一个优势,谢谢提醒!但是一则复制文本以及搜索某本具体词典(而不是所有打开的词典)中一个关键字,并不常用,只是查阅单词的一个很次要的附带功能,且;二则OCR有很多错误这些文本肯定有乱七八糟的东西。
最后,词典软件提供的环境不是一个标准的浏览器,在很多时候对javascript的支持远不如标准浏览器,给编程人员造成麻烦,而且调试起来也很不方便。那个API有可能受限在词典中无法正常运行。我有空试试吧。

在词典软件中用 Javascript直接打开PDF还可能有一个致命的问题:扫描版词典体积太大,词典软件可能会卡死,尤其是有多部这样的PDF图片词典要打开的时候。我刚才做了个实验,用CHROME打开一个1.5GB的PDF,如果拉动滚动条太厉害想跳过好多页往下看明显卡顿了,在GoldenDict这种词典软件里估计要彻底死掉的。

大致看了一下ADOBE的那个API,貌似没有打开PDF时跳转到指定页面的方法可以调用,就是说需要人工输入跳转到的页码。如果真是这样,用这种方法当词典查就没戏了,最多只能在词典软件里通读该词典,那还不如用acrobat reader算了,没有实用价值。

IBHI 兄,方法錯誤,一次打開1.5G能不卡嗎?哈!哈哈,怎不每頁一個檔案
https://www.pdawiki.com/forum/forum.php?mod=viewthread&tid=39764

肯定要先 split(切割)成一页页的 PDF 啊,每次只显示“当前页”,点击触发“上一页”和“下一页”。

拿PDF当查询有很多缺点:
无法和其他词典联合查询;
无法自动简繁体转换查询;
无法使用构词法查询;
……

我自己的实践,那些收集来的PDF几乎都是压箱底,打开次数从下载开始到现在几乎为0,偶尔有几次的,还是在确认版本、转换格式之类的整理工作,而不是查询之类本身。

2 个赞

哈哈和尚所言极是!我脑袋拍砖了没想到每页一个PDF当一个个图片用了。那这种同PDF格式查看的图片词典方案有可取之处了,有时间做做看!

1 个赞

根据英语词汇26个字母排列方式可判断检索词是否落于某页首、尾词之间。如果是汉语词典,要怎么对检索词定位?

Johnny_Van 兄,漢字只能按照字典本身的排序,有的是 部首 + 筆畫 ,需要已有張表是按部首 + 筆畫來排序,此匹配應該是蠻複雜的
詞組很多是按第二個字,橫,豎,撇…
對照起來更是麻繁了

也有按漢語拼音, 是相對簡單,但如同上面,省不了工

2 个赞

IBHI 兄,在此豬羊變色的重大時刻…小弟再次呼喻仁兄,不要再殺豬公了…
https://forum.freemdict.com/t/topic/5611/63

请问软件有头绪 了吗?:eyes: