Can you iterate JavaScript object properties in insertion order?

Yes.  Yes, you can.  At least as of ES2015.  I found this out when working with the jstree contextmenu plugin.  That plugin receives an object with named keys for the items to show in the menu.  It assumes that jQuery’s $.each will traverse those items in the same order they were added to the object.  $.each boils down to a for-in loop.  Well, turns out that since ES2015, the for-in loop returns properties in a deterministic order!  As long as your keys are strings that can’t be parsed as integers, you will get them out in the same order they were added.

Useful links:

This relates to my new Google Chrome extension, TabFern, about which more news soon.  If you have lots of browser windows and tabs open, or want to manage multiple browsing sessions, TabFern may be just what you are looking for!

Advertisements

NBSP in Word, part 2

This is a follow-on to my previous post on the subject.  These are my notes as I’m working, so they don’t read very well as text 🙂 .

Another test, on a different file exhibiting the same problem:

In the UI:

  • Removed all the new-style equations (OMath objects)
  • Changed all OpenType fancy features to defaults (in the Character Properties)
  • Changed the proofing language for all text to English

In word/settings.xml:

  • Removed FELayout
  • Removed all w:compat/w:compatSetting except for [@w:name=”compatibilityMode”]
  • Left m:mathPr for now, but I may remove that another time. Edit: I removed that below.

Did `find . -name \*xml | xargs grep -il asia`.  That gave me word/{document,numbering,settings,styles}.xml.

Used XML Notepad 2007 to move tags onto their own lines — just open the file, then save it.

settings.xml: it was w:themeFontLang.  Leaving that in for now.

styles.xml: It’s a bunch of <w:lang/> and <w:rFonts/> (`grep -i asia word/styles.xml |sort|uniq|less` is my friend!).  Leaving them in for now.

numbering.xml: Again, just <w:rFonts/>.  Leaving them for now.

document.xml: There were two lonely <w:rFonts/> tags!  Those I left in at first.

Zipping it

I tried using 7z, both from the context menu and with `7z a -tzip -mm=Deflate -mx=0 ../draft8e.docx *` (7z command-line options reference).  However, Word 2013 didn’t like either.  I used Send To | Compressed Folder, and that was OK.  A problem for another day.

More changes

Result?  Still no luck.  Time to strip the rFonts!

  1. Remove the rFonts referencing asia (/asia/g, in fact) from document.xml.  Result? No luck.
  2.  Remove that pesky m:mathPr from settings.xml.  You know, I wonder…  Result?  No luck.
  3. Remove w:themeFontLang from settings.  In styles, leave w:val, but remove w:eastAsia and w:bidi.  Result: success!!!!

So if you do all of the above, you’ll probably be OK 🙂 .

 

 

Music of the Day

“Moonmadness” by Camel.

Wow!  I had heard of Camel before, but this is the first full album I’ve listened to.  It will be in my collection as soon as I can conveniently arrange it 🙂 .  Solid prog rock in a fantastic style.  Well worth a listen, and I suspect it will stand up to repeated play.

More details at Prog Archives.

Word 2013 non-breaking space width: an end to the insanity!

Pre-Word 2013, a persistent annoyance was that non-breaking spaces (Chr(160)) were fixed width, even in justified text.  Word 2013 changed that.  Now, in justified text, regular spacing and non-breaking spaces are the same width.

Sometimes.

If you’re lucky.

User slasza on Microsoft Answers posted this test case from Word 2013, in which everything should have been right, but the nonbreaking spaces still didn’t show up:

NBSP failure – image by slasza

I ran some test files and took a look at the Word XML, and found the culprit at last!  It is the <w:useFELayout/> tag in the <w:compat> group in word/settings.xml.  If that tag is present in a Word 2013 document, nonbreaking spaces are fixed-width.  If it is absent, nonbreaking spaces are variable-width.

More detailed instructions on how to fix this are coming soon.  But rejoice that at least now you know what the problem is!

Edit 1

I just fixed one legacy file by going on an odyssey through the UI and the XML.  I:

  1. In the UI, turned off all the fancy OpenType features
  2. Set the proofing language to US-English for all text
  3. In word/settings.xml, removed FELayout, everything under w:compat except for w:compatSetting, and I think a few other things under /w:settings.
  4. In word/*.xml, removed just about every mention of the word “asia” (case-insensitive)

And my NBSPs are finally variable-width!

vim: cleaning up mixed indents

Thanks to the wiki for this.  If you run across a file that mixes tabs and spaces (ewww!), set the tab settings the way you want (e.g., ts=4 sts=4 sw=4 et ai) and run

:retab

to convert all the tabs to the right number of spaces.  This takes tab stops into account, which :%s/^I/    /g won’t.

This replaces what I used to do, which was /^I s<Tab><Esc> followed by a whole lot of n.n.n.n.n.n.n.n. … .  One command is much better 🙂 .  I’m not even going to try to count the keystroke savings on my current project (pym, a preprocessor written in Python).