我正在使用PDFBOX和itextsharp dll并处理pdf . 这样我就可以得到矩形内文本的文本坐标 . 使用itextsharp.dll提取矩形坐标 . 基本上我从itextsharp.dll获取矩形坐标,其中itextsharp使用坐标系统作为左下角 . 我从PDFBOX获取pdf页面文本,其中PDFBOX使用坐标系统作为左上角 . 我需要帮助将坐标从左下角转换为左上角
提前致谢
Updating my question
请原谅我,如果你理解我的问题,如果没有提供完整的信息..
好吧,让我试着从一开始就提供更多细节 .
我正在开发一个工具,我得到一个PDF,其中使用注释部分中的一些绘图标记绘制一个矩形 . 现在我正在使用iTextsharp读取矩形坐标
PdfDictionary pageDict = pdReader.GetPageN(page_no);
PdfArray annotArray = pageDict.GetAsArray(PdfName.ANNOTS);
其中pdReader是PdfReader .
并使用PDFBOX提取页面文本及其坐标 . 在哪里我有一个类创建pdfBoxTextExtraction在这个我处理文本和坐标,使它返回文本和 llx,lly,urx,ury "line by line"请逐行注意而不是句子明智 .
所以我想提取位于Rectangle坐标内的文本 . 当从itextsharp返回矩形的坐标时,我陷入困境,即llx,lly,urx,一个矩形的ury在 lower left 处有一个原点,因为从PDFBOX返回的文本坐标的原点是 upper left . 然后我意识到我需要调整y轴使原点从左下角移动到左上角 . 因为我得到了页面的高度和庄稼的高度
iTextSharp.text.Rectangle mediabox = reader.GetPageSize(page_no);
iTextSharp.text.Rectangle cropbox = reader.GetCropBox(page_no);
做了一些基本调整
lly = mediabox.Top - lly ury = mediabox.Top - ury
在某些情况下,调整工作,而在一些PDF需要调整cropbox
lly = cropbox .Top - lly ury = cropbox .Top - ury
在某些PDF文件上工作的地方 .
我需要的是帮助调整矩形坐标,以便我得到矩形内的文本
希望这很清楚 . 如果不是请原谅我并要求同样的
谢谢
2 回答
PDF中的坐标系在ISO-32000-1中定义 . 该ISO标准解释了X轴朝向右侧,而Y轴朝向上方 . 这是默认值 . 这些是iText返回的坐标(幕后,iText解析所有CTM转换) .
如果你想转换iText返回的坐标,以便在Y轴向下方向的坐标系中获得坐标,你可以从页面顶部的Y坐标中减去iText返回的Y值 . .
An example: 假设我们正在处理A4页面,其中底部的Y坐标为0,顶部的Y坐标为842.如果您有Y坐标,如
y1 = 806
和y2 = 36
,则可以执行以下操作:现在
y1 = 36
和y2 = 806
. 您只需使用简单的高中数学就可以颠倒Y轴的方向 .Update based on an extra comment:
每个页面都有一个媒体框 . 这定义了最重要的页面边界 . 可能存在其他页面边界,但它们都不会超过媒体框(如果有,则表示您的PDF违反了ISO-32000-1) .
裁剪框定义页面的可见区域 . 默认情况下(例如,如果缺少裁剪框条目),裁剪框与媒体框重合 .
在你的评论中,你说你从高处减去llx . 这是不正确的 .
llx
是左下方的 x 坐标,而高度是在 Y 轴上测量的属性, unless 页面被旋转 . 您是否检查了页面词典是否具有/Rotate
值?您还声称iText返回的值与PdfBox返回的值不匹配 . 请注意,iText返回的值符合ISO标准定义的坐标系 . 如果PdfBox不遵循这个标准,你应该向PdfBox why 的人们询问他们是不是遵循标准,而是使用他们正在使用的 what 坐标系 .
也许这就是mkl的评论 . 他写了:
也许PdfBox搜索最大Y值
Ymax
和最小X值Xmin
然后在所有坐标上应用上述变换 . 如果要渲染PDF,这是一个有用的转换,但它是如果要使用坐标,例如在相对于页面上的文本的特定位置添加内容,则执行此类操作是不明智的(因为已转换的坐标不再是"PDF"坐标) .Remark:
你说你需要PdfBox来获取页面的文本 . 为什么需要这个额外的工具? iText完全能够提取和重新排序页面上的文本(假设您使用正确的提取策略) . 如果没有,请澄清 .
请注意,我们最近决定支持Type3字体,虽然我们不相信这是有道理的(请参阅Text extraction is empty and unknown for text has type3 font using PDFBox,iText (difficult topic!)以了解为什么不这样做) .
有些人认为"wrong extraction"通常可以"wrong interpretation"提取的内容,如本邮件列表答案所述:http://thread.gmane.org/gmane.comp.java.lib.itext.general/66829/focus=66830
在其他情况下,我们遵循规范,导致结果与PdfBox返回的结果不同 . 观看https://www.youtube.com/watch?v=wxGEEv7ibHE了解更多信息 .
这些都是最后的调整