I have been trying to develop a simple J2ME application using LWUIT in Bengali language. However, because of heavy usage of vowels as conjuncted letters in Bengali language, I am facing some problems with LWUIT.
For example let us say, “X” is a consonant letter and “#” works as a vowel in Bengali; now they are combined together when needed becoming a conjuncted format “X#”.
Using LWUIT, when I add such vowels and try to display them as the conjuncted format with a consonant in a real application, they are combined with their previous letter (which is in a consecutive order) as defined in the charset. Although interestingly, in the LWUIT designer display/preview, the characters appear correctly.
For details, kindly download this document here (http://dibbaa.com/lwuit/doc/lwuit.doc) and see the real-life examples.
I will appreciate if anybody can help me out on this. Just let me know how can I set LWUIT framework in such a way so that it doesn’t combine the letters as they defined in the charset by consecutive order while painting them.
I have used LWUIT version 1.3 and font “KarnaphuliP.ttf” for my application.
Thanks
I know nothing about Bangali, and I cannot find the font you mentioned. But I managed to get an alternative font for recreating the problem:"Bengali-Progoty.TTF" (which, unfortunately, is not a bit similar to yours). You can get the font here:Bengali-Progoty.TTF.
Those vowels are special, in that their width are zero ,and I bet their origin point is the right-top point, instead of left-top. This way, vowels can be drawn on top of other characters preceding them.
When lwuit designer generates bitmap font, it draws every character (What I mean is, unicode character) onto a big bitmap, calculates the width of current character, add that width to current offset, and draws the next character. As a vowel has a width of zero, it will be combined into the last non-vowel character preceding it.
To solve this problem, you can either switch to unicode font (Bangali has a place in unicode), or you can stick to the current font and do some customization work to the font generation process.
1 Create your own class overriding the EditorFont class in lwuit's editor.jar.
2 Override EditorFont#getBitmapFont() method, do your own drawing of every character. You can test if any character is a vowel, and if so, draw it with a preceding space.
3 Override the FontTask Ant task provided in lwuit's editor.jar.
4 Override the FontTask#addToResources() method, insert your own EditorFont instance instead of the original one.
5 Override the LWUITTask class, add an AddXXX method to support your overriden FontTask.
6 Build a resource using ant, and use your own version of LWUITTask and FontTask instead of the original version.
7 As vowels have become regular characters, they will take up the same space as other characters and cannot be drawn on top of other characters any more. You have to draw them on top of other characters manually. The com.sun.lwuit.CustomFont class may have to be overriden in order to draw these vowels correctly.
Given the complexity introduced, I highly recommend switching to unicode font. But as I have said, I know nothing about Bangali and cannot tell if it is adequate to use a unicode font. Maybe you have to do it the hard way after all.
Good luck.
I think it may be better for you to implement your own Virtual keyboard. There is a sample in the LWUIT developer guide and demo. I am sure if u invest time in that it will come in handy later on.
Related
I'm trying to create a script for Linux that will detect where the text cursor is. This should be done in maximum 1 second. In order to implement this, the best solution seems to be to programmatically add some text via xdotool, take a screenshot via some other utility, try to figure out the position of that text, and then remove the text we've inserted using xdotool again.
I tried inserting a random string (like <-- CURSOR HERE). Using Tesseract 4 it takes about 20 seconds to find the position of the string, although it's very precise in terms of pixel coordinates. I was not able to use whitelisting (in version 4 of Tesseract) to narrow result to specific letters or digits only, which I assume would speed up processing.
I don't know what font the user will be using, but every font has dashes and slashes, so I could create some sort of shape (for instance, |/\|/\|/\|/\|), and use some library to detect that shape. What would be a good choice?
I don't care about what's on the rest of the screen: it could be more text, images, etc. I only need o know where my random string is (<-- CURSOR HERE, |/\|/\|/\|/\|, or can you think of anything else), and get its X/Y position in pixels.
Using HitTestTextPosition style API from IDWriteTextLayout I did not managed to handle properly text positions inside "ti", "ffi" or other ligatures with fonts like Calibri. It always returns position after or before ligature not inside like t|i or f|f|i.
What is the recommended way to do a caret movement inside ligatures with DirectWrite API?
There... is no "inside" position if you have GSUB replacements turned on?
Opentype GSUB ligatures are single glyph replacements for codepoint sequences, rather than being "several glyphs, smushed together". They are literally distinct, single glyphs, with single bounding boxes, and a single left and right side bearing for cursor placement/alignment. If you have the text A + E and the font has a ligature replacement that turns it into Ӕ then with ligatures enabled there really are only two cursor positions in that code sequence: |Ӕ and Ӕ|. You can't place the cursor "in the middle", because there is no "middle"; it's a single, atomic, indivisible element.
The same goes for f. ligatures like ff, fi, fl, ffi, ffl, or ſt: these are single glyphs once shaped with GSUB turned on. This is in fact what's supposed to happen: having GSUB ligatures enabled means you expressly want text to be presented—for all intents and purposes—as having atomic glyphs for many-to-one substitutions, like turning the full phrase "صلى الله عليه وعلى آله وسلم", as well as variations of that, into the single glyph ﷺ.
If you want to work with the base codepoint sequences (so that if you have a text with f + f + i it doesn't turn that into ffi) you will need to load the font with the liga OpenType feature disabled.
The text editors I know of use the simple hack of (1) dividing the width of the glyph cluster by the number of code points within the cluster (excluding any zero width combining marks), rather than use the GDEF caret positioning information. This includes even Word, which you can tell if you look closely enough below. It's not precise, but since it's simple and close enough at ordinary reading sizes, it's what many do:
(2) I've heard that some may (but don't know which) also use the original glyph advances of the unshaped characters (pre-ligation) and scale them proportionally to the ligature cluster width.
(3) Some text editors may use the GDEF table, but I never knew of any for sure (possibly Adobe In-Design?).
The most challenging aspect of using methods 2 or 3 with IDWriteTextLayout is that accessing the corresponding IDWriteFontFace in that run requires quite the indirection because the specific IDWriteFontFace used (after resolving font family name+WWS+variable font axes) is stored in the layout but not publicly accessible via any "getter" API. The only way you can extract them is by "drawing" the glyph runs via IDWriteTextLayout::Draw into a user-defined IDWriteTextRenderer interface to record all the DWRITE_GLYPH_RUN::fontFace's. Then you could call IDWriteFontFace::GetDesignGlyphAdvances on the code points or IDWriteFontFace::TryGetFontTable to read the OpenType GDEF table (which is complex to read). It's a lot of work, and that's because...
The official PadWrite example has the same issue
IDWriteTextLayout was designed for displaying text rather than editing it. It has some functionality for hit-testing which is useful if you want to display an underlined link in a paragraph and test for it being clicked (in which case the ligature would be whole anyway within a word), or if you want to draw some decorations around some text, but it wasn't really intended for the full editing experience, which includes caret navigation. It was always intended that actual text editing engines (e.g. those used in Word, PowerPoint, OpenOffice, ...) would call the lower level API's, which they do.
The PadWrite sample I wrote is a little misleading because although it supports basic editing, that was just so you can play around with the formatting and see how things worked. It had a long way to go before it could really be an interactive editor. For one (the big one), it completely recreated the IDWriteTextLayout each edit, which is why the sample only presented a few paragraphs of text, because a full editor with several pages of text would want to incrementally update the text. I don't work on that team anymore, but I've thought of creating a DWrite helper library on GitHub to fill in some hindsight gaps, and if I ever did, I'd probably just ... use method 1 :b.
I'm in the process of vectorizing true type fonts to render them as Direct3D primitives. So far I've successfully managed to extract the glyphs using GetGlyphOutline, and render them as linelist primitives. Anyway, on to the spacing...
How can I find out the spacing between characters, or how/where is it determined?
Clearly the spaces vary with non-monospace fonts.
Is there a GDI+ or other windows function call to determine the spacing?
You are referring to the advance width of the glyphs (stored in the hmtx table of the font, or vmtx for vertical text). Via GDI, which it sounds like you are using rather than DirectWrite, you can use:
GetCharABCWidthsI if you already have an array of glyph ids. This approach can support any character in Unicode including extended CJK and newer additions like Egyptian heiroglyphics, not just the lower basic multilingual plane.
GetCharWidth32 for character widths - limited to the basic plane, but the simple option.
Call GetGlyphOutline with GGO_METRICS and use gmCellIncX. This returns more fields than you're probably interested in though.
Kerning is an additional optional adjustment to the nominal advance, such as in the word "AVATAR" where 'A' and 'V' would be shifter closer for aesthetic purposes.
I don't know anything about direct3d, but if your just after the metrics they are stored in the typefaces kerning table; GetKerningPairs will tell you the correct placement for sets of character pairs.
I'm interested how to construct certain kinds of layout in RTF documents, ideally using techniques that do not depend only on the most recent RTF standards, and that are "native", i.e., they do not involve embedding other representations, like picture files. In particular:
In Postscript and DVI, I can specify a coordinate at any time that the next text will be printed at: can this be done with RTF?
Can RTF compose characters through overstriking?
Can lines, outline boxes and filled boxes be drawn, with their geometry specified either absolutely, or relative to text?
You can use the \pvpg \phpg \posx123 \posy123 construct after
you start a paragraph with \pard to position it relative to the top left of the page. See: http://biblioscape.com/rtf15_spec.htm#Heading39
Yes, but it's rather involved, and I think it was only introduced in RTF 1.5. See the drawing objects section of the spec. Here is a basic example of drawing a box (I'm not sure it's entirely valid but it should give you an idea of how to work with drawing objects):
{\rtf1\ansi\deff0
{\pard {\*\do
\dobxcolumn \dobypara
\dprect \dpx0 \dpy0 \dpxsize1000 \dpysize1000 \dplinew25
}\par}
}
If you're doing any work with RTF it's worth picking up O'Reilly's RTF Pocket Guide.
I don't believe this is possible. You'd need to use tabs and newlines to get the text where you want it.
Not really, unless \strike and \strikedl count.
http://www.biblioscape.com/rtf15_spec.htm#Heading52 says drawing objects are an option, and so is inserting images, but neither are really "native", both being absent in the first RTF specs. (And the latter is a bad choice for i.e. just a line.)
As I have a background in the publishing industry, I prefer to use fixed-width spaces like em spaces. However, IE6 displays a box when I use , which really bugs me. Can I do a javascript replace just for IE6, or should I just not use em spaces?
Edit
Just to prove that it's not just my computer, MercerTraieste usefully linked to this image:
Example of incorrect emsp entity display http://img11.imageshack.us/img11/6207/20090810154159.png
Perhaps IE6 uses a font without an em space. Missing characters are often shown as boxes. If this is true then the question is not why does IE6 display a box instead of an em space?, but instead why does IE6 not use the font that has an em space?
You say that you are using Georgia. On my computer I did not find an em space in the Georgia font. Perhaps the other browsers tries to use another font having an em space or doesn't use the box character to indicate a missing character.
One way to look for the em space character is to use Character Map available in Accessories. If you check the Advanced view check box and selects Unicode for the Character set and sets Group by to Unicode Subrange you get a Group By box to the right. The em space is found in the General Punctuation category. It might be hard to spot as it is... well, a space.
According to Google Doctype IE6 supports the character entity, so your font might not.
One possibility is that you could find a different font that does do what you want with the em spaces and then just use that; alternatively, you could use a stylesheet and set the text property word-spacing to 1em. http://www.w3schools.com/CSS/pr_text_word-spacing.asp
Of course, if you're only using em spaces in some areas and not in others, then you'd be better off just using a similar font that does support em spaces.