Software Development investigate

Sub-pixel placement and Apple restrictions

Tony McSherry examines the problems he has encountered while developing HTML applications in a Windows environment.

Programming has often been described as nailing jelly to a tree, but usually I like to think of it as hitting your head against a wall — it feels good when it stops.

Our current development project is a new version of our authoring system in .Net (WPF), which produces interactive e-learning in HTML, using either Flash or HTML 5 for audio and video. Our current problem is WYSIWYG — getting the HTML screens to look exactly like those in the WPF Windows environment.

We have recently purchased DevExpress WPF controls specifically for their Rich Text Editor. This loads Microsoft Word and HTML documents, provides Microsoft Word-style text editing, integrated spell checker, etc. A great control, but our problem comes when we try to produce text in HTML with exactly the same on-screen placement. Apart from Word line spacing not being the same as HTML line height, we also have the problem of modern browsers using sub-pixel placement.

The purpose of sub-pixel placement is to make the text easier to read, and make its position on the screen more accurate. However, this is only IE9/10 and Safari for the most part. We can produce text that matches exactly in HTML format for Chrome, Firefox, and IE9 in compatibility mode, but sub-pixel placement will often cause word wrap and increased paragraph height, due to its more accurate placement. To make matters worse, IE9 in compatibility mode won't use HTML 5, so we need Flash installed for the audio and video.

After playing with this for some time, we reached a compromise: we just ignore the differences in the new browsers, and offer a "save as PNG" option for the text for those who want an exact match. Yes, it's a compromise, but we can't really justify the time and money to write the rich text code from scratch, and banging our heads was starting to hurt.

Another irritation in publishing our HTML apps is Apple. We have been forced to become Apple developers by Apple's HTML 5 limitations — namely, the ban on the use of the autorun property in HTML 5

Why is Apple doing this? Well, the official line is that it's to prevent users from running up data charges without them actually pressing an audio/video controller. None of the other platforms have this restriction, and it would also be fairly easy to make it a restriction only when connected to your phone provider, rather than Wi-Fi.

To make our public-service e-learning available to Apple iOS users, we had to become Apple developers, wrap our HTML 5 app in a UIWebview and set two parameters.

UIWebView.allowsInlineMediaPlayback = YES;
UIWebView.mediaPlaybackRequiresUserAction = NO;

Of course, the app could now only be delivered by iTunes (CFA Household Bushfire Self-Assessment Tool), although, since it was free, Apple did not require a pound of flesh. All the other PCs, Macs, Android phones and tablets, and Win Phones and the new Win 8 simply needed a URL where they could run it in multiple browsers.

Is this a deliberate attempt by Apple to restrict the use of HTML 5 apps, or is Apple just being overly cautious? I must admit that I lean towards the first explanation. We await each version of iOS in the vain hope that the restrictions might be removed, and we can return to being just Windows, web and open-source developers.

About

Tony is the owner and managing director of Microcraft eLearning and is one of the creators of the AUTHOR eLearning Development System.

0 comments