Scramble / confidentiality macro; ignore some paragraphs

[NisusUser]

Attached is a macro that scrambles letters, but ignores digits. I have one additional thing I'd like ignored, but I don't know how to write the macro (edit it).

I would like it to totally ignore scrambling in any paragraph that begins with "$$ " (two dollar signs and a space). Could someone show me how or do that for me?

Thanks!

[phspaelti]

Here's a really simple approach. The macro first selects all paragraphs not protected with '$$' and then scrambles only that part.

redact-creates-new-file-no-digits-(edited).nwm

(20.49 KiB) Downloaded 1039 times

[phspaelti]

Anyhow, in case you were interested how I did that, I made two small changes.

First I added the following code before the macro starts the Find and Replace.

Code: Select all

# select all paragraphs not 'protected' with initial '$$'
Find All '^\$\$.+$', 'Ea'
Invert Selection

Then I changed the $options variable, adding the s option to limit the Find/Replace to the selection.

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?)

[NisusUser]

Anyhow, in case you were interested how I did that, I made two small changes.

First I added the following code before the macro starts the Find and Replace.

Code: Select all

# select all paragraphs not 'protected' with initial '$$'
Find All '^\$\$.+$', 'Ea'
Invert Selection

Then I changed the $options variable, adding the s option to limit the Find/Replace to the selection.

Thank you very much for your help! And for explaining it.

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?)

Yes, I think it was from Martin a long time ago.

[NisusUser]

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

words in ALL CAPS.
sometimes the first word of a paragraph
the first word after <<

And, as in the original macro, it does not scramble Lithuanian characters.

Thus I added this as line 50 in the macro (assuming all Lith. characters would change to the "ė"):

Code: Select all

		$value.replaceAll( '\p{Lithuanian}', 'ė', $options )

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.

Code: Select all

\tab \tab $value.replaceAll( '\\p\{Lithuanian\}', '\u279 ?', $options ){\nisusselectcaret \par

I could not save the .nwm file as UTF-8 in NWP 2.0.6., so I saved it as a .txt file with UTF-8 encoding in NWP. Then I changed the suffix to .nwm and tried running it again. It still hung on line 50.

[martin]

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.

[martin]

Thus I added this as line 50 in the macro (assuming all Lith. characters would change to the "ė"):

Code: Select all

		$value.replaceAll( '\p{Lithuanian}', 'ė', $options )

But the macro always hangs there.

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:

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.

[NisusUser]

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.

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.8). Please see attached screenshots.

[NisusUser]

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?

Thanks!

[phspaelti]

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.

[martin]

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.

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]

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:

Code: Select all

$options = 'aE-isS'