Open PeacefulGrapes opened 3 years ago
Good suggestion. Arabic was on my mind years ago when working on the layout algorithm. Perhaps you could be a tester for RTL. ref: https://fontlibrary.org/en/font/droid-arabic-naskh ref: https://harfbuzz.github.io/ ref: http://designwithfontforge.com/en-US/Adding_Glyphs_to_an_Arabic_Font.html
As a side note, another case is traditional Japanese, which is vertical and RTL.
Good suggestion. Arabic was on my mind years ago when working on the layout algorithm. Perhaps you could be a tester for RTL.
I'd be glad to help make it happen, and I sincerely appreciate your work.
As a side note, another case is traditional Japanese, which is vertical and RTL.
Yeah but I don't think it's cursive so I think Arabic would require some additional work.
You're correct.
I'd be happy to test for Farsi
I'd be happy to test for Farsi
Adding support to Arabic automatically extends to include other languages that share the same alphabet and writing characteristics such as Persian, so that's nothing to worry about.
The general approach would be to negate the advances provided by the font and allow initialization of each line to be onto the opposite side of the page, all controllable by a "right-to-left" mode alternate to "left-to-right" mode. Most of that is already symbolic (variable).
Look to see if a font provides any hint about its direction.
Using the book and font here, i get mostly blank pages with a few printed characters outside the range of Arabic. Need to turn the debug drawing on to see what's up. One potential issue is possible variation in "UTF-8 or not", though i can't see why this would ever be user-specific. Seems like using UTF-16 or UTF-32 for Arabic is not unreasonable because of where Arabic is placed in the UTF codepages. The book itself claims to be in UTF-8.
Using the book and font here, i get mostly blank pages with a few printed characters outside the range of Arabic. Need to turn the debug drawing on to see what's up. One potential issue is possible variation in "UTF-8 or not", though i can't see why this would ever be user-specific. Seems like using UTF-16 or UTF-32 for Arabic is not unreasonable because of where Arabic is placed in the UTF codepages. The book itself claims to be in UTF-8.
If you're referring to the font you've recently provided in your comment, I've tried it and my DSi device gave the same result I had reported before when I first started this issue (link for it here.
Other than that I don't see how I can provide you with more useful information since I'm not that professional in the field of programming nor all that UTF stuff.
What version of dslibris are you using?
I'm using this version (v1.5.1).
I'm on 1.6.0 with some dev changes, which isn't yet released. That's very possibly the reason.
I don't mean to rush things up but is there any news concerning Arabic development?
It's not in the cards from my viewpoint. There aren't any other individuals involved in this project, but this would be a great place for someone to contribute.
Yeah you're right especially with the DS having gotten so old. Anyway, thanks for the great app.
ref: #31
I've been using this app for reading and it's been great but I was wondering if it can view epub files that are in Arabic language (for a bit of context; the Arabic language is an RTL, cursive language).
I managed to view the file using an Arabic font but the letters were from left to right they weren't conjoined as they should be.
Here is a picture of how it appears in the dslibris app (after using the Arabic font) and here is another one showing how it should be (the app used is Lithium for Android and here is the epub file in Arabic that I'm doing my tests on).
The font file I've used to show the letters in dslibris is DroidNaskh.ttf (link provided), without it the letters would show as squares.
If there's any additional information you'd like to know about the case or the language itself that could help you add Arabic support to the app I'd be glad to help.