|
|
Post by kenvanm on May 1, 2014 15:53:20 GMT -5
SPFLITE (v7.1.4016) has a problem when operating under Windows 7. The same problem occurs with one of the version 6 releases (6.2.0.3060). It works OK under Windows XP.
The file to be edited was created by saving a WORD (.doc) file as plain text. The file is apparently saved as Unicode coding. For example, the word "MAJESTIC" is displayed (under XP) as M#A#J#E#S#T#I#C#, where I'm using "#" to represent the blob displayed for the hex code 0d. If I turn hex on I see that "M" is represented by hex "4d0d".
Under Win 7, SPFLITE displays MAJESTIC OK (no blobs), but stops displaying anything after about 70-80 characters in the line. If I turn hex on, it shows ASCII codes for the letters (no "0d" characters) and shows hex codes beyond where the normal character display ends (70-80 characters). I'm not sure that this is clear, so I'll say it again, a different way. With hex on, there are 3 lines displayed, normal characters, first hex character and second hex character. Under Win 7 and hex on, a long text line is displayed as:
first line: 70-80 characters normally then blanks (or dashes?)
second and third lines: hex codes (as if the characters were ASCII coded) for the entire line, continuing beyond where the first line goes blank.
The display is also weird: if you page up and down, remnants of previous pages presist on the right side of the display -- like the display is only partially refreshed.
The find command also does not work "f MAJESTIC" cannot find MAJESTIC, even though the display clearly shows it.
It seems that SPFLITE is trying to handle the Unicode, but gets totally confused. The way it works under XP is not ideal, but much preferable to Win 7
|
|
|
|
Post by kenvanm on May 1, 2014 16:27:45 GMT -5
I misspoke, under Win 7 with hex on, the second and third lines do contain the "0d" characters. Also, the first line seems to go blank after about 120 characters, not 70-80.
Sorry about the "&" in the subject line -- I don't know how to change it to "7".
|
|
|
|
Post by robert on May 1, 2014 17:23:00 GMT -5
First guess, you have a profile problem, and your profiles for version 6 vs. 7 are not the same. You should email George with a copy of the data file (at least the part with the problem) and the contents of the INI file. You say you saved the file as "plain text" but then say it's Unicode. Those are not the same, so they can't both be true. You may have not save the file in the right format. Hex 0D is CR. Windows lines end in CR/LF, and in Unix it's just LF. No one really uses just CR any more. So, maybe SPFLite has a problem, but your data seems to have a problem, too.
|
|
|
|
Post by George on May 2, 2014 12:15:48 GMT -5
kenvanm: I'm echoing Robert. Send me a sample file, the xxx.INI profile file that matches the file's extension, and probably the SPFLite.INI file. The latter is in the \Documents\SPFLite folder, the former in the \Documents\SPFLite\PROFILES folder. If there's no security exposure, sending the .DOC file is also helpful.
Also when you load the file, does SPFLite produce any warning message? e.g File loaded is in LF format, Profile indicates CRLF (or some such wording)
George
|
|
|
|
Post by kenvanm on May 2, 2014 14:19:06 GMT -5
Since I have a dual boot system, I can use SPFLite in either Win 7 or XP. The profile for Win 7 was simply copied from the XP version so they are basically identical. Ordinary Word files, saved as plain text are no problem. However, the file I was editing is weird.
For some reason, the original author of the text file created the file as a Word table, consisting of single character cells. E.g., the word MAJESTIC is represented as as 8 cells in this table (each letter alone in a ell). When I had Word save it as plain
text, Word preceded each ASCII character with x'0d'. When I display the result, either in Notepad or SPFLite, the x'0d' characters dissappear, so it reads as MAJESTIC. However, with hex on or in a HexEditor program, the x'0d's are there.
I suspected that the Microsoft text handling software that SPFLite uses has changed from XP to Win 7 so that it now ignores the x'0d'. I tried an experiment -- I looked at my file with Notepad under XP. It displayed the word with the "undisplayable character" symbol between each character. Microsoft has done it to us, again.
While I don't mind sending my original file to you, I don't think you need it -- just enter x'4d0d410d4a0d450d530d540d490d43' as a hex string into an empty file, then turn hex on. This explains why SPFLite can't find MAJESTIC.
Incidentally, my workaround is simple: "d x'0d' all" seems to fix it.
I don't know why Word inserts the '0d' characters when it converts a table to "plain text", but it seems to do so consistently.
By the way, I now realize that it wasn't Unicode -- I just assumed it was, since there were two bytes per character.
|
|
|
|
Post by robert on May 2, 2014 15:18:49 GMT -5
Your workaround does not seem reasonable. First, D is not a command, although DEL is. I entered the hex string you show, and I get the string M#A#J#E#S#T#I#C# where the # is hex 0D.
You didn't say what your EOL value is. For text, this should be set to CRLF. I am assuming it is. Using your hex string example, I get just a single line.
Then, if I then say DEL X'0D' ALL, the one and only line in the file is deleted. Perhaps George can help more, but something about this is not adding up.
|
|
|
|
Post by kenvanm on May 2, 2014 16:11:25 GMT -5
You're right my "workaround" makes the whole line dissappear. I must have done something different to fix it earlier.
My procedure was to create a new text file and enter a '#' in it. Then I "c '#' x'4d0d410d4a0d450d530d540d490d43'" and turn hex on. the resulting display shows MAJESTIC on the first line and hex bytes on the 2nd and 3rd lines. the hex byte strings are twice as long as MAJESTIC and show the '0d' bytes. (This is all under Win 7 - under XP the display is different.)
I have also sent an email to spflite@gmail.com with the following files attached:
1. The file I'm editing -- DBSA ANNEX A Revised ZZ.txt
2. SPFLite.INI
3. SPFLiteCfg.INI
Look at the file with Notepad -- the lines are very long. When I look at the file in SPFLite, the text is truncated after about 70-80 characters but the hex bytes are not truncated.
|
|
|
|
Post by George on May 4, 2014 12:10:19 GMT -5
Hi Kenneth, Thanks for the sample files, I can see what's going on now. Basically, SPFLite is doing just fine handling the file (I know it sure doesn't look so). Mind you the file has been very mucked up during it's creation. The font you have chosen (FixedSys) is simply making things much worse, as it does not handle the embedded non-text characters at all, it clouds the whole issue. If you can, download the optional font package from the SPFLite web site and install one of the Raster fonts (Raster14 is a good one). The Raster font will accurately display ANY character. I'm attaching a BigHex.INI profile to this note. It is simply one with RECFM = F, LRECL = 32000 and EOL = None. This is so it will read the file as one big record and let us see what it really has. I renamed the file to have the .bighex filetype and loaded it. When I load the file with this, I get the following: I've tried to use vertical cr and lf to keep the spacing, but the following is not that clear BRITISHclclMclAclJclEclSclTclIclCclclclclclclcl(cl1cl4cl)clcl....
rfrf rf rf rf rf rf rf rf rfrfrfrfrfrfrf rf rf rf rfrf....
I attached the real screen shot to the note as well, what's going on is very simple to see with that. But what it also shows is that the file is crawling with extra CRLF sequences inserted by the export process. When using FixedSys as the font, the display gets totally mucked up. FixedSys is fine when the data is truly just normal text characters, but it falls totally apart when special characters are present, it just makes diagnosing what's wrong even harder. I'd highly recommend the Raster fonts, you will never have this problem.
So I think you have an export problem, not an SPFLite problem. If the text is coming from a Word table, my bet is that Word is treating the contents of every table box as a separate text line, and stuffing in a CRLF. I'd bet the table was used trying to get the layout of the characters spaced properly in some kind of grid. Works fine while still in word, but exporting? Makes a big mess.
GeorgeAttachments:bighex.INI (6.25 KB)
|
|
