NB: My whole senario is for only android version ICS.
My Goal is to render text having complex script/indic script. In ICS, this feature has been added in WebView (and so Browser). If any indic text is rendered in Browser or WebView it renders correctly. But in other widgets (TextView,EditText) it renders broken.
Now my goal is to re-use the code for properly drawing indic text in webcore and use that code to draw indic text in a custom widget.
I also tested using HTML5 canvas in browser and it can render indic text fine.
I have tested android's android.graphics.Canvas and it failed to render indic text properly.
libskia seriously lacks of documentation so i cant work out how to render text using this.
I checked the objdump of libwebcore.so and saw that it depends on lib "skia" "libicu". So i'm assuming i can draw indic text using these libraries.
Can anyone suggest how can i draw indic text using skia and icu ? or Can anyone point to specific code segment in libwebcore ?
There are a couple of alternate text stacks that are in common use, but neither is directly exposed through the Android NDK. At the base level, you need to:
Break your text into runs of a single script, in a single font, in a
single direction, on a single line.
Convert the sequence of characters in each run into a sequence of
glyphs.
Lay out those glyphs in 2D space, potentially going back to step (1)
if your linebreak didn't work out.
Rasterize the glyphs in the chosen positions.
The most popular stack for this is approximately (1) fribidi, (2) harfbuzz-ng, (3) more harfbuzz-ng, (4) libfreetype. All of these projects are pretty easy to get running on Android; documentation quality varies.
There's also the Pango project, which sits on top of the stack just described, but provides a higher level interface. Unfortunately, Pango has quite a few dependencies, such that it might be more effort to incorporate Pango than to just use the stack directly. If nothing else, Pango serves as great documentation for how to use the stack.
As an alternate stack, the various parts of libicu can replace fribidi, harfbuzz-ng, and Pango (the last with the nearly-undocumented ParagraphLayout class); you'll still need libfreetype to actually deal with fonts and rasterization. Be aware that parts of libicu are being moved over to harbuzz-ng, so these stacks are not completely distinct; and while parts of libicu are both excellent and updated regularly, other parts are a but fuzzier.
Related
I am working on a banner creating app where the user can create custom banners for any purpose. The banner will have text, icons, background, etc. The app needs to provide features such as
Text Editing which includes simple effects like bold, italics, underline, font changes etc. But also more advanced effects
such as envelope distortion, curving, outline etc. Moreover in the
future, there may be more such effects that may need to be added.
Background editing by adding an existing image or creating a background with available options in the app
Think of it as slides in power point where user can add their own text and format it plus have backgrounds. There need to be a lot of customization
I need to decide what tools to use to develop this. The main issue is how to render texts dynamically. The options I have been thinking of are
Using TextViews/EditTexts and other top-level view classes
Using CustomViews i.e Canvas
Using a more advanced and lower-level approach such as an
ImageProcessing library to render text or even something along the
lines of 3D graphic rendering.
I need to make a choice that isn't incompatible to support future effects that may be needed. I am pretty sure TextViews/EditTexts etc won't be the solution here. I am not sure how powerful the Canvas class is and whether it is possible to create such an app by just using CustomViews.
Coming to ImageProcessing or 3D graphics, it may be used to have much more control over the effects by using PixelShading/Transformations etc but it comes with its drawbacks. i.e low level of abstraction and higher development time possibly.
Can some more experienced folks give some insights? Thanks!
Use Image Processing and for different themes use lotte-Animations.
I'm a designer and interested in different ways I can handoff animation to Android developers and the best ways to do that depending on a particular case.
1. JSON
I know Lottie works best for animating micro interactions and creating animated illustration, like those on onboarding pages. For a designer it's easy to provide JSON file since it can be generated with Bodymovin plugin in AfterEffects. Developer just gets the file and uses it as is, no more additional efforts for him.
2. Java or Kotlin
UI elements that require complex interaction are usually build with code, like BubblePicker since it has changeable content in those bubbles and different conditions how it can be interacted with. Since design tools don't generate production-ready code designers export video recording from tools like Principle, generate clickable prototypes in ProtoPie or other tools. Designers try different ways to show the idea of animation but in this case all the work is left for a developer.
3. XML
Don't know when developers use this type and if designers can provide it using export from some design tools.
What are other technologies developers use to create animations?
What type of files, prototypes designers should provide for the developer considering different cases?
Android animation API is really diverse, meaning there are lots of ways a developer may choose to deliver an animation. I dare to say this should never be conditioned by the nature or limitations of the provided resources. Let's understand by resources anything that's not actual code: bitmap images, audio files, and even text. Knowing the file types or formats the developer can or wants to use involves communication and you can expect them not to be always the same.
Always provide a video of the animation, unless it can be described with a single word.
The most common animations in android are:
Drawable animations. This type of animation usually happens inside a pre-defined area on the screen and is achieved by loading a series of images, one after the other. Here a common filetype would be PNG images, one for each step of the animation. Probably the same amount of different sprites you used for the video, never as many as 24/s! Keep in mind that to support different screen sizes and densities, different size/densities will have to be provided for each series. If the image is simple Vector Graphics would simplify the job for both the coder and the designer, regular SVGs are supported.
One can also animate on the paths of the vector images, even morph between several of these, as long as the paths are compatible for morphing, which according to the documentation they must have the same number of commands and the same number of parameters for each command....this takes more understanding of the intrinsics of the vector file definitions, if you can see the image by reading the SVG code, go for it!
Another major group comprises the animation (by acting on properties like color, position, size, etx) of the application UI elements. This type may or may not involve image resources, and are usually applied to components of pre-defined types. E.g.: all buttons should have a ripple effect starting where the pointer clicks. Android has pre-defined effects with particular names (flip, zoom), it could be useful to know this vocabulary.
Finally, layout changes are animations that happen when you reorder things around to better convey information or hint the user towards actions. Similar to these are the Transitions, which happen when switching screens but can also be used to create animations that move images around, altering their positions and properties. They are really simple to implement and may require resource files of the same type as mentioned in 1
For reference, check the following which has some code but also illustrative examples:
https://developer.android.com/training/animation/overview
To know how to support different screen sizes, check:
https://developer.android.com/training/multiscreen/screensizes
To know more regarding SVG support in the Android platform: https://developer.android.com/studio/write/vector-asset-studio
After trying several available eng.traineddata files with an Android app that employs Tesseract, I have less than stellar accuracy. Since my application will be using just a few fonts (font sizes, bold and regular), I thought I could get much better accuracy by building my own data. An example of the kind of thing (an 8.5x11 inch paper) that users will taking a picture of is here:
I have looked at jTessBoxEditor, but wondered if that was an appropriate path to investigate. And if so, I was unsure how to proceed with respect to a starting point, or to try from scratch. The font (which looks like Times New Roman) is very common, and didn't want to re-invent the wheel. I also wondered about how to treat the font on the two different color backgrounds.
Also, I wondered if I could just print-out ABC... abc... 123... in Times New Roman font and get that into a custom eng.traineddata file. If I understand correctly, you want the 'cleanest' data (i.e. no 'bad examples' of letters) in the source material used to train your system. But it would seem as if there would be a tutorial or procedure defined for how to build trained data for a specific font. If there is, it's been eluding me.
I would consider using machine learning, but so you don't have to do it on your own, look at Tensorflow Mobile. This is a version that is for mobile devices, and to help with character recognition you can look at this article.
To train any neural net a set of training data along with correct
outputs must be provided. In this case this will be a set of 128x64
images along with the expected output.
This will help you easily implement a solution to recognize the characters, and by going with this approach you can extend to more fonts if you desire by just doing more training.
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html