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

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

问题描述

好的,这是一些代码(pdfDocumentcom.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),在分辨率为96dpi(我的是)的屏幕上,3f点应该恰好是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查看器,显示设备或任何其他涉及的组件(例如图形驱动程序,OS显示抽象等)的限制

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, ...)

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

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