Monthly Archives: February 2013

UX Write 1.1.0, now with Microsoft Word support

Posted on by

At long last, the first release of UX Write to support Microsoft Word’s .docx file format is now available on the app store. This has been a very complex undertaking that’s involved many months of work, and represents a significant step forward for the app in terms of making it useful to a much wider audience. Now you can seamlessly work on the same document using UX Write on your iPad or iPhone and Microsoft Word on your PC or Mac.

To the best of my knowledge, UX Write now provides the highest level of compatibility with .docx files out of any word processor available for the iPad. Virtually all of the basic text and formatting properties are supported, along with essential features like figures, tables, styles, numbered headings and captions, cross-references, and automatically-generated tables of contents. While these features were already supported for HTML documents in version 1.0, you can now use all the same features with Word documents as well.

As with previous versions of UX Write, all documents are displayed using a continuous, reflowable layout rather than the fixed-size page layout that Word uses. Reflowable layout is a much more suitable approach for mobile devices, which, particularly in the case of the iPhone and iPad mini, do not have screens large enough to comfortably display a full-sized A4 page without some combination of squinting or excessive horizontal scrolling. The reflowable layout model used by UX Write is the same as that of e-book readers such as Kindle and iBooks, and just like in these apps, UX Write lets you adjust the text size to whatever you find the most comfortable for reading. You can still see what the printed version of your document will look like by using the “Generate PDF” option.

HTML remains the default file format, and UX Write continues to rely on the WebKit layout engine (the same as used by Safari and Chrome) for displaying documents. When you open a .docx file, UX Write temporarily converts it to HTML for editing, and then converts it back to .docx upon save. However, it does this in an intelligent manner which preserves any formatting properties or other elements in the document (such as page breaks and tabs) that can’t be represented in HTML, as I described in an earlier post.

I’m still a very strong proponent of HTML as a standard document format — it’s worked pretty well for the web over the last 20 years, and is fully supported by every modern computing platform and web browser. Its simple, text-based syntax makes it easy to edit by hand (as millions of web developers do every day), and plays well with version control systems such as Subversion and Git. HTML is also the basis for the EPUB standard for e-book publishing, which I’ll be adding support for in an upcoming version.

One caveat I should mention is that I won’t be supporting the legacy .doc file format used by older versions of Microsoft Word prior to 2007. While I’m aware that it’s still used by some people, it’s a hideously complex binary format that wasn’t designed with interoperability in mind, and I estimate it would take at least another six months to support (and probably a great deal longer to do so properly). When faced with the choice between doing that, and instead investing that time in arguably more important features like find & replace, spell checking, footnotes, EPUB export etc., I decided to go with the latter. If you have a .doc file you wish to edit in UX Write, you can easily convert it to .docx using any recent version of Word (2007 or later).

Although this release has had extensive beta testing, it’s inevitable there’ll still be a few issues remaining, and I’ll be releasing regular updates (probably every couple of weeks or so) during the 1.1.x series. There’s a bunch of other features (such as footnotes, citations, and improved PDF output) I’ve got planned for upcoming major versions which I’ll be working on in parallel, but bug fixes to any issues reported with the .docx support will take priority for the time being. If you do encounter any bugs in this version, don’t hesitate to contact me, and I’ll endeavor to get them fixed as quickly as possible.

Update on Microsoft Word Support, Part 3

Posted on by

Yes, more delays.

Rather than another long-winded post, I figured that this time I’d just give an example of how HTML approaches things compared to Word. Hopefully this will illustrate why I’m such a strong proponent of the former.

Specifying an image in HTML

<img src="filename.png" width="66%">

Specifying an image in docx (method 1)

<w:drawing>
  <wp:inline>
    <wp:extent cx="5270500" cy="3513667"/>
    <wp:docPr id="1" name="Picture 1"/>
    <wp:cNvGraphicFramePr>
      <a:graphicFrameLocks noChangeAspect="1"/>
    </wp:cNvGraphicFramePr>
    <a:graphic>
      <a:graphicData uri="http://schemas.openxmlformats.org/drawingml/2006/picture">
        <dpct:pic>
          <dpct:nvPicPr>
            <dpct:cNvPr id="0" name="image"/>
            <dpct:cNvPicPr/>
          </dpct:nvPicPr>
          <dpct:blipFill>
            <a:blip r:embed="rId1"/>
            <a:stretch>
              <a:fillRect/>
            </a:stretch>
          </dpct:blipFill>
          <dpct:spPr>
            <a:xfrm>
              <a:off x="0" y="0"/>
              <a:ext cx="5270500" cy="3513667"/>
            </a:xfrm>
            <a:prstGeom prst="rect"/>
          </dpct:spPr>
        </dpct:pic>
      </a:graphicData>
    </a:graphic>
  </wp:inline>
</w:drawing>

Specifying an image in docx (method 2)

<w:pict>
  <v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
    <v:stroke joinstyle="miter"/>
    <v:formulas>
      <v:f eqn="if lineDrawn pixelLineWidth 0"/>
      <v:f eqn="sum @0 1 0"/>
      <v:f eqn="sum 0 0 @1"/>
      <v:f eqn="prod @2 1 2"/>
      <v:f eqn="prod @3 21600 pixelWidth"/>
      <v:f eqn="prod @3 21600 pixelHeight"/>
      <v:f eqn="sum @0 0 1"/>
      <v:f eqn="prod @6 1 2"/>
      <v:f eqn="prod @7 21600 pixelWidth"/>
      <v:f eqn="sum @8 21600 0"/>
      <v:f eqn="prod @7 21600 pixelHeight"/>
      <v:f eqn="sum @10 21600 0"/>
    </v:formulas>
    <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
    <o:lock v:ext="edit" aspectratio="t"/>
  </v:shapetype>
  <v:shape id="_x0000_i1025" style="width:96pt;height:64pt" type="#_x0000_t75">
    <v:imagedata r:id="rId4" o:title="min"/>
  </v:shape>
</w:pict>