This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TivaWare Graphics Library Rendering of Arabic Font

Hello,

Question 1: Spaces Between Characters

I am using the TivaWare Graphics Library and require multi-lingual support.  Someday Arabic is a language that needs to be supported.

I have attached a zip file of what the font rendering of Arial Unicode MS looks like when I view the font in Excel, and another of the font when I render the font on my screen using the TivaWare Graphics Library.

You'll notice in Excel, the "J" looking character gets connected to the "o" but with TivaWare they are not connected.

I cannot upload my entire language translation, so I am uploading just the small snapshot of what I'm trying to render.  I have included a .csv file and the make file I'm using to generate the code files (run C:\ti\ccsv6\utils\bin\gmake.exe in the folder with the .csv file and the make file).

Question 2: Right To Left Rendering

According to "Section 3.2.4.1 Text Rendering Direction" of the TivaWare user's manual, it states the following: "Left-to-right text rendering is used by all western European languages and is also supported for Chinese, Japanese and Korean. Other languages, notably Hebrew and Arabic, require right-to-left text rendering with the ability to insert left-to-right strings within the base left-to-right text. While such languages could be rendered by reformatting the source text into display order and rendering it left-to-right, the base graphics library does not currently support the ability to render strings stored in reading order in these languages. To support different rendering directions, a replacement string renderer could be modeled on GrDefaultStringRenderer() but update the rendering coordinates for each character differently to provide right-to-left rather than left-to-right text."

I am wondering if anyone has implemented a solution for the replacement string render as indicated in the manual?

Thanks,

Aaronhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/Graphics.7z

  • Might I suggest that such may have been done (elsewhere) for Hebrew - and that your search in that direction may prove most fruitful. Our small tech firm "bumped against this" several years past - and time's passage dims recall.

    I can report that the, "right-to-left" text entry is not that difficult an implementation. (one essentially subtracts from pixel column rather than adds)
  • Hello Aaron,

    Regarding your first question, I wanted to confirm if you have read about "ftrasterize" in Chapter 14 of the "TivaWare Graphics Library". Are you using the FreeType font rendering package to create the "Arial Unicode MS" font that the TivaWare Graphics Library can understand? If yes, can you briefly list the steps that you used to create the .c file - maybe I can re-create the .c file at my end and try to help in finding a resolution?

    Thanks,
    Sai
  • Yes, we are using a .ttf file.  If you look at my original post there should be an attachment near the end of the post.  It has the makefile that we use to generate the fonts.  We use the "gmake.exe" executable found in "C:\ti\ccsv6\utils\bin"

  • Hello,

    I have run into another snag in another language, Thai...

    In Excel, the translation looks like this:

    In TivaWare it looks like this:

    Is there something I can do (perhaps manually editing the font file) in order to get the correct positioning of the glyphs (under the character instead of after)?

    Thanks,

    Aaron

  • Aaron Geier said:
    Is there something I can do (perhaps manually editing the font file) in order to get the correct positioning of the glyphs ... 

    Might that unwanted "shift" of the glyph result due to a font, "pixel height restriction?"    (i.e. the combined height of the "proper" and "offset" glyphs exceeds that devoted to the font.)    You may be able to tweak that "font height setting" - and if lucky - that offset glyph may "snap" into position.   

    Admittedly your font rendering appears small here - and this tactic does not always work...   (yet we have succeeded in "just this manner" - although not w/this vendor's graphic package...)