Find invisible symbol fields in WP files imported in Word 2002?

[Edward Mendelson]

I'll be very grateful for any help with this frustrating problem that
involves a special kind field in Word 2002 that is normally invisible - and
that can't be revealed by any combination of the F9 key. This problem does
not seem to occur with versions earlier or later than Word 2002 (XP)

When you import a WordPerfect 5.x file into Word 2002, and the original file
contains typographic symbols like curly quotation marks or dashes, Word 2002
does NOT convert the symbol into the equivalent native character in the
current font, but instead creates an invisible field that takes the place of
the original symbol. For the em-dash, for example, something that looks like
an em-dash appears on screen and on the page, but it's not the same as
Word's em-dash character; it's really a field, although nothing on screen
shows that it's a field.

So, if the original WP document contains an em-dash, you can't search and
replace the em-dash in Word by entering ^+ in the search field (by using
Find/More/Special), as you can to search for a real em-dash - and as far as
I can tell, you can't search for the WP-imported em-dash at all. And you
can't search for the invisible field by entering ^d either. If you copy the
imported em-dash from the text and paste it into the Find field, you get an
upper-case C, which doesn't help at all.

You can't reveal these fields by using any combination of the F9 keys, but I
found that you can see them by saving the file in WinWord 2.0 format and
reopening it in Word 2002. (CrossEyes from www.levitjames.com also displays
the fields.) At this point, you can see that (for example) a quotation mark
imported from WP is really a field that looks like this:

{symbol 65\f "WP Typographic Symbols"\s 12}

But you can't search for this field by using "^d symbol" in the Find dialog.
You CAN search them if you add a space after the opening brace and before
the closing brace, but I can't find a way to add those spaces automatically.

Question: is there a way to use VBA to find these fields and replace these
hidden fields with the native Windows characters? I'd like to have a macro
that will replace invisible fields containging quotation marks, section
marks, paragraph marks, em and en dashes when a WP file is opened in Word
2002. Fixing them by hand is a bit time-consuming!

Thanks for any help anyone can give.

Edward Mendelson
Contributing Editor
PC Magazine

 

[Edward Mendelson]

Hi Edward,
if you count the all fields,
is the field in question counted, too?
If so, one might be able to access it's code.
If you like, you could send me such a doc to
"h.weberHHH" & chr(64) & "mi-SSSverlag.de".
Delete uppercase, of course.
I'll have a go at it, but might be a matter of luck.
Use as topic anything starting with "NG: ".

Hello Helmut,

I've sent you the file, which is self-documenting. Many thanks! When I count
all fields on a document with four of these hidden fields, the count is 1,
not 4. I don't understand this at all!

Thanks again,

Edward Mendelson

 

[Helmut Weber]

Hi Edward,
sorry, but this might help you nevertheless,
as the problem is, that I don't have any problem.
I open the file from inside Word and Word doesn't
ask me for any conversion, it just opens the text
and that's it. I can search for ^+ or ^=, no prob.
There is a hidden private field, of which I don't
know what it is good for, but it causes no trouble.
These are my compatibility options for Wordperfect 5.x
With ActiveDocument
.Compatibility(wdNoTabHangIndent) = True
.Compatibility(wdNoSpaceRaiseLower) = False
.Compatibility(wdPrintColBlack) = False
.Compatibility(wdWrapTrailSpaces) = True
.Compatibility(wdNoColumnBalance) = True
.Compatibility(wdConvMailMergeEsc) = False
.Compatibility(wdSuppressSpBfAfterPgBrk) = False
.Compatibility(wdSuppressTopSpacing) = False
.Compatibility(wdOrigWordTableRules) = False
.Compatibility(wdTransparentMetafiles) = False
.Compatibility(wdShowBreaksInFrames) = False
.Compatibility(wdSwapBordersFacingPages) = False
.Compatibility(wdLeaveBackslashAlone) = True
.Compatibility(wdExpandShiftReturn) = True
.Compatibility(wdDontULTrailSpace) = True
.Compatibility(wdDontBalanceSingleByteDoubleByteWidth) =
True
.Compatibility(wdSuppressTopSpacingMac5) = False
.Compatibility(wdSpacingInWholePoints) = False
.Compatibility(wdPrintBodyTextBeforeHeader) = False
.Compatibility(wdNoLeading) = False
.Compatibility(wdNoSpaceForUL) = True
.Compatibility(wdMWSmallCaps) = False
.Compatibility(wdNoExtraLineSpacing) = True
.Compatibility(wdTruncateFontHeight) = False
.Compatibility(wdUsePrinterMetrics) = True
.Compatibility(wdSubFontBySize) = False
.Compatibility(wdWW6BorderRules) = False
.Compatibility(wdExactOnTop) = False
.Compatibility(wdSuppressBottomSpacing) = False
.Compatibility(wdWPSpaceWidth) = False
.Compatibility(wdWPJustification) = False
.Compatibility(wdLineWrapLikeWord6) = False
.Compatibility(wdShapeLayoutLikeWW8) = True
.Compatibility(wdFootnoteLayoutLikeWW8) = True
.Compatibility(wdDontUseHTMLParagraphAutoSpacing) = True
.Compatibility(wdDontAdjustLineHeightInTable) = True
.Compatibility(wdForgetLastTabAlignment) = True
.Compatibility(wdAutospaceLikeWW7) = False
.Compatibility(wdAlignTablesRowByRow) = True
.Compatibility(wdLayoutRawTableWidth) = True
.Compatibility(wdLayoutTableRowsApart) = True
.Compatibility(wdUseWord97LineBreakingRules) = True
.Compatibility(wdDontBreakWrappedTables) = True
.Compatibility(wdDontSnapTextToGridInTableWithObjects) =
True
.Compatibility(wdSelectFieldWithFirstOrLastCharacter) =
True
.Compatibility(wdApplyBreakingRules) = False
.Compatibility(wdDontWrapTextWithPunctuation) = True
.Compatibility(wdDontUseAsianBreakRulesInGrid) = True
End With
Options.ConfirmConversions = False

 

[Edward Mendelson]

Hi Edward,
sorry, but this might help you nevertheless,
as the problem is, that I don't have any problem.
I open the file from inside Word and Word doesn't
ask me for any conversion, it just opens the text

Hello Helmut,

Your answer showed me a workaround for the problem! Here is what seems to
happen when you open a WP5 file in Word 2002:

IF you have the special fonts installed by WordPerfect for Windows on your
system for handling typographic symbols and multinational characters,

THEN Word 2002 creates special invisible fields for WP typographical symbols
when opening a WP5 file.

ELSE (in other words, if you do NOT have the WP for Windows fonts on your
system) Word 2002 performs the conversion exactly in the way that you
describe, without creating invisible fields. END IF

Presumably, you do not have the WP typographic font files on your system.
That is why you did not see the special fields when you opened the file.
Word 2002 apparently wants to allow easier back-and-forth conversion of WP
documents, so it preserves the original font information - but I am only
guessing at this.

If you are interested in seeing how the problem works, you can download the
WPWin fonts here:

ftp://ftp.corel.com/pub/WordPerfect/wpwin/9/wpfonts.exe

It would be interesting to know a way to find the hidden symbols, but
there's no need to do so, because the simple answer is to move the WP fonts
out of the Fonts directory before opening the WP file in Word 2002.

Thank you for the report!

Edward Mendelson

 

[Bob S]

You can't reveal these fields by using any combination of the F9 keys, but I
found that you can see them by saving the file in WinWord 2.0 format and
reopening it in Word 2002. (CrossEyes from www.levitjames.com also displays
the fields.) At this point, you can see that (for example) a quotation mark
imported from WP is really a field that looks like this:

{symbol 65\f "WP Typographic Symbols"\s 12}

If a person who had one of these files containing a hidden symbol were
to open that file in a plain text editor (or in recover text mode in
Word) and search for

WP Typographic Symbols

The person might find out what the text of the symbol field looked
like. In other words, what did Microsoft alter to make it hidden
instead of ordinary; is it like hidden bookmarks for example? If they
were then to post what they found, one of the experts in the group
might be able to figure out how to search for these things. At the
very least it would be a useful contribution to knowledge.

Of course, the Word programmers might have used some less obvious
method of hiding the field, and this might not work at all.

Bob S