如何在iText 7中查找文本位置和边界

Question

正如评论所说，这项工作很难，所以我想一步一步地解决它，看看它的局限性。首先，我将集中在下面的第一个问题上。

起源：

我想替换PDF文件中的文本以进行翻译，例如，将英文PDF转换为中文PDF。

我的解决方案是：

1. 查找位置为矩形的所有文本

具体来说，我实现了IEventListener接口来获取渲染信息，并使用此渲染信息来查找带有位置矩形的文本。

但我遇到了一些问题：

1. 使用“渲染信息”，我无法获得文本的确切位置（起点准确，但终点有时不准确）

有没有比当前解决方案更好的方法来实现我的目标？

或者，任何人都可以就上述问题提供一些建议？

更新：

第一个问题的例子：

我只是记录文本和它们在渲染中遇到的位置，并在每个文本块周围画一个矩形。代码是：

主要的。JAVA

PdfDocument pdfDoc = new PdfDocument(new PdfReader(srcFileName), new PdfWriter(destFileName));
SimplePositionalTextEventListener listener = new SimplePositionalTextEventListener();
new PdfCanvasProcessor(listener).processPageContent(pdfDoc.getFirstPage());
List<SimpleTextWithRectangle> result = listener.getResultantTextWithPosition();

int R = 0, G = 0, B = 0;
for(SimpleTextWithRectangle textWithRectangle: result) {
    R += 40; R = R % 256;
    G += 20; G = G % 256;
    B += 80; B = B % 256;
    PdfCanvas canvas = new PdfCanvas(pdfDoc.getPage(pageNumber));
    canvas.setStrokeColor(new DeviceRgb(R, G, B));
    canvas.rectangle(textWithRectangle.getRectangle());
    canvas.stroke();
}

pdfDoc.close();

SimplePositionTextEventListener。java（实现IEventListener）：

private List<SimpleTextWithRectangle> textWithRectangleList = new ArrayList<>();

private void renderText(TextRenderInfo renderInfo) {
    if (renderInfo.getText().trim().length() == 0)
        return;
    LineSegment ascent = renderInfo.getAscentLine();
    LineSegment descent = renderInfo.getDescentLine();

    float initX = descent.getStartPoint().get(0);
    float initY = descent.getStartPoint().get(1);
    float endX = ascent.getEndPoint().get(0);
    float endY = ascent.getEndPoint().get(1);

    Rectangle rectangle = new Rectangle(initX, initY, endX - initX, endY - initY);

    SimpleTextWithRectangle textWithRectangle = new SimpleTextWithRectangle(rectangle, renderInfo.getText());
    textWithRectangleList.add(textWithRectangle);
}

public List<SimpleTextWithRectangle> getResultantTextWithPosition() {
    return textWithRectangleList;
}

@Override
public void eventOccurred(IEventData data, EventType type) {
    renderText((TextRenderInfo) data);
}

@Override
public Set<EventType> getSupportedEvents() {
    return Collections.unmodifiableSet(new LinkedHashSet<>(Collections.singletonList(EventType.RENDER_TEXT)));
}

SimpleTextWithRectangle。JAVA

private Rectangle rectangle;
private String text;

public SimpleTextWithRectangle(Rectangle rectangle, String text) {
    this.rectangle = rectangle;
    this.text = text;
}

public Rectangle getRectangle() {
    return rectangle;
}

文件是：PDF文件

Answer 1

不正确的框坐标是iText 7 CMap处理中的错误的结果。

当解析类型0字体（例如GBK-EUC-H）的命名编码CMap时，使用该CMapEncoding构造函数的else分支：

public CMapEncoding(String cmap, String uniMap) {
    this.cmap = cmap;
    this.uniMap = uniMap;
    if (cmap.equals(PdfEncodings.IDENTITY_H) || cmap.equals(PdfEncodings.IDENTITY_V)) {
        cid2Uni = FontCache.getCid2UniCmap(uniMap);
        isDirect = true;
        this.codeSpaceRanges = IDENTITY_H_V_CODESPACE_RANGES;
    } else {
        cid2Code = FontCache.getCid2Byte(cmap);
        code2Cid = cid2Code.getReversMap();
        this.codeSpaceRanges = cid2Code.getCodeSpaceRanges();
    }
}

现在FontCache。getCid2Byte（cmap）使用CMapCidByte在以下位置构建映射：

public static CMapCidByte getCid2Byte(String cmap) {
    CMapCidByte cidByte = new CMapCidByte();
    return parseCmap(cmap, cidByte);
}

cmapcibyte（可能还有其他CMap类）的一个特点是，它存储映射逆：

private Map<Integer, byte[]> map = new HashMap<>();
[...]
void addChar(String mark, CMapObject code) {
    if (code.isNumber()) {
        byte[] ser = decodeStringToByte(mark);
        map.put((int)code.getValue(), ser);
    }
}

也许这样做是因为最常用的查找方向是相反的。只要原始映射是内射的，即所有键都映射到不同的值，这是可以的。

不幸的是，CMAP不需要注射。例如，对于GBK-EUC-H，我们有cidrange条目

<21> <7e> 814 

和

<aaa1> <aafe> 814 
<aba1> <abc0> 908 

因此，在导入此编码时，后面的映射会覆盖字符代码0x21的许多映射。。0x7e。

在手头的文档中，页脚文本中确实使用了编码为GBK-EUC-H的字体。因此，对于这种字体，许多单字节代码为0x21。。iText的字体信息中缺少0x7e。

这一系列代码以单间距字体对比例西文字符进行编码，尤其是替代代码0xaaa1。。0xaafe和0xaba1。。0xabc0编码的西文字符与等距字符相同。

在示例文档的页脚区域中，这些比例拉丁字符被使用。由于缺少映射，一些iText 7代码路径中的这些字符被替换字符符号替换（例如文本提取本身不返回西文字符，而是“”），在一些路径中，它们完全丢失（例如，当计算文本块的长度时，这些西文字符被忽略）。

因此，字符块的长度计算不正确，因此边界框的大小和位置都不正确。

这也解释了为什么每一行上错误放置的边界框从该行第一次出现西文字符时开始，以及为什么在西文字符最多的行上缺少最大的框大小。