使用文本字段截断时，如何防止 jasper-reports HTML 导出出现换行？
使用 iReport 4.5.0，我设置这两个属性和值：
net.sf.jasperreports.text.truncate.at.char=truenet.sf.jasperreports.text.truncate .suffix=...
目的是在必须截断文本字段时将“...”添加到文本字段的末尾，并且截断确定发生在字符级别，而不是在词的层面上。导出为 PDF 时，这可以按预期工作。但是，导出到 HTML 时，最后一个截断的标记（附加后缀）通常（但并非总是）会错误换行。 （即使 StretchType 设置为“无拉伸”，它也会执行此操作。）示例：
如果我更改 net.sf.jasperreports.text.truncate.at.char=false （这样它会在单词而不是字符上中断）它似乎更频繁地工作，但这只是因为单词中断通常会为 后缀。意外的换行仍然会在断字时发生，特别是当我增加给定后缀的长度时。
我最好的猜测是 HTML 导出器测量并没有精确计算给定后缀所需的宽度（如果它正在计算的话）。
- 任何人都可以确认吗？
- 有关解决方法的任何建议吗？
似乎将 StretchType 设置为“无拉伸”，HTML 导出器可能还应该设置空白：nowrap。然而，尽管这会阻止换行，但后缀的末尾将被部分隐藏（由于溢出：隐藏样式）。
Using iReport 4.5.0, I'm setting these two properties and values:
net.sf.jasperreports.text.truncate.at.char=truenet.sf.jasperreports.text.truncate.suffix=...
The intent is to add "..." to the end of textfields whenever they must be truncated, and that the truncation determination happens at the character level, rather than at the word level. This works as expected when exporting to PDF. However, when exporting to HTML, the last truncated token (with the suffix appended) will often, though not always, wrap incorrectly. (It does this even though StretchType is set to No Stretch.) Example:
If I change net.sf.jasperreports.text.truncate.at.char=false (so that it breaks on words instead of characters) it seems to work more often, but only because word breaks usually leave more space for the suffix. The unexpected line wrapping still occurs with word breaks, especially if I increase the length of the given suffix.
My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all).
- Can anyone confirm?
- Any suggestions as to a workaround?
It seems like with StretchType set to No Stretch, that the HTML exporter should probably also set white-space:nowrap. However, although that would prevent the line from wrapping, the end of the suffix would be partially hidden (due to overflow:hidden styling).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“我最好的猜测是，HTML 导出器测量并没有精确计算给定后缀所需的宽度（如果它正在计算的话）。”
但实际上并没有一个简单的解决方法。您的 PDF 很好，所以您做的事情是正确的。嗯...你做的很多事情都是正确的。 ;-)
在 HTML 中，您不知道（以非常基本的方式）将呈现文本的字体的精确细节。您当然可以指定字体。但客户端机器可能没有它。或者它可能有一个相同的......但不完全相同。或者客户端可能通过各种客户端覆盖机制选择使用不同的字体或不同的大小。
如果您尝试不同的字体，您应该会注意到结果略有不同。您也许能够更频繁地找到一种效果更好的产品。 （显然，这并不是 100% 完美。）
如果您没有使用字体扩展，那么您应该使用。如果您使用字体扩展，则可以按降序优先顺序指定应该在 HTML 中使用的字体列表。这应该为您提供足够的控制力，以便在大量情况下获得良好的行为。通常，您可以在您关心的所有情况下使其变得完美。
"My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all)."
But there's not really a simple workaround. Your PDF is good, so you're doing something right. Well... you're doing lots of things right. ;-)
In HTML you don't know--in a very fundamental way--the precise details of the font that will render the text. You can certainly specify the font. But the client machine might not have it. Or it might have one that is the same... but not quite the same. Or the client might choose to use a different font or different size via various client-side override mechanisms.
If you try different fonts, you should notice slightly different results. You may be able to find one that works better more often. (Clearly, this isn't 100% perfect.)
If you aren't using Font Extensions, then you should. If you are using Font Extensions, then you can specify the list of fonts in descending preference that ought to be used in the HTML. This should give you enough control to get behavior that is good in a large number of cases. Often you can make it perfect in all of the cases that you care about.