现在,印度人口为13.24亿,人们使用移动电话,例如马拉扬语作为母语(3800万)比瑞典语(920万)使用的语言更多,为此,我们可以在Readium CSS中提供良好的支持。
换句话说,如果我们看一下原始数据,情况将变得非常棘手,因为我们显然希望提供我们所能获得的最佳支持,并且我们不一定知道对这些语言的支持可能会影响很多人。
例如,您能否确定您正在使用或开发的搜索库是否可以按预期管理CJK,阿拉伯语和印度语? Unicode规范化,零宽度非连接符和零宽度连接符(非打印)字符,标点符号和符号以及从右向左的方向都是您计划在国际上进行测试的较早项目。在某一点。
让我们看一下更复杂的语言:日语。 对于日语,我们必须支持垂直书写。 但这是故事中最简单的部分……

您是否知道日本出版商有自己的印刷规则,代表其品牌,因此行调整成为一个超级复杂的问题?
说到这一点,阿拉伯语-波斯语脚本有一个称为“ Kashida伸长率”(کشیده)的概念,这是Web浏览器尚不支持的一种证明。

最后,我们甚至不得不禁用某些用户设置,例如word-spacing和word-spacing因为它们不能应用于某些语言! 然后是可访问性,而我们所掌握的信息很少-它恰好是EDRLab的核心任务之一。 目前,我所知道的是,我们可能想禁用阿拉伯文字中的连字,以使有阅读障碍的人更容易使用它。
字体很棒
我学到了很多关于非拉丁语言的文本布局要求的知识,这真是令人难以置信。
这是到目前为止我已经阅读的文本布局要求的列表:
- 日语文本布局要求;
- 中文文字排版要求;
- 韩文(韩文)文本布局要求;
- 阿拉伯文字要求;
- 希伯来文字排版要求;
- 印度文字版式的要求。
老实说,这真的让您感到谦卑。 坦率地说,您在拉丁语言中遇到的所有问题与某些语言必须处理的问题相比,都没有什么。
例如,正交音节边界是浏览器在印度语中应使用的参考。 有时他们没有。 如果浏览器不能很好地包装或连字,您将如何应对? 或:first-letter无法为您的脚本选择正确的字符组?

还有悬挂式标点符号,在某些西方语言中纯属美感,但在某些其他语言中却可以形成或破坏和谐关系,例如,日本版面(Kihon-hanmen)依靠重力。
事实上,如果您认为拉丁文字排版很难,可能是您从未在CJK中遇到过红宝石注释。 Ruby(ruビ)是一个非常复杂的系统,我什至无法理解其所有细节。

我也无法理解阿拉伯语中不是连字形式的连接形式的所有特质。 而且我刚刚开始熟悉CJK中书写方式( horizontal-tb / vertical-rl )所需的印刷调整。
至于诸如Warichu (割注)之类的特殊印刷功能,这是一种内联注释,其中文本在两行上运行,我一直想知道如何利用CSS提供的现代规范来实现这一点。 因此,国际化无疑使我保持头脑,并提供了一些意想不到的空间来锻炼CSS肌肉。

这是一个艰巨的挑战,但我喜欢这个。 我一生可能无法阅读,书写和说这些语言,但是字体印刷至少是我们可以共享的一种通用语言。 发现这些新概念真是太棒了,因为我现在可以从一个新的令人兴奋的角度看到母语的排版。
如果排版仅是一组规则,并且您最近一直在以自动驾驶模式进行操作,那么我只能建议您阅读上面列出的要求。 您将有机会获得一块新的画布,在该画布上,您可以通过打破迄今为止一直遵循的规则来尝试新方法。
碎片是网络尚未解决的问题(尚未)
在电子书领域,人们(无论是作者还是用户)都希望分页浏览。 如果您查看EPUB / Kindle文件,则可以清楚地告诉作者设计CSS时将假定分页内容。 而且,如果您未在应用中提供分页功能,那么很多用户可能甚至根本不会考虑对其进行测试。 别忘了电子书不是长篇内容,而是超大型长篇内容,因此某些用户希望将其分成多个页面。
而且,我们经常会忘记一个技术约束:eInk。 其超慢的更新速度使滚动确实让人感到痛苦,因此将内容分割成屏幕(页面)是我们目前唯一可行的选择-不幸的是,在讨论如何革新电子书时,人们常常忽略了eInk,尽管它是一个重要的基石这个行业 至少值得一提。
las,国际化在那里带来了很多问题。 有趣的是,看看现有的阅读系统针对这些问题的解决方案。
由于在实践中没有什么要讲CSS的内容,因此我们使用多列来分割内容。 当前,CSS multicol实际上是唯一在Web浏览器中使用分段的跨平台规范。 在某个时候,我什至发现CSS区域可以被视为Blink / Webkit中列的超集。
问题是列轴取决于writing-mode文档的使用。 例如,在vertical-rl中,列将自动vertical-rl在彼此的顶部(y轴),而不是彼此相邻(x轴)。

信不信由你,但苹果公司通过在Safari 7中稍微扩展multicol规范来解决此问题,以便在iOS上创建分页API。 综上所述,您可以通过在Safari中使用-webkit-column-axis来强制设置列轴(此处是您必须在Safari中打开才能演示其运行情况的演示)。
不幸的是,Chromium于4年前将其删除。 公平地讲,CSS区域在当时仍然是一件大事,而分页溢出旨在解决此类问题。 Blink只删除了CSS区域,Opera的页面溢出的实现在很大程度上依赖于CSS区域……今天,我们什么都没有了-有趣的故事:如果您尝试在Chromium(内部版本251715)中overflow:-webkit-paged-x paged overflow:-webkit-paged-x ,其中-standard -webkit-column-axis属性仍然受支持,您将获得所需的结果。

结果,我们需要通过拥抱y轴并相应地调整页面前进方向来作弊:当您向右或向左滑动/点击时,页面会向上或向下移动。 这意味着除非我们在iOS / Safari上使用非标准的-webkit-column-axis CSS属性,在Windows上的MS Edge中使用CSS Regions,以及在其他平台上使用JavaScript中的渲染引擎,否则我们无法进行垂直书写的扩展。
不用说CSS Houdini可能是电子书社区需要解决的用例零散问题的缺失部分。 但是,实施标准的column-axis属性可能会在近期内帮助解决90%的用例。
最好的
显然,就电子书而言,CSS只是国际化难题的一部分。 整个框架都会受到影响(元数据处理,格式转换,页面进度,用户界面,应用功能等)。
我们可以实施基准,但需要专业知识才能使国际化达到最佳状态。 我们必须选择每种语言可以找到的最佳字体,我们需要对文档和样式表进行审核,在遇到极端情况时必须做出明智的决策,依此类推。

如果您精通这些语言或使用这些语言进行Web开发/设计,那么您可能会知道我们目前无法掌握的许多细节,以及获得特殊印刷功能的CSS技巧。 您的知识是无价的,并且绝对可以帮助我们创建从巴黎和莫斯科(Москва)到东京(东京)和加德满都(काठमाडौं)所有用户都会喜欢的阅读系统。
如果您想提供帮助,请随时关注我们的本地化问题或本文的评论,或者在Twitter上对我进行ping操作。
网路很美,让我们将这本电子书CSS参考书对世界各地的使用者来说都很棒。