发布网友 发布时间:2022-09-25 19:48
共1个回答
热心网友 时间:2023-09-20 20:15
我为什么要开启这个系列,努力试着从源头开始,用 PDFium 制作一款阅读器?有人喜欢问这个做了有什么用,这个是唯一的吗?
当然不是唯一的,底层技术更不是我的。不过我认为在维护者的推动下,PDFium 越来越完善,功能越来越多,不真正拿来做些什么实在是可惜了。另一个重要原因则是,其他APP要么臃肿或者简陋,要么用着磕手、滑动卡顿、误触频发,而且大多还不免费。( 更正,近年来倒是多了好多免费的PDF阅读器 )
目标期望:
热身运动:当检测到单击( GestureDetector )时,若点击处存在超链接,则打印出超链接的对象。
头文件:fpdf_doc.h
需要将屏幕坐标转换为页面坐标,然后再次在native层转换为所谓的user space、page space。别问我那是啥我也不知道。不过在论坛提问后,有人替我指出了相关文档所在,有时间去看看!
屏幕坐标:[event.getX(), event.getY()]
页面坐标:先前提过将整本PDF当作一张超级大图,subsampling-scale-imageview 有一系列的 viewToSource 坐标转换方法。屏幕转换得到 source 坐标后,减去点击页面的左上角坐标,就是页面坐标。
原始页面坐标需用 FPDF_DeviceToPage 再次转换,才能传给FPDFLink_GetLinkAtPoint,获取坐标处的链接指针。
超链接对象统一返回字符串,可以是Uri地址,也可以是页码 @页码 。
热身运动2:在单击处获取一个英文单词或者汉语词组,需要用到安卓的 BreakIterator。
头文件:fpdf_text.h
首先实现 nativeGetCharIndexAtCoord 方法,获取单击附近的文字索引,需进行同样的坐标转换。
若返回的文字index大于等于零,则此 index 指向该页面全部文本当中的一个字符。全部文本用 FPDFText_GetText 获取(实现 nativeGetText):
接下来就可以用 BreakIterator 分词了:
与绘制PDF本身差不多,不过 bitmap 换成 rect 而已。用到的API依次是FPDFText_CountRects、FPDFText_GetRect。
直接将选框覆盖绘制在前。若要绘制在后面的背景上,就需要三层透明视图了,那么加载铺块和缩略图的时候就要用透明色清空 bitmap,页面的白色背景等也需要另外绘制(Google PDF Viewer应该就是这样,还给背景加了阴影)。这些较为复杂,到时候再说。
有个问题可能需要解决:同一行的选框,部分没有合并。
都是小事儿,暂时不在这上面花时间。
之前做过类似的事情,将普通 TextView 自带的文本选择功能禁用了,然后用API自己做出一个来,包括单击选词,长按托选,放大镜等等。所以相关的内容还是熟悉的。
绘制 Selection Handle 可以用 AppCompat 支持库中的图标资源:
控点的触控操作也很简单,在 Action_Down 中检测落点是否在其中一个 handle 内。若是,则在 Action_Move 中一边移动该 handle,一边检测新的字符索引,作为文本选择的新边界。
由于PDF的复杂性,页面上的字符索引可能间杂排列,比如头一段开头是100,下一段开头50,再下一段150。这就造成先前简单的选择系统“失效”了:
没什么解决方案,API 就这么点。而且,静读天下、Google PDF 查看器都是这样的,唯有 ezpdfreader 没有这个问题。
热心网友 时间:2023-09-20 20:15
我为什么要开启这个系列,努力试着从源头开始,用 PDFium 制作一款阅读器?有人喜欢问这个做了有什么用,这个是唯一的吗?
当然不是唯一的,底层技术更不是我的。不过我认为在维护者的推动下,PDFium 越来越完善,功能越来越多,不真正拿来做些什么实在是可惜了。另一个重要原因则是,其他APP要么臃肿或者简陋,要么用着磕手、滑动卡顿、误触频发,而且大多还不免费。( 更正,近年来倒是多了好多免费的PDF阅读器 )
目标期望:
热身运动:当检测到单击( GestureDetector )时,若点击处存在超链接,则打印出超链接的对象。
头文件:fpdf_doc.h
需要将屏幕坐标转换为页面坐标,然后再次在native层转换为所谓的user space、page space。别问我那是啥我也不知道。不过在论坛提问后,有人替我指出了相关文档所在,有时间去看看!
屏幕坐标:[event.getX(), event.getY()]
页面坐标:先前提过将整本PDF当作一张超级大图,subsampling-scale-imageview 有一系列的 viewToSource 坐标转换方法。屏幕转换得到 source 坐标后,减去点击页面的左上角坐标,就是页面坐标。
原始页面坐标需用 FPDF_DeviceToPage 再次转换,才能传给FPDFLink_GetLinkAtPoint,获取坐标处的链接指针。
超链接对象统一返回字符串,可以是Uri地址,也可以是页码 @页码 。
热身运动2:在单击处获取一个英文单词或者汉语词组,需要用到安卓的 BreakIterator。
头文件:fpdf_text.h
首先实现 nativeGetCharIndexAtCoord 方法,获取单击附近的文字索引,需进行同样的坐标转换。
若返回的文字index大于等于零,则此 index 指向该页面全部文本当中的一个字符。全部文本用 FPDFText_GetText 获取(实现 nativeGetText):
接下来就可以用 BreakIterator 分词了:
与绘制PDF本身差不多,不过 bitmap 换成 rect 而已。用到的API依次是FPDFText_CountRects、FPDFText_GetRect。
直接将选框覆盖绘制在前。若要绘制在后面的背景上,就需要三层透明视图了,那么加载铺块和缩略图的时候就要用透明色清空 bitmap,页面的白色背景等也需要另外绘制(Google PDF Viewer应该就是这样,还给背景加了阴影)。这些较为复杂,到时候再说。
有个问题可能需要解决:同一行的选框,部分没有合并。
都是小事儿,暂时不在这上面花时间。
之前做过类似的事情,将普通 TextView 自带的文本选择功能禁用了,然后用API自己做出一个来,包括单击选词,长按托选,放大镜等等。所以相关的内容还是熟悉的。
绘制 Selection Handle 可以用 AppCompat 支持库中的图标资源:
控点的触控操作也很简单,在 Action_Down 中检测落点是否在其中一个 handle 内。若是,则在 Action_Move 中一边移动该 handle,一边检测新的字符索引,作为文本选择的新边界。
由于PDF的复杂性,页面上的字符索引可能间杂排列,比如头一段开头是100,下一段开头50,再下一段150。这就造成先前简单的选择系统“失效”了:
没什么解决方案,API 就这么点。而且,静读天下、Google PDF 查看器都是这样的,唯有 ezpdfreader 没有这个问题。