In This Edition:
Building the Helix Highway: Detours & Speed Bumps
11 July 2008 — Eleven days ago we shipped the Intel-native version of Helix Server, along with new Preview Releases of Helix Client and Helix Engine (also running natively on Intel-based Macs) and breathed a huge sigh of relief. We finally shipped a new product that faithful upgrade customers could purchase. The result has been encouraging as many of you stepped up (again!) and bought the upgrade, including some of you who were not intending on installing it right away.You reasoned, rightly so, that we could use the money. For that, we thank you.
In many of our previous editions of The Latest Word we’ve likened the process of bringing Helix to macOS to a journey. After shipping Helix Server for Intel, we thought we were finally out on the open highway, ready to roll down the windows, let the wind whip through our hair, and make time. When suddenly…
Detour Ahead
As soon as we shipped Helix Client/Server 6.1.1 we got a message about a bug. A user reported that when using Helix Server for Intel, queries on dates were not working. They would sometimes show all the records, and other times they would show none of the records, but it would not show the right subset of records. That’s a pretty serious bug. We suggested switching to Helix Server for PowerPC as a temporary workaround while we investigated. Fortunately this one was very easy to reproduce, and we had it fixed within a couple of days. That was a good thing, because as soon as we started beta testing this fix, we were contacted about yet another bug. In this case, using Helix Client Classic to paste a large (over 32K) picture into a picture field would not work. Once again this was very easy to reproduce and just as easy to fix.
And so, less than two weeks after the release of Helix Client/Server 6.1.1 we are announcing the immediate availability of… Helix Client/Server 6.1.2! You can read more about this release on the Helix 6.1 product page.
During this time we also had a chance to study the crash logs that our new Helix Server for Intel was producing. Our own techdb was crashing 2–3 times a day, and at first they seemed to be ‘all over the map’ as far as where the problem was. But then the common thread was discovered and in the 6 days since we switched to Helix Server for Intel 6.1.2 we have not had a single crash. We can’t guarantee that every installation will be this trouble-free, but we are pretty confident that we’ve reached that level of stability Helix Server users have come to expect.
Before we leave this subject, there is one more thing that must be said: about a year ago we had a tough decision to make: keep plowing forward with the PowerPC-only Engine and Client and get them out sooner, or take a (hopefully short) detour to do the work required to extend Helix into the new world of Intel-native code. Obviously we chose the detour, which was at times painfully longer than we thought we (and you) could endure. However, thanks in no small part to the Universal Pioneers who financed that work, we are now reaping the rewards. Six months ago there was no way we could have found and fixed bugs as fast as we can today. We are really starting to hit our stride and are optimistic that the rate of progress will only continue to accelerate in the weeks to come. As evidence of that, we also are also announcing today new Preview Releases of Helix Client and Helix Engine. We’re now in a place where we can roll these improvements out pretty fast.
And speaking of fast, end users are reporting that Helix Server for Intel is easily twice as fast as Helix Server for PowerPC. If you’re using an Intel Mac as your server but running Helix Server 6.0 or Helix Server for PowerPC 6.1, you’re running under Rosetta. Helix Server for Intel eliminates the need for Rosetta and brings you the speed you expected when you purchased your new machine. So if speed considerations were part of your upgrade concerns, this one is a no-brainer.
But we realize “Helix users do not live by speed alone.” There are other important considerations as well. Since we first shipped Helix Server for PowerPC and the Preview Release of Helix Client, a couple of hot topics have dominated the airwaves and we’re going to address them here.
Speed Bump Ahead
The first one we’d like to discuss is speed. Our initial tests showed Helix Server for PowerPC 6.1 running slightly faster than Helix Server macOS 6.0 and Helix Server for Intel 6.1 about twice as fast, which about what we expected. But then we started getting reports that 6.1 was somewhat slower than 6.0. It took us a bit of head-scratching before we realized the problem. Our tests measured Helix running on a Local Area Network (LAN) and the reports of slowness were coming from people using Helix on a Wide Area Network (WAN).
Although most people still use Helix primarily as a local office database, more and more people are tapping into the power of serving their databases to Clients around the world (or at home) via the internet, and those people were disappointed. And although our work in Helix 6.1 so far has been almost obsessively focused on making the code Intel-native and getting the macOS Client running, we were concerned enough to huddle our engineers for a discussion about it. Two things emerged that are worth sharing with you.
First: a speed sacrifice was required to create Intel Helix. Over the years, much of Helix’s network speed was gained by ‘packaging’ messages together and sending them across the network in one large chunk, leaving it to the recipient to unpack the data and make sense of it. This worked to our advantage when Helix first made the transition from AppleTalk to TCP/IP, where latency is a critical factor in WAN performance. When accessing a Helix Server on a Local Area Network, there is no such issue and local Clients are reporting that they too see the speed improvements we expected.
But bundling messages doesn’t work in a cross-platform world (Here’s a link if you care about the technical details) and in order to allow both types of Helix Server (PowerPC & Intel) to talk to all three types of Helix Client (Classic, PowerPC & Intel) we had to either build a layer into Helix so that the Server knew which ‘language’ each Client was speaking and every Client knew which language the Server spoke, or unpackage the messages. 2 types of Servers times 3 types of Clients is only 6 possible combinations, and it might not be too bad creating a 6-level ‘translation table’ in order to avoid losing any speed right now. However, looking down the road to the PiHC (Platform independent Helix Client) future where we could have many new types of Clients (not to mention the possibility of direct Client-to-Client communication) and you can see that this could grow into an unwieldy mess in a short time. Plus, Helix already understands the individual messages, and that code is well-tested, so unpacking allows us to use code we know we can rely on. Adding a whole new layer to the process would slow development down significantly.
Second: With all of that said, let us add that we did look for (and find) some ways to regain speed. We still plan on keeping our main focus on getting all of Helix to macOS, but rest assured that we are also working to improve WAN performance. Right now it might feel like ‘two steps backwards’ but your patience will be rewarded when we take ‘three steps forward’ in the performance race.
Temporary Inconvenience, Permanent Improvement
The other hot subject comes from those users who have been experimenting with printing in the Preview Releases.
Early in this process, we knew one of our biggest problems moving to macOS would be printing. It’s a renovation project we’ve put off so far — some would say for too long — but we know we need to roll up our sleeves and get to it at some point.
First, let it be said: printing in macOS is different than it was in Classic. This reality is unassailable. For instance, if you’re still working with Macs from the 1990s running ImageWriter printers and you’re waiting for everything to be perfect before you take the plunge and spend all that money and buy new machines and upgrade and… you’re in for a rude awakening. You won’t be using ImageWriters anymore. There simply is no way to plug one in to a modern Mac. [Editor’s Update: We have learned that it is possible to use an ImageWriter with macOS. Click here to see our FAQ page.]
In fact, if you rely on multi-part forms, finding any impact printer that works seamlessly with macOS is going to be a job in itself. (If you know of one, please let us know.) The point we’re making here is the further back you’ve hung, the bigger the adjustment you’re going to have to make. Even new printers that come with native OS 9 printer drivers (yes, there are still a few out there!) work differently when used with macOS native drivers.
The worst of it is that some printers even have different page margins depending on which OS you are printing from. And because Helix’s template layout is based on the ‘printable area’ model (as opposed to the actual page size) the exact location of the printed material can change depending on the printer you are using. Even in the days before macOS this was a struggle for Helix users. But the main point is that the printing paradigm has shifted once again and the way Helix prints must shift with it. But this time, when we do it, we’ll look for a way that ends the aforementioned struggling. Consequently, the logic goes, when Helix prints in the macOS context, you will need to ‘Print Different.’ There is no way around it: adjustments must be made.
Second, we must remind you: the printing you see today is not the final word. Rewriting Helix’s printing code correctly is a substantial project, and we do intend to do it right. In our early plans, we thought it would be months before printing would be enabled at all. But we hit upon a bit of dumb luck and managed to get it up and running pretty quickly, albeit with some rather annoying limitations. We haven’t yet gotten to the place where we can dedicate the resources we need to hit printing with “the big hammer,” but until then, a little information can help you produce output in Helix that is actually quite good, provided you’re willing to put in the work. What follows are some tips we’ve picked up to help you make the transition to printing in macOS.
Tip #1: Scale to match your printer. Remember that bit of ‘dumb luck’ we mentioned above? Here’s what it was: although there is no magic way to print in macOS, wxWidgets does provide just such magic. But like all real magic it does it by a clever sleight of hand. What wxWidgets gave us was a simple way to capture the contents of a window on screen and send that to the printer. This is, essentially, a fancy version of the “Print Screen” key on the old IBM PC keyboards. The trade-off is that since Helix’s display resolution is 72 dpi, the printed output is limited to 72 dpi. Most of us these days are used to seeing the crisp output from 300 dpi ink jet printer, and the lower resolution can be somewhat disheartening.
Most modern print drivers do something called anti-aliasing to improve the quality of low resolution output. But in the case of text, that works against Helix, making things look less sharp. However, you can maximize the quality of Helix output by first making sure that you’re output is sent at a resolution that is an integral factor of your printer’s resolution. Let’s translate that with an example. Helix draws your views at 72 dpi, but your ink jet printer is probably printing at 300 (or 600) dpi. Dividing the printer resolution (300) by 4 gives you 75, which is an integral factor of 300. But there is no integer you can divide into 300 to arrive at 72 (the desired dpi). The key is to reconcile the discrepancy between 72 (Helix’s view resolution) and an integral of your printer’s resolution. Using our example, 72/300 is 0.24, or 24%. Obviously, scaling your view down to 24% of its normal size isn’t very useful, but 24% * 4 = 96%, which is very close! So scaling the print to 96% (which you do in the Page Setup dialog) gives converts the Helix view into an integral resolution that the printer needs for optimal results.
But this leads us into a painful point which you must remember: Page Setup settings do not ‘stick’ in Helix 6.1. Actually, they do stick (that is, remember the setting you entered) as long as the collection remains open. But when you Quit Helix, those setting are forgotten and they revert to their original form. Why? Well, this was a conscious decision on our part. Because Helix collections have many different views, some designed for printing specific things (like checks) on specific paper sizes, every template stores its own Page Setup information. This is how Helix — unlike most other programs — can remember that your Invoice view prints on Letter size paper while your Sales Report view prints on Legal size paper. To compare this to the ‘normal’ way things work, choose Page Setup for this web page and note that the Scale is 100%. Then open a new browser window and use Page Setup to change that window’s Scale to 50%. Now switch back to this window and check Page Setup again — this window’s Scale has been set to 50%!!! This is the way Page Setup usually works, but Helix is much more powerful than that and that’s about to cause a bit of (temporary) pain.
Here’s the problem: The information that comes out of the Page Setup dialog in macOS is significantly different than it is in OS 9. Most important, the data is both bigger and differently arranged. For us to store macOS Page Setup data in Helix, we would have to change the structural definition of the template, where the OS 9 Page Setup is stored. That would mean breaking backwards compatibility with Helix 6.0. Of course, we could choose to forego that at any time, and we are getting closer to the point where we will, but until then we have to stick with our ‘no new structure’ pledge. Updating structure means we slow down to create new versions of Helix RADE, Helix Utility & Update Collection and we do not want to slow the progress of the macOS Client and Engine to do that yet.
So for now, when you open the Page Setup dialog in macOS and make changes, those settings are stored in memory instead of in the collection itself. When you Quit Helix, those settings are lost. That’s painful, but that’s just the way it is for now.
Tip #2: Use modern fonts. Fonts are a critical element in printing, and some work better than others. The right font can mean all the the difference.
Because fonts barely resemble what they were back when you used to use Font/DA Mover to install them, a lot of funny stuff will happen as you open in your collections Helix goes looking for fonts that don’t exist in macOS. Very few fonts from Classic are available in macOS and even those are not really the same font. That is, they may have the same name, and they may look mostly like the font you are used to, but there are differences (some subtle and some not so) between, for example, the OS 9 version and the macOS version of Helvetica.
To help out, we’ve added a new tool to let you know which fonts are used in your collection, whether they are available in macOS, and if not, which font is being used as a substitute. If a font you used in your collection (even in Styled Text) is replaced by a substitute, that font is not available to you in macOS. Your options are to a) find a macOS version of that font and install it, b) allow Helix to continue automatically substituting for it, or c) switch to a font that is supported in both OS 9 & macOS.
How forms are designed in Helix affects the way they print. Relying on font substitution is a problem, and the more font problems you correct, the better your printing will look. It may take a bit of experimentation until you find fonts that print well for you in both macOS and OS 9, but once you find them, be careful to use only those fonts in your collection design. You will be rewarded.
Tip #3: Follow Apple’s Human Interface Guidelines. In macOS, boxes and lines do different things on screen (and on paper) than they used to do. You may be quite pleasantly surprised at how the use of framing rectangles automatically gives your forms a more “macOS look.”
As for checkboxes, radio buttons, popup menus and command rectangles, if you’re one those people who used ‘non-standard’ font styles (London 18 point green, anyone?) in these interface elements (referred to as ‘controls’ in Apple’s HIG documentation), you may be a bit disappointed when Lucida Grande 13 point black takes its place. But a few clicks in RADE, designing with that result in mind, can make everything look better and print cleaner.
While many Helix users these days are sending pdf copies of their forms instead of paper, the printing industry is still very much alive. If you are concerned about the printing transition, you can have an impact on the process: Start working with the Preview Releases now, testing on your own printers and giving us the vital feedback we need to make it work right. Remember that saying about ‘an ounce of prevention…’
Work Area Ahead
With a lot of words and a lot of editions of The Latest Word over the past two and half years, if there’s one thing we’ve been trying to get across is that unlike all previous updates to Helix, this one is not necessarily going to be a simple matter of “run-Update Collection-and-go-back-to-work.”
As you work with Helix in macOS, you will probably want to invest some time in your collections to make them look better, but that’s a small price to pay for this major leap. Keep in mind these three important considerations as you prepare for macOS:
- These problems don’t happen to everyone. You may light things up in macOS and everything will look and work just fine for you. Don’t let all of this talk scare you away.
- There is ‘no silver bullet’ that can automatically make your forms look pretty in macOS. In some small way, virtually every form will be a little (or a lot) different when viewed in macOS. But your forms will work. Your data will be secure. Your collection will still do what it did before. Things that don’t appear to work properly may, in fact, just be bugs that will eventually be corrected. Remember: Preview Engine and Client products are not finished yet. If something doesn’t work the way you expect, visit our techdb and see if other users have reported it. If not, submit a bug report.
- The things you have to address will be largely cosmetic in nature; most everything else will just work! Having to do some template work shouldn’t really be such a bad experience. You’ve probably been meaning to do it for years. For most people, the only issue is time.