相比同类应用，我尽量地在 Time 时间卡的交互体验与视觉设计上做着突破，以让这款应用更贴近实际生活的场景需要，比如：
言简意赅的事件创建
在我们使用 Time 添加事件时，会发现有「倒计日」和「累计日」两种事件的创建入口，这样做的意图在于明确给出用户创建时间卡的类型，让用户能够根据自己的实际需求创建对应的「倒计日」或「累计日」。再交互上采用这样的形式会更为直接，也不会给用户带来太多使用上的选择压力。
轻便快捷的手势操作
Time 在开发过程中，融入了一系列的手势快捷操作。如时间卡的归档和删除只需通过左右滑动即可完成；时间卡的排序，可以通过长按拖拽的方式移动到想要的位置。这些使用场景，其实也是在贴合日常生活中我们使用应用的习惯。这样做直接的结果是，我们使用 Time 的时候，在交互操作上时常会有似曾相识的熟悉感，在体验上也会更为轻便快捷吧。
当前的 Time 一直在遵循「小巧」的原则，所有事件的创建，都是由用户根据生活中的实际需要进行添加，动机是自发的。所以我在想，Time 能不能给用户提供一个类似信息流的媒介，可以为用户找到一个创建时间卡的动机。比如公布一部电影未来的上映时间，用户只需要点击添加按钮，Time 就会为用户自动创建一个对应的时间卡。
游戏难度不高，如果你时常接触这类游戏应该会觉得算是比较简单的一款。每一个关卡的目的是到达房间里的目标点，但是你也可以想办法收集散落在各处的星星（这样会提高游戏难度，因为一旦死亡关卡将会重置），收集的星星可以用于解锁其它类型的史莱姆，获得不同的属性加成。整体算是中规中矩的一款作品，感兴趣的玩家可以在 App Store、Google Play 免费下载。
回归者：0 Returner Zhero
《Returner Zhero》是 3D 科幻解谜游戏「回归者」系列的第二款作品，前作《Returner 77》以其精致的 3D 场景而受到玩家关注。本作依旧延续前作色彩瑰丽、场景壮阔的科幻风格，描绘了一曲令人叹服的太空歌剧。
游戏玩法很简单，玩家只需要点击屏幕就行了。但是悬空的墙壁并不是那么好攀爬，钉刺、电击、加速带等等让你抓狂的陷阱将游戏难度提升到了 S 级。随着游戏进程，你可以解锁更多的可操纵角色，以及看到丰富多变的游戏场景。如果你觉得人生还不够艰难，可以试试这款作品，你可以在 App Store、Google Play 免费下载该游戏。
你可能会感兴趣
「始祖级」多人射击生存游戏《H1Z1》开发商 Daybreak 近日宣布将联手 NantWorks 打造移动平台的《H1Z1》，不过已经有了 PUBG Mobile 与 Fortnite 抢占移动市场，这时候才做出决定会不会有点晚？
网易旗下移动平台大逃杀游戏《荒野行动》宣布将于 2019 年初登陆 PlayStation 4。（保持微笑）
近日，网页版 Microsoft To-Do 更新，新版中加入了颜色分组的功能，它可以让你可以通过颜色来组织任务列表，区分不同的内容场景。此外，新版还加入了「计划」功能，该功能类似于已有的「每日计划」的升级版，允许你进行五天或者更晚的任务规划。
Google 照片推出相册 API，允许第三方应用使用
Google 近日推出了新的 Google 照片相册 API。新的相册 API 允许开发者创建由 Google 照片提供支持的的应用，并通过 API 将照片上传至 Google 相册。新的相册 API 还允许根据内容和类别查找和过滤各类照片，并支持通过 API 添加照片标题、说明、位置等附加信息。Google 照片的相册 API 在 5 月份就加入了开发者预览版，现可供所有人使用。来源
PDF是我们打交道最多的文件格式之一。提到这个格式，即使是对技术并不熟悉的用户，也能说出「通用性好」、「格式不会乱变」这些优点。但同时，PDF 也是让我们感到困惑最多的格式之一，因为与 Word 文档等其他常见办公软件格式相比，PDF 似乎有着太多的「怪癖」，例如复制文字困难、几乎没法编辑等等。PDF 软件数量繁多、质量良莠不齐的现状，也进一步让很多用户无法正确理解和使用 PDF。
然而，事实并非如此。这些问题大多不是 PDF 格式的「缺陷」，而是因为我们在观念上把 PDF 当成了和其他办公文档格式相近的东西，并因此期待 PDF 也具有和后者相似的功能和特征。
尽管 PDF 格式和 Word 格式在实际用途上有诸多重叠之处，但那只是表面现象。从技术角度看，两种格式之间的差异要远远大于 Word 文档和网页之间的差异，甚至还要大于 Word 文档和 Excel 表格之间的差异。
但这并不意味着 PDF 就是一种难以理解的格式。恰恰相反，对大多数用户来说，PDF 可能是他们接触到的格式中最「接地气」、与现实生活最接近的。因为，PDF 与其说是一种数字文档，不如说是实体文档在数字世界中的影像。对 PDF 的操作，很大程度上可以看成对真实纸张的操作，只是操作环境从物理世界换到了数字世界而已。PDF 的创建就是一种虚拟的打印，复制 PDF 文字的过程更像是一种抄写，而 PDF 的编辑实质上是一种涂改。
当然，只给出这样的结论并不足以令人信服。因此，下文的主要任务就是通过回答几个关于 PDF 格式普遍关心的问题，结合 PDF 的结构和语法，解释为什么「PDF 的本质就是数字化的纸张」，从而深化对 PDF 格式的理解。
为什么 PDF 的外观非常稳定？
在我们日常使用的文档格式中，PDF 文件的外观是最稳定的。一经生成，无论在什么操作系统上、用什么软件打开，得到的显示效果几乎总是一致的。相比之下，Word 所使用 docx 格式的保真性就差得多了：哪怕只是换台电脑，显示效果都可能发生了变化，更不要说用不同版本的 Word 或者第三方软件打开了。
PDF 的这种保真性让它广受青睐，但它究竟是如何做到这一点的？PDF 的稳定是绝对的吗？
「打印」出来的 PDF
如果平时注意观察，容易发现各种软件中涉及 PDF 的操作，用词都比较特别。其他格式都是被「新建」（new / create）出来或者「保存」（save）下来的，只有 PDF 是被「导出」（export）甚至「打印」（print）出来的。这些词语并不是随意选用的，它们本身就说明了 PDF 的重要特征：「导出」暗示着文件编辑已经告一段落，而「打印」则更是形象地表明 PDF 的创建是一个「固化」的过程。
为了进一步理解这种区别，让我们来对比一组外观上完全相同的 Word 文档和 PDF 文档。下图中，右侧的 PDF 格式文件是由左侧的 Word 文件导出得到的，两者的内容都只有「Hello world!」一行居中文字。（注：为了避免不必要的复杂性，我们暂时只以英文文档为例。）
一对内容相同的 Word 文档和 PDF 文档
先来看 Word 是如何实现这一版式效果的。用任意解压工具将该文档解开（docx 文件 实质上就是一个压缩包），找到其中的 /word/_rels/document.xml并打开。其中的关键部分如下（代码经过整理）：
请在头脑中想象一下这个过程——是不是有一种强烈的「机械感」？如果说 Word 文档使用的标记语言很像是给人下命令（「这里有一段话，把它用 Times 字体写出来，位置上居中对齐……」），那么 PDF 的语言则更像是在控制机器，定位、调整、落笔、抬起，移动到下一行；如此重复。联想一下，铅字排版和打印机的工作机制不也是类似的吗？可见，用「打印」一词来搭配 PDF 是十分恰当的。
如此对比之下，PDF 显示效果的保真性就容易解释了。虽然 Word 格式使用的语法明显更容易理解，但问题在于不同「人」——不同软件环境——听到同样一段指令，头脑中的反应未必是相同的。「用 Times 字体显示」——哪个是 Times 字体？没有安装这个字体怎么办？「居中对齐」——以什么为参照物居中？怎么计算居中？Word 文档对此笑而不语，把问题留给了软件去思考。正是这种自由裁量的空间为显示效果的差异留下了隐患。
用 Pages 打开 Word 文档出现的字体缺失问题
在 PDF 中，这样的问题就很难出现。与标记语言那种相对的、描述式的标签不同，PDF 语言几乎都是绝对的、指令式的。例如，上面的 PDF 中，文字明显是居中的，但代码中从头到尾没有半个字提到「居中」；相反，它直接指明了文字的坐标。因此，无论什么阅读器读到这份文件，只要根据坐标「照葫芦画瓢」地绘制，一定能得到相同的显示效果。
8 w 1 J [20] 0 d【设置画笔为 8pt 宽、末端圆角、20pt 点状线】200 200 m 200 100 l 250 100 l 【移动到(200,200) 画直线到(200,100) 画直线到(250,100) 】S 【确认绘制】
PDF 外观稳定性的另一个原因是它嵌入了各种需要用到的外部资源。我们注意到，上面的 PDF 在设置字体时，没有像 docx 文件那样直接指定字体名称，而是引用了一个代号般的 /TT1。实际上，/TT1指向的是一个内嵌的字体，存储在 PDF 内部的偏后位置。显示时，阅读器将根据这个代号找到字体，按照其中记载的形状、宽度等信息，将字符「书写」在指定的坐标上——就好比活字排版工按指示从字盘中取出字模，并放在母版上的特定位置一样。相反，Word 文档默认是不嵌入字体的；只要另一台电脑上没有安装用到的字体，或者安装了不同版本的字体，就会导致显示效果的差异。
活字
保真性的例外
不过，PDF 的这种保真性也不是绝对的。尽管 PDF 语句已经非常精确，也不能排除存在不同解读方式的可能。特别是在 PDF 文件本身有瑕疵（例如语法不合规范、资源文件缺损等）时，阅读器就必须「猜测」文件原本的意图，误差也就因此产生了。
例如，下面这份 PDF 格式论文是从中国知网下载的。在用 Adobe 的官方 PDF 工具 Acrobat 打开时，文件基本显示正常。而在用 macOS 自带的预览 app 或 PDF Expert 打开时，就能明显看出显示效果是有问题的——所有的中文都变成了黑体，而不是应有的宋体。（你可能注意到从知网下载的 PDF 经常存在字体显示问题。这是因为它们并非由排版软件直接导出的「一手」版本，而是从私有的 CAJ 格式转制而来的，存在很多兼容性问题。）
其中，Acrobat 是一个非常「仁慈」的阅读器，会尽可能做一些合理推测来修复文件本身的瑕疵。可以看出，它选择了一个类似的字体——同属宋体的 Adobe Song Std Light——来代替这个不存在的 STSong-Light。相反，自带的预览 app 就没有那么多考虑了，它选择直接回退到系统界面的默认字体—— 苹方来显示，于是我们就只能和一片黑糊糊的黑体大眼瞪小眼。而如果用 Acrobat 的修复功能将缺失的字体文件补充进 PDF 后，将会发现预览 app 也能正确显示中文字体了，这印证了我们对问题成因的分析。
为什么 PDF 中的文字经常难以复制？
如果说 PDF 显示效果的稳定是它吸引人们使用的主要优势，那么「文字难复制」一定是它让很多人敬而远之的原因之首。确实，从网页上复制文字的那种方便灵活在 PDF 这里几乎是一种奢望。很多时候，就连第一关——准确选中要复制的文字，都是难以跨越的障碍。
PDF 为什么对复制操作这么不友好呢？换种问法，满足什么条件的 PDF 才能正确复制出文字呢？答案是，PDF 文件的内容、文本的排列方式，以及文本和字体的编码都会影响到文本的复制。另外，阅读器对于复制操作的优化也是不可忽视的。
从扫描版 PDF 复制文本
要把文字复制出来，一个前提是 PDF 中必须真的包含文字。这听起来好像是一句废话，但实践中大多数「文字复制不出来」的问题，原因都是目标 PDF 中根本没有文本。这尤其多见于那些扫描而来的电子书和电子文档；如果不经处理，它们的每一页不过是原始文件的一张「照片」而已，显然无法复制出文字。
当然，扫描版 PDF 是完全可能支持复制的。OCR（光学字符识别）工具可以识别出图像中的文本，并将其写入 PDF 中，使其支持选中和复制；这也是很多收费 PDF 软件主要宣传的功能点。需要避免的一个认识误区是，即使经过 OCR 处理的 PDF，其中的文本也并不是「附身」在原来的图片上的。相反，它们通常被存储在一个单独的文本对象中，与图片中的文字位置一一对齐。只不过由于 PDF 中的文本可以被设置为隐藏，当用户试图选中和复制这些隐藏文本时，看起来就好像是直接在图片上选中和复制文字一样。
经过 OCR 处理的扫描版 PDF 同样可以选中和复制
这就解释了为什么在一些扫描版 PDF 中，文字选中效果看起来是「歪」的；而在另一些 PDF 中，选中和复制操作总是不连续或不完整。前者是因为加入的隐藏文本图层没有与图片上的文字位置对齐，后者则是因为 OCR 识别不全，或者将连续的文本识别成了孤立的文字。
跨行和跨段复制文本
麻烦还远没有结束。即使确认了 PDF 中包含文本，也并不意味着就能把它们原封不动地复制出来。在复制跨越数行乃至数段的大片文本时，我们往往不能得到所预期的完整段落，而是多了一些无用的空白或者换行。例如，在下图所示的复制结果中，PDF 似乎把页面上的换行和连字符照单全收了，即使它们显然不是原文的一部分。同样的问题也会影响到文本搜索，很多 PDF 中，断成两行的词是无法正常搜索的。
读取 PDF 时，阅读器首先从文件头确定文件类型和版本号，旋即跳转到文件尾，获取交叉引用表的位置（以字节位置表示），它进而列出了 PDF 中所有对象的位置。凭借这张表，阅读器就能找到每个对象，解析它们之间的包含和引用关系，并按照其中的命令将文件的全貌绘制出来。
这样的构造对 PDF 的编辑有什么潜在影响呢？可以看出，PDF 的结构是高度固化并且相互依赖的。它就像是一个积木堆，其中的每一块「积木」——PDF 中的一个对象——都不是独立的，而是与四周的其他积木相互支撑。编辑 PDF 文件就如同试图改变一个成型的积木堆：移去或挪动一块积木（对象），周围的木块不仅不会自动补上空白，反而可能因为失去支撑（对象的交叉引用关系）而变形。比如，从 PDF 中删去一段，后面的文本并不会自动调整位置；相反，如果绘制它们的语句引用了被删除部分的样式，这些样式也可能随着删除操作而丢失。
用 PDF Expert 删除一段文字，后面的段落无法自动补齐空隙
而如果要往积木堆上增加一块——往 PDF 中增加内容，面临的风险同样很大。且不论现有的空隙是否允许这么做，你也无法预知剩余的积木块中是否有自己需要的。例如，出于节省体积的考虑，PDF 中嵌入的字体文件往往都是高度「子集化」的，只包含文件中用上的那部分字符。如果准备追加的字恰好不在其列，就很可能引发显示问题。
退一步说，即使编辑操作幸运地没有引发任何问题，它的成本也是很高的。哪怕只是插入一个字母的「微量」编辑，也会导致排在它之后所有内容的地址向后偏移 1 字节，于是依靠字节计数来定位的交叉引用表必须整个重写。假如你的改动幅度更大（例如用了新的字体），就需要靠新增对象来实现，于是其他对象也必须相应更新以反映对象编号的变化。另一方面，从 PDF 中删去内容时，编辑器未必能聪明到把不再有用的对象一并删去。很多时候，这些成为空壳的对象就被「抛弃」在原地，白白占用空间，并且增加阅读器解析文件时的计算成本。
需要加以区分的是，对 PDF 的标注（annotation）操作——包括高亮、下划线、笔记等——不属于「编辑」的范畴。在实现层面，PDF 中的标注是附属于所在页面的子对象，其中记载了标注的类型、位置、形状（如果有）、文本（如果有）等，与存储文件内容的对象相互独立。它们就像是纸上的便利贴，可以随时移除而不留下痕迹。
那作为用户，如果确实遇到编辑 PDF 的需求，应当如何解决呢？
首先，应当考虑是不是真的需要修改 PDF 文件本身。假如你将一份文件打印出来以后发现了错别字，第一反应恐怕是回到电脑上修改、然后重新打印那一页，而不是用胶带粘去错字然后手写。类似地，既然 PDF 文件的本质就是「电子纸张」，如果发现错误，最正确和简捷的做法应该是改动用于生成这个 PDF 的原始文档，然后重新导出一遍，而不是考虑怎么修改 PDF 本身。
即使手上没有生成 PDF 的原始文档，在直接修改 PDF 时也应该尽量控制编辑幅度。因为修改越多，对文件的「污染」就越大，也就越有可能造成格式混乱、体积膨胀等结果。如果要修改的内容确实很多，甚至可以考虑转换/ OCR 为其他格式—编辑文字—导出为 PDF 这样的路径，或许效果反而比直接编辑好得多。
最后，尽管 PDF 对编辑操作非常不友好，但毕竟「事在人为」，不同软件的编辑能力有很大差别。例如，来自第一方的 Acrobat Pro 就明显高于平均水平。根据测试，它不仅能从 PDF 的布局中判断出段落并以此为单位编辑（而不是孤立的文本块），还能在编辑中一定程度上维持原有的对齐方式、段间距等设置。更为「黑科技」的是 Acrobat 的 OCR 功能，它甚至可以做到在识别文字的同时，将文本矢量化后、分离到与背景独立的图层中，从而能增删扫描版 PDF 中的文字。
Acrobat 可以将扫面版 PDF 中的文字矢量化后实现编辑
结语
任何文件格式都有自己最擅长的用途。对 PDF 来说，它擅长的领域就是跨平台交换和文件归档，而那些需要频繁编辑文本内容和版式的应用场景，则是其不能胜任的。只是在日常使用中，我们常常被 PDF 和其他文档格式在外观上的相似所误导，把它用在了不擅长的领域，然后反过来抱怨这种格式在编辑和复制中的「笨拙」。这多少是错怪了 PDF。本文之所以一再将 PDF 类比为实体文档，一方面是为了便于解释技术原理，另一方面也是为了提供一种选用 PDF 格式的标准：适合打印出来的内容，一般也才适合「打印」成 PDF。
理解 PDF 的原理也有助于挑选合适的阅读/编辑工具。如上所述，软件对瑕疵 PDF 的宽容度和修复能力，对文本搜索、复制的识别、优化能力等细节，是最值得重点考察的；这些看似不起眼的功能点对使用体验和工作效率有极大影响。相反，那些频繁被当作营销「亮点」的功能，特别是 PDF 编辑、格式转换等，反而不那么重要。因为 PDF 从结构上就不适合修改，这些所谓的编辑功能很难达到用户的预期，何况还有大量类似于 SmallPDF的免费工具可以满足临时的、精度不高的编辑需求。至于严肃、专业的 PDF 编辑，Acrobat 可能是唯一的选择。
最后需要说明的是，PDF 涉及的技术非常复杂，这篇文章只是从日常使用的角度做了最粗浅的介绍。文中很多地方为了便于理解，采用的解释和比喻是过度简化的。如果对 PDF 格式的原理有进一步的兴趣，建议直接阅读 PDF 的 标准文件。这份标准虽然十分冗长，但并不难读。哪怕只是挑选几个关心的主题来浏览，相信都会对理解 PDF 格式以至排版技术有很大的启发。
此外你也可以直接添加任务到「今日」列表中，这适合当天临时得到且需要当天完成的情况。当然添加到今天视图的任务，也和添加到项目中的任务拥有一样的操作逻辑，即包含了左滑、右滑和点击效果，但菜单选项则略有不同，多了额外的 3 个选项：放到明天做 (Do tomorrow)、移动到未来的某个时间 (Move to future)、将任务放到「接下来」中 (Move to up next)。
闪念胶囊是 Smartisan OS 的灵魂。在 515 发布会中，你会发现无论是「子弹笔记」，还是「发牌手」搜索等功能，都有闪念胶囊的影子。闪念胶囊已经成为了整个 Smartisan OS 的开始——信息输入都是从闪念胶囊开始的。
我们以前的交互逻辑是以应用为中心，首先是打开需要的应用，再输入有关的信息。这样的话，输入的信息难以在其他的应用之间进行传输。但是，Smartisan OS 的闪念胶囊是以信息流为中心，注重信息的输入，应用只是信息的一个入口而已。让信息的优先级高于应用的优先级别，从以应用为中心到以信息为中心的转变，这是交互逻辑上最大的改变。
此外，XS/XS Max 尽管在设计语言上和 iPhone X 一脉相承，但仍然存在两处细微的改动。一是在边框的左下角增加了一处天线开口。考虑到去年 iPhone X 曾经因为使用 Intel 基带机型的网络性能弱于高通基带机型而受到争议，通过增加开口增强信号的举动使可以理解的。尽管新增的天线挤占了底部开孔的空间，由于左下方的开孔本来就是麦克风，新设计并不会对扬声器性能造成影响，唯一的问题是导致了 iPhone 底部的开孔不再对称，不够美观。
Series 4 使用了新的 Apple S4 处理器。除了性能上的提升，S4 芯片最引人注目的特性在于它是 64 位的；这也是我们首次在智能手表上看到 64 位处理器的应用。不过，有迹象表明该处理器仍然运行在 32 位模式下，或许是因为 Apple Watch 较小的内存（S4 的 RAM 容量尚不明确，S3 仅为 768MB）并不需要 64 位的寻址能力，如此升级主要是为了利用 AArch64 架构的指令集优势。
网络支持方面，去年国行 Series 3 的蜂窝版本是「特供」的，与其他任何地区的型号都不相通用。而今年的国行版本则与大多数美洲之外的国家使用同一型号（A2007/A2008），与美版（A1975/A1976）的差别在于多出了对 TD 网络的支持，但至于相互的兼容性则只能等待实际测试。
功能：心电图获 FDA 钦点，多数新表盘仍可用于旧设备
心电图（electrocardiogram, ECG）功能的加入是 Apple Watch 此次发布的最大亮点之一。发布会上，苹果宣布该功能获得了美国 FDA 许可（clearance）的时候，不出意外地收获了一阵欢呼。但网络上随之而来的疑问是：FDA 的许可是否意味着 Apple Watch 具有了和医疗设备相同的性能？「许可」和在其他一些器械宣传中的「批准」（approval）有何区别？
FDA 将医疗设备按照对用户的潜在风险由低至高分为三类，等级越高，合法销售之前需要经过的检验也越严格。Apple Watch Series 4 的心电图功能被归为其中的二类（Class II）——有中等（moderate）风险对用户产生伤害。居于同类的医疗设备还包括电动轮椅和一些孕检器材等。二类设备在上市前须向 FDA 进行售前申报（Premarket Notification）以获得「许可」（clearance），标准是该设备是否与市场上既有设备实质等同（substantially equivalent）。
当然，限于穿戴设备的体积和性能，Apple Watch 的心电图功能必然与专业的医用设备有差距。例如，医院中使用的心电图设备是 12 导联（lead）的——同时在多个部位进行测定，而 Apple Watch 则只是单导联。FDA 也在许可函中明确表示该功能不应用于替代传统治疗方法，也不作为诊断依据。另外，不要忘记这仍然是一项实验性功能，在上市时的系统版本中暂不可用，并且在国行版本中完全不被支持。
Series 4 的另一项功能更新是发布会上提及的多种新表盘。不过，专属于 Series 4 的只是图文表盘和图文模块表盘两种，因为它们更高的信息密度依赖于新设备的高分辨率支持。其他的表盘（水火、烟雾、液态金属、呼吸）由于实际上只是原有动画背景表盘的变种，在旧款设备上仍然可用，只是动画背景被固定在一个圆形边框中，而不是像 Series 4 那样「边到边」。
事件的起因是：发布会后，随着官网页面的更新，不少人发现新 iPhone 名字中的字母「R」「S」都是大写形态，却比旁边的 X 矮了一截。这随即被指出属于所谓的「小型大写字母」；它们一般被用在全大写的场合，通过增加版面错落感，避免连续阅读大写字母的视觉疲劳，提高美观度和可读性。对网页检查元素可以发现，苹果是通过 CSS 的 font-variant-caps属性实现这一效果的。
Big news. Small caps.
这种独特的拼写方式不仅是苹果历史上首次，也给一般用户的输入提出了难题——如何在社交媒体等纯文本环境下输入小型大写字母呢？网络上随即出现了一种「解决方案」：使用 Unicode 中的 ʀ（U+0280 Latin Letter Small Capital R）等特殊字符来代替，甚至有教程一本正经地教人设置文本替换来「快捷地」输入「正确名称」。
这种做法是不值得提倡的。且不论远超必要的输入成本，这种做法还会给文本搜索造成不便（无法通过输入常规字母 S 和 R 搜索到），并且影响字体风格的统一性（大多数字体都不包含这类特殊字符）。从字体排印的角度看，小型大写字母只应在字体支持的场合下启用，使用软件拉伸得来的「伪」小型大写字母是一种适得其反的做法（请联想一下丑陋的中文斜体）。
实际上，苹果似乎暂时自己也没有搞清楚怎么拼对这些名字。产品信息页面和在线商店使用了全大写形式的 iPhone XS 和 iPhone XR（本文采此用例），技术参数页面却又变成了小写字母 s 拼写的 iPhone Xs。权威的用法到底是什么，也许只能等待之后的官方回复了。
