11 Replies Latest reply on Sep 26, 2009 9:03 AM by timo888

    Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR

    timo888

      I've written an application in WinForms/.NET that I'd like to port to the Macintosh platform. I have never developed for the Mac but it seems as though AIR might be a good choice. I'm totally new to AIR. Some advice and info would be much appreciated!

       

      Can an app be developed in AIR on a PC running Windows and then later be deployed transparently on a Macintosh? Or do I need to be developing on a Mac?

       

      The app is a search interface for use against text-bases comprised of texts composed in ancient European languages. I pre-index the text-base and store it in SQLite as a fully-normalized (1NF) set of relations:  TITLES, WORDS, WORDOCCURRENCES.  So the app is really nothing more than a (query-only) database application with some specialized glyph-rendering requirements.

       

      In the WinForms app, I used a custom third-party edit control with  extensive support for the RTF specification, in combination with some third-party fonts that contain the necessary glyphs for rendering the Unicode characters corresponding to RUNES and to some abbreviations found in medieval manuscripts. BTW, these special non-ASCII characters are represented in the database not as unicode codepoints but as entities that can be represented in standard ASCII (e.g. "þ"   ); when rendered to screen, the correct glyph has to be substituted when the Unicode codepoint for the entity supplied -- in this example the codepoint would be [U+00DE] and a thorn glyph  ( Þ) should be rendered.

       

      Since it might not be possible to find a single omnibus Unicode font that contains a glyph for every codepoint I need to render (what are the most glyph-rich freeware Unicode fonts for Macintosh, btw?)  the text widget must let the programmer "wrap" a Unicode character or series of Unicode characters in whatever font may be required at that point in the text. Is there a rich-text widget for AIR that can do this?  A widget that can render HTML and supports CSS stylesheets would be ideal (inline-CSS-only would be OK too). If the widget had CSS stylesheet support, the string of Unicode codepoints could be wrapped with a <span class='rune'>.....</span> and  the font-name for the .rune class could be specified in the CSS stylesheet.

       

      Thanks very much if you've taken the time to read through this tedious stuff !

        • 1. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
          adobe_paul Adobe Employee

          I'm afraid I'm not a unicode/font expert, but I think I can give you some guidance based on the questions you asked.

           

          AIR apps use the same installer file on all platforms (win/mac/linux) so any AIR app can run on any of these OSes, regardless of which OS the developer used.

           

          As far as rendering HTML and supporting CSS, the AIR runtime includes the Webkit HTML engine (the basis for the Safari browser among others) so it has very good HTML/CSS support. There are a few ways that you can use the Webkit functionality:

           

          • Develop your app using Adobe Flex, and use Flex's HTML component. You would author your app using Flex MXML (a markup language for declaratively defining your user interface) and ActionScript. Flex includes the HTML component, which is a user interface component that is an HTML content area -- basically it's the "widget" you described in your question.
          • Develop your app using Flash Professional or entirely in ActionScript, and use the HTMLLoader class to display the HTML content. The HTMLLoader class is the native AIR class that provides a visual area for rendering HTML content. It is a display object, which means its one of the native classes that can be added to the "display list" and renders visual content. (The Flex HTML control is actually a wrapper for the HTMLLoader class, that integrates it with Flex layout functionality and provides a couple of extra features.)
          • Develop your app entirely in HTML/CSS/JavaScript. If you know Ajax/JavaScript well, and especially if you're familiar with one or more Ajax frameworks, this might be the best approach. If you don't already have a favorite IDE for authoring HTML, two options that include built-in support for creating AIR apps are Aptana Studio (free, eclipse-based IDE: http://aptana.com/studio) and Adobe's Dreamweaver.

           

          With any of these options you can use the SQLite database and dynamically generate HTML and pass it to the appropriate control (Flex/ActionScript) or add it to the document DOM (JavaScript).

          1 person found this helpful
          • 2. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
            timo888 Level 1

            Thanks for the helpful reply.  Good that I don't have to borrow my wife's Mac to develop the app

             

            I'm finding the Adobe product line a little bewildering.   It's not clear to me, from my introductory reading, what the distinct advantages of using Flash versus Flex would be. More reading required.

             

            If the FLEX HTML control, or the HTMLLoader class, understand CSS, then it seems there will be choices.

             

            If I need to "ship" a font that isn't found on the user's Mac, can that be done?

             

            I would also need to "inject" HTML markup as a string into whatever class or widget is used, not point the class or widget at a URL.  It looks as though there's a loadString method. Excellent.

             

            http://help.adobe.com/en_US/AIR/1.1/jslr/flash/html/HTMLLoader.html

            • 3. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
              adobe_paul Adobe Employee

              Flash Professional started as an animation tool and was expanded with a programming language that became ActionScript (now ActionScript 3.0). Content creators began using Flash to develop applications rather than just animation, so a lot of developer-centric and application-centric functionality was added to Flash, including pre-built user interface components (written in ActionScript). All that functionality and those components are still available in Flash Pro today. However, many developers who came from a traditional programming background had trouble getting into Flash Pro because it is really an animation design tool -- so it uses a timeline, layers, visual drawing canvas, and it required some figuring out to learn how to structure an application in that type of tool.

               

              In response to this, Macromedia (now Adobe of course) created Flex. Flex uses ActionScript just like Flash Pro. Flex also includes numerous user interface controls, written in ActionScript. Flex also adds advanced, flexible layout control and many utilities for common programming tasks like loading data from or sending data to a server, formatting values, validating user input, and more. With Flex, you can define your user interface using an XML markup language (MXML); the compiler then turns the MXML into ActionScript code before turning it into your compiled application. As far as tooling, an eclipse-based IDE called Flex Builder was created that gives you a code editor, a workable but not designer-oriented design view, and other developer tools like debugging and profiling. (Note that Flex Builder has been renamed to Flash Builder for the next release, which is currently in public beta.)

               

              So to generalize, Flash Pro favors a more visual design and animation type of working style, whereas Flex favors a more text-based, code-centric working style. (But that's just a generalization -- many people, especially people who "grew up" with Flash before Flex, still prefer Flash Pro even though they're heavy coders.)

               

              Also, if you want to write everything in code with no pre-drawn visuals (i.e. Flash Pro) and without using MXML or Flex components, you can create your application entirely in ActionScript code. Flex Builder supports ActionScript-only projects for that purpose.

               

              Here are a few links for getting started with Flex, which I would personally recommend if you haven't used either one and you're building something that's more "application" focused rather than media or animation focused:

               

              Flex "Quick Starts" -- short articles focused on specific tasks in Flex

              Flex "Getting Started Experience" -- designed as a set of training courses, intended to take 12+ hours to complete (but you can skip around of course)

              "Flex in a week" video training -- a free 5-day video tutorial series on Flex

              Flex Developer Center "Learning Paths"

               

              As a side note, the link you included actually goes to the JavaScript version of the documentation, which is what you would want if you are going to use HTML/Ajax to build your app. However, if you're wanting to use Flex you would want to use the Flex version of the documentation:

              http://livedocs.adobe.com/flex/3/langref/mx/controls/HTML.html

              http://livedocs.adobe.com/flex/3/langref/flash/html/HTMLLoader.html

               

              And if you're wanting to use Flash, you can use the Flash Pro version of the documentation:

              http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/html/HTMLLoader.html

               

              Yes, it's somewhat confusing and overwhelming. We're definitely working on improving things in that regard.

              • 4. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                timo888 Level 1

                The documentation for the HTML control says "Runtime Versions: AIR 1.1" and the HTMLLoader documentation says "(AIR  only)". But  after some initial basic proof-of-concept experimenting, I don't believe it's going to be possible for me to use AIR because of its limitations with regard to custom items on an edit ContextMenu. I'm going to have to use a Flex browser-app instead.

                 

                (In AIR's WindowedApplications, it appears to be the case that the control for which you wish to create a custom ContextMenu cannot be inside a container but must be "top-level" according to the documentation, which seems to be correct. Browser-deployed applications are not subject to this limitation. For my app, in which users often need to supply characters not found on the keyboard, a context-menu that presents each of these off-the-keyboard characters as a menu-item on the context-menu attached to the textinput, is a very important feature for user-friendliness; and since the layout would use splitter panels (VDividedBox, HDividedBox), AIR is a no-go for my app. )

                 

                To recap the core text-rendering requirement:

                a) the texts I work with are multi-lingual within the confines of a single text (e.g. words and phrases in one (natural) ancient language are glossed by another language, so the words in different languages appear side-by-side)

                b) a single font won't contain all the characters needed for each of the languages that appear in a text, so the text-control employed in the app must be able to switch font-names mid-stream, so to speak:

                 

                <div><span class="lang1">foo</span><span class="lang2">bar</span></div>

                 

                In the <DIV> above, foo and bar require different fonts.

                 

                Are there any native or third-party text-rendering controls, for non-AIR Flex, that can switch fonts in that manner?

                It would be great if the control understood HTML with an internal CSS stylesheet or inline styles, instead of the deprecated HTML tag <font face="x">.

                 

                Thanks again.

                • 5. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                  Joe ... Ward Level 4

                  The context menu limitation that you cite is a Flex limitation, not an AIR limitation. Flex applications in the browser will have the same limitation. I'm not a Flex expert, but at least in AIR, this problem can be easily solved. See http://www.adobe.com/devnet/air/flex/quickstart/adding_menus.html for a tutorial on AIR menus.

                   

                  For advanced text rendering, you should consider the new Flash Text Layout Framework, which can be used in AIR, Flex, and Flash.

                  1 person found this helpful
                  • 6. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                    timo888 Level 1

                    Thanks for the reference to the Flash Text Layout Framework ( I will look into it) and also the link to the XML menus. I am exploring that approach now. Seems promising!

                    • 7. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                      timo888 Level 1

                      The nativemenu context-menu example seems to work only if the TextArea has selectable="false".  If the TextArea is selectable, then the standard context-menu is displayed.

                      • 8. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                        timo888 Level 1

                        Joe,

                         

                        You wrote:

                         

                        The context menu limitation that you cite is a Flex limitation, not an AIR limitation. Flex applications in the browser will have the same limitation

                         

                        Are you certain about that?

                         

                        I am getting different behavior with context-menus on controls inside containers depending upon whether I choose "Web application" or "Desktop application" when creating the new project, which leads me to suspect/wonder if the behavior is application-type dependent.  The web apps seem not to have the same limitations. But I'm too new to Flex to know whether it's something I'm doing wrong.

                        • 9. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                          Joe ... Ward Level 4

                          You're right. The built-in text edit menu was added to Flash since I wrote the example. I don't see a way to get rid of it when using the TextArea control that is based on TextField. However, if you use TLF, you will be able to control the edit menu.

                           

                          In Flex 4, which is in Beta now, so you can try it out, there are text controls that use TLF internally, so the edit menu is controllable.

                          • 10. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                            Joe ... Ward Level 4

                            I'm not a Flex expert, so I suppose it is possible the Flex framework introduces different context menu behavior on the desktop than on the web. But it doesn't seem logical that they would do so since AIR has inherently fewer limitations than the Flash Player browser plug-in.

                             

                            At the runtime level (i.e. AIR vs. Flash Player), the differences in context menu behavior are:

                            1. In Flash Player, you always have a default context menu. In AIR you will only have a default menu for text.

                            2. In Flash Player, the menu will always contain certain built-in items. In AIR, there are no built-in items (except for the text edit menus).

                            3. In AIR you can pop-up a context menu programmatically on a right-click event. In Flash, you can't.

                             

                            In both, any InteractiveObject can have a its own context menu.

                             

                            Flex is, of course, built on top of the lower-level Flash APIs, so it could introduce limitations of its own. The business about only having a context menu at the top level of a container is one such. (It's also possible/likely that our documentation is oversimplifying the matter.) You can certainly have a context menu inside an HTML control (if you choose to render your text using HTML+CSS) or in a TLF-based text control (if you go that route).

                            • 11. Re: Unicode/glyph/font advice needed for porting WinForms app to Macintosh using AIR
                              timo888 Level 1

                              Joe ... Ward wrote:

                               

                              .... I suppose it is possible the Flex framework introduces different context menu behavior on the desktop than on the web. But it doesn't seem logical that they would do so since AIR has inherently fewer limitations than the Flash Player browser plug-in.

                               

                               

                              Agreed, it would be ironic if a Flex Desktop Application had greater limitations on context-menus than a Flex Web Application, and if a Flex Desktop Application had better support for HTML/CSS than a Flex Web Application does.

                               

                              The TLF seems to be a powerful typography subsystem, and offers much more sophistication than my app calls for.  All my app needs is this:

                               

                              a) a text input field that can have its own custom context menu even if the text-field is encapsulated in a user-defined control which is subsequently placed inside nested containers, such as a panel placed on a horizontal-divider container

                               

                              b) a text display field that can deal correctly with one or both of these approaches to CSS styles in HTML:

                                       (1)  <span class="foo">render me in the font assigned to class foo in an associated internal or external CSS stylesheet</span>

                                       (2)  <span style="font-family: Junicode;">render me in Junicode</span>

                               

                              I will check out the beta 4.

                               

                              Thanks for your help.