积分 ->像素 iText (im) 精度 [英] Points -> pixels iText (im)precision

查看:78
本文介绍了积分 ->像素 iText (im) 精度的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

好的,这是一些代码(pdfDocument 是一个 com.itextpdf.text.Document):

Okay, here's some code (pdfDocument is a com.itextpdf.text.Document):

PdfPTable table = new PdfPTable(1);
PdfPCell cell = new PdfPCell();
cell.setFixedHeight(3f);
for (int i = 1; i < 100; i++)
{
    table.addCell(cell);
}

pdfDocument.add(table);

根据我的计算(像素 = 点数/0.75f)3f 点在 96dpi(我的是)的屏幕上应该正好是 4 个像素.但是,当我使用上面的代码创建表格时,我会得到单元格 4 - 3 - 4 - 3 - 4 - 3 等的交替高度...

According to my calculations (pixels = points / 0.75f) 3f points should be EXACTLY 4 pixels on a screen with 96dpi (which mine is). However, when I create a table with the code above, I get alternating heights of the cells 4 - 3 - 4 - 3 - 4 - 3 etc...

为什么会这样?我会理解我输入的值是缩放到 x.6 像素的值,所以每隔一段时间就会出现一个比其他单元高一个像素的单元格.

Why does this happen? I would understand the value I put in was something that scales to x.6 pixels so every so often would appear one cell that is a pixel higher than the rest.

例如:

如果我将值减小到 2f,大多数单元格将高 2 个像素,但每 10 到 15 将是 3 像素高.

If I decrease the value to 2f, most of the cells will be 2 pixels high, but every 10th ot 15th will be 3 pixels high.

如果我将值增加到 4f,所有单元格都将是 5 个像素高,但每三个边框将厚一个像素.

If I increase the value to 4f, all cells will be 5 pixels high, but every third border wll be one pixel thicker.

此外,如果我确实使用 x.6 作为值,该值会被四舍五入 (5.99 -> 6) 还是舍入 (5.99 -> 5) 为整数?

Also, if I do use x.6 as a value, will the value be rounded (5.99 -> 6) or floored (5.99 -> 5) to an integer?

由于 iText 只适用于点,我猜这是一个内部 PDF 的东西,.但我还是想知道.

Since iText only works with points, I'm guessing it's an internal PDF thing,. but I'd still like to know.

我现在需要确切地知道一个单元格将被赋予多高的浮点值,以便我可以精确地预测整个表格或对象的高度,然后我可以将其计算到整个页面的组成中.如果我不可靠地知道,我就不可能做到.

I need to now exactly how high a cell would be given the float value so I can precisely predict how high the whole table or object would be so I can then calucalte that into the composition of the whole page. If I don't know reliably, it's impossible for me to do.

有没有一种可靠的方法可以让我准确地计算出 pdf 版本的浮点值应该是多少 x 像素高?好像我用的公式不行,或者还有别的什么?

Is there a reliable way in which I can calculate exactly what the float value should be for the pdf version to be exactly x pixels high? It seems that the formula I'm using doesn't work, or maybe there's something else?

推荐答案

乍一看表格行似乎有不同的高度:

At first glance the table rows seem to have different heights:

但是如果放大,您会看到它们实际上具有相同的高度,例如此处1600% 时:

But if you zoom in, you'll see that they actually have the same height, here e.g. at 1600%:

因此,您在 100% 时看到的效果只是 PDF 查看器的显示伪像.

Thus, the effect you see at 100% is merely a display artifact of the PDF viewer.

如果您进一步查看页面内容,您会发现:

If you furthermore look at the page content you'll find:

0.5 w
88.3 803 418.4 3 re
S
0.5 w
88.3 800 418.4 3 re
S
0.5 w
88.3 797 418.4 3 re
S
0.5 w
88.3 794 418.4 3 re
S
0.5 w
88.3 791 418.4 3 re
S
.
.
.
0.5 w
88.3 515 418.4 3 re
S
0.5 w
88.3 512 418.4 3 re
S
0.5 w
88.3 509 418.4 3 re
S

即99 个矩形,每个高度为 3,垂直距离也为 3,线宽为 0.5.此外,没有转换或用户空间单位定义,因此这些维度的单位是 1/72".

i.e. 99 rectangles with a height of 3 each and a vertical distance of 3, too, with a line width of 0.5. Furthermore there is no transformation or userspace unit definition, so the unit of those dimensions is 1 / 72".

因此,本质上,PDF 内容准确地描述了您想要的内容,每个行的表格都正好是 3/72" 高.

In essence, therefore, the PDF content describes exactly what you wanted, a table of rows each of which exactly 3 / 72" high.

因此,任何显示不准确都是由于 PDF 查看器、显示设备或任何其他相关组件(例如图形驱动程序、操作系统显示抽象等)的限制

Thus, any display inaccuracy is due to limitations of the PDF viewer, the display device, or any other component involved (e.g. graphic drivers, OS display abstractions, ...)

这篇关于积分 -&gt;像素 iText (im) 精度的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆