Want to Talk to Me?

Martin Sevior wonders how one talks to me.

Well, you come over to my blog, and you leave a comment. I'd have answered Martin's question by leaving a comment there, but his blog doesn't have comments turned on.



Currently playing in iTunes: Whipping Post by The Allman Brothers Band

Comments (71)
  1. Hi Rick,

    What a surprise! I never thought I’d be able to talk directly to a genuine MS Word developer.

    I have so much to ask. Just a couple of questions to start…

    MS Word has a gazillion features. How do you determine what is useful and what is bloat?

    What if anything would you remove given your druthers?

    Another question would be, how does a feature request filter up to you?




    My email address is msevior &*&%^ physics #$ unimelb @# edu $% au

  2. Hi Rick,

    Here’s another question. We’ve been reasonably successful at reverse engineering the MS Word binary format.

    Is there a source of documentation to the format you know I’m allowed to read and use without signing an NDA?



  3. Rick Schaut says:

    First, if you want an e-mail conversation, you an use the "contact" link on my home page. You don’t have to follow any secondary links in order to drum up my e-mail address.

    How do we determine what is useful and what is bloat? We ask our customers. As it turns out the "bloat" tends to be rather small. While few individuals use more than 60% of Word’s features, well more than 90% of Word’s features get used.

    What would I remove? Marching red ants, but the code to support animated text is so small, that removing it would be a negligible reduction in Word’s size. So, I spend my time working on things that we believe will have a more positive impact on our customers’ overall value proposition.

    How does a feature request filter up to me? Program managers use a variety of information sources to design how features ought to behave, including individual feature requests. After a program manager has written a draft of a feature specification, then a cross-disciplinary team reviews the spec before I actually sit down and write a design document. Another cross-disciplinary team reviews my design document, and then I start writing code.

  4. Rick Schaut says:

    I’d suggest Google. The format spec is on the web. No NDAs required.

  5. Mike Hearn says:

    As far as I’m aware, the only spec on the web is for Office 97 not any newer versions and is actually hosted by an AbiWord developer. When I last searched for this information I also came to the conclusion that the format specs had to be licensed for newer versions. The "free" spec (really just grabbed from MSDN when it was up there for a short while) was very hard to read and consisted mostly of code that had clearly been copied/pasted from the Word sources itself.

  6. Rick Schaut says:

    Mike, as far as I know, that <em>is</em> the only spec that’s been written. Nothing I’ve seen internally has been updated since then.

  7. Thanks for the answers Rick!

    OK here are some follow ups.

    Regarding features, at some point users become sophisticated enough to know they don’t need new things, they just want what they want to work well. There is a classic(admitted self-serving) mini-review of our new brand new OSX port versus your product here.


    (BTW we will keep making regular OSX releases on at least a monthly basis, each one better than the last.)

    Other people who have compared MS Word 2004 to our program appear to have similar views.

    Would regard this as failure of execution, (you guys didn’t do a good job of executing the vision), a failure of vision (you guys really don’t know what your customers want) or that the people who prefer our program are a minority of users outside the mainstream market?

  8. OK here is is a technical question.

    I am very impressed with the Scalability of MS Word. Your application generally degrades it’s performance gracefully with document size.

    At present the fundamental limit of how well AbiWord scales with document size is that our PieceTable (Document Model) is constructed as a linear, doubly linked-list and we fundamentally need to know the position of every fragment of the list.

    So when an insertion or deletion happens in the document we need to update the position of every fragment in the document.

    This means of course that insertions or deletions will degrade linearly in speed with

    the document size.

    Does MS Word also need to do this?

    One of our developers experimented with implementing the PieceTable as a tree with each fragment of the PieceTable knowing only it’s local size and it’s relation to it’s neighbours. Insertions/deletions into this structure only ever involve updating the links to the fragment and the fragment’s own size.

    Document positions are determined by navigation through the tree.

    Consequently insertions/deletions degrade logorithimically with document size.



    Is this something that MS Word does already?

  9. Rick Schaut says:

    Do I think AbiWord getting some favorable reviews against Word is a failure of our process? No. Clearly there are some users who don’t want all of what Word offers. There’s a difference between satisfying everyone and maximizing the met need over a broad user base. Read through some of the archival posts I’ve made, in particular with respect to value propositions.

    The only thing I’ll tell you about Word’s piece table is that you guys have been thinking in the wrong direction ๐Ÿ˜‰

  10. bi says:

    May I know what kind of broad user base’s met need is satisfied with interfaces such as these: http://ghettographics.org/bi/soapbox.html#20050313 ? Or, failing that, when will Microsoft developers rethink these interfaces so that they suck less? Thanks.

  11. Rick Schaut says:

    Well, it turns out that the equation editor is a feature used by a relatively smaller portion of the market. The answer, then, is that, by not spending much time bringing the UI for equations more up-to-date, we’ve been able to do work that appeals to a broader cross-section of the market.

    That doesn’t necessarily mean that we won’t revamp equations at some point in the future. It does, however, mean that our understanding of the market and broad user base is distinctly different from yours. But, then, that was my point.

  12. Geez, talk about antagonizing questions.

  13. bi says:

    I did freely admit that Microsoft’s idea of the "market" includes such niches as "the Fred Mbogo Organization wants to look grand by partnering with some humongous company", which probably isn’t part of LyX’s "market".

    Speaking of which, what exactly is the "market" that Microsoft tries to gain? What are the methods by which Microsoft gauges the kind of things the "market" wants? (Well, if Microsoft considers all computer users as part of its potential "market", and it gauges the mood of the "market" by asking only current Microsoft customers… then it’ll get exactly the wrong idea about the "market".)

    In any case, my point remains that the "costly, time-consuming effort to understand users’ high-level problems" don’t immediately translate to better products. It doesn’t take a committee to figure out what’s wrong with "Insert / Object / Create New / Microsoft Equation 3.0"; but someone needs to have the incentive to _act_ on this high-level problem and actually solve it. And the current interface itself can’t be based on any "understanding" of any "high-level problem", it was almost slapped together in an ad-hoc manner.

  14. Axel says:

    I think the equation editor is a chicken and egg problem. I write very few documents that do not contain at least a few equations, and that is one of the reasons why I avoid Word whenever possible. This, I belive, is true for many people in my field (I’m a Ph.D. student at a technical university), who prefer LaTeX since unlike Word it caters to OUR needs, not the needs of a consultant or a secratary.

    The tree main resons for avoiding MS Word:

    1). Equations in Word are apalling

    2). Support for vector graphics is bad. On screen rendered APS text looks appaling. MATLAB cannot produce EMFs that look good. Not sure if this is MATLABs or Words fault, but there are at least two dealbraker issues with EMF.

    3). Rendering bugs. (See below)

    Words own stylesheets usually work well enough. But when you submit conferance papers in Word format, you usually have to use a Style sheet supplied by the conferance holders. They NEVER work. Chapter numbering screws up, font styles change, the TOC misses chapters, etc. There must be something fundamentally wrong with the way stylesheets work in word if someone can screw them up so easily.

  15. OK Rick,

    That was an interesting point about "Not enough resources to justify the work". We tend to view MicroSoft has having infinite resources. I would have guessed that the MircoSoft Office profits which I guess run at around $2,000,000,000 per year would be sufficient to hire a few 100k$/year programmer(s) to get a decent equation editor. There are number floating around the Free Software world that are significantly better than yours.

    OK Another technical question. How much of the code base of the Mac and Windows versions of MS Word is shared? We in AbiWord are quite proud of clean seperation between our cross platform backend and our various Front Ends. It means every platform gets a native look and feel.

    We do this by implementing class structures with a cross platform base class containing abstract virtual methods and derived children which implement the methods in platform-specific methods?

    Is this the route that you use? Do you have a more entwined solution ala the Open Office VCL or the Mozilla XUL? Or have you just hacked out the Windows calls and replaced them with OSX? Or something else?

    Care to comment on which approach you would prefer if you had the chance to do it again?

  16. Hi Rick.

    Looks like you opened up a can of worms with your invite. ๐Ÿ™‚ I just hope you don’t give away any trade secrets to the competition. LOL


  17. Rick Schaut says:

    Bi, I’ve already blogged about some of the things we do for market research. As for whether or not this makes a product "better" in the over-all sense, I think you need to look at more than one feature.

    Axel, yes, there is some part of chicken-and-egg problem involved, but it’s really more a matter of priorities. Given a choice, for example, between reimplementing a better UI for equation editing and implementing the UI for styles I mentioned in the Deaf Developers post, the UI for styles will win every time. Very simply put, the new styles UI will benefit far more users than a new UI for equation editing.

    Martin, it might be convenient to think that we have infinite resources, but the fact is that we don’t. It doesn’t matter what revenues one has, one still faces opportunity costs. Moreover, there’s a point of diminishing returns with the number of developers working on a single project.

    Win and Mac office "share" quite a bit of source, but the trees have been forked following the release of Office 97. From time-to-time, we’ll merge changes accross the two branches, but it’s not like we build each others sources on a daily basis.

    As for what I’d do differently, see my post on Mac Word 6.0.

    Clarence, yes, it is rather amusing that I’m being asked some questions that would constitute a competitive advantage (e.g. regarding the details through which Word’s performance degrades gracefully). Despite that, it’s good to hear from you, and I hope you’re enjoying your retirement. We miss you, and I don’t think I need to say why here :-).

  18. Rick Schaut says:

    By the way, Martin, I think your diary link to this post rather inaccurately portrays my comments about corss-disciplinary teams review the spec. Your comment presumes that I don’t participate in those cross-displinary teams, when all I’d said is that I write the design document. Note that my design document is, in turn, reviewed by a cross-dicipliinary team.

    Honestly, I’m surprised at your mischaracterization of my remarks given your PhD. I’d expect a bit more rigor than your comments exhibit. Interesting that you would use the word "committee" when I clearly used the word "team".

    For the record, I participate as a member in these cross-displinary feature teams, though I’d really wonder how one might conclude that such cross-displinary teams somehow both exclude and operate "beneath" front-line developers.

    You also concluded that I don’t ever actually see any direct customer feedback. One wonders why I blog at all, or read various newsgroups, or watch focus groups, or sit down and chat with members of our customer council–all facts of which one could become quite aware if one were to take the time to actually read my blog.

  19. Oppenheimer says:

    Don’t hold it against Martin. His surroundings in terms of developers less old, less wise, and less altruistic tend to diminish the benefits of the rigor of his profession.

    As the free software community in general ages (spoken like a true old fogey, I know), I think that the intellectual rigor with which they treat themselves, their projects, and their surroundings will finally come up to match their ability to churn out lines of code.

  20. Hi Rick,

    You are right. I haven’t read your blog in detail. Just a few bits that seemed interesting to me. Time is precious to me too.

    Here is what I was thinking when I wrote that sentence.

    I imagined you going to meetings where a team member stand ups and says, well "we’ve received 100 requets requests for XXX, 500 feature requests for YYY. A good example of XXX is characterized by Mary Shelley, who writes:… "

    In my imagination you don’t see the 99 other feature requests. Your committee (team) member has decided which one is typical. He has done his thinking for you.

    I still find it weird you claim you can’t fix the Equation Editor through lack of resources. It’s been broken since at least Word 2000 which I guess constitutes at least 50 man-years of software development time (assuming you have at least 10 developers working on MS Word). If this is actually the case (not enough resources) it obvious that the Free Software process is a far more efficient means of producing software.

    Axel, where I come from, if someone asks me to talk to them, I bring up subjects that I think will be interesting to them. We have no trade secrets in Science. We build on each others work. We struggle to be the first to discover something and to let others know of the discovery. It is the foundation of our modern civilization and is one of the reasons Free Software appeals to me on a very fundamental level and why it has such a strong appeal to the Academic Community at large.

    I’m not sure why Rick invited me to talk to him. He knows I work on a competing project with a fundamental ly different development methodology. Even telling me how Microsoft determines which bugs to fix could be construed as an example of giving away trade secrets. Why not go the extra step and have a discussion about the relative merits of different approaches to the same problem (performance issues with large documents)? I told him what we were thinking and what I thought was a pretty cool idea. I might be totally wrong, jeeze, I’m just an amatuer who does this essentially for fun. He decided not to share his experience.

    OK that tells me a limit of Ricks openness.

    Rick has now told me that Windows and Mac versions of Word are essentially forked and Microsoft has not altered the structure of it’s document model since Word 97. I’d already guessed that but it was nice to have it directly confirmed.

    At some point I knew we were going to run out of things to say to one another. We might as well find out what the parameters of discussion are. I can be entirely open and honest.

    Rick can’t.

    That is not to say Rick is bad person or anything. It’s just the parameters of the environment he chooses to live in prevent him.

    There are a number of people in the Free Software community who think I should give up AbiWord and leave Office Productivity applications to the professionals at SUN.

    But I choose not to.



  21. if I might be so bold, I believe the tone Martin was taking in his blog was less about your process, and more a direct reaction to Eugenia Loli-Queru’s recent misrepresentation of how developers for the GNU Network Object Model Environment view code contributions over feature requests; that is, if someone wants to help make the code better, and it’ll be quite a bit of effort for the programmer to do it himself, the audience is encouraged to contribute. Eugenia’s stance was that GNOME ignores it’s userbase, and listens only to the large corporations with money. Martin was simply stating that perhaps there’s nothing wrong with ignoring the vocal minority that want drastic shifts in the program, and business needs (in the form of a committee) might actually be a viable way to program.

    this is not to say you don’t innovate, it simply means you implement features and solve problems given to you by others in the organization. individual users and replies in your blog probably account for an interesting subset of features, but are they the primary source of your ideas?

    sorry for the long-windedness, but your last post sounded like you weren’t aware of why he used you as an example. in my eyes, it seemed as if he was honoring you, and not giving you any sort of backhanded compliment.

  22. Rick Schaut says:

    Oppenheimer, one wonders what the result is when people churn out many lines of code in the absence of rigor :-).

    Jason, Martin might well have given me a backhanded compliment, but I was hoping someone who speaks so eloquently about openness and honesty could be a little bit more careful about the truth.

    Martin, you asked how someone talks to me. I answered your question rather openly and honestly. As for limits on the extent to which I’m allowed to be open, a good number of the secrets to which I am privy have little to do with Microsoft. It is part and parcel of life as a professional software developer.

    Your image of our feature process is both amusing and telling. I’m most struck by the absence of any understanding of how one might approach the issues more proactively. Market research is not rocket science. They even teach it in business schools :-).

    As for not finding resources, why would you ever believe that some level of revenue somehow obviates opportunity cost? I think I’m as baffled by your apparent inability to understand the concept of opportunity cost as you seem baffled by the fact that we are still subject to its operation.

    Perhaps rephrasing the point will help to make it clear: it’s not a matter of ability to do something. It’s a question of choosing what to do based on priorities set through a proactive process of understanding what will be most beneficial users.

    For that reason, we aren’t going to fix everything we might want to fix in any given product cycle. Why is that so difficult a concept to understand? You do recall me saying that we might fix this at some future date?

  23. Rick,

    My appologies for incorrectly characterizing the process with which you choose to fix bugs and implement features.

    Regarding my bafflement, it’s because the cost to fix it appears so small compared to the size of resources. I simply don’t understand why it’s so hard. Your statement implies that working with the Word codebase has become very difficult.

    Regarding the outcome of the processes, well if AbiWord sucks, or constantly crashes, I can assure you I’ll know all about it. There are plenty of people looking over our shoulders.

    I’ll also say this. When I first saw MS Word in 1995 I was in total awe. I had done a fair bit of programming by then but I did not have the imagination to see out how you guys got it to work.

    Congratulations on an inspirational piece of work!

    It’s been great fun for me to work out how to implement all the features we find useful. I am actually looking forward to having an open discussion about the trials and tribulations of writing a word processor.

  24. Rick Schaut says:


    Perhaps your understanding of what ought to be fixed, and how, is somewhat limited? Suppose we make the process of inserting an equation, using the current Equation Editor, more direct and simple. Does that really solve some of the more significant issues users have with creating equations in Word?

    I’m glad you’ve found Word to be an inspirational work :-). Out of curiosity, what are your thoughts on how Word’s change-tracking features have evolved over time?

  25. This has been a very interesting read, thanks Rick.

    A note on the docs for the binary Word 97 file: they are incomplete even with regards to the 97 features and what’s worse, they contain numerous factual errors, but I suppose that’s life (and presumably your source code contains all the comments you need).

  26. Martin Conv says:

    Hi Rick,

    I find it fascinating to see you and Martin Sevoir discussing this common interest from 2 different perspectives.

    I would like to know what you think of abiword. Does it compare to MS Word? Where do you think that it is lacking/naive and what do you feel are it’s strengths – technical and non technical?

    My opinion is that both projects are very evenly matched up to the 60% of features that everyone uses. I suppose it is the remaining 40% of features that are used by the few where the different development methodologies make a difference and where you feel your approach will have the advantage.

    However I trust that both projects contain very capable, intelligent people who can solve the remaining problems in efficient and insightful ways resulting in a very close race!

    All the best to you & Martin

    Martin Conv

  27. Rick Schaut says:

    Tomas, you expect the documentation for something as complex as Word’s file format to be entirely accurate? :-). Fundamental principle of all software: the truth is *always* in the code.

    Martin C, I think the most I can say at this time is that I think Martin S has done a fine job with AbiWord, and that the product is likely to do quite well for a non-trivial number of users.

    I am, however, going to shy away from any kind of objective comparison, simply because I don’t believe "objective" comparisons are all that meaningful. Of course, one can do the standard table of check boxes feature comparison, but that doesn’t tell you how the products resolve respective real-world problems.

    From the technical point of view, I have not looked at AbiWord’s sources, so I can’t give you a meaningful comparison. Even if Martin S asks me to look, I’m going to decline simply because I don’t want to incur the potential legal risk of being accused of copying code from an open-source project.

    As for whether or not the race is "close," I can assure you that we’re not standing still :-).

  28. Rick,

    I’ll answer your second question first. My real job is an Academic in the School Of Physics at the University of Melbourne. My field of research is Experimental Particle Physics.

    I haven’t closely followed the development of MS Word. I only use MS Word 2000 running under CrossOver Office on Linux. I don’t have much need for it frankly. AbiWord-2.2 is fine for most of my day-to-day needs for a Word Processor. For Scientific or really complex documents with lots of maths I use Latex. The only time I need Word 2000 is when I prepare Grant Applications. I only use it then because the application forms are provided in RTF format.

    Now when I write Grant Applications I’m usually part of a Research Team. We did try once to use the "Track Changes" feature in MS Word to update the grant application. Unfortunately the result just confused everyone, including me. I recall not being sure if I had the authority to accept changes, and if I did if the decision was reversable. I didn’t know what would happen if I liked part of a set of changes from someone but wanted to change the rest. Having deletions left in the document but crossed out made the document harder to read. So we abandonded the practice pretty quickly. So I can say "we", me included, didn’t like the feature as available in Word 2000.

    To be fair, my brother, who works as a high level engineer for a TV network, sings the praises of "Track Changes" as the best way to prepare collaborative documents so I guess once you know how to use the feature properly it becomes useful.

    The "Track Changes" feature in AbiWord I believe roughly matches the behaviour of MS Word 2000. The developer who implemented it, Tomas Frydrych, has been reading this discussion and may want to comment further.

    Oops gotta run. More on the Equation Editor (for which I have a lot to say!) later.



  29. Hi Rick,

    My real job is Associate Professor in the School Of Physics at the University of Melbourne. My research interests are in the field of Experimental Particle Physics.

    I don’t actually use MS Word very much. AbiWord is more than sufficent for my day-to-day Word Processing needs and contains many usabilty improvements over MS Word. (Like auto-update Word Count, numerous easy to use non-modal dialogs, visual drag and drop of text plus other stuff.)

    In particular I find dealing with lists and tables far easier in AbiWord than MS Word. Well fair enough I designed them for my needs :-). We can have a discussion about how these are differently implemented in our programs later if you like.

    However many of these features have only recently been added to AbiWord and before then I used MS Word 2000 running under CrossOver Office wine on Linux. I haven’t tried a more recent version because CrossOver’s support for Office XP has only arrived recently and Word 2000 suffices.

    I mostly used MS Word for writing Research Grant applications because the application forms are complex beasts distributed in RTF format. Being involved in Experimental Particle Physics means working with teams. My team collaborates in the process of writing Grant Applications. We discovered the "Track Changes" feature in MS Word one year and tried to use it in the application process. It didn’t work out too well. Here is what I recall I found hard.

    1. Didn’t know if "Accept Changes" was reversible.

    2. Didn’t how to accept some changes but not others.

    3. Didn’t know if I could make a change to someone elses changes and if so whose changes win.

    4. Deleted text as "crossed out" made it difficult to read the document critically. My eye found it hard to jump over all the crossed out text to what the revision would look like.

    So we abandoned using the feature and went back to our old ways of doing things.

    (lots of emails explaining what we’d changed to each other.)

    To be fair, my brother, who works as a high level engineer for a TV Network thinks that "Track Changes" is a great feature and the best way to write collaborative documents. I think he spends a very large fraction of his time doing this so maybe if we’d learned how to use the feature better I would have more appreciation of it.

    Tomas Frydrych, who has posted here today, is the author and architect of AbiWord’s "Track Changes" feature so he may be able to be more objective.

    I’ll write about the equation editor in another post.



  30. Bystander says:


    I implore you to watch your tone in your replies. I found one reply to be somewhat rude, condescending and insulting, especially since you invited the conversation.

    Now many of us lurkers already have a somewhat lower opionion of MS and their practices, I’m sure you are not eager to reinforce that those thoughts.

    It’s a really shame you are unable to get into some of the technical detail. For me that is far more interesting than the process.

    Lastly, Martin, I feel much more awe at the achievements of AbiWord. A nimble cross platform wordprocessor written by a disparate bunch on unpaid hobbyists being compared to the cash-cow product of a mega-corp. Quite amazing.

    Now that I have shown my bias, I hope the ‘softies don’t dismiss the comment out-of-hand.

  31. Rick Schaut says:


    Forgive me if I seem a bit rude, or condescending, but I don’t think it’s fair to characterise this post as an outright invitation–at least not any more than an invitation than the existence of this blog is an invitation.

    If I seem a bit rude and condescending, it is in no small part because Marting asked how one talks to me. Given that he found out about me via this blog, and it has comments enabled, I thought Martin’s question not only rude and condescending, but outright insulting–as if I blog without wanting comments. Recall that Martin’s blog doesn’t have comments enabled. Who’s being more open, Martin or Me? Don’t make snide remarks about other people and expect not to get at least some snarking back :-).


    You’ve mentioned issues we’ve long recognized as being problematic. That’s why both versions of Win Word and Mac Word now have a completely revamped UI for track changes. While it doesn’t necessarily resolve all of the issues, the new UI both makes it far easier to see final version while still seeing markup and makes it clearer as to how changes to changes will show up.

    If either you or Tomas has seen the new UI, I’d be interested in what you think compared to your previous experience.

    Lastly, given that you work in academia, particular in the field of particle physics, I’m not surprised that you find Word lacking. This has been a long-standing hole in Word’s feature set for quite some time, and we’re well aware of it.

    It might help if I explain a little bit more about opportunity costs and resources. I’ve blogged about this before, but I’ll reiterate the point. Prioritizing our dedication of resources to solving any one given problem is not based on how much revenue we’re making now. Rather it’s based on how much revenue we think the respective solutions will generate in a future release.

    Opportunity cost operates whenever resources are finite, and is based on the recognition that no resource can be committed to doing more than one thing at a time. The cost of committing a resource to doing one thing, then, has to include any benefit you might have incurred if you committed those resources to doing something else.

    Unfortunately, opportunity cost is difficult to quantify. The only way to be certain as to which choice is the correct choice is to, somehow, be able to live along two distinct time-lines simultaneously. While this might make sense in terms of the mathematics of particle physics, there’s little chance we can make it work on our macro level :-).

    I look forward to your comments on equation editing. I’m fully expecting a rather scathing review. I’m even tempted to try to anticipate a number of the complaints you might have==though I’ll bet that the vast majority of them stem from the fact that equations are OLE objects–but it’s late. And I have to rise early tomorrow morning.

  32. Hub says:

    Rick wrote:

    "Tomas, you expect the documentation for something as complex as Word’s file format to be entirely accurate? :-). Fundamental principle of all software: the truth is *always* in the code."

    And Rick <a href="http://uwog.net/blog/?p=39#comments">also wrote</a>:

    "Now, exactly what benefit do I get by GPLโ€™ing Word source?"

    I think that the quote at the top of this comments perfectly answer the question in the second quote….

    Opening the source code of Word would open the file format of Word document, and give some respect to your customers.

  33. Which is the new UI for tracking changes; is it the one in Word 2000, or later? I will try to give you more specific feedback later, but as a user, the main thing for me is to be able to locate and accept/reject changes quickly; I do that by recording an ‘accept and find next’ and ‘reject and find next’ macros and assigning keyboard shortcuts to those (I prefer using kbd to the mouse).

    On a separate note, could I, on behalf of all the academics and students out there, plead for a bug to be fixed? Since Word went 32 bit many years back, it has the tendency to place footnote text for a footnote that is near the end of page on the page following the reference. The start of a footnote text should _always_ be on the same page as the reference, it can continue on the following page if necessary. I have wasted countless hours tweaking fmt to work around this, not mentioning the irritation this causes me reading through other people’s papers. In fact, I have a coleague who insists on using Word 6 for this very reason. Please, would you guys fix this? Or perhaps footnotes do not represent sufficient oportunity to justify the cost?

  34. Bystander:

    Thanks for your support and interest. But really I did do Rick a disservice when I jumped to a conclusion based on a hasty reading his first response and my own preconceptions.

    He was right to call me on it and I appologized publically on my blog.

    Rick to clear up another mis-conception. The site where I host my blog, Advogato has no comment system. This site pre-date the current craze of blogging by several years and is rather archaic generally. However I like it because of the community feel and support.

    Rick I’m not quite sure how to take this sentence.

    "Oppenheimer, one wonders what the result is when people churn out many lines of code in the absence of rigor :-)"

    Taken in conjunction with Oppenheimer’s post it could be either a wry smile and that things are not what they seem, (thanks!) or a sign that you guys actually believe your own marketing (very amusing :-)).

    Regarding "Track Changes", well the next time I get the chance to test the latest version of MS Word (I can’t afford it) I’ll have a look.

    Hmm maybe I can scam some time at a retail shop.

    OK on to equation editting.

    Well firstly it is clear that the UI directing one to the feature is confusing to say the least. As bi has already pointed out "Insert Object=>Create New=>choose… equation" definately makes it hard to find the feature. Just giving maths it’s own "insert" catergory would be an enormous help for your cause.

    I often receive assignments written by students in MS Word except for the equations which are scribbled in by hand. I would guess that only 30% of Physics students who otherwise use your product know anything about the equation editor.

    You have failed to make an easy-to-use facility. I’m saying this as a fact, not casting aspersions on the work that went into it. I know it’s hard to make entering maths easy.

    Your definition of opportunity cost makes some of your decisions easy for me to understand. Though I would argue that the Mac Business Unit should have complained louder at having one the Mac’s strongest market segments, Schools and Universities, ignored by hiding your maths facility.

    Next, as you say, equations as out-of-process COM objects was just a bad idea. It’s just too slow. You can scroll a page full of equations and stare at blank space for several seconds until they appear. Also you can’t edit the equations in place in the document. The fonts are not integrated with the equations either. If you highlight a row text containing maths and change the font size, the maths doesn’t change size appropriately.

    OK I don’t know this for absolute fact but I asserted it point blank to someone who should know and he didn’t deny it. Please correct me if I’m wrong.

    By far your biggest mistake was doing the deal with the company that supplies your equation editor. I don’t why you guys agreed to ship deliberately broken code but it really is infuriating to customers. You know it. It’s broken just enough to be annoying without breaking your document. Who wants to get a pop-up add while fighting with a broken piece of code saying "If you give us more money we’ll ship you something that works."! I mean come-on! Every single member of any focus group you run would tell you that this is a lousy thing to do. You know it’s a lousy thing to do.

    I once had a very angry conversation with the CEO of the company that supplies your equation editor. His whole business model appears to be to make your product bad enough for people who use maths to buy his product as well.

    It’s always a bad idea to ship deliberately broken stuff. People know when they’re being used. They hate it. I hated it. I guess you decided the opportunity cost of doing your own product didn’t justify it.

    OK enough rant. In my next post I’d like to explain what I think is the cool stuff we’ve done (and still doing it not complete) with Maths in AbiWord.



  35. Priit says:

    Hi Rick,

    as this turned out be a "night of questions and answers", i’d like to find out about one annoying thing about MacWord. Or at least some deeper explanation how Word works internally.

    I work in company where I receive lot of latvian & lithuanin texts, written in WinWord. My job is to copy paste them into various layouts, for example Quark. What makes me angry is Word’s way of changing characters not present in current font. I open Latvian text and it is shown using _ in the place of such characters. Then I open font from menu and see some strange choices (Times CE, Helvetica CE,…) which are not present in other programs . I change the text into Times CE and after that I see all the characters correctly. C&P into Quark, works well too. But if I do not change the font, all those underscores are copied and pasted and all the text is ruined. Why? On the other hand – if I change the font into something I use in Quark final layout ( some Frutiger CE I have here), then the underscores stay, again c&p and text is ruined. But using the same Frutiger CE in Quark works well ( after times ce in word and c&p).

    Why must you use underscores and ruin the original text in such way? And if there’s a good explanation to _show_ those characters, then why cannot you copy the original ones to clipboard?

  36. Rick Schaut says:


    I don’t think you answered my question. There are a number of ways we can make Office’s source available to customers–in fact we’ve already done so for various government agencies. I asked why we should GPL the source. Why that license, and what benefit do I get from sharing under that license and not the one under which we’ve already shared it?


    The UI has been updated a bit since Word 2000. If you guys used a Mac, you could download the test-drive version and get a far better idea of what I’m talking about. The changes are difficult to describe.

    That said, you can assign keyboard shortcuts to the Find Next and Find Previous change commands. At that point, it’s trivial to walk through the document accepting and rejecting changes without having to grab the mouse.

    The footnote issue is fixed as of Word 2000, but there’s a preference that reverts to the Word 97 behavior. When you open an older document in Word 2000, that preference is turned on by default. With new documents, it’s turned off (unless, of course, you’ve selected a default set of compatibility options that turns the preference on). Check tools/preferences compatibility options tab to check.


    It’s difficult to explain why this happens without going into deep background about Unicode, different character sets, fonts and script codes. To understand what’s happening with the clipbard, I’d also have to get into a discussion of clipboard formats, and how applications both supply and look for different clipboard formats.

    The short answer, though, is that both drawing the text and putting plain and/or formatted text on the clipboard requires converting Word’s internal Unicode into some other text representation. That conversion can, under some circumstances, result in a loss of character information, which is where the underscores come from.

    If you want a fuller explanation, send an e-mail via the contact link in the upper-left hand corner of this web page, and I’ll try to go into more detail.


    The lines of code in the absence of rigor was merely a ribbing dig, which is what the smiley was intended to convey. I certainly don’t presume that OSS developers lack rigor.

    As for your comments regarding equation editing in Word, I have to agree with all of them. Whenever I’ve done equations in Word, I’ve reverted to using the old EQ fields (which have been around since the beginning of time, yet are more obscure than even the Equation Editor), and for the very reasons you cite. I want my equations to behave like text, not a graphic.

    There are times we make bad decisions. The problem with most of them is that we’re forced to make them in the absence of perfect information. When you decide to use a third-party tool, you’re putting your faith in that third party to actually execute as well as you would hope. But, what do you do if they fall short of your expectations? Cut the feature entirely, or ship it with the warts that exist? That’s never an easy call.

  37. jason cook says:


    Thanks for hosting an interesting discussion. Figured I’d de-lurk by asking my own questions (from a total non-programmer’s stance): what do you think of Xcode? Versus your use of Metrowerks? And how does that choice of build environments affect the end user?

    I bookmarked this blog when you first explained your take on Carbon vs. Cocoa, which was elucidating for me. And I’ll readily confess that, before that, I’d always ascribed Word X’s sluggishness and quirks (esp. its weird visual artifacting) to what I imagined was an especially crufty codebase — and I also took it as evidence that Carbon didn’t compile as well as Cocoa, performance-wise. My experiences with the teensy-download Mellel (which boasts of its Cocoa pedigree, IIRC) also reinforced these beliefs, whether true or not.

    Add to that thinking the commonly-reported statement that Mac OS X got faster with each release in large part because the GCC compiler gets better (I’ve heard claims like 5-10% speed increases), and I’ve always wondered: well, apart from starting fresh in Cocoa, then why doesn’t MS occasionally update old software to take advantage of these new & improved compilers — just drop the Office v.X source into the latest rev of Xcode, and press some big red ‘compile’ button and…. presto, 5-10% faster version of old program, right? (Actually, I’m guessing the answer is ‘no’, but I’d love to understand why.) And, presumably, you’d pass that along to users…

    Anyhow. I suppose I find the whole business of compilers and performance rather interesting, if only because it seems (again, to a non-programmer) like such an easy way to squeeze a bit more speed out of the same old code… like old-school disk defragmentation, in a sense. But does it really matter/work?



  38. Rick Schaut says:


    Personally, I like XCode. It’s a nice environment, and I don’t have build-tool restrictions that are inherent in Metrowerks’ build model. I can, for example, quickly cobble together a simple shell script as a build step to, say, run flex and bison to generate a quick-and-dirty parser.

    As for our use of Metrowerks, that’s dictated more by legacy code than anything else. Things like the order of allocation of bit fields within a data structure can be really problematic when one moves from one compiler to another. And, not using bitfields is simply not an option (some of these data structures are written to the file).

    Do I think there’s a significant performance hit because we use Metrowerks and not XCode/GCC? Not really. We’ve already optimized a number of core bits such that incremental improvements in compiler technology won’t really help much. There is the CFM vs Mach-O issue, but we really won’t know until we make that transition (which is, itself, independent of the Metrowerks vs. XCode issue).

    Will we eventually move to XCode rather than Metrowerks? I can’t say with any authority. I’d like to. Apple would certainly like us to. But the decision isn’t mine to make.

    As far as perfromance is concerned, however, a move from one compiler to another, particularly from one completely different compiler implementation to another, can actually have a negative effect. That’s because you have a tendency to learn the quirks of the older compiler, and have written the code in such a way as to take maximum advantage of the old compiler’s idiosyncracies.

    Word has additional considerations outside of the choice of compiler. Word relies very heavily on the concept of caching. This is a tricky concept to work with, because changes to underlying data require that you invalidate the caches. However, if you are too aggressive at invalidating caches, then you suffer a significant performance hit–might as well not have the cache at all.

  39. Rick,

    as promised I’d thought I’d say a little about where we’re at Maths in AbiWord..

    Firstly thanks for the little tidbit about equation fields. I had no idea of their existance.

    I’d like to post code here but in deference to your GPL sensitivities I won’t ๐Ÿ™‚

    AbiWord achieves it’s cross platform abilities by exploiting C++ class heiracies. We place cross-platform code in core libraries and the base classes. Then as needed we derive platform implementations from the base class.

    A classic example is how we actually draw text to the screen. The smallest element of text we have we calls a run. It’s piece of the document with contiguous properties like a string of text with all the same font etc. a text run fp_TextRun is dervice from our fp_Run base class.

    Now one thing fp_TextRun has to do is draw it’self on the screen. It does this with a method fp_TextRun::draw(…).

    OK now this run looks up a pointer to our graphics class. Then when it calls the method


    characters appear on the screen at location (x,y)

    Now fp_TextRun is pure cross platform code. It’s built by the Windows/Unix/linux/OSX/QNX compilers.

    Yet it directly calls a method that puts characters onto the screen with 4 radically different display API’s.

    We do this by making GR_Graphics::drawChars(x,y,…) a pure virtual method and leave it to the child classes GR_Win32Graphics, GR_UnixGraphics, GR_CocoaGraphics, GR_QNXGraphics to actually implement the drawChars method.

    ie GR_UnixGraphics::drawChars(x,y,…)



    All implemented with native calls to their respective API’s

    OK so in ascii art.

    / XP XP |->GR_Win32*

    | Model | –> (GR_Graphics)-|->GR_Unix*

    | View | |->GR_Cocoa*


    We use the structure of C++ to separate the platform code.

    The advantage of this is that we have one source tree for every platform. This tree is constantly built and people complain loudly of someone breaks their platform build.

    It has the very real benefit of making each build a genuine native application on each platfrom. The GNOME guys love us because we can integrate right into the GNOME environment.

    At the same time we are clearly a native OSX application and a native win32 application and we can make use of native resources on each platform.

    OK what has this to do with maths?

    Well about 4 years Luca Pavoni from the University of Pisa developed a GtkWidget for the display of MathML. He did a great job of overeing the full version 2.0 specification and made the code GPL. Now his widget was built with much the same philosphy. It has a pure C++ core with pure C++ graphics class. It has a number of different chid class that implement drawing into Gtk+, PostScript and other drivers.

    When I looked at this code I saw the similarity. His graphics class looks very much like ours.

    So the plan was use the gtkmathview core to drive it’s abstract graphics class and interface that to abi’s abstract graphics class. The abi would use all it’s native interfaces to draw on the canvas and print to paper.

    Luca and I finally met up last year at the annual GNOME European developers convention. We hacked way for 3-4 days and…

    IT WORKEd!

    gtkmathview abiword abiword

    (GtkMathview)=> abstract => abstract=>platform

    It was great fun.

    It’s fast, it prints, selections work. The maths changes with the selection font size. Further more because it’s MathML exporting to HTML is trivial. So we finally have a tool Uni professors can use to easily put maths on the web.

    Did I say one of the reasons I develop AbiWord is for my own personal benefit? ๐Ÿ™‚

    OK that was year. We did all the work in a special branch of the Abiword CVS. Unfortunately GtkMathViewis a large library. Loading it takes about an extra second in startup time.

    Since that increases the load time for AbiWord by about 40% on many machines it was unacceptable.

    Also GtkMathView has not yet been ported to Windows and Mac. There is no reason it can’t we just don’t have enough developers to do.

    If we directly interfaced it into the build we would halt development on windows and Cocoa until it was ported. This was unacceptable. So I turned it into a plugin.

    The plugins also have a generic XP interface with many virtual methods that are overlaoded by specific platform code too.

    In addition the plugins (wiil be) loaded on demand so people without Maths in their docs don’t suffer load-time penalty and people who do get the penalty when their first use of maths occurred not at start up when they’re most impatient.

    So this all works now. You can find screen shots of it action on my blog.

    Regarding an editor, well I implemented a really quick hack which uses the itex2MML application to convert equations to MathML via a non-modal dialog. The latex is stored along with the MathML as well as a png respesentation of the MathML for platforms without gtkmathview or older versions of AbiWord(for backwards compatibility.) Having a genuine XML file format really helps with sort of thing.

    Anyway this would actually be my prefered means of entering and editing math but I’m very interested in exploring graphical equation editors or some other means of entering math. As I said before it is hard to easily enter math with a keyboard attached to a computer.

    We’ll prolly just go with the Latex editor for our 2.4 release this Northern Summer. Later we’ll see what we can do.

    I guess that’s the Free Software way of addressing opportunity cost.

    Well this has been a really post. I’d just say one more thing. We made a lot of progress this last few months by leveraging other GPL code. As the total pool of GPL code increases so does the amount of power we can deliver to our users.



  40. Rick Schaut says:


    I appreciate your deference to my preference with respec to GPL’d code. I have no desire to jump into that bramble bush (c.f. google for "Karl Llewellyn").

    At first blush, your design is a very nice way to go. Platform dependent details are buried in neat little subclasses, and, freed from having to worry about those details, you can code to a higher-level of abstraction.

    There are some low-level details, however, that can cause problems in a number of cross-platform scenarios. One of the biggest is text measurement, e.g. ATSUI vs GetTextExtentExPoint. Given these low-level differences, it’s possible to end up with an implementation that’s lightening fast one one platform yet dog slow on another.

    One of the things we’ve been able to achieve since Word 6 is, if you use a font that’s available on both Windows and the Macintosh, then lines of text will always break at the same location in your document regardless of the platform. We’ve even improved this with the latest version of Word for the Macintosh such that documents printed out on the same relatively high-resolution printer (anything greater than 300 dpi) cannot be distinguished at the character level. That’s hard to do when you bury important details in different sub-classes. The granularity of abstraction needs to take these details into account, or you loose some important compatabilities.

    The real problem with compatibility isn’t so much a matter of simply being able to read another program’s (or another version’s) files. It’s making sure that the output doesn’t change when you move from one program to another. Unless you achieve that, your compatibility story is always going have significant holes.

    To relate this back to the equation editing problem, the problem with any TeX-based way is that you won’t get identical layout from one platform to another. TeX (whichever flavor you’re talking about) is designed to maximize the quality of the output for each given platform, but that sacrifices some aspects of layout compatibility.

    Suppose, for example, you have two people working on a paper. One uses a Windows computer, the other uses a Macintosh. Should that paper include a rather lengthy equation, there’s a good chance that the equation might fit on one line when the document is opened on the Mac yet not fit on one line when the document is opened on the Windows computer.

    If you have access to both a Windows computer and a Macintosh computer, play around with this, and see if your implementation doesn’t have this problem. Better yet, see if you can convince yourself that you don’t have this problem regardless of what the inputs are.

    I can state with certainty that, unless you’ve properly abstracted text measurement, and incorporated this abstraction into your layout algorithm, then you will not have sovled this problem even for just plain old text.

  41. Alberto says:


    I think you (and we all developers) have a problem: given that we hear request, opinions and so on from our customers (we like rather talk about "users"), we have a vision biased by design. Take my case: I am a Math, so I never will use Word for writing maths papers, so you never vill hear from me and you don’t improve Eq Editor, etc.

    How do you think we could solve this?


  42. HI Rick,

    Thanks for your interesting email.

    Just to let you know we don’t actually use Tex for layout. Do a Latex -> MathML transaltion and layout the mathml with the gtkmathview library.

    The latex is our easy-to-use input tool for creating complex maths ๐Ÿ™‚ Here is the 3D single-particle Schrodinger Equation expressed in Latex form:

    [ -ihbarfrac{partial Psi}{partial t} = V(vec{r}) – frac{nabla^{2}}{2m}Psi ]

    Believe it or not this capability really excites a useful fraction of our user base.

    Your point about text layout is very well taken. Frankly we haven’t worried very hard about getting pixel-perfect documents simultaneously on all our platforms.

    In principle it should all work since we do all our layout at 1440 DPI then scale to the resolution of the current zoom and display device be it screen or printer.

    It should work provided the platforms agree on the sizes of all the glyphs of the same fonts.

    We have worried very hard about making our documents print *exactly* as they look on the screen and it could be that this has the nice effect of cross platform compatibility.

    In practice I haven’t tested it much.

    Lemme see…

    Actually I have access to a Win 2000 machine here at work. And I have my Fedora-core-3 laptop. The compressed abiword document found at:


    Looks *exactly* the same in both ๐Ÿ™‚

    The lines are broken at exactly the same places. So I guess FreeType-2(Linux) agrees with the font-metics the Win32 API calculates.

    A pity I don’t have OSX handy. Maybe someone with access to both OSX and (Win32 or Linux) could comment? You can download AbiWord-2.2.5 from


    However we’re not happy with our current layout engine because we can’t do sub-pixel positioning. The result is that text looks a bit funny on screen in full-justification. We need to move from our current integer based calculations at 1440 DPI to double-precision calculations plus implement kerning to fix this.

    Marc Mauer has a patch to do replace our integer calculations with double-precision ones but we haven’t merged it into CVS HEAD yet.



  43. A note on opportunity cost: I think Rick cannot say every thing, so you have to read between the lines. M$-Word team just add a sufficient number of new features so that people buy the new version. If they improve every thing in one shot, what would be left for the next versions? "Opportunity costs" should be read "opportunity for new incomes".

    Rick, your note on cross platform compatibilities is interesting. I personnally think abiword should use more gtk/gnome librairies on all platform to improve the stability AND the compatibility. The native look-and-feel can be made at the toolkit level.

  44. Rick Schaut says:


    The "solution" is for us to do precisely what we have been doing: figure out what your pain points are without waiting for you to come to us to tell us about it.


    First, there’s a better solution to device-independent layout than using floating-point math. I’ll bet that, if you google a bit on various combinations of words on the subject, you’ll find something that discusses how Word does it.

    Second, the real reason to be able to do sub-pixel position has to do with anti-aliasing, particularly on the Mac.

    Third, one sample document doesn’t provide an adequate test of cross-platform layout compatibility.

    Lastly, it really is a shame that you don’t have OS X around, because that’s going to be your real problem child :-).


    You assume that we can simply put as many developers on a project as would be required to implement every feature we want to implement. Even if we ignore such issues as ROI, that assumption is false. There is a point of diminishing returns with respect to the number of developers working on a project.

  45. Rick,

    Your are right that there are issues related to the cross-platform design of the layout engine, but they are not unsurmountable, and achieving decent peformance on different platforms is not that big a deal. Our layout engine is entirely in the xp code (the code that is shared between all platforms). We then have an abstract layer for accessing platform specific text-rendering APIs; this layer provides not just virtual functions, but also virtual data structures, which means that when AbiWord runs on Windows, the data stored in the layout engine is such that is suitable for passing directly to the win32 APIs; this gets around the performance problem you describe. (We use Uniscribe on win32, and I love Uniscribe — the guy who designed the library knew what he was doing, a breath of fresh air in the sometimes convoluted world of Windows programming. I am particularly impressed with support for Syriac, even though that undoubtedly did not make much sense from the oportunity cost point of view; I understand the guy did that in his spare time, is that right?)

    As far as the portability of document layout, while not unimportant, IMO this is less of an issue in a wordprocessor than you suggest, and can be only trully achieved if you embed fonts (which I know Word can do, but you pay for that much in the file size). Perhaps more importantly, there are solutions that are specifically designed to achieve document layout portability, and do great job at it. If I really want document layout to be fixed, I produce a pdf, not an AbiWord document (or a Word document, for that matter). The virtual printer PDFCreator, another open source tool, makes this trivial whether I use Word or AbiWord. (There is an additional advantage to doing this even when I use Word: the pdf file is noticeably smaller than the original doc.)

  46. Rick Schaut says:


    I love Uniscribe as well, though I have no idea why one would think that Syriac would not make sense from the standpoint of opportunity cost. Uniscribe works based on various Unicode character properties and information in various font tables. Getting that right should cover just about any script/language at little or no cost.

    Also, the time it takes to implement something is only a small part of the cost. There’s a reason that the number of testers in Mac BU outnumbers the number of developers :-).

    Reliance on Uniscribe will be problematic when it comes to layout compatibility on the Mac. At the present, there is no way to take advantage full Uniscribe-like functionality independent of using ATSUI to perform all line layout.

    I should note that, cross-platform, or cross-product, layout isn’t important because you or I think it’s important. It’s important because *users* think it is.

  47. Mike Hearn says:

    Martin, one issue we have with running MS Office on Linux via Win32 emulation (I work for Codeweavers) is that the FreeType auto-hinter does not produce metrically compatible glyphs. If you enable the bytecode interpreter then it does so we ship a licensed (from Apple) build of FreeType with Crossover. I suspect AbiWord may encounter similar issues at some point.

  48. Hi Mike,

    I’d better check whether Australia now recognizes Software Patents. We did not use to but we bargained that away with the Free Trade agreement with the US. I’ve always compiled FreeType with the auto-hinter on.


  49. Mike,

    Firstly let me say congratulations on a such fine software. Codeweavers wine is truely an awesome piece of of work.I’m very happy to pay $60 per year to you guys!

    I’ve been thinking a bit more about your comment about needing auto-hinting. If I understand how autohinting works, this would actually make no difference to where AbiWord breaks lines for Windows, Linux or OSX builds.

    We position text using 1440 dpi fonts for all platforms. At that resolution, the auto-hinting is turned off, right? We then scale down to screen and zoom resolution keeping the each character positioned at the nearest pixel to where it would be at 1440 dpi. As I said this makes the text look a bit funny on-screen especially at zooms where we’re close to half-way between font sizes.

    However printed text looks fantastic and is gaurenteed to break at the same point as the screen text.

    Did I understand you correctly when you said you needed the auto-hint patent to make MS Word break it’s lines correctly? If so that is an interesting new fact on how MS Word positions text and is certainly different from the direction we’re planning of taking.

  50. Martin,

    On Windows we have encountered the additional problem that when drawing on screen the system intentionally gives you a font which is slightly bigger than what you in fact requested (in the name of readability, the SDK says). This really makes WYSIWYG extremely hard to achieve — the documentation does not explain the algorithm used to adjust the font size, but it appears non-linear and I have not been able to find a way of turning this behaviour off.

    From using Word it is clear to me that this is possible to work around to a major extent. Word occasionally exhibits the signs of mismatch between the positioning of characters and the props of the screen font, but it happens much less frequently than in AbiWord, and they are less pronounced, which makes me think these are more due to rounding errors that actual font selection. Perhaps there is some undocumented API?

  51. Rick Schaut says:


    Word does not use any undocumented API for either text measurement or text rendering. You’re getting warmer with the rounding error idea, or, more precisely, with how that error is distributed over a run of text.

  52. xslf.com says:

    ื–ื” ืืžื ื ืงืจื” ื‘ื—ื•ื“ืฉ ืฉืขื‘ืจ, ืื‘ืœ ืจืง ืขื›ืฉื™ื• ื ืชืงืœืชื™ ื‘ื–ื”: ืฉื™ื—ื” ืžืขื ื™ื ืช ื‘ื™ืŸ ืžืคืชื— ืฉืœ ืžื™ืงืจื•ืกื•ืคื˜ ื•ื•ืจื“ ืœื‘ื™ืŸ ืžืคืชื— ืฉืœ ืื‘ื™ื•ื•ืจื“, ืฉื”ืชืงื™ื™ืžื” ื‘ืื•ืคืŸ ืคื•ืžื‘ื™ ื‘ื‘ืœื•ื’ ืฉืœ ื”ืžื™ืงืจื•ืกื•ืคื˜ื™. ืžืขื‘ืจ ืœื“ื™ื•ืŸ ื•ื”ืžื™ื“ืข ื”ื˜ื›ื ื™ ื”ืžื•ืคื™ืข ืฉื (ื”ืžืขื ื™ื™ืŸ ื›ืฉืœืขืฆืžื•), ืžืขื ื™ื ื™ื ื”ื™ื—ืกื™ื ื‘ื™ืŸ ืฉื ื™ ื”ืžืคืชื—ื™ื….

  53. Travis Fisher says:

    The problem abiword on windows continuously has with glyph positioning is that some letters of words end up by rounding to be a pixel too far apart, and some end up to be a pixel too close together. My guess at how to fix this would be to layout each word as a unit according to the typeface hinting, and then position the word to be centered (or maybe left- or right- justified depending) on the 1440 dpi calculated position. This would make things look nice for typical cases of normal sized words separated by spaces; for very long strings of characters you would need to break this into chunks so as not to get too much sizing error built up in one place…

    Out of curiosity, Rick, is this more-or-less what MS Word does?

  54. Rick Schaut says:


    No, that’s not what Word does. While that’s not an entirely bad idea, it tends to lead to something called "wysiwiggle," where characters to the right of the insertion point jump a pixel or so in relation to each other as the user types. It can be annoying.

  55. Travis Fisher says:

    Said Rick: <i>it tends to lead to something called "wysiwiggle," where characters to the right of the insertion point jump a pixel or so in relation to each other as the user types.</i>

    Hmmm… do you mean left of the insertion point? You would always expect things to the right to move as you insert things before them. Yes, I see that in what I suggested, if you centered the word on its calculated position its left part would wiggle as you type. To keep the current word from wiggling as you type you would have to left-justify the word to its calculated position.

    This might make right-hand edges look a tad ragged (assuming they were supposed to be justified), so maybe you would want to redo the screen layout of a line to be pretty once the insertion point is off that line, having the left edges of words positioned correctly at the left of the line and modifying the rounding so by the time you reach the right edge of the line the right edges of words are in the right position.

    I seem to remember some program (Word? Wordperfect?) doing a wiggle when you hit say cursor-up after making an insertion, indicating a different screen layout mode for a line being edited vs. otherwise.

  56. Rick Schaut says:


    Sorry. You are correct. I meant to say "left," not "right," of the cursor.

Comments are closed.

Skip to main content