处理 SSRS 2005 中非常高的文本框和分页

发布于 2024-09-07 14:20:10 字数 789 浏览 3 评论 0原文

我在 SQL Server Reporting Services 2005 中有一个报表。它使用页眉和页脚,并且没有子报表。主体部分包含一些较小的元素,然后是一个简单的单列表。该表有一个标题行和一个详细信息行。基本上,标题只是一个标签。详细信息行是单个文本框,其输出为简单的 Fields!FieldName.Value。

问题在于,在本例中,FieldName 是一个高度可变的长度字符串。它可以是最多 8000 个字符的句子(通常不超过 2 页)。文本可以包含换行符/段落符(回车符),但不能包含其他特殊格式。只要内容适合一页,一切都很好。一旦文本超过一页(8.5x11),文本就会被突然切断。由于这是一个分页问题,​​因此仅在导出为 PDF 或在打印布局中查看报表时才可见。

似乎第一页上的行可以增长到最大大小,然后它会将其砍掉并在第二页上启动它。但这种切断与文本的关系并没有得到仔细管理。它可以出现在一行的中间,使其显示第一页上字母的上半部分和第二页顶部的下半部分。

显然,这是不可接受的,因为它看起来非常不专业,并且会损害如此混乱地分割的行的可读性。我也永远无法确定它会严重分裂,因为有时它或多或少会均匀地结束页面,尽管通常我仍然可以看到下一页上某些字母的尾部(例如 g 和 p)。

第二个问题是我真的希望表格行标题在每一页上重复。设置明显的属性“RepeatOnNewPage”没有效果。我怀疑这是因为它仍在尝试显示单个真正垂直高的行。重复标题并在详细信息行之间很好地分割页面似乎是可以的。但是因为这基本上只是一大块文本,因此只是一个非常高的行,所以它不能很好地分割它。

我可以做什么或用什么来解决这个问题?我可以在没有重复标题的情况下生活,只要它不切断行中间的文本即可。

I have a report in SQL Server Reporting Services 2005. It makes use of a page header and footer and has no subreports. The body portion contains a few smaller elements and then a simple single column table. The table has a single header row and a single detail row. The header is just a label, basically. The detail row is a single textbox with a simple Fields!FieldName.Value as its output.

The problem is that FieldName, in this case, is a highly variable length string. It can be a sentence up to 8000 characters (usually no more than 2 pages worth). The text can contain line/paragraph breaks (returns) but no other special formatting. Everything is fine so long as the content fits on one page. Once the text exceeds a single page (8.5x11), the text is very nastily cut off abruptly. Since this is a pagination problem, it is only visible when exporting to PDF or when viewing the report in Print Layout.

It seems as though there is a maximum size the row can grow to on the first page and then it chops it off and starts it up on the second. But this cutoff is not carefully managed in relation to the text. It can occur right in the middle of a line, causing it to show the top halves of the letters on the first page and the bottom halves at the top of the second page.

Obviously, this is unacceptable, as it looks very unprofessional and can impair the readability of the line that was so messily split. I also can never be sure it'll split badly, as sometimes it more or less ends the page evenly, though usually I can still see the hanging tails of certain letters on the next page (g and p for instance).

The secondary problem is that I'd really like the table row header to repeat on each page. Setting the obvious property, "RepeatOnNewPage" has no effect. I suspect this is because it's still trying to show the single really vertically tall row. It seems like it's okay repeating headers and splitting pages nicely between detail rows. But because this is basically just a big block of text, and thus just one really tall row, it doesn't split it nicely.

What can I do or use to solve this problem? I can live without the repeating header so long as it just doesn't cut off text in the middle of a line.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

爱的故事 2024-09-14 14:20:10

不幸的是,分页微调是 SSRS 的最大弱点之一。

我只能建议您在 SSRS 获取长文本之前将其分解为多行。您需要解析文本以查找断词。结果将是输出中看起来很奇怪的中断,因为您不知道中断将出现在打印报告中的哪一行上。然而,它比将文本切成两半更具可读性。

如果文本由大小合理的段落组成,您可以用这种方式解析它。

您甚至可以使用 SQLCLR 和 System.Drawing.Graphics.MeasureString 方法来测量文本以微调输出,但我不建议您采用这种佯装方式。

Unfortunately, page break fine tuning is one of the biggest weak points of SSRS.

I can only suggest that you break up the long text into multiple rows before SSRS ever gets it. You'd want to parse the text to look for word breaks. The result will be odd looking breaks in the output since you won't know where the break will come on a line in the printed report. However, it'd be much more readable than cutting text in half.

If the text is comprised of reasonably sized paragraphs, you could parse it out that way instead.

You might even go so far as to measure the text using SQLCLR and the System.Drawing.Graphics.MeasureString method to fine tune the output but I wouldn't recommend that route for the feint of heart.

瑾夏年华 2024-09-14 14:20:10

在 SSRS 2008 R2 和 Visual Studio 2008 中:

单击(不是右键单击)文本框并转到属性窗口(VS 的右下侧)->保持在一起=假。

文本将在一行之间清晰地剪切并继续下一页。

只是想在此处添加,因为搜索此内容不会返回很多结果。

In SSRS 2008 R2 and Visual Studio 2008:

Click (not-right click) a textbox and go to the properties window (lower right side of VS) -> KeepTogether = false.

The text will cleanly cut between a line and continue on the next page.

Just thought to add here as searching for this doesn't return many results.

っ左 2024-09-14 14:20:10

我已经按照 JC 过去的建议进行了操作,将文本分解为段落,每个段落实际上都是其自己的行。考虑到 SSRS 的局限性,效果相当好。

需要注意的一件事是,您需要确保段落正确排序。在大多数情况下,它会以正确的顺序显示它们,但添加带有 sortID 的列以向表提供一些排序提示可能是一个好主意。

I have done what JC has suggested in the past where I've broken down the text into paragraphs and each paragraph would in effect be its own row. Works pretty well given the limitations of SSRS.

One thing to be careful about is that you would need to make sure that your paragraphs sort properly. In most cases it would display them in the correct order, but adding in a column with sortID to give some sorting hints to the table would probably be a good idea.

会发光的星星闪亮亮i 2024-09-14 14:20:10

最后,文本截断问题是由于相关文本框上的非标准填充造成的。

无论出于何种原因,填充大于默认值(周围 2pt)似乎会导致其分页变得糟糕。我想这是因为算法在决定在哪里中断段落时没有考虑填充。使用默认填充,每页上的行总是干净漂亮地结束。

作为一种解决方法(因为我喜欢填充为布局提供的额外空白),我使用矩形来实现边框,并使其内部的文本框比矩形小约八分之一英寸。这给了盒子一些内部填充,同时显然仍然允许分页正确确定何时拆行。

尽管如此,还是有很多不必要的头痛。

In the end, the cut-off-text problem was due to non-standard padding on the textbox in question.

For whatever reason, having padding any greater than the defaults (2pt all around) seemed to cause its pagination to go sour. I imagine it is due to the algorithm not taking padding into consideration when deciding where to break the paragraph. With default padding, the line always ends cleanly and nicely on each page.

As a workaround (since I liked the extra white space the padding gave to the layout), I used a rectangle to achieve the border and made the textbox inside it smaller than the rectangle by about an eighth of an inch. This gave the box some inner padding while still apparently allowing the pagination to correctly determine when to break up lines.

Still, a lot of unnecessary headache.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文