Believe me, I really wanted to write an interesting article about a surprising subject but...this is just YAAAAA (yet another article about Advanced Access Preview Release). And if you want my opinion, we will probably continue like this for a few months. :-)

If you've seen the huge list of new features, you've probably noticed that the font engine has changed. Improving the appearance of small point size TrueType fonts was our main goal. The extensive use of anti-aliasing is certainly the most immediately noticeable part of these changes, but perhaps not the most effective. Although smoothing the shape of bitmaps on the screen is clearly a way to make them look better, optimizing the relative position of each pair of contiguous characters can also greatly improve the overall appearance of a string. By extending our "spacing model" we've introduced some subtleties that you must be aware of, at least if you want to use its full power properly.

First, let's run down the list of the goals of the new font engine:

• It should be as WYSIWYG as possible

• Fonts should scale smoothly

• The spacing mode must be adaptable to get optimal results for different needs

• It must support Unicode UTF-8 (the only encoding scheme used throughout the system), and standard 8-bit character sets like ISO-Latin (which can only be used in a BView)

Consequence #1: External bitmap fonts are no longer supported. They're replaced by a private format that's anti-aliased and that can be hand-tuned. We'll be distributing a set of utilities (with sources) that will...

• Let you hand-tune specific point sizes of an existing scalable TrueType font.

• Convert an existing bitmap font into the Be format as long as you ALSO have the corresponding scalable font for those bitmaps.

(And just to head off confusion: If ALL you have is a bitmap font—in other words, no corresponding scalable version—then you're out of luck. Back to our story...)

With these tools, you'll be able to get a very nice looking bitmap font at any size. For example, we will use these tools to integrate bitmaps for small size TrueType Kanji.

Consequence #2: All metric processing is now done in floating-point (with the exception of bitmap glyphs—we don't support sub-pixel positioning in the current engine). Floating-point metrics let us define a better character spacing model. So let me now introduce to you our four spacing modes:

B_CHAR_SPACING, B_STRING_SPACING, B_BITMAP_SPACING, and B_FIXED_SPACING.

Let's go through a quick overview of what these different modes are supposed to do.

B_CHAR_SPACING Spacing Mode:

This is the old spacing mode used in DR8. It's clearly a good way to get WYSIWYG printing, it scales smoothly, and handles rotated and sheared fonts very well. Plus, it's really easy to use...but it has one big fault: It can't improve the readability of small point sizes. So, for drawing a lot of small text, B_CHAR_SPACING is a very bad choice.

B_STRING_SPACING Spacing Mode:

This mode is also WYSIWYG and it scales smoothly, but it doesn't handle rotated or sheared fonts. But it does have one important advantage: It uses a dynamic kerning algorithm to improve the individual position of each character inside a string without modifying the string's total width.

This feature makes B_STRING_SPACING the most difficult of the four modes for the programmer to manage.

B_BITMAP_MODE Spacing Mode:

This mode doesn't care that much about being WYSIWYG, so if you print, widths and positions can change slightly. Also, it doesn't scale very smoothly. Its main features are that it's easy to use, and it gives a very good result when you draw a lot of small text on the screen.

B_FIXED_SPACING Spacing Mode:

This mode is designed to improve the appearance of non-proportional fonts by making all glyphs (of such fonts) share the same width (called "escapement"). This common escapement is an integer, so you can get perfectly regular columns of text.

StringWidth = (sum of individual escapements) x
              (specific point size)

RealEscapement = (individual escapement) x
                 (specific point size)

< DrawString("microsoft") >
< DrawString("micro") DrawString("soft") >
< DrawString("mic") DrawString("ros") DrawString("oft") >

StringWidth =
  (sum of individual escapement in B_CHAR_SPACING mode) x
  (specific point size)

< DrawString("microsoft") >
< DrawString("micro") DrawString("soft") >
< DrawString("mic") DrawString("ros") DrawString("oft") >

StringWidth =
(sum of individual escapements for one specific
 point size) x
(that specific point size)

RealEscapement =
(individual escapement for one specific point size) x
(that specific point size).

< DrawString("microsoft") >
< DrawString("micro") DrawString("soft") >
< DrawString("mic") DrawString("ros") DrawString("oft") >

StringWidth = (count of character) x
              (escapement for one specific size) x
              (that specific point size).

RealEscapement = (escapement for one specific size) x
                 (that specific point size).

In Be Newsletter #72, I wrote about the kind of support we were establishing to serve developers and end-users. This time, I'd like to tackle the question of how to set up support within an organization. Let me start by clarifying terms; by using the term "support," I am referring to the technical support of customers. There are other issues involved in Customer Service; publishing your product, order taking, money collection and distribution, to name a few. While those tasks are within the scope of our Customer Support department here at Be, they are not going to be covered here.

Many developers "fall" into technical support, that is, they publish a product—be it freeware, shareware or a commercial application—then sit back and hope that the phone does not ring. It will, I promise you. Even if you include a disclaimer in your shareware product that is in 72 point type and says "Technical support is not included with this product," you'll get a ton of email, and even phone calls (it is uncanny how some people are able find you). So, let's start with this premise: Every product needs support.

The level of staffing, expense and effort spent on technical support varies depending upon the level of sophistication of both the product and the company that produced it. You can compare this issue to the concept of sailing. Sailboats come in various sizes and have varied crew requirements. You can sail a small day-sailer with one person, zipping around the Bay all day, having a great time and getting one heck of a sunburn. You can sail a 40 foot sloop with two or three people, spend days on board, and go long distances: Trans-Atlantic or, like Erich -- our Grand Vizier of Code—out to Hawaii. It costs more, but you experience different thrills and challenges (notice I did not say "you have more fun"). A large three masted barkentine, the workhorse of days past, requires a large crew and a major investment, but to some people's way of thinking it is the most comfortable way to travel and will allow the most work to be done.

Are you with a day-sailer kind of company? Most developers start here. One or two people, probably the same people who wrote the code, answer inquiries about the product and writing bug-fixes in between trying to get Version 2.0 out the door. You can survive like this for awhile, but eventually you must go with your core strengths. This is a theme I will return to often. Most programmers are good at...programming (duh!). Unless you really want to get out from behind the monitor and deal with <gasp> people, you'll need to rely on support professionals to help customers.

This brings you up to the 40 foot sloop range. You are still the skipper; your hand is firmly on the tiller. You may even haul a line now and then, that is, answer a particularly thorny question. You leave the day-to-day sailing to your crew, however. They become very good at answering questions and even set up a database of frequently asked questions, posting it to your web site. They become the subject matter experts, second in knowledge only to the people who actually write the central code.

Let's look at some of the economics of these support people and how you might go about deciding how big a crew to press. To start, you have to agree on a "fully loaded" price for each person. By fully loaded I'm referring to salary, fringe benefits, office space, equipment, phones, Internet access and other miscellaneous costs. I'll take a stab at an estimate based on my experience (admittedly with a large hardware and software manufacturer, which shall remain nameless). Let's use a round figure of US$100,000 per engineer (don't choke, just adjust the figure to match your experience and rerun the numbers).

Most good support people can handle between 25 to 40 contacts per day. Lots of factors go into this estimate; the complexity of the product, sophistication of the customer, tools that the support person is using and method of contact (email, phone, fax). I've managed organizations that were able to average 40 contacts per day. However, we hit that number after lots of work and with a staff of 29 that had been working together for over a year and had a constant flow of similar questions to answer. To be fair, and set proper expectations, I'll use a figure of 30 contacts per day per person.

It is my opinion that, in order to provide for contingencies and for the mental health of your support people, a minimum staff of 2 is required. Otherwise, vacation, sick time, jury duty, you name it, hits and one of your people will be off listening to the defense attorney vehemently state that his client could not have been anywhere near the scene of the crime, while your support questions keep rolling in.

These "contingencies" bring up another issue, one that in Call Center parlance is known as an efficiency, staffing or load factor. It is a factor that modifies the equation to provide for the time that the support people are off for those events mentioned above. I can't tell you the amount of time Call Center managers spend arguing about this. Suffice it to say that, the "Theory According to Romson" is that one must allow for a 20% staffing factor (your mileage may vary). This factor will affect the number of calls per year each person will be able to take.

**Chart 1**

Personnel cost (per person)...................$100,000
Number of contacts handled/day/person...............30
Number of people.....................................2
Efficiency factor..................................0.8
Number of work days................................260
Calls handled/person/year.........................6240
Cost per contact................................$16.03

You'll notice that you are able to calculate a rough cost per contact from this model. Keep that number in mind, you can compare it to what is available if you decide to hire a crew from the outside (also known as outsourcing).

Forecasting the number of contacts you will be offered is like forecasting the weather. Worse, actually, since it depends on a sales forecast rather than a butterfly flapping its wings in Brazil. Given this challenge, support managers use a number of formulas to come up with a forecast. The factors that figure into this formula are much the same as mentioned above regarding the type of product, customer, and contact methods you encounter. Many software companies use between 35% and 50% for a contact rate. That means for every 100 units sold, you'll get 35 questions. If you include hardware in that equation (like that unnamed "fruit" company) the factor could go as high as 150%. Add novice users, and it soars to 300%. Another reason your call rate could be as high as 300% is if your product is so complex that the user must call for installation help. Some LAN products come to mind.

Experience in taking calls and email will give you a real contact rate, but the most common dilemma encountered when setting up support is that you must start with a guess. Make an educated guess and verify it with experience, but have a contingency plan, in case the contacts go through the roof. For our hypothetical voyage upon the Sea of Support, I'll use a midrange contact rate of 50%.

Given that rate and the calculations we went through above, it appears that your 2 Support Engineers will be able to handle the results of the sale of 25,000 copies of your software (two people taking 6,420 calls per year, each call being the result of the sale of 2 copies of the product = 24,960 units). Not enough to match your sales forecast? Congratulations! The formula can extend to millions of units; just add people.

Aye, but there's the rub. Do you want to invest in additional high priced support personnel in-house or should you look to an outside company to do the first-line support for you? You are quickly moving up to a much larger sailboat and you'll need to decide if you want to sail her yourself or let an experienced captain and crew take you into the future.

That is a discussion for next time. Come on back to the Be Newsletter next week, and we'll get into outsourcing, loss of quality control, vendor management, and more sailing metaphors.

So, what multimedia OS would be complete without pretty good support for FireWire? If you were at the Be Developer's Conference and attended the session covering video, you saw a lot of slides about where to get info on FireWire and a number of the other technologies that we will be supporting in the future. One piece of the demo that we did then was released last week. The VideoMania application didn't do any FireWire, but it did the Picture-In-Picture thing. Well, how about camera control, VCR control, and the rest.

What are we missing? Well, FireWire is a relatively new technology, and there aren't a lot of APIs in OSes to support it yet. We do have a working framework for it though.

ftp://ftp.be.com/pub/samples/fire.tgz

This archive contains a driver for the Adaptec FireWire board, as well as a whole lot of stuff to support the AV/C command set. We want your input as to how we can make it better. We want to provide a number of classes that make AV support relatively trivial in the BeOS. We have the Midi Kit, the Media Kit, and now the AV Kit in the makings. This is your chance to get in on it while it's still in the oven.

What will be added over time is support for the various subtypes available in FireWire, that means cameras, TV tuners, and monitors. At least according to the spec. Right now, there is only support for camera and VCR subtypes.

If that's not enough, I hear Geoff Woodcock has been working on a ISO9660 file system extension. I don't want to steal his thunder, because it makes for a good tutorial on writing file system extensions. I will say that it is quite a relief to be able to mount standard CD and get at my shovelware easily without having to go through a floppy or network transfer phase. Keep a lookout in the ftp.be.com/pub/dr9/samples directory for these goodies.

Well, summer is rapidly upon us here in California. 102 degrees one day, rain the next, followed by fog. Ahhh, what a life. The DR9 samples are flowing, apps are coming in, and the world is a wonderful place. If you don't believe it, then you're not programming on the BeOS. Have you bought your Hauppauge tuner card yet? If you haven't, you're missing out on all the fun.

The dreaded sentence. We heard it often, in various guises. In the VC trade, the kind condemnation is worded as "interesting." The "but" is a way to introduce the objection that the better product won't win. Look at Betamax, look at the Mac. I won't get into the Macintosh story for today, but let's take a look at the Betamax story. There is more than meets the lore.

Yes, when comparing the polar display of VHS and Betamax video output on an oscilloscope, the Beta standard stood as clearly superior. And Sony sold much Betacam equipment to the pros. That didn't happen with the consumer version, Betamax. Why? Was it a case of the mighty, foxy Matsushita steamrollering poor little Sony?

Consumer Reports gave us the answer a few years back. Yes, Betamax looked better on the scope, but... not on the TV. Using a double blind experiment (where neither the person running the test nor the subject know which parameters are used) with ordinary program material, a panel of viewers could not distinguish between a VHS and a Betamax recording displayed on a run-of-the-mill TV set. For the consumer, Betamax didn't yield better viewing than VHS.

Things got worse for Betamax: Consumer Reports then looked at the repair history of VCRs. All the Matsushita brands (National, Panasonic, Technics...) stood at the top of the quality scale, and Sony at the bottom. (At the risk of angering Sony fans, Sony's conversion to VHS hasn't improved their standing, they still rank at the bottom of quality surveys.) QED: the customer is smart. Or to quote a past Vice-President: "The market's invisible hand has spoken."

Betamax lost fairly.

Now, the above doesn't imply we'll succeed because we have a superior product. We're working on it, we hope to be on our way, but we haven't proven that yet. And, as the "product" word implies, there are many factors involved. The meaning of "better" is one of them. In a metaphoric view, an operating system is a musical instrument. As such, "better" has to be qualified: for whom, for what. As musical instruments go, not every piece of music written for one instrument can be felicitously rendered on any other one. An organ toccata won't play on a flute; string glissandi won't render on a piano. Our goal always has been to provide an opportunity for composers, programmers, to write music that couldn't be easily written elsewhere, or that wouldn't play as well elsewhere. In addition, Be music can be marketed, delivered and updated inexpensively on the Web, thus lowering the cost of entering the market. Basically, all you need is sweat equity—I was going to write: "a better product."

Another way to look at "better" is this: think of three categories. Better than yesterday, impossible yesterday and unthinkable yesterday. Place them on a horizontal axis from left to right. In general, the profit opportunity improves as one moves towards the right. On the left, marginal improvements, in the middle, removal of painful obstacles, on the right, a brain-teaser. Note I wrote "unthinkable yesterday" in order to afford us the benefit of hindsight, of retroactive recognition of the inconceivable. Examples abound: four years ago, who thought of the Web? It has quickly shifted left at least one column. I'd say two if there was a T3 line into every home; that's almost unthinkable.

Back to the original challenge, if we are perceived as merely offering marginal improvements upon existing OS platforms, then the "nice product, but" sentence is justified. The competition will easily catch up with us and we'll fail. Fortunately, in our chosen field of media applications, we've been able to locate much of our work in the "impossible before" (at the PC level). As for the "unthinkable," we'll have to wait until it becomes retroactively obvious.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.