原笔迹手写保存生成 svg 数据,并将 svg 保存为 pdf 格式

有个朋友提了一个需求,将签名数据生成 svg 数据,并保存为 pdf,传送到后台。

初步分析了一下,难点在于

  1. svg 的生成
  2. pdf 的生成。

首先对 svg、pdf 的文件格式进入了初步的了解。尝试将笔迹生成 svg 格式,然后再将 svg 转化为 pdf graphic command,再将这些 command 转化为 pdf 文件。

相对之前对 svg 有所涉及,pdf 方面的入门门槛更高一点。好在并不需要实现很复杂的功能。首先通过 mediabox 定义页面的大小,然后通过对颜色配置的学习,实现了对笔迹颜色的支持,最重要的是,用过对 curv path 的格式规范的学习,实现的笔迹笔锋和压感的效果。

最后,让我们来看一下效果(关键是 svg 和 pdf 是矢量图,放大不失真):

原笔迹控件原始效果:

生成的 svg 数据的效果:

继续阅读原笔迹手写保存生成 svg 数据,并将 svg 保存为 pdf 格式

App隐私政策

本软件尊重并保护所有使用服务用户的个人隐私权。为了给您提供更准确、更有个性化的服务,本软件会按照本隐私权政策的规定使用和披露您的个人信息。但本软件将以高度的勤勉、审慎义务对待这些信息。除本隐私权政策另有规定外,在未征得您事先许可的情况下,本软件不会将这些信息对外披露或向第三方提供。本软件会不时更新本隐私权政策。您在同意本软件服务使用协议之时,即视为您已经同意本隐私权政策全部内容。本隐私权政策属于本软件服务使用协议不可分割的一部分。

1.适用范围

a)在您使用本软件网络服务,本软件自动接收并记录的您的手机上的信息,包括但不限于您的健康数据、使用的语言、访问日期和时间、软硬件特征信息及您需求的网页记录等数据;

2.信息的使用

a)在获得您的数据之后,本软件会将其上传至服务器,以生成您的排行榜数据,以便您能够更好地使用服务。

3.信息披露

a)本软件不会将您的信息披露给不受信任的第三方。

b)根据法律的有关规定,或者行政或司法机构的要求,向第三方或者行政、司法机构披露;

c)如您出现违反中国有关法律、法规或者相关规则的情况,需要向第三方披露;

4.信息存储和交换

本软件收集的有关您的信息和资料将保存在本软件及(或)其关联公司的服务器上,这些信息和资料可能传送至您所在国家、地区或本软件收集信息和资料所在地的境外并在境外被访问、存储和展示。

5.信息安全

a)在使用本软件网络服务进行网上交易时,您不可避免的要向交易对方或潜在的交易对方披露自己的个人信息,如联络方式或者邮政地址。请您妥善保护自己的个人信息,仅在必要的情形下向他人提供。如您发现自己的个人信息泄密,请您立即联络本软件客服,以便本软件采取相应措施。

原笔迹手写–圆珠笔效果

圆珠笔跟毛笔效果,还是有挺大的区别的。

首先,圆珠笔是硬笔,笔尖有滚珠,硬尖,书写时没有很明显的提、按动作,书写快速,流畅。

所以笔锋变化不能太大,效果也必须有更加笔挺,硬朗的感觉。

下面是我实现的效果,大家觉得如何?

自我感觉笔锋变化还可以再小一点,这个更倾向钢笔了。

SeetaFace2AndroidDemo 扩展,支持 arm64 架构

最近在研究基于 Android 平台的人脸识别,seetaface2 开源算法是知名度比较高的一个,github 上有比较完善的代码,但是推荐的 Android demo 只支持 arm32 平台,研究了一下,编译了 arm64 位的库,方便在目前的主流手机上进行测试。在这里记录一下,有兴趣的可以 github 查看,地址如下:

https://github.com/kevinems/SeetaFace2AndroidDem

Readme:
这是中科视拓开源项目SeetaFace2的android示例

由于模型文件较大,需要用户自己去下载然后放到app模块的assets目录下,或者/sdcard/seeta/model目录下。 记得修改一些环境变量为你自己的配置环境,如ndk、cmake等,祝好运。

====================================================

kevinems: 在原作者的基础上,修改如下,具体可以查看修改记录:

  1. Android Studio 4.0 上编译通过。
  2. 使用重新编译的 seetaface2 的库,并支持 arm64。(原项目没有提供 arm64 库,所以在目前的主流手机上都跑不了)
  3. demo 修改为使用后置摄像头。

Android apex 学习总结

最近对 apex 文件进行了大致的了解,其中主要涉及到安全方面的学习,在这里跟大家分享一下:

  1. apex 是什么?
    Android Pony EXpress (APEX) 是 Android 10 中引入的一种容器格式,用于在较低级别系统模块的安装流程中使用。此格式可帮助更新不适用于标准 Android 应用模型的系统组件。一些示例组件包括原生服务和原生库、硬件抽象层 (HAL)、运行时 (ART) 以及类库。
  2. apex 文件的构成
    apex_manifest.json, AndroidManifest.xml, apex_payload.img,apex_pubkey
    其中我们需要关注的是 apex_payload.img和 apex_pubkey。
    apex_payload.img 是由 dm-verity 支持的 ext4 文件系统映像。各种原生常规文件包含在 apex_payload.img 文件中。
    apex_pubkey 是用于为文件系统映像验签的公钥。
  3. apex 如何生成?
    apex 在 Android 源码编译,需要进行相应的配置,然后编写相关的模块编译文件 Android.bp,最终编译生成 unflatten 的 apex 文件。
  4. apex 文件如何安装?
    通过 packageInstaller 或者 adb 等安装工具安装。
  5. apex 如何验签?
    apex 有两层的签名,第一层,首先 apex 其实也是一种 apk 文件,所以系统会对 apex 整体进行一次签名,签名和验签过程与 apk 一样。
    第二层,apex 中 apex_payload.img的 vbmeta 描述符中包含哈希树,通过 dm-verity 来验签。/system 分区下的 apex 文件通过 dm-verity 保证安全;/data 中的 apex 文件在启动时, 由 apex 服务来进行验签,验签原理与 dm-verity 一致。
  6. 我们的系统支持 apex 更新吗?
    目前 msm8937 的 sdk 中并没有启用 apex 更新功能。启动这个功能需要相关的配置,并重新编译系统。
    而添加支持的方式也很简单,在 {device.mk} 中添加一下语句,同时配置各个服务的 rc 文件,使服务支持 apex 更新。
    $(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)
  7. 供应商系统有必要启动 apex 更新支持吗?
    个人认为没必要。apex 目前支持的更新模块主要 Google 核心运行时库,而这些更新更多是由 Google 来做支持。

读书笔记:深入理解Android卷I

闲来无事,重新系统地学习一下 Android 系统的整个框架,《深入理解Android卷I》这本书之前貌似有看过,但是那时对 Android 的理解尚浅,有很多地方都没有理解,现在重读,相信一定能对 Android 系统原理有更加深入的理解,“学而时习之,不亦说乎”。

书籍的具体章节,这里就不重新码字了,有兴趣的可以自己看看。这里只是记录自己读书的一些新的发现以及心得。

虽然这本书的内容是居于 Android 2.2 的,但是 Android 的很多编程理念,原理还是相通的。

继续阅读读书笔记:深入理解Android卷I

光大银行惊现原笔迹手写控件

前两天去光大银行办理业务,签字的时候,光大银行用的是手写签字板。我签字的时候,发现光大银行的手写签名的效果还是挺好的啊,跟我的手写控件的效果有得比啊。于是认真观察一下,哇,这不是跟我的手写控件的效果一模一样的效果么?这笔锋,这流畅度,这搬圆滑的曲线,真的很像很像。

可惜那时没有拍个照片,回来好好对比。后来想想的确有可能是我的手写控件,因为之前的客户有提过他们会给各个银行提供手写板方案,所以很有可能是客户把这个手写控件应用到银行的签名系统了。


原笔迹手写控件还可以这样玩–绣花机

更多内容,可以查看相关文章:原笔迹手写技术与智能绣花机的第一次亲密接触

以下是原笔迹手写控件在绣花机上的实例应用,实例中的手写效果没有使用压感屏,如果配合电磁屏的平板设备,效果会更好。


Android 9.0 系统开发要注意的事项

如果说 5.1 到 7.1 是一道小坎。那 7.1 到 9.0 就是一道大坑,有很多需要注意的问题,下面简单记录一下。

1. 编译

编译工具链需要使用 64 位的,NDK, JDK 需要使用 64 位的,前期的 buildroot 集成的那些工具,也要更新为新的 64 位的,不然会出现各种奇怪的编译问题。

还有就是新的编译框架 NINJA。

之前有提过,7.1 有启用过 jack,但是现在 9.0 上已经完全看不到 jack 了。

8.0 开始,Android 引入了 Android.bp 来代替之前的 Android.mk。而 Android.mk 也同时支持,但是相信以后的版本,mk将会慢慢消失(所以我们要开始学习 bp 文件的编写,bp 文件的编写,会更加简单和明了)。

我们需要大概知道,编译系统会通过 soong 将 Android.bp 转化成 ninja 文件;所有的 makefile(mk文件)也会转化成 ninja 文件,然后两个 ninja 文件合并成一个文件,最终的编译,就是依赖这个 ninja 文件。

至于编译系统ninja,简单来说,就是一个专注编译速度的编译系统,更多资料可以参考 https://ninja-build.org/

继续阅读Android 9.0 系统开发要注意的事项