今天在改进 iText 上传前压缩大图的功能。

其中，百度、腾讯、Google 等各家 OCR 服务对上传的图片尺寸都有要求、也都要求对图片进行 base64 压缩。可这要求跟要求可就不同了。

为什么实际大小与简易理解大小不一致呢？

• 首先，base64 压缩后，得到的大小会增加约 1/3
• 进一步，base64 是使用字符串表示的。那么，一个字符串如 ‘a’ 占几个字节呢？看起来百度是使用 2，腾讯是使用 1
• 综合起来，就是上面看到的缩水版大小
• 另外，百度要求图片最大分辨率为 4096 * 4096；而其他 2 家则无此要求

既然 base64 会带来计算上的麻烦，为什么不直接使用解压后的图片大小呢？没错，Google 就是这么干的。你无需考虑 base64 带来的尺寸增加，也无需考虑一个字符串到底占几个字节，只要原图是 4 MB 以下即可

从这一点上看，服务接口的素质（公司的节操）顺序为：

Google > 腾讯 > 百度

我自己有写文章的习惯；尤其，发布一款产品后，我会写些长文，记录产品诞生的整个过程。例如，我之前写的：

• 《Mac 开发的神秘面纱》
• 《Klib 到底赚了多少钱？》
• 《在 iPic 周岁时，说说这款让我骄傲的产品》

这次，有朋友提：干嘛不在 GitChat 等类似的平台，开个 Live 或者文章付费阅读？我想想也是，既能带来点收入，还能增加点曝光，对自己的品牌建设也有一定的好处。

于是，就有了《如何独立开发一款 macOS 应用：从概念到上线》

在这场 Chat 中，我将详细为你介绍：

• 这个点子是如何诞生的？
• 如何验证这个点子是否为真实需求？
• 如何获取第一批用户？
• 国内、国外的 OCR 服务各有何特色？
• 识别后的文本，应如何优化排版？
• 形成产品时，如何取名、如何设计 Logo？
• 截图应用要上架 Mac App Store，有哪些限制？
• 产品发布后，如何进行宣传？
• …

第一手、最新鲜的细节，仅此一家；
别的产品，你绝对无法了解这样的细节。

等你来。

听「盒马生鲜」已经很多次了，今天终于去了一次。

其中的环境是不错，但也没到非常棒的程度，可能是人多使得体验下降。东西怎么样我还真不敢说，因为要去别的地方，并没有在那里吃或者买。

关键，我最大的感触是，有了「马云开的」这个头衔，就使得这家店有了至高的信任背书、让人无比羡慕的流量，进而有无数的多的口口相传。

有品牌，之后的事就好做很多。可，品牌并不好做。不过，还是要做品牌，越难，才越能突显出价值。

今天，找了一天如何优化 iText 识别文本的排版。其中，在 GitHub 上找到 2 个很有用的东西：

• 译文排版规则指北
  • 这是稀土所翻译的文章排版的规则，比如「中英文之间需要增加空格」，方便自己知道，正确的排版应该是什么样。
• typeset
  • 一个基于 Python 的开源项目，自动修正中文、英文、代码混合排版中的全半角、空格等问题。

这两个分享，一个告诉我应该做成什么样，一个告诉我该怎么做。特此感谢。

正是这样的分享，让我们可以不再重复花时间研究别人已经研究过的东西，更快地做出更好的东西。特此致敬。

我也会在合适的时候，开源自己的产品、或者产品中的模块，比如我之前开源的 IAPHelper

昨天，大体完成了 iText 识别文本后的段落识别。今天，本打算再稍微改进一下。没想到，又折腾了一天。

并且，还有不少已知的问题。哎，不打算改了，因为永远也改不完，还是先做其他事情的吧。

其中有一点，如果先写好单元测试的机制和案例，能省不少时间。

另外，今天还尝试着把应用提交到 App Store 了，主要是想验证下，当前截图的方式能否上架 App Store，先祝自己好运。