Text export problem
Hi all.
I have a report that that I need to export as TXT, to be read by another application. The report detail is set up with one string per detail, and information at fixed positions, divided by spaces.
When exporting as TXT the amount of spaces between the columns are reduced, and the output file thereby unreadable for the other application (not ours).
The columns shuld start at position 1, 3, 9, 16, 23 .... but in the exported text it starts at 1, 3, 7, 13, 18 ...
Is there a solution to this?
Petter
I have a report that that I need to export as TXT, to be read by another application. The report detail is set up with one string per detail, and information at fixed positions, divided by spaces.
When exporting as TXT the amount of spaces between the columns are reduced, and the output file thereby unreadable for the other application (not ours).
The columns shuld start at position 1, 3, 9, 16, 23 .... but in the exported text it starts at 1, 3, 7, 13, 18 ...
Is there a solution to this?
Petter
Comments
If not, then this might possibly be a proportional font spacing problem. First thing I would try is to use a fixed width font like Lucida Console or any of the Courier fonts.
If not, then this might possibly be a proportional font spacing problem. First thing I would try is to use a fixed width font like Lucida Console or any of the Courier fonts.
[/quote]
Thanks.
It's a regular report, not at dot-matrix.
The font used is Courier New.
The attached pic1.jpg shows the report preview. The pic2.jpg shows the exported file in notepad. I tried to upload a .fp3-file with my report, but the forum did not accept the upload...
Petter
I suggest you look at the text file with a hex viewer (IrfanView has one). This should deliver a definitive conclusion as to whether the exported file is a problem and what it is.
IMO it will always be dicey to produce the file you require from a non-dotmatrix report, no matter what report engine is used.
Thanks for the tip.
I have checked the file with other editors (edit.com from command prompt). The file is correct as shown in notepad.
So I redid the report as a dot-matrix, but the text-export is still the same; lots of spaces are removed from my lines.
Then I tried to add a header to the report, where the header has no spaces that could be removed. And, now the text-export is correct! (attached picture). My only problem is that I can't have a header in my text-file....
It seems to me like the text export in FR only focuses on keeping each column intact, without counting the spacing between them.
I'm very pleased with FR, after moving more than 300 reports from Rave to FR during the last 3 months, so this was a little setback...
There isn't any visible difference in the pictures in the printable characters, so I suspect the problem lies in the 'white space'. Does the file import once you have removed the header with e.g. notepad?
I wonder whether the import gets confused about the end-of-line marker, which could be any of CR, LF, CR-LF, or LF-CR? Or maybe initialization code? FR may also insert control code in front or after a field, e.g. bold-on/off, or italics on-off. Of couse one would expect this to be visible on the template, but there may be other codes which are not.
Have you got a file which imports correctly? A byte by byte comparison should show what the difference is.
Maybe you need to have an additional processing step between export and import?
Thanks again!
I have not been able to actually test the file import, because I don't have the actual application available. What I do to test the output is to compare the old and new text-files (Rave and FR) with a compare-tool, and the differense between the files appears to be quite clear.
I've now attached the actual text-files exported from FR (I'm sorry for not doing that at first...). They are both produced from the same dot-matrix report. One is made with Pageheader1.visible=true. This one has correct columns spacing. The other one is made with Pageheader1.visible=false. This one has reduces columns spacing.
(My previous picture was not accurate, as I did some alignment-errors when redoing the report as a dot-matrix. I'm sorry for that.)
Petter
It seems to be a very odd problem. One thought which just came to me now is this, the background has its own character pitch. IOW, the background, page white space, may have a different pitch to the print fields.
Background could be 12cpi while the print fields are set to 10cpi or vice versa. Because there aren't any control commands the export might just interpret the gap with the wrong pitch, increasing or reducing (in your case) the number of characters needed to fill that space. The header, being a different band maybe initialises the export to the right pitch for the page.
I think the problem arises from the export not using the template characteristics as the basis for exporting but the the rendered, printable file. In the past this casued havoc with the Excel export (better now) because even with the most careful aligning of the columns the rendered image did not align 100% and the export then failed to recognize that this was the same column. A simple excel sheet could then easily have double of triple the number of columns, in some cases misaligning the column values altogether.
I am heavily into speculations by now. Examining the export source code may shed some light on this.
Personally, I would consider using some other export method. Whatever the problem is, if we can get it to work without finding an explanation it may rear its ugly head again at the most inopportune time. Mike Skolnik's exports work very well (www.scalabium.com) but I am sure there are others.
Hi again.
Here are testreports; one with header ane on without. I've removed all database from the report, so now there is just 2 bands, each with one memo. In the 'without' the headerband is set to not visible.
The export to text is the same: With header is OK, without header is not.
Petter