|
|
Post by donaldf on Apr 20, 2017 7:15:36 GMT -5
When I edit a text file with hex on, the font for the top alpha line of each line triplet is in a different font than the two lines for the hex display. It is impossible to line up the characters. How do I change the top line to match the other two. At this point, I really don't care which fixed space font is used as long as it lines up.
|
|
|
|
Post by George on Apr 20, 2017 11:12:41 GMT -5
donaldf:  Can you post a screenshot? What font are you using? All text output to the screen uses the same font, text lines, hex lines, line numbers, command line etc. The only one different is the status line at the bottom. George |
|
|
|
Post by donaldf on Apr 20, 2017 15:28:01 GMT -5
OK, I'm a newbie to this board so some of my posting will be clumsy. This is from a SPFLiteScrPrt.log file.
Command > Scroll > CSR
****** ************************** Top of Data ****************************
--------------------------------------------------------------------------
000001 Owatonna, Steele, MN, USA
0000476766662257666622442255400000000000000000000000000000000000000
1000F714FEE1C03455C5C0DEC053100000000000000000000000000000000000000
--------------------------------------------------------------------------
****** ************************* Bottom of Data **************************
--------------------------------------------------------------------------
Note the file is binary and I suspect that may be large part of the problem? Is there a setting that will turn the nonprintable characters into "."s like the mainframe version does. The font is "Lucida Sans Typewriter".
|
|
|
|
Post by donaldf on Apr 20, 2017 15:29:56 GMT -5
And that didn't post well. The left edge of the box character and the 0 and 1 on the next two lines are all aligned.
|
|
|
|
Post by donaldf on Apr 20, 2017 22:18:59 GMT -5
Here's another try.  |
|
|
|
Post by donaldf on Apr 21, 2017 6:58:38 GMT -5
George: the fix may be pretty easy. I've used the SPF editor and it's clones and successors for many years. In the early versions of SPF/VS that operated on a mainframe (1970's), unprintable EBCDIC characters were changed to "." in that upper row. That practice was continued with SPFPC in the early years of PC's (late 1980's and into the 1990's). This is the first version I've encountered that didn't do that. In SPFPC, the characters affected were 0x00 through 0x1F and 0x80 through 0xFF. Please consider that as a display option.
|
|
|
|
Post by George on Apr 21, 2017 12:12:20 GMT -5
donaldf: Robert: There are a variety of reasons for things being as they are. Yes Robert - expediency. First, all print in SPFLite is done using Graphic text commands, the entire screen is not created as a 'text' window, but as a Graphic window. Doing print by manually spacing using an 'average' character width, would work, but means printing everything one character at a time via the graphic print routines. Right now, printing always does the longest possible string as one call. As to this method opening things up to proportional fonts - I experimented with that many years ago in some trial releases. It creates surprisingly ugly displays. Not a great idea. The 2nd main problem is that although a lot of the printing goes through common routines, a large amount of printing, especially by the keyboard handlers, directly manipulates individual characters on the screen. Again, efficiency, why reprint an entire line to alter 1 character. Altering this means a search mission to track all these down and convert to some other method which handles unprintable characters. Given that: - we're talking a text editor here, files with binary data will always cause some kind of problems
- unlike the old 3270's, which only had the single built-in font available, PC's have access to thousands of fonts
- the simple process of choosing a font which has a defined character for all 256 characters is trivial
how on earth can making extensive changes to the display logic be justified.
I don't want to seen 'hard-nosed' here, but given the ease of a perfectly viable solution here, there's no way I will tackle code changes to correct this problem.
George
>>> ======= >>>
George ...
The stuff I wrote above was just ideas about how to do it if you were inclined. I knew the whole thing would be ugly if you tried, and even if it worked it would really slow things down. So, no biggy about being hard nosed.
The only real way to do this without being awful is you'd have to translate the data to removed any 'bad' characters, and then display the translated string in a single call. Even so, you'd adding overhead, and brother - you'd have to make sure you found every last place you ever displayed something. in 80,000+ lines of code, that shouldn't be too hard, write ? :-))
Robert
|
|
|
|
Post by donaldf on Apr 21, 2017 13:12:03 GMT -5
George, you had me at "First ... Graphic ..." (ugh); thank you for the info. The change to Raster font worked so I'm proceeding.
|
|
|
|
Post by George on Apr 21, 2017 13:27:50 GMT -5
Donald: I'm glad the Raster font does the trick. I love that font as it makes browsing raw text files, or binary files so much more convenient. Especially having stuff like CR LF FF etc. nicely readable, rather than saying "Hmm X'0A" - is that LF? FF?"
You can thank Robert for Raster, he's the creator.
George
|
|
Can you post a screenshot? What font are you using? All text output to the screen uses the same font, text lines, hex lines, line numbers, command line etc. The only one different is the status line at the bottom.