1 person found this helpful
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.)
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.
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
And if you're wanting to use Flash, you can use the Flash Pro version of the documentation:
Yes, it's somewhat confusing and overwhelming. We're definitely working on improving things in that regard.
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">.
1 person found this helpful
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.
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!
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.
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.
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.
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).
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.