Long text fields sometimes truncated when exporting report to .rtf

Question

Hi, all. I have what I hope is a simple problem with exporting a report to .rtf format.

Specifically, some long text fields (i.e. what were formerly called "memo" fields) in some records are missing the last few words after I export them. If I view the report in Access itself, they are intact; it is only the exported .rtf file that has the problem.

I've googled this issue and found several people with similar problems, but none with the exact issue I'm having. The following are some things I found that are NOT the issue in my case:

• The cut-off point is not 255 characters, or for that matter any one consistent number. In fact, it's not even the longest fields that are being truncated. On the first page of the exported file, for example, one field is cut off at 231 characters. But in the record immediately above it, one with 236 is left intact, as are others throughout the report that are much longer. (I'll paste a couple records below, so you can more easily see what I'm talking about.)
• The cut-off points are not places where there are two consecutive paragraph marks. In all the cases I've noticed, a field ends in mid-sentence (though never in mid-word, which I suspect is relevant). In the same case mentioned above, the record that is cut off had no paragraph marks in it before exporting, while the one that was intact did have two consecutive paragraph marks in it. All the cut-off points seem to be places where the export introduced a paragraph mark, not places where there was one all along.
• The cut-off points do not occur only at the ends of pages.

Below are two sample records, the very ones I refer to in the first bullet point above in fact.  These are the third and fourth of just over 200 overall, both from the first page of the exported file. The first one (Aim) appears exactly as it should. The second (Alchemical Counter) ends in mid-sentence in the exported .rtf file. Within Access, the last bit reads "regardless of its normal area of effect." (without the quotes).

(Note that the line wrapping isn't this ugly in the original .rtf file, however I wanted to leave the paragraph marks from the original exported records alone in case they're somehow relevant.)

This sort of thing continues throughout the report, with no obvious pattern, overall affecting perhaps 15% of the records. The longest and most complicated description in the entire report, at 1269 characters, is perfectly intact; on the previous page, a description short enough to fit in a tweet is cut off at 121 characters. It makes no sense, at least to me.

Any idea what might be causing this, and whether/how it can be prevented?

Aim

Modified Ranged Strike (Bow, Boom-Stick)

Recovery:              +1

Taking an extra moment when aiming sometimes pays off.

If you get at least one (total) success on this strike but zero or fewer net successes, you hit anyway, dealing damage as

though you had one net success.

In addition, add your total (not net) successes to the total damage of this strike.

Alchemical Counter

Reaction

Requirements:        Use when a strike against you gets -2 or fewer net successes.

When a strike against you gets -2 or fewer net successes, you may use a bomb against the attacker as a reaction,

provided the attacker is within that bomb's usual range. This bomb affects only the attacker regardless of its normal

(By the way, this reminds my of a different, lesser problem with this export. There's supposed to be a black line between records. That doesn't survive the .rtf export either, even though .rtf format should be able to handle that. Any way to preserve this?)

Answer 1

I haven't experienced this problem, so my thoughts on the matter are just speculation.

Do the text boxes in which these fields are displayed on the report have their CanGrow property set to Yes?

Are they sized close to the point where the text would just fit, without a lot of extra space or blank lines?

Answer 2

The second question is potentially interesting. I don't have time right at the moment, but the next time I do I'll play around with the size and spacing of the boxes on the report and see if that makes a difference. It could be that this issue affects only fields that are just a little too big to fit in the box, but for ones that are way too big CanGrow kicks in as expected. That sounds a bit goofy to me, but it's not like it makes any less sense than the fact that the problem happens in the first place.

Yes, my thought is that something is wrong or inconsistent (between the code that displays the report and the code that exports it to RTF) in the calculations used to determine whether the last word does or doesn't fit in the text box.  It's pure speculation, but your idea of tweaking the size of the text boxes is what I was going to suggest as the next line of investigation.

I've tried this a couple different ways and so far, it's had no effect. The funny thing is it's been consistently the same records getting truncated, through not only this change but other, arguably-bigger ones. The problem seems random, but clearly it isn't random at all.

I'm going through the printout and I think I see the pattern, at least. So far, all the cases where truncation occurs in the Description field (the unlabeled text in normal type near the end of the record) happen when that field consists of one paragraph at least three lines long. In these cases, the exported file is missing the last line.

If this field has multiple paragraphs (like Aim above, where it consists of two very short paragraphs), it is always left intact. If it consists of one paragraph and that paragraph is short enough to fit on one or two lines, that's no problem either. It's only descriptions of certain intermediate lengths that are cut off, and even then it seems to depend how they're formatted.

The problem also affects some flavour texts (the italicized text just before the description). In this case, the problem occurs when the text would consist of one two-line paragraph, as opposed to one one-line paragraph. That's as long as this particular field normally gets.

This suggests a workaround - when entering the data, hit Return one extra time at the end of a field that might have this issue. But I'd still really like a way to get rid of the problem entirely.

Answer 3

I got an e-mail saying a moderator had deleted this thread. Obviously that isn't actually the case, but that scared me for a moment! Does anyone have any idea why that would have happened?

The only thing I can think of is copyright concerns with the two records I posted. In case that's the issue, let me clarify that these are from a game I am in the process of writing, and the copyright in all aspects of it is owned by me (technically by a sole proprietorship that I own, which amounts to the same thing). I hereby give myself permission to post bits of my work-in-progress here as needed :-).

I am not posting anyone else's work, with or without their permission, have no plans to do so, and if I were to do so I'd at least attribute it properly.

Answer 4

The second question is potentially interesting. I don't have time right at the moment, but the next time I do I'll play around with the size and spacing of the boxes on the report and see if that makes a difference. It could be that this issue affects only fields that are just a little too big to fit in the box, but for ones that are way too big CanGrow kicks in as expected. That sounds a bit goofy to me, but it's not like it makes any less sense than the fact that the problem happens in the first place.

Yes, my thought is that something is wrong or inconsistent (between the code that displays the report and the code that exports it to RTF) in the calculations used to determine whether the last word does or doesn't fit in the text box.  It's pure speculation, but your idea of tweaking the size of the text boxes is what I was going to suggest as the next line of investigation.

Answer 5

First of all, my apologies; your first question hit on something I meant to include in the OP, but forgot to. Thanks for the chance to remedy that error. Having said that:

Yes, I made sure to check CanGrow on all relevant fields of the report. In any case, if that were the issue, I'd expect it to be affecting only the longest fields, not seemingly random ones; but that's not to deny it was worth checking.

The second question is potentially interesting. I don't have time right at the moment, but the next time I do I'll play around with the size and spacing of the boxes on the report and see if that makes a difference. It could be that this issue affects only fields that are just a little too big to fit in the box, but for ones that are way too big CanGrow kicks in as expected. That sounds a bit goofy to me, but it's not like it makes any less sense than the fact that the problem happens in the first place.