通过

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, §2.15.3.51, 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, §2.15.3.51, pages 1,462, lines 6–20 and page 1,463, lines 1–13, will be replaced with the following:

2.15.3.51 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:

BTBD=unitsPerEm+2pt

[Example: If this compatibility setting is turned on:

<w:compat>
<w:suppressTopSpacingWP />
</w:compat>

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]

-Brian

Comments

  • Anonymous
    January 18, 2008
    The comment has been removed

  • Anonymous
    January 19, 2008
    The comment has been removed

  • Anonymous
    January 19, 2008
    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.)

  • Anonymous
    January 19, 2008
    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.

  • Anonymous
    January 19, 2008
    The comment has been removed

  • Anonymous
    January 19, 2008
    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.

  • Anonymous
    January 19, 2008
    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.

  • Anonymous
    January 19, 2008
    [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.

  • Anonymous
    January 19, 2008
    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?". :o)

  • Anonymous
    January 20, 2008
    The comment has been removed

  • Anonymous
    January 20, 2008
    The comment has been removed

  • Anonymous
    January 21, 2008
    The comment has been removed

  • Anonymous
    January 21, 2008
    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 : http://www.noooxml.org/forum/t-35323/microsoft-patents-by-brian-jones (note that a number of these patents are related to OOXML. So much for the free party).

  • Anonymous
    January 21, 2008
    Example : http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=WO2005111830&F=0

  • Anonymous
    January 21, 2008
    The comment has been removed

  • Anonymous
    January 21, 2008
    The comment has been removed

  • Anonymous
    January 21, 2008
    The comment has been removed

  • Anonymous
    January 21, 2008
    Marc, 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. -Brian

  • Anonymous
    January 21, 2008
    The comment has been removed

  • Anonymous
    January 22, 2008
    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.

  • Anonymous
    January 22, 2008
    S., a point is a typographic measure. Check http://en.wikipedia.org/wiki/Point_(typography). 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.

  • Anonymous
    January 22, 2008
    @the troll, That shows your ignorance : the specs is riddled with "pt" used in completely different ways all throughout the specs.

  • Anonymous
    January 22, 2008
    S, 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? -Brian

  • Anonymous
    January 22, 2008
    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.

  • Anonymous
    January 26, 2008
    Adobe Photoshop has 72 points/inch and 72.27 points/inch as choices for meacurement units.