[Home] [Puzzles & Projects] [Delphi Techniques] [Math Topics] [Library] [Utilities]
Here's a program illustrating the use of FileStream (TFileStream component) to manipulate a text file. The specific task at hand is to eliminate redundant carriage return characters from a text file. The problem occurs in several fonts included with the LEDSign package - a Java implementation simulating scrolling LED signage.
How the extra carriage returns originate is anyone's guess. A Google search on "extra carriage return characters" returns 33,000 hits so it's not exactly a unique problem. I've seen blame placed on Unix, Mac, Netscape and a site named furryterror.org.
My theory is this: Many utilities exist to insert an extra carriage return (Cr) in front of a linefeed (Lf) to convert a Unix format file to Windows format. If the utility isn't smart enough to check if a Cr already exists, running such a program twice would result in the Cr-Cr-Lf sequence.
My specific instance of the problem occurred with a couple of the font files included with the LEDSign download. LEDSign is a Java based package which simulates LED signage. I didn't run the package, but did want to borrow the fonts for my Delphi version of the same project.
OK - the pattern we are looking for is Cr-Cr-Lf (Cr=carriage return=13=hex 0D, Lf=linefeed=10=hex 0A). TFileStream effectively replaces the old Blockread/Blockwrite procedures even though Blockread and Blockwrite are still available. The general strategy for the program is
If we could be assured that the entire file fits into a single buffer, the problem would be simplified - but I'm assuming that that is not the case. So the tricky part of the program is to detect Cr-Cr-Lf that may cross a buffer boundary (for example a buffer fill ends with a Cr and then next buffer fill begins with a Cr-Lf). My solution is to not write the last 2 characters of the buffer, but move them to the beginning of the buffer and read the next chunk of data starting at position 3. Don't forget to write out those last 2 bytes of data when all the data has been processed.
The download includes a test file named Snow.font demonstrating the problem.
I had thoughts of generalizing the program to replace all occurrences of an arbitrary string with another string. Two problems I didn't feel like addressing, since I didn't really need the more powerful version: 1) How to enter and display non-character data (like Cr and Lf) in the strings and 2) writing string processing type procedures that would work for a buffer which is not actually a string (or perhaps make the buffer a real string?). If anyone tackles this, let me know.
Update 2/25/07: The above link to LED Sign was reported as broken during a recent scan of DFF hyperlinks. The font files are available elsewhere and some have been kind of "corrected" by removing all Carriage Returns, leaving only Line Feeds. FileFixup also handles this case by inserting a CR in front of each LF that is not preceded by a CR.
Copyright © 2000-2013, Gary Darby
All rights reserved.