suppressTopSpacingWP – Compat Settings #1

I know a lot of people were worried about a subset of the compatibility settings in wordprocessingML that specified the behavior of an older application should be used (such as “suppressTopSpacingWP”). While the vast majority of the settings were fully documented, there were a few that didn’t provide enough information. We were torn over what the best approach would be. We could remove them from the spec, but we know that there are files out there (albeit a very small percentage) that use these properties. So we decided to move them into the deprecated section of the spec (making it clear that new documents should not have these settings specified), and in addition to fully document the behavior so that people could implement them.

Since this was such a highly elevated issue, I thought it would be nice to post the responses to the various compatibility settings so that folks could review them. Here’s the TC45 response to the setting suppressTopSpacingWP:

Agreed; we will fully define the information necessary to implement this property (specified below). This description provides all of the information needed to mimic a behavior observed in a previously existing word processing application (WordPerfect 5.x).

In addition, we will remove it from its current location in the specification (Part 4, §, pages 1,462–1,463), and place it into a new annex for deprecated features.

Following the precedent set by other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998), we will make use of a new Annex that contains normative descriptions of all deprecated features. The intent of this Annex is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of those deprecated features to preserve their fidelity, while noting that new documents should not use them. Accordingly, the Conformance clause will also be changed to state that newly created documents (those not created by migrating existing binary documents) should not use deprecated features. All deprecated features will be removed from their current locations in the standard, but will be fully defined in this new Annex.

To provide a full description, the existing text in Part 4, §, pages 1,462, lines 6–20 and page 1,463, lines 1–13, will be replaced with the following: suppressTopSpacingWP (Use Static Text Leading)

(The terms baseline to baseline distance and unitsPerEm, used below, are defined in ISO/IEC 14496-22:2007.)

This element specifies that applications should use the values defined below to calculate the baseline to baseline distance (BTBD) in this document. This can result in lines appearing slightly condensed vertically.

Without this setting, applications calculate baseline to baseline distance using the metrics defined by ISO/IEC 14496-22:2007. This element, when present with a val attribute value of true (or equivalent), specifies that applications should calculate this as follows:


[Example: If this compatibility setting is turned on:

<w:suppressTopSpacingWP />

Then applications use a baseline to baseline distance as calculated before. With a 16 point font, this would result in a baseline to baseline distance of 18 points. end example]


Comments (25)

  1. hAl says:

    I wonder if anybody is actually interested in using that info.

    I think the issue was only interesting as ammo to find fault with Office Open XML and not about an actually need for the information.

  2. Luc Bollen says:


    IMO, the reason for the related comments is not "ammo to find fault with Office Open XML", but the result of a wish to preserve quality in ISO standards.

    I’m sure you will agree that including a feature in a ISO standard, but not defining it is definitively not what can be called "best


    I agree that nobody implementing an office document ISO standard should need to know this information.  This information is useful only for people converting old files.

    So, the good approach is not to add the info in a "deprecated annex", but to remove it from the standard, and publish it for example as a Technical Specification.

  3. Francis says:

    Luc: that’s a valid idea, but there is also an advantage to retaining this information in the standard but moving it to an annex. It keeps everything in one place–so developers and implementers will not have to scour the net looking for the definition of, e.g., suppressTopSpacingWP.

    Of course, one could extend that argument, asking "why don’t we add everything but the kitchen sink" to the standard?

    The answer would be that suppressTopSpacingWP is not germane to any other standard. It only makes sense in the context of ISO DIS 29500. Publishing the compatibility settings in a separate document instead of an annex would increase, not decrease, the effort developers and implementers have to make. (They’re free to disregard the annex.)

  4. Luc,

    "I agree that nobody implementing an office document ISO standard should need to know this information.  This information is useful only for people converting old files."

    I do not agree. I think it is a major improvement to OOXML that these combat-settings are not defined – and also that they are so relavively easy to implement. It is also not only of relevance to those converting old files. It is important if you receive an OOXML-document that was previously converted to be able to preserve the original layout.

    I think the compat-settings should have been in the spec from the beginning.

  5. Dammit,

    "that these combat-settings are not defined"

    should naturally be

    "that these compat-settings are NOW defined"

    sorry … :o)

  6. Wu MingShi says:

    More information about those compatibility setting is indeed welcomed. Moving them about simply make the intention clear but nothing else.

    However one question that has always nagged me why should they actually make an appearance at all. Opposition had been claiming this and so far, I have no satisfactory description beyond vague description of "backward compatibility". I do not claim to know all about document layout and processing, but do see myself as able to understand why the trade off is performed. The trade-off is of course not mine to make, but it will be interesting to see why the decision maker makes those.

    To me, the simplest and most elegant will be to simply translate it into standard OOXML syntax. The approach will be the cleanest and easiest for all (except for those who have to convert from bin->xml) but as I understand it, there is another ECMA project going to focus on that.

  7. Wu,

    I think that when you look at all the compat-settings and the explanation of them you will realize, that not having them in OOXML would make it impossible to preserve the visual layout of the original documents. They all deal with how lines are wrapped or compressed, how font heights are calculated, how objects let surrounding text wrap arounbd them and how characters from east-asian aplhabeth are positioned alongside "normal" letters.

    I truly believe that OASIS should have done the same instead of making settings like these application specific and not part of ODF.

  8. hAl says:

    [quote]that not having them in OOXML would make it impossible to preserve the visual layout of the original documents.[/quote]

    However, document standards like OOXML and ODF are not about describing the visual layout of documents but about syntax and structure mostly. So why describe how a element is different from the normal if the standard does not describe what the normal is.

  9. hAl,

    True – but look at the responses to the Danish comments,  e.g. DK010 autoSpaceLikeWord95, DK011 footnoteLayoutLikeWW8 or DK014 shapeLayoutLikeWW8). They are not just about structure but about how the objects in a document sometimes behave differently than would normally be expected.

    Interoperability is not just being able to "transfer" all letters in a document. It is also very important to be able to preserve the visual layout of the documents – if for nothing else, to keep users from being nervous and thinking "what the f*** happened to my document?".


  10. Wu MingShi says:


    "[wrt compat-settings]that not having them in OOXML would make it impossible to preserve the visual layout of the original documents."

    No. Express them in existing standard OOXML syntax. OOXML has settings parameters that says how much inter-line spaces, how big the font sizes are. Turn compatibility settings into that. Its what those settings are for!

    Look at it another way: Eventually, all these compatibility settings are going to be expressed in those details. Those compatibility setting do makes it easier for the programmer to conceptualize and easier to program, that’s all. An analogy is ice-cream It is easier to think of ice cream,  than sugar, eggs, favouring mixed and chilled.


    Your first sentence make me realize one thing: Move compatibility setting to annex, but make it as information, not deprecated item. Specifically, says that implementers should NOT implememnt it.

    These compatibility setting are then specified as OOXML syntax. In other words, rather than  tell you how to deal with it when you see an MS binary documents, it tells you what you should do to translate any WordPerfect/WordStar/Old doc format to standard OOXML syntax, in order to ditch the compatibility setting strings. It will be simply reference information for people wanting to convert from old MS documents/WP/WS documents to OOXML.

    Perhaps those annex should actually move to the next ECMA project about binary MS docs to OOXML.


  11. Wu,


    Please, it’s "Jesper" … with an ‘e’ :o)

    "No. Express them in existing standard OOXML syntax. OOXML has settings parameters that says how much inter-line spaces, how big the font sizes are. Turn compatibility settings into that. Its what those settings are for!"

    I don’t really have strong feelings for this – my primary concern is that the settings are now described. Since they only appear in a small number of files (according to ECMA), having them seperated from the rest of the spec provides an easy way to remove them – and I really don’t have any problems with this.

    That being said – the compat-settings were really not my strongest desire for improvement … there were other areas, where I thought it more important to fix the spec.

  12. A says:

    Just a couple of responses.

    1 – A lot of people are taking the viewpoint of file producers.  Agreed, one should not make new files with "Linespace like WP 5.x" turned on.  But you’re forgetting the consumers who have to display the files.  Those people, if they want to show the file the same way as Word, need even the deprecated features documented, since Word will use them when converting old binaries.  It doesn’t really matter where they are documented, but it should be as easy for developers to access as the rest of the specs.

    2 – I don’t think all those compatibility options can be converted into more "normal" features, though I don’t doubt some of them could.  For example "Wrap trailing spaces to next line" (sorry, using a 2003 example since I’m more familiar with those).  You can’t delete those spaces when the option is off because if the user reformats the page, they may no longer be trailing spaces, and thus should show.  Or, if not-wrapping is the default behaviour (which it is), how would you turn on the wrapping given other elements in the Schema?

    A bit of devil’s advocate, I myself dislike compat-options, they make my life complicated, but I can see how it is impossible for MS to remove them completely if they want to maintain the layout of their older files which have some of these weird non-convertible features.

    Many users are already afraid to convert because of the new UI.  How terrified do you think they’d be if they find out that those binary documents they spent hours setting up to page break just right suddenly get scrambled when they convert?  They’d never switch to 2007.  I’ve seen one Excel file that looks different in 2000, XP and 2003. In 2000 it looked right, in 2003 it displayed nonsense.  I’m sure the author was not thrilled.  (It was a cropped wmf that got scrambled if you’re wondering)

    I won’t comment on whether OOXML should be a standard or not because of this, but the frightened user is why MS put so much effort in maintaining these bizarre "features".

  13. S says:

    When it comes to standards designed to improve interoperability, it’s simple :

    1) either it’s documented, or it’s not. There is nothing meaningful in between. What is meant by documented is, any specification that carefully and unambiguously explains how to provide run-time interoperability across platforms and applications. This certainly includes the specification such as reading, writing, rendering, calculating, and so on. A good way to test the specification is to come up with a second implementation. That’s why a large specification should take years to stabilize. Anything less than that (as is the case with ECMA 376) is completely bogus.

    2) Microsoft does not have a great record writing international standards. Thing is, writing international standards is very hard. That’s why international standards are very short, and are based on other standards rather than reinventing the wheel. On both accounts, OOXML today is an abomination, an abject failure. Something any responsible Microsoft employee should be embarassed to put in public.

    3) Brian Jones, among others, is more used to filing patents. Examples :

    (note that a number of these patents are related to OOXML. So much for the free party).

  14. marc says:

    >Something any responsible Microsoft employee should be

    >embarassed to put in public.

    reading the +2000 pages[1] of corrections ( and this was just a result of a couple of months of rushed reviewing by some technical experts [ BSI@UK, France, Japan, Durusau/Weir/Farance@USA, Israel, Denmark, and a few more ] ), i can’t avoid to feel embarrassed ( and i’m not a Microsoft employee, just a standards consumer ) for all the omissions, errors, lack of interoperability, poor editorial quality,  notorious obscurity by overdosing of useless examples and repetitive definitions, etc, etc.  of a document that aspires to be an ISO standard via fast-tracking.

    and now i feel amazed by the amorphous thing that is becoming this specification ( four date bases, my god ! bitmasks still there, +700 pages of deprecated material with lot of duplicate semantics with normative non-deprecated ones, etc. )

    besides that, i’m changing my point of view regarding all this ISO fast-track standardization fiasco and Microsoft dramatic attempt to catch up the ISO train, it summarizes with this phrase:

    "Never ascribe to malice, that which can be explained by incompetence."

    Simply, Microsoft don’t know how to write ISO standards in less than 1 year. ECMA helped them rubber-stamping OOXML but now they have lot of (prepared) eyeballs seeing this proprietary-software-product-internal-documentation suddenly upgraded to ECMA standard status ( aka DIS 29500 )

    Luckily, some proud ISO guys ( that really cares about standards ) are doing the homework that Microsoft and ECMA should have done: reviewing and trying to make DIS 29500 understandable and implementable ( hard work , isn’t it? ).

    But i believe that everything is possible in ISO JTC1 ( lot of contradictions ignored, eight "unknown" National Bodies suddenly becoming P-members few days before ballot closing, Microsoft allowed 4 months to prepare responses and to change lot of the initial draft, subverting the fast-tracking spirit, etc, etc )

    so … as the next-BRM’s convenor said[1]:


    Six thousand pages,

    And five days in Geneva;

    Maybe it will pass.





  15. Reggie says:

    marc, ODF should’ve gone through the intense scrutiny that OOXML did, then maybe ODF 1.0 would be worth a damn.  ODF got a free ride because nobody gave a damn about it.  It’s easy to sneak through a shoddy incomplete spec when nobody is watching because nobody cares.

  16. marc says:

    >marc, ODF should’ve gone through the intense scrutiny

    >that OOXML did

    intense scrutiny? are you serious?

    i have scrutinized DIS 29500 a couple of hours and found +200 omissions,

    errors, inconsistencies ( many of them were found by several national bodies,

    others remains in DIS 29500 ), and i’m not an XML expert

    they are *evident* to anyone

    Do you think that national bodies were 24 hours a day scrutinizing this beast?

    do you think that this people work for Microsoft and have all the time

    to fix the results of MS standardization adventures ? they did their best,

    in the limited timeframe of a fast-tracking process

    > ODF got a free ride because nobody gave

    >a damn about it.

    ( by the way Japan NB members actually *did* a review recently,

    and found -100 observations, most of them minor editorial corrections [3] )

    the difference here is that ODF was generated by a trusted organization,

    OASIS, through a transparent and traceable process , not a rushed one

    ( +4 years of work )

    do you trust ECMA TC 45? this is the level of quality that you expect for

    an international standards organization? man, demand quality ! you have rights!

    do you trust what organizations gave to you just because you see big names? (

    Microsoft, ECMA, IBM, Barclays Capital, BP , etc )? they think in their pockets, not in the

    factiblity that consumers find alternative and competitive software

    implementations of DIS 29500 [4] )

    thanks god this TC doesn’t make chemical

    or safety standards , they didn’t bother even to pass a spell checker to the DIS 29500 ( even my Firefox browser is proofing my text as i write it ),

    or to validate the XML examples(*) and elements/attributes names ( showing total lack of respect

    to the reviewers and national bodies all over the world )

    (*)( to brian employees: man… you are Microsoft, you develop XML validators! ,

    do you think that standardization is a game: the "ISO crazy race"? )

    the word *rush* perspire all this specification ( see for example Response 559 [1]  )

    And please read ODF, is far from a perfect format, but it wasn’t rushed,

    you have 4 year of public mailing lists testifying it development.

    You will recognize that there is serious editorial work done on it, before

    ever thinking about submit it to fast-track ( do you know Patrick Durusau?

    well, find out about his work on ODF edition, read the comments he made during

    DIS 29500 review at INCITS-V1/USA [he is the chair of V1 ] [2] )

    And please don’t defend DIS 29500 attacking ODF,,,

    we have DIS 29500 on the (world) table here. National bodies (and people like you

    and me ) will have an oportunity to say anything we want about ODF , when OASIS submit

    the next version to ISO ( ODF 1.2 )






  17. says:


    What are these major errors that you’ve seen? Please share so we can add them to the list of things that need to be addressed in the next version.

    No standard is perfect, which is why ODF is often brought up. Open XML is being held to a completely different bar. There will be errata, and these can be fixed/improved over time.


  18. Wu MingShi says:


    "Please, it’s "Jesper" … with an ‘e’ :o)"

    Sorry. Please accept my apology.

    [On expressing compat settings as standard OOXML syntax] "I don’t really have strong feelings for this – my primary concern is that the settings are now described. Since they only appear in a small number of files (according to ECMA), having them seperated from the rest of the spec provides an easy way to remove them – and I really don’t have any problems with this."

    I think it is important because it greatly affect implementations. Expressing in standard syntax means there is no need to create special routines to implement them inside the document engine. Otherwise one will have to translate each and everyone of them separately into a form understandable by the document engine.

    On the existing public specs, they appear small because they were not described. Look at Jone’s example, a one line non-description (refers to AppX) expanded to a few lines. Multiply it by all the compat settings others had identified. Then imagine having to implement each and every one of them. That will turn out to be a lot of work. All for what? For some scenarios that far and between but cannot be ignored because it is certain to occur?

  19. S says:

    Speaking of documenting stuff, something as simple "+2pt" above in the blog post is meaningless without also making a reference to the coordinate system in which it is expressed. 2 points in a 72DPI resolution is not the same thing as 2 points in a 96DPI resolution is not the same thing as 2 points in a resolution-independent system is not the same thing as 2 points in a "normal font" scale.

    That’s why *REAL* standards are based on other standards :

    1) no ambiguity

    2) verifiable claims

    3) interoperability across platforms

    4) implementation cost kept low

    5) ability to discuss and share libraries

    All 5 points are notably lacking in OOXML right now.

  20. Anonymous Coward says:

    S., a point is a typographic measure. Check

    A point is not the same thing is a dot. I bet you are not a native english speaker, as some languages use the same word for both things. But that should not excuse your trolling.

  21. S says:

    @the troll,

    That shows your ignorance : the specs is riddled with "pt" used in completely different ways all throughout the specs.

  22. says:


    Can you give an example of what you’re talking about? Point ("pt") is a pretty well defined term (not to be confused with pixel or "px").

    Are you saying the "point" is defined to be a different measurement? Where do you see that?


  23. Dave S. says:

    Wasn’t the charter of MSO-XML to faithfully represent every detail in billions of exisiting documents? If so, it must account for every detail those documents might have.  Even a rarely used feature is bound to be in tens of thousands of documents.

    What’s important is the ability to convert the old documents into any other format. To convert requires documentation in complete detail of how exisiting documents are formatted. The MSO-XML group must have gathered or generated that information to ensure they have all those elements in the new format and a mapping to find them. Had the old formats been through ISO before MSO-XML then most of the arguments would be eased if not eliminated.

  24. Dave S. says:

    Adobe Photoshop has 72 points/inch and 72.27 points/inch as choices for meacurement units.