Aspose Imaging generating blank pdf for corrupted xif file

Hi Team,

We are creating pdf file for files which has application type as “Tagged Image File Format” using below code.

public static void convertTifToPdf(String inputFilePath, String outputFilePath) {
	try (Image image = Image.load(inputFilePath)) {
		image.save(outputFilePath, new PdfOptions());
	}
}

But for the attached file which seems to be corrupted and has application type as “Tagged Image File Format”, blank pdf file is getting generated instead of throwing any exception. Also, the image object from above code doesn’t provide any methods to identify if the image generated is blank image or not. I tried using methods like getSize(), getWidth() or getHeight() which seems to give me the size of the file or width and heights of the file, but it didn’t give concreted functionality to check the file is blank or not. Can you please let us know how we could identify if the file generated is blank file or if there can be any exceptions thrown during such scenario?

@ShubhamYerpude

To address the issue of generating a blank PDF from a corrupted TIFF file, you can implement a data recovery mechanism when loading the TIFF image. This will enable you to recover as much data as possible from the corrupted file, preventing the generation of a blank PDF.

Cause: The problem arises when attempting to load a corrupted TIFF file, which can lead to incomplete data being processed and result in a blank PDF.

Solution: Modify your code to include data recovery options using the LoadOptions class. This allows you to specify a recovery mode that attempts to salvage data from the corrupted file.

Here’s how you can implement this:

import com.aspose.imaging.*;
import com.aspose.imaging.fileformats.tiff.*;
import com.aspose.imaging.imageoptions.*;

public static void convertTifToPdf(String inputFilePath, String outputFilePath) {
    LoadOptions loadOptions = new LoadOptions();
    loadOptions.setDataRecoveryMode(DataRecoveryMode.ConsistentRecover); // or MaximalRecover
    loadOptions.setDataBackgroundColor(Color.getRed()); // Set a background color for recovery

    try (TiffImage image = (TiffImage) Image.load(inputFilePath, loadOptions)) {
        image.save(outputFilePath, new PdfOptions());
    } catch (Exception e) {
        System.out.println("Error processing the image: " + e.getMessage());
    }
}

In this code, you can choose between ConsistentRecover and MaximalRecover based on your specific needs. Additionally, setting a background color can help visualize any recovered data.

Next Steps: Implement the modified code in your project and test it with your corrupted TIFF files. If you still encounter issues, consider checking the integrity of the TIFF file before processing.

This approach should effectively help you avoid generating a blank PDF when dealing with corrupted TIFF files. If you have any further questions or need additional assistance, feel free to ask!

Instead of recovering data, is there a way to explicitly throw exceptions or identifying blank pdf file in such scenarios.

@ShubhamYerpude Hello! Thank you for your interest in our product. Could you please provide a sample file so we can investigate the issue further?

BET.PC.00155450.0.zip (20.5 KB)

Attached sample file for which it generates blank pdf file.

@ShubhamYerpude
Aspose.Imaging does not support XIF image files.
Please, look at the supported file formats table.

Can you please create a new feature enhancement for supporting this file format.

@ShubhamYerpude
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their implementation according to the terms mentioned in Free Support Policies.

Issue ID(s): IMAGINGNET-7767

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

@ShubhamYerpude I have created a corresponding task in our system. However, support for this format is not planned in the foreseeable future.

@Alexey.Karpenko can you please file another ticket in your system for the ability to have an error generated? I understand that you may not support this file and in that case your software should throw an error stating unsupported or another message. Right now, nothing happens. This should not be the case.

@ShubhamYerpude
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): IMAGINGNET-7802

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.