FR: Japanese vertical formatting (tategaki) support #11469
Comments
|
Support for vertical text is unfortunately unlikely to show up soon. You might be able to use a program like calibre to convert such EPUBs to PDF if desired.
|
|
Perhaps the paragraphs wouldn't even need to be render vertically with css/html. Maybe, we could just have the engine rotate the font, so that it is sideways. Then, we could rotate the entire view and—viola, vertical text. We might need to rotate the UI as well to maintain the illusion of the correct orientation, though. To see what I mean, pay attention to how Moon+ Reader on Android handles vertical text. Change the app language to Japanese and turn on vertical text. It just rotates the font, basically. The only thing the app forgets to do is rotate the UI. |
And it doesn't look completely horrible? You can probably experiment with some custom font in that case. Chances are they already exist. |
|
That's what I was going to suggest: making your own custom font. OpenType fonts are very powerful, they can have some rules (and code maybe) to do stuff to their glyphs. I have no idea how this works in OpenType and what tools to use - but I would definitely find that investigation fun if I wanted to get vertical text for me :) |
|
I never considered using that method for Opentype fonts. I did manually rotate glyphs in ttf fonts with Fontforge a while back. And then I just rotate the screen when I use the rotated font in KOreader. The problem, though, is that I can't rotate the UI as well, and I have to keep turning my device this way and that when I use the dictionary. Some readers, like Librera, with custom CSS applied, If KOreader can use this CSS to just rotate the glyphs, I don't think the result would be more "bad" or "horrible" than Librera's, which looked standard to me. And then, maybe the UI can be rotated without rotating the view with the text, or the view with the text can be rotated by itself. I'm not sure how KOreader's whole layout works, but maybe it is possible? Otherwise, is there some sort of User Tweak that can rotate the UI? It's gotta be possible, right? Or at least to rotate the modals to make the dictionaries and highlighting useful in this mode? |
I don't know how other softwares do that, may be they use real web browser web rendering engines, that can do proper vertical text. But you could :)
I looked if it would be possible to rotate some widgets, but no, it would be complicated and kludgy. If the book is set to Typography rules: Japanese, it hacks a few credocument methods to pretend we draw on HxW instead of WxH, and convert x/y coordinates in a few getSomethingFromScreenPosition methods, so at least work lookup, highlighting and following links work (some other stuff like marks in the margins aren't updated). It also switches "invert reading order" so tap on the left side goes forward - some side effects in the ToC at it is made RTL :/) (Feel free to read the code and comment out stuff or add new stuff.) I have no idea how natural it will feel to Japanese readers (with rotated glyphs), but it looks quite neat in
The nice thing with this trick is that all the vertical lines stuff feel proper: justification, underlining, line-heights ensured... As it had been previously the case when I worked on having RTL for Arabic and Hebrew, my mind is totally twisted after seeing highlights made top to bottom and page turning the other way around - I will need a few hours to recover and be able to read again my horizontal books :) |
What underlines should look like (if like anything at all) is one of the things I actually wondered about. |
|
@poire-z, the patch works great! I don't know Lua, but looking at the code and reading your explanation makes it sound complicated. And you did all of that fast. Like, woah.
Finally, I can read comfortably with my messily rotated fonts in my favorite reader! I didn't think it was possible—thank you so much. |
|
@Bluemoondragon07 |
|
Wow, thank you so much. I will be using this script a lot! Now I don't have to click random options in FontForge :) |
Thank you for the script! |
|
If there is a usable solution coming out of this discussion, I can add it to the user guide so other users can benefit too. But I need someone (developer or user) to write step-by-step instructions because this is all...how to say... Japanese to me. |
|
Basically, to achieve tategaki (vertical Japanese), one must follow these steps:
The same can be done for vertical Chinese with a rotated Chinese font and modifications to the user patch to change the criteria for the document language to be set to Chinese instead of Japanese. |
|
@offset-torque : depends if you are writting a User Guide - or the Hitchhacker Guide to KOReader ? :) |
|
[*] By the application of this patch on ancient and powerful eldritch software you accept that you may become perpetually doomed to be dissatisfied by non-rotated images. |
|
Ok then, keep your secrets @poire-z :) I agree, in this case adding it to the user guide might make it look kinda "official" and open the door to more requests and fixes. We can skip this. |
I'll keep mine, but I'm curious about others' :) I have read https://www.learnwitholiver.com/japanese/blog-post-2. My questions: A1 Can Japanese or Chinese readers read any text horizontal or vertical with the same ease ? Can some people just not adapt to one or the other? Publishers can specify in an EPUB that this EPUB book is to be rendered vertical. With the above patch and your font with rotated glyphs (CJ glyphs only I assume): If you have seen any fancy vertical text EPUB, with images, blocks of text with different font size and indentation/side-margins, alignment, epigraphs... Thank you for your answers :) |
Can you explain detail for me how to rotation with this scripts in Font Forge. I install fontforge and choosing my Tff Kyokasho and the click Execute scrips and then go to github link of scrips and paste the scrips in main.py to execute box in fontforge. Then it crash. |
|
@rukit24 my script is a python script using the fontforge library, not a fontforge script. |
Note:
Some other notes:
ps I think the progress bar going from left to right, when the pages go from right to left, is weird. |
|
As a Chinese native speaker who happens to read Japanese and Korean novels, I'll also add my replies too to your questions: A1 Can Japanese or Chinese readers read any text horizontal or vertical with the same ease ? Can some people just not adapt to one or the other? Yes, we could read text in either horizontal or vertical way; however, users have preference to read in vertical or horizontal. In Japan, most novels are published (digital or physical) in vertical reading way. So it's common that people used to read books in vertical. And for Chinese, it depends since there are a lot of books published in horizontal too. Young people are used to horizontal reading because of the nature of internet. However, as a pretty old-fashion reader, since most old novels were also published in vertical reading, I tend to read Chinese content in vertical too. That's more of a habit instead of a hard requirement for most people. So, being able to read epub from horizontal to vertical is a big sale point (or a must have feature) for Eink device manufacturers (at least in Taiwan). A2 Would you read any CJ (Chinese or Japanese) document vertically if possible, ie. Wikipedia articles as shown in a screenshot above ? For novels, it's better to read in vertical; however, for books like, programming books, technology books, or books involved with more western content inside, it's better to read in horizontal. A3 Would you then switch to horizontal if the book contains code or math formulas, or many English snippets? Yes. For this kind of books, we read by default in horizontal; and I think no one will try reading in vertical in this scenario. Publishers can specify in an EPUB that this EPUB book is to be rendered vertical. Yes, I guess it's publishers' decision. It's usually not only configuring in CSS, but also considering how the content layout should be done when it contains images. B2 Or should it somehow be a reader decision, to prefer reading a same book with horizontal or vertical text? it's also reader's decision too. when publisher did not generate their books in vertical, it's always good to allow users being able to make it vertical in reader apps. B3 How do other reading softwares doing good vertical layout do: just following the publisher specifications, or allowing the user to switch between horizontal or vertical mode ? In Taiwan, most Eink devices we sell here supports reading epubs in vertical, no matter the original settings (four local Eink device brands, all of them have its own online bookstores). With the above patch and your font with rotated glyphs (CJ glyphs only I assume): It bothers a lot; but the system rotation bothers more. With your patch, it's much better now. :) As for the rotated glyphs, some fonts are better converted, so the punction can be still in the middle of the glyph. C2 How it is with latin/western text and numbers not being rotated ? The "specs" mentions that abbreviations should have glyph upright (like the CJK glyphs), but largers bit of text like words or quotes can/should be laid dows as they are now, so one has to tilt his head or her device to read the words. latin/western text, usually we leave them as what they are (no matter they are long or short). But for some delicated-handled epub files, the number-bulleted numbers can also be shown in vertical too. C3 How does ruby look and feel? (I haven't look how it's supposed to look when vertical, but probably not how we have it look :)) ruby looks great. C4 How do in-page footnotes look and feel (as a vertical column on the right :) it feels like it would look super odd). how to show them? C5 How do popup footnotes look and feel (popping at bottom with horizontal text) ? popup footnotes looks fine at the bottom of the screen. :) If you have seen any fancy vertical text EPUB, with images, blocks of text with different font size and indentation/side-margins, alignment, epigraphs... hmm.. in fact, I haven't seen fancy vertical text EPUBs with images; most of my Japanese or Chinese books are novels. If they come with images, although the image is not rotated, I think it's bearable. :)
D2 How is it with KOReader, this patch and a rotated font ? I expect none of the previous issues are fixed, but I'd like to know how much % of the unconfortableness is gone with it, and how much % are left and bearable. 10% unconfortableness, if the 90-degree font is not handling punction position well D3 Do such books use margin/padding-left/right/top/bottom, or the newest margin-block-start/end and margin-inline-start/end (that KOReader/crengine does not support) ? not sure. usually I prefer setting margins myself (no matter the text is in horizontal or vertical). D4 Do you have to enable some specific style tweaks (ie. Ignore horizontal/vertical padding/margin or Left aligned most text) to get things better? no. I don't have to. :) |
|
Thanks for the feedback!
Not sure I understand what you mean by "system rotation". Do you mean that without that patch, you had to rotate the device (and so, menu and other popup were rotated and you have to rotate back the device to use them) ?
Didn't think about them :) Indeed, these numbers could look odd and bothering:
Via
Not only images, but any fancy spacing, ie. at the start of a chapter, with a title centered with various amount of spacing above and below, and some epigraph right aligned taking 30% of the screen width... could look odd if made vertical while the CSS mentions stuff like margin-top: 2em actually working as margin-right, stuff like that.
That's for the outer margins. What I mentionned in the previous paragraph are margin/padding set by the publisher for cosmetic reasons. The punctuations looks quite alright on the single line of your screenshot :) |
|
Thanks for your quick reply. Here's screenshot showing how I rotated screen after applying 90-degree-rotated font (before I found your patch). Yes, the numbers are not looking good for in-page footnote, but that's how most reader apps support if they offer "vertical reading" feature for original horizontal layout books. So, it's acceptable. 
you mean indentation like this in front of each paragraph? it looks just fine. As for the punctuation in my screenshot, those fonts are especially taken care of commas and period, that's why they look good. People who prefer vertical readings did some effort to make sure any workaround is utilized. :) (I have some 90-degree rotated fonts that does not show punctuations in the middle; I seldom use them though). Thanks for showing me more info related to CJK typography, I'll have a look at the links, and feedback to you later. By the way, currently, the only issue I found with your patch is that, when setting highlight style to underline, it will only show underline for the lowest single character. I guess it also need to override some functions to provide rotated coordinate so that it could be correctly drawn. However, it's an easily avoidable issue since I can just use Lighten or Invert style instead. Thanks for the patch again. It really makes Koreader more useful for me (and many other CJK readers. :) ) |
No, I meant layout like this in horizontal books (the spaces in yellow are publisher's margins/paddings) But an original vertical layout book, when wanting to ensure these spacing, may use So, you mean we're not the only software that would be using this trick of just rotating the buffer? Do other softwares (not using real web engine) do more than that, by rotating & fine positionning the glyphs themselves, without needed tweaked fonts?
Indeed : This is drawn by the frontend code, so indeed it would need some patching. I think it would be the same function I tweaked for #11581 (comment) . |
|
@poire-z |
|
@poire-z The margins are gone from what I tested (see figure below). Other reader apps I know, they just use web engine, so they can support css vertical style easily. for the punctuation, I guess people just replace half-width ones with full-width one, so they are always in middle. |
|
DONE~ In case anyone need the patch that supports underscore style of highlight feature, here's the gist for it: https://gist.github.com/plateaukao/e546f8226727acb3a25597e572ef39fc screenshot: |
|
For anyone wondering why that excellent patch isn't working, it's because the file needs to be renamed from |
Nowadays everyone should be used to horizontal texts. Those not familiar with vertical texts may find it slightly difficult to read.
I prefer to read Traditional Chinese and Japanese literatures or sociology books in vertical mode.
Math books and books with much English are usually horizontal. MathML used in epub doesn't seem to have support for vertical typesetting. I think even nerd guys from (La)TeX don't have a proper solution for this.
As it is defined by the publisher in CSS (e.g.
This is a consideration for ebook readers: to obey the styles defined by publisher and display them as-is, or to modify them for consistency and customization? I have to say, KOreader is good at both.
Kindle will follow the specifications in book and not allow user to set them. Vertical-lovers have to edit book file if possible.
It looks fine for me. And I think this is what JLREQ perfers.
Reading rotated Latin words can be difficult, but with some experience this won't matter much. Full-width numbers and letters (Unicode FF00-FFEF) should be used if they are expected to be upright. However, this can be problematic for other scripts like Cyrillic and Greek (In many Japanese fonts, these letters are always full-width version). Plateaukao mentioned that counters in lists should be shown in vertical, which can be implemented through
I've found a bug that effect both horizontal and vertical mode: Alignment of ruby text is affected by -epub-text-align-last · Issue #11771. Besides that, everything looks fine for me.
It looks fine for me. Some printed books put footnotes at the bottom of page (like sidenotes in horizontal books after rotated), but as literature books generally have few notes, this could be space-wasting.
It looks fine for me.
Due to software restriction, in Kindle, many vertical-typesetting books with complicated layout may just display pages as pictures. The book I'm using as example is 変な家 (Hen na Ie; A Strange House) by 雨穴 (Uketsu), which can be found at……uh, you know where.
For hanging indent, the book use a combination of text-indent: -4em;
padding-top: 4em;Which works well in vertical mode of modern browser (they will counteract each other). However, in horizotal mode of KOreader, it will become blank area on the top, and texts going out of left bound. Other paddings and margins also have similar problem. What's more, the publisher adds blank area to top and bottom of pictures to make them all have identical height. When displayed horizontally, this will become redundant. There's another trivial problem: the book uses
Same as above-mentioned problems, just rotated. Those out-of-bound texts are detrimental to reading, while it affect both vertical and horizontal mode. Some part of the book have bar over top (as
Every book I've seen uses
I have to ignore paddings and text indents to avoid those blanks and out-of-bound texts. |
|
Thanks for the detailed feedback and insights.
Then, I guess that if we later go on at making all this better, and let crengine know that we are in this "vertical formatting hack mode", it could somehow translate
We don't support CSS --- a/crengine/src/lvfntman.cpp
+++ b/crengine/src/lvfntman.cpp
@@ -1598,29 +1598,29 @@ public:
virtual LVFontRef getDecimalListItemFont() {
if ( !_DecimalListItemFont.isNull() )
return _DecimalListItemFont;
if ( _kerningMode == KERNING_MODE_HARFBUZZ && !(getFeatures() & LFNT_OT_FEATURES_P_TNUM) ) {
// We can request the same font with OpenType feature "tabular nums", for fixed width
// digits and better alignment of decimal list items (no need to do it if this feature
// has already been enabled for this font). If the font does not support the feature,
// we'll just have another useless instance of the font.
_DecimalListItemFont = fontMan->GetFont(
getSize(),
getWeight(),
getItalic(),
getFontFamily(),
getTypeFace(),
- getFeatures() | LFNT_OT_FEATURES_P_TNUM,
+ getFeatures() | LFNT_OT_FEATURES_P_TNUM | LFNT_OT_FEATURES_P_FWID,
-1, false);
if ( _DecimalListItemFont.isNull() ) // shouldn't happen
_DecimalListItemFont = LVFontRef(this);
}
else {
// LFNT_OT_FEATURES_P_TNUM won't be used with other kerning modes, so use this same font
_DecimalListItemFont = LVFontRef(this);
}
return _DecimalListItemFont;
}A quick try with @Bluemoondragon07 's fonts shows:
https://drafts.csswg.org/css-text-decor/#emphasis-marks Just some thoughts, not planning going there soon :) |
May i ask what code have you tweaked to get that result |
|
That one line is in https://github.com/koreader/crengine/ But you can't test it without compiling the program. |
is it possible to patch crengine to make it display vertical text? |
|
@MyK00L Thank you for your script! I finally figured out how to get it working. If any of you are interested, I just updated my repo of rotated Japanese fonts specifically for this purpose. The fonts are much more accurate now--except for IBM Plex and Shippori Mincho; they are still outdated. But everything else will appear much more accurately to how it should look in tategaki. |
|
@Bluemoondragon07 you could provide images in the Readme too, as previews |
As far as I'm aware of KoReader does not yet have tategaki (縦書き) support for Japanese texts. Tategaki is vertical formatting for Japanese texts.
A toggle to enable tategaki for Japanese texts would be amazing, filling a gap that is really only filled by ttu reader w/ yomichan at the moment. It would be a really nice as koreader already has great Japanese dictionary ability similar to yomichan.
Reading Japanese texts in a horizontal layout can become very tiring, so I think this feature would help make koreader's Japanese even more comprehensive.
The text was updated successfully, but these errors were encountered: