But the macro always hangs there. Actually the first time it hung, I opened the macro in TextWrangler and saw that apparently NWP was changing what I saw on screen in NWP to the following as TextWrangler presented it.

phspaelti wrote:PS: What's the deal with the f option used in the part of the macro dealing with the properties? Did this macro originate with the Nisus crew? (Martin?)

It's an old and undocumented option that stands for "fast". It used to disable some part of the code that worked to preserve the selection, in favor of getting the job done quicker. Now it does nothing and shouldn't be used.

There is no "\p{Lithuanian}" Unicode character class, like there is with "\p{Arabic}". Whenever I try to use "\p{Lithuanian}", in either a macro or the Find dialog, I receive an error alert. Are you somehow aborting the macro before it runs that line of code? If so, that would explain this problem:

NisusUser wrote:Interestingly enough, the edited macro does not scramble some things:

words in ALL CAPS.

Capitals are scrambled by the macro separately, later in the code, to replace them with fatter garbled characters so the garbled text layout is closer to the original. If you cancelled the macro halfway through, that would explain why they haven't been scrambled. When I run the macro Philip attached on the file you sent us privately via email, it handles words in all caps.

I could not save the .nwm file as UTF-8 in NWP 2.0.6

Why not? What happened? You will see the warning about discarding formatting, which you must confirm, but that's expected.

Martin wrote:
There is no "\p{Lithuanian}" Unicode character class, like there is with "\p{Arabic}". Whenever I try to use "\p{Lithuanian}", in either a macro or the Find dialog, I receive an error alert.

I've just deleted that line (I have no clue what a "Unicode character class" is; I was just guessing!). Instead I've just inserted the non-English characters into the lists of characters in the macro.

However, if you'll look at the one with Philip's section selecting the paragraphs and then inverting the selection (the macro with "added-LT-characters" in the name), I think you'll see that somewhere there's a problem. For one thing, that process really slows down the macro. But, more importantly, as I watch the macro execute, I can see that the selection stays active, but late in the macro execution, the macro still changes the letters before the digits in the paragraphs that start with "$$ ". So something in the macro is ignoring the selection.

And to further emphasize my ignorance, I don't understand what the code at the bottom does anyway, i.e., the section re: properties. Is that section needed or only if those languages are being scrambled?

NisusUser wrote:
And to further emphasize my ignorance, I don't understand what the code at the bottom does anyway, i.e., the section re: properties. Is that section needed or only if those languages are being scrambled?

The document properties are the stuff you can enter under File > Properties. It contains general info about the file (Author, Filename, Date, Keywords, etc.). 99% of users probably ignore it and leave it blank, but some (many?) programs fill in information taken from the user's default settings, e.g., the author typically gets filled with the name of the person to which the program is registered.

This is the kind of info that leads to insidious inadvertent leaks. So it was clever of Martin to scramble that info.

Why not? What happened? You will see the warning about discarding formatting, which you must confirm, but that's expected.

The change encoding drop down list is grayed out when saving to Nisus Macro format or Rich Text Format (at least on my machine running 2.0.6 on OS 10.6.. Please see attached screenshots.

Ah, I see what you attempted now. What you experienced is completely expected. Rich Text Format (RTF) and Nisus Macro files (which actually use RTF internally) don't have a single text encoding. The encodings are instead decided based on the text inside the file, and can change at any moment. For example, the text encoding might changed mid-paragraph if a word was encountered in another language. You do not need to control the text encoding inside RTF or macro files.

What you attempted to do by forcing your macro file to be interpreted as plain text is not valid. RTF and macro files are not plain text. So what you saw in TextWrangler was RTF codes, not the text content of the file.

Martin wrote:
There is no "\p{Lithuanian}" Unicode character class, like there is with "\p{Arabic}". Whenever I try to use "\p{Lithuanian}", in either a macro or the Find dialog, I receive an error alert.

I've just deleted that line (I have no clue what a "Unicode character class" is; I was just guessing!). Instead I've just inserted the non-English characters into the lists of characters in the macro.

Ah, sorry for my jargon. A Unicode character class is just a PowerFind Pro / regex term for those expressions that look like "\p{Arabic}". Each matches a great many characters that share a certain property, ie: a certain class of characters (eg: being Arabic).

In any case, there's no such character class for Lithuanian and your solution to match those special characters (eg: letter A with circumflex) manually is the easiest.

However, if you'll look at the one with Philip's section selecting the paragraphs and then inverting the selection (the macro with "added-LT-characters" in the name), I think you'll see that somewhere there's a problem. For one thing, that process really slows down the macro. But, more importantly, as I watch the macro execute, I can see that the selection stays active, but late in the macro execution, the macro still changes the letters before the digits in the paragraphs that start with "$$ ". So something in the macro is ignoring the selection.

You're right that the macro does run much slower with the selection preserving options. I'll take a look and see why that is, and if we can speed it up.

As for the macro incorrect garbling characters in the $$ paragraphs: the edited macro code you attached has an error from Philip's original. Your options string is missing the "s" option, which specifies to replace only in the selection. The options string should be: