GroupDocs.Comparison for Java 26.11 – نکات برجسته انتشار نوامبر 2026

ما خوشحالیم که انتشار GroupDocs.Comparison for Java 26.11 را اعلام می‌کنیم که از نوامبر 2026 در دسترس است. ویژگی اصلی این نسخه مقایسه تصویر مبتنی بر OCR است: اکنون می‌توان تصاویر را بر اساس متنی که در آن‌ها شناسایی می‌شود، نه بر اساس پیکسل‌ها، مقایسه کرد. مقایسه صفحات گسترده به‌طور کلی بازطراحی شده است — ردیف‌ها بر اساس محتوا مطابقت داده می‌شوند و مقایسه شیت‌های بزرگ در ثانیه‌ها به‌جای دقیقه‌ها انجام می‌شود. نتایج PDF اکنون از صفحه منبع چیدمان می‌شوند، همان‌طور که در GroupDocs.Comparison برای .NET است و مجموعه‌ای از اصلاحات شامل مقایسه متن، Word، ارائه و پیش‌نمایش HTML می‌شود.

چه چیزهای جدیدی در این انتشار وجود دارد

تغییرات رفتاری که قبل از ارتقا باید بررسی شوند

1. وابستگی جدید. POM منتشرشده یک وابستگی جدید به Aspose.OCR for Java اعلام می‌کند که فقط برای مقایسه OCR استفاده می‌شود. این وابستگی ONNX Runtime را همراه با کتابخانه‌های بومی می‌آورد. اگر از OCR استفاده نمی‌کنید می‌توانید آن را حذف کنید — تمام مقایسه‌های دیگر بدون آن کار می‌کنند (به چگونه به‌روزرسانی را دریافت کنیم مراجعه کنید).
2. تغییرات صفحه گسترده. وقتی ردیف‌ها اضافه یا حذف می‌شوند، مقایسه صفحه گسترده تغییرات متفاوت — و معمولاً بسیار کمتر — را گزارش می‌دهد، زیرا ردیف‌ها اکنون بر اساس محتوا مطابقت داده می‌شوند.
3. چیدمان PDF. نتایج PDF به‌صورت متفاوتی چیدمان می‌شوند: هر جزء در همان موقعیتی که در صفحه منبع بود می‌ماند.
4. ترتیب جایگزینی‌ها. در نتایج متن و PDF درون‌خطی، کلمه یا عبارت جایگزین‌شده اکنون ابتدا قدیمی و سپس جدید خوانده می‌شود.
5. حالت ارزیابی. فقط دو صفحه اول یک PDF در حالت ارزیابی مقایسه می‌شوند، همان‌طور که در GroupDocs.Comparison برای .NET است.

ویژگی جدید: مقایسه تصاویر بر اساس متن شناسایی‌شده (OCR)

اکنون می‌توان یک تصویر را بر اساس متنی که Aspose.OCR در آن می‌خواند، نه بر اساس پیکسل‌هایش، مقایسه کرد. این گزینه برای اسکن‌ها، عکس‌ها و اسکرین‌شات‌های اسناد مناسب است، جایی که همان متن هرگز پیکسل‌های یکسانی تولید نمی‌کند — صفحه‌ای که با کمی جابجایی یا با کیفیت متفاوت دوباره اسکن می‌شود دیگر در همه‌جا تفاوت نشان نمی‌دهد.

try (Comparer comparer = new Comparer("source.png")) {
    comparer.add("target.png");

    OcrOptions ocr = new OcrOptions();
    ocr.setEnabled(true);
    ocr.setDisplayMode(OcrDisplayMode.SIDE_BY_SIDE);  // or TEXT

    CompareOptions options = new CompareOptions();
    options.setOcr(ocr);
    comparer.compare("result.png", options);

    for (ChangeInfo change : comparer.getChanges()) {
        OcrChangeInfo ocrChange = (OcrChangeInfo) change;
        System.out.println(change.getText() + ": confidence " + ocrChange.getConfidence()
                + ", " + ocrChange.getSourceBoxes().length + " box(es) on the source");
    }
}

آنچه می‌توانید کنترل کنید:

• حالت نمایش. SIDE_BY_SIDE (پیش‌فرض) دو تصویر را کنار هم نشان می‌دهد و کلمات تغییر یافته را در جعبه می‌گیرد. TEXT فقط متن شناسایی‌شده را نشان می‌دهد و تغییرات در آن علامت‌گذاری می‌شوند.
• جزئیات تغییر. هر تغییر یک OcrChangeInfo است که جعبه‌های پوشش داده‌شده بر روی هر دو تصویر (getSourceBoxes(), getTargetBoxes()) و میزان اطمینان شناسایی (getConfidence()) را دارد. جعبه‌ها در حالت TEXT خالی هستند.
• زبان. setLanguage(OcrLanguage) زبان یا اسکریپت را انتخاب می‌کند؛ پیش‌فرض LATIN است. زبان‌های دیگر نیاز به مدل شناسایی دارند که در اولین استفاده دانلود می‌شود. setDisableResourceDownloads(true) و setResourcesPath(String) شناسایی را به مدل‌های موجود روی دیسک محدود می‌کند.

Aspose.OCR for Java باید در مسیر کلاس‌پث باشد. این کتابخانه وابستگی POM منتشرشده است، بخشی از jar نیست. بدون آن، مقایسه OCR با پیغامی که کتابخانه گمشده را نام می‌برد، شکست می‌خورد.

مقایسه صفحه گسترده

ردیف‌ها بر اساس محتوا مطابقت داده می‌شوند

قبلاً ردیف‌ها با ردیف‌ای در همان اندیس در کتاب‌کار دیگر جفت می‌شدند. وقتی ردیفی اضافه یا حذف می‌شد، تمام ردیف‌های پس از آن به‌عنوان بازنویسی گزارش می‌شدند. برای مثال، یک کتاب‌کار شش ردیفی که یکی از آن‌ها حذف شده بود 91 تغییر تولید می‌کرد؛ اکنون فقط 8 تغییر تولید می‌کند — شش سلول ردیف حذف‌شده که در جای خود علامت‌گذاری شده‌اند و شمارش ردیف‌ها در شیت خلاصه.

اکنون ردیف‌ها و ستون‌ها بر اساس محتوای سلول‌هایشان هم‌راستا می‌شوند. ردیف‌هایی که در هر دو فایل یکسان هستند مستقیماً جفت می‌شوند و فقط آنچه بین آن‌ها قرار دارد هم‌راستا می‌شود. تعداد تغییرات گزارش‌شده برای چنین فایل‌هایی با نسخه‌های قبلی متفاوت است.

ثانیه‌ها به‌جای دقیقه‌ها

مقایسه صفحه گسترده حتی برای فایل‌های یکسان می‌توانست دقیقه‌ها طول بکشد: دو شیت 200 × 20 یکسان 2.5 دقیقه زمان می‌برد. اکنون زیر یک ثانیه (چند ثانیه برای اولین مقایسه پس از راه‌اندازی JVM) زمان می‌برد و یک شیت 400 × 20 با یک ردیف حذف‌شده حدود 7 ثانیه زمان می‌گیرد.

تفاوت کلمه‌ای پشت هر مقایسه بازنویسی شد و همان نتیجه قبلی را با سرعت بسیار بیشتر برمی‌گرداند — بنابراین مقایسه Word، PDF و متن نیز بهره‌مند می‌شوند. ردیف‌ها و ستون‌های یکسان بدون امتیازدهی جفت می‌شوند، بنابراین دو شیت یکسان اصلاً هم‌راستا نمی‌شوند.

ارتفاع ردیف‌ها، نوع عدد و رنگ برجسته

• ردیف‌هایی که ارتفاع خاص خود را ندارند اکنون برای محتوایشان در نتیجه تنظیم می‌شوند، بنابراین سلول‌های بسته‌شده و با فونت بزرگ دیگر بریده نمی‌شوند. ردیف‌هایی که ارتفاع صریح دارند همان ارتفاع را حفظ می‌کنند.
• اعداد و تاریخ‌های بدون تغییر نوع خود را حفظ می‌کنند و به‌عنوان متن بازنویسی نمی‌شوند. سلول‌های فرمول همچنان با مقادیر محاسبه‌شده‌شان نوشته می‌شوند.
• StyleSettings.setHighlightColor اکنون پس‌زمینه سلول‌های تغییر یافته را پر می‌کند:

StyleSettings deleted = new StyleSettings();
deleted.setHighlightColor(Color.PINK);

CompareOptions options = new CompareOptions();
options.setDeletedItemStyle(deleted);

نتایج PDF

چیدمان از صفحه منبع

موتور PDF اکنون نتایج را همان‌طور که GroupDocs.Comparison برای .NET انجام می‌دهد، چیدمان می‌کند:

• هر جزء نتیجه در همان موقعیتی که در صفحه منبع بود قرار می‌گیرد؛ تصاویر در مختصات خود قرار می‌گیرند و گرافیک‌های برداری صفحه منتقل می‌شوند؛
• جدول شبکه خود را می‌کشد و متن هر سلول در لبهٔ خود پیچ می‌شود، شامل سلول‌های ادغام‌شده؛
• خطوط به‌صورت پاراگراف بر اساس فاصله بین خطوط پایه گروه‌بندی می‌شوند و حاشیه‌های صفحه از خود صفحه گرفته می‌شود؛
• صفحاتی که در هر دو سند یکسان هستند می‌توانند در هر جای سند یافت شوند، نه فقط در ابتدا، و دوباره مقایسه نمی‌شوند.

نتایج نسبت به نسخه‌های قبلی متفاوت به‌نظر می‌رسند. محتوای حذف‌شده در جایی که در صفحه منبع قرار داشته رسم می‌شود؛ جایی که هدف محتوای دیگری دارد، دو محتوا می‌توانند هم‌پوشانی داشته باشند.

اصلاحات کوچک

• عبارات جایگزین‌شده. جایگزینی چند کلمه به‌صورت جفت‌جفت رسم می‌شد، به‌طوری که «Richard McClintock» به «Vasily Pupkin» تبدیل می‌شد «Vasily Richard Pupkin McClintock». نتیجه درون‌خطی اکنون ابتدا عبارت قدیمی و سپس جدید را نشان می‌دهد.
• خطوط کمی طولانی‌تر. در نتیجه درون‌خطی، خطی که یک جایگزینی یک کلمه به آن اضافه کرده بود دیگر کلمهٔ آخر خود را به خط جدید منتقل نمی‌کند.
• شبکه جدول‌ها. حاشیهٔ جدول که رنگ آن قابل تشخیص نبود دیگر به‌صورت سیاه بر روی حاشیه‌های اصلی جدول کشیده نمی‌شود.
• صفحات رسم‌شده از طریق فرم‌ها. صفحاتی که همه چیز را از طریق فرم‌ها رسم می‌کردند (مانند صفحه گسترده‌ای که به PDF ذخیره شده)، قبلاً به‌عنوان بدون تغییر در نظر گرفته می‌شدند. اکنون فرم‌ها نیز مقایسه می‌شوند و تغییراتشان گزارش می‌شود.
• خطوط خالی. خطوطی که فقط شامل فضا هستند دیگر به‌عنوان تغییر گزارش نمی‌شوند.
• فهرست‌های مطالب. شماره صفحهٔ خط فهرست مطالب تغییر یافته در همان خط خود باقی می‌ماند.

سایر اصلاحات

متن درون شکست خط

ویرایشی که طول یا کوتاهی یک خط از فایل متنی را تغییر می‌دهد، کلمات را پس از آن به‌سرخط‌های دیگر می‌برد. هنگام مقایسه خط به خط، این کلمات به‌عنوان حذف از یک خط و درج در خط بعدی گزارش می‌شدند. اکنون خطوط به‌هم پیوسته می‌شوند تا تغییرات کمتر شود، به‌عنوان یک اجرا مقایسه می‌شوند و بر روی خطوط هدف بازچیدمان می‌شوند. یک جایگزینی ابتدا قدیمی و سپس جدید گزارش می‌شود و نمای HTML مقایسهٔ متن تغییرات پذیرفته‌شده و ردشده را همانند نتیجهٔ متنی اعمال می‌کند. مقایسهٔ یک فایل با چند هدف همچنان خط به خط انجام می‌شود.

Word: ستون یا ردیف جدول خالی شده

وقتی ستونی یا ردیفی از جدول خالی می‌شد، به‌عنوان حذف و سپس یک ستون یا ردیف خالی به‌عنوان درج گزارش می‌شد و سلول‌های پس از آن جابجا می‌شدند. اکنون در جای خود می‌ماند و محتوای حذف‌شده آن گزارش می‌شود.

ارائه‌ها: منابع خارجی

LoadOptions.setSkipExternalResources و setWhitelistedResources که در 26.10 اضافه شده بودند، در ارائه‌ها اثر نداشتند. اکنون برای ارائه‌ها همان‌طور که برای Word و اسناد HTML اعمال می‌شوند، عمل می‌کنند و ارائهٔ نتیجه هرگز منابع خارجی را بارگیری نمی‌کند. تصویری که بارگیری نشد به‌عنوان تصویر خالی مقایسه می‌شود.

پیش‌نمایش HTML

صفحات پیش‌نمایش یک سند HTML به‌صورت نام‌های ثابت در پوشهٔ موقت رندر می‌شدند، به‌طوری که دو پیش‌نمایش همزمان صفحات یکدیگر را بازنویسی می‌کردند و شمارهٔ صفحات درخواست‌شده نادیده گرفته می‌شد. اکنون صفحات در حافظه رندر می‌شوند، فقط صفحات درخواست‌شده برگردانده می‌شوند و روی پس‌زمینهٔ سفید رندر می‌شوند نه پس‌زمینهٔ شفاف.

کتابخانه‌های Aspose به‌روز شدند

کتابخانه‌ها همان‌طور که قبلاً در jar بسته‌بندی شده‌اند، باقی می‌مانند. Aspose.OCR 26.10.0 جدید است و به‌عنوان وابستگی در POM می‌آید.

چگونه به‌روزرسانی را دریافت کنیم

Maven

مخزن GroupDocs و وابستگی را به pom.xml خود اضافه کنید:

<repositories>
    <repository>
        <id>groupdocs-artifacts-repository</id>
        <name>GroupDocs Artifacts Repository</name>
        <url>https://releases.groupdocs.com/java/repo/</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>com.groupdocs</groupId>
        <artifactId>groupdocs-comparison</artifactId>
        <version>26.11</version>
    </dependency>
</dependencies>

اگر از مقایسه OCR استفاده نمی‌کنید می‌توانید Aspose.OCR و کتابخانه‌های بومی آن را حذف کنید:

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-comparison</artifactId>
    <version>26.11</version>
    <exclusions>
        <exclusion>
            <groupId>com.aspose</groupId>
            <artifactId>aspose-ocr</artifactId>
        </exclusion>
    </exclusions>
</dependency>

دانلود مستقیم

JAR را از صفحهٔ دانلود GroupDocs.Comparison for Java 26.11 دریافت کنید.

منابع

• یادداشت‌های کامل انتشار
• مستندات
• نمونه‌های GroupDocs.Comparison for Java در GitHub
• انجمن پشتیبانی رایگان GroupDocs.Comparison